Det här blogginlägget publicerades på Hortonworks.com före sammanslagningen med Cloudera. Vissa länkar, resurser eller referenser kanske inte längre är korrekta.
Under 2016 publicerade vi den andra versionen v1.0.1 av Spark HBase Connector (SHC). I den här bloggen kommer vi att gå igenom de viktigaste funktionerna som vi har implementerat i år.
Stöd Phoenix-kodare
SHC kan användas för att skriva ut data till HBase-klustret för vidare nedströmsbehandling. Den stöder Avro-serialisering för in- och utdata och ställer in som standard på en anpassad serialisering med en enkel inbyggd kodningsmekanism. När SHC läser indata trycker SHC ned filter till HBase för effektiv genomsökning av data. Med tanke på Phoenix-datas popularitet i HBase, verkar det naturligt att stödja Phoenix-data som input till HBase utöver Avro-data. Att förinställa sig på den enkla inbyggda binära kodningen verkar också vara mottaglig för framtida förändringar och är en risk för användare som skriver data från SHC till HBase. Till exempel, med SHC framåt, måste bakåtkompatibilitet hanteras korrekt. Så standarden, SHC måste ändras till ett mer standardiserat och väl testat format som Phoenix.
För stöd för sammansatt nyckel, innan denna funktion, krävdes att värdelängden för varje dimension var fixerad – med undantag för sista dimensionen av sammansatt nyckel. Denna begränsning har tagits bort av Phoenix-kodaren. För närvarande, om användare väljer Phoenix som datakodare, behöver de inte ange längden på varje del av den sammansatta nyckeln i katalogen.
Eftersom Phoenix är standardkodaren är den enda ändringen för användarna att om de vill använda PrimitiveType som datakodare måste de ange "tableCoder":"PrimitiveType" i sina kataloger för att meddela SHC att de vill använda PrimitiveType istället av Phoenix som "tableCoder".
def catalog =s”””{
|”table”:{“namespace”:”default”, “name”:”table1″, “tableCoder”:”PrimitiveType”},
|”radknapp ”:”key”,
|”columns”:{
|”col0″:{“cf”:”rowkey”, “col”:”key”, “typ”:”string”} ,
|”col1″:{“cf”:”cf1″, “col”:”col1″, “type”:”boolean”},
|”col2″:{“cf”:”cf2″, “col”:”col2″, “type”:”dubbel”},
|”col3″:{“cf”:”cf3″, “col”:”col3″, “typ” :”float”},
|”col4″:{“cf”:”cf4″, “col”:”col4″, “type”:”int”},
|”col5″:{“cf”:”cf5″, “col”:”col5″, “type”:”bigint”},
|”col6″:{“cf”:”cf6″, “col”:”col6” ″, “type”:”smallint”},
|”col7″:{“cf”:”cf7″, “col”:”col7″, “type”:”string”},
|”col8″:{“cf”:”cf8″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
Cache Spark HBase Connections
SHC cacheade inte anslutningsobjekt till HBase tidigare. Specifikt anropet till 'ConnectionFactory.createConnection' gjordes varje gång SHC behövde besöka HBase-tabeller och -regioner. Användare kunde se detta helt enkelt genom att titta på exekutorloggarna och observera djurskötareanslutningar som upprättas för varje begäran. I dokumentationen för interface Connection står det att anslutningsskapandet är en tung operation och anslutningsimplementeringarna är trådsäkra. För långlivade processer skulle det därför vara mycket användbart för SHC att hålla en anslutning cachad. Med den här funktionen minskar SHC antalet skapade anslutningar drastiskt och förbättrar dess prestanda avsevärt i processen.
Stöd dubblerade kolumnfamiljer
SHC har stöd för duplicerade kolumnfamiljer. Nu kan användare definiera sina kataloger så här:
def catalog =s”””{
|”table”:{“namespace”:”default”, “name”:”table1″, “tableCoder”:”PrimitiveType”},
|”radknapp ”:”key”,
|”columns”:{
|”col0″:{“cf”:”rowkey”, “col”:”key”, “typ”:”string”} ,
|”col1″:{“cf”:”cf1″, “col”:”col1″, “type”:”boolean”},
|”col2″:{“cf”:”cf1″, “col”:”col2″, “type”:”dubbel”},
|”col3″:{“cf”:”cf1″, “col”:”col3″, “typ” :”float”},
|”col4″:{“cf”:”cf2″, “col”:”col4″, “type”:”int”},
|”col5″:{“cf”:”cf2″, “col”:”col5″, “type”:”bigint”},
|”col6″:{“cf”:”cf3″, “col”:”col6” ″, “type”:”smallint”},
|”col7″:{“cf”:”cf3″, “col”:”col7″, “type”:”string”},
|”col8″:{“cf”:”cf3″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
I katalogdefinitionen ovan har kolumn 'col0', 'col1' och 'col2' samma kolumnfamilj 'cf1'.
Använd Spark UnhandledFilters API
SHC har även implementerat Spark API unhandledFilters, vilket är en effektiv optimering. Detta API berättar för Spark om filter som SHC inte implementerar i motsats till att returnera alla filter. Det tidigare beteendet, i det här fallet, var att återanvända alla filter när data har hämtats i Spark. Detta borde vara idempotent, så det ändrar ingen data, men kan bli dyrt om filtren är komplicerade.
SHC Community
SHC-gemenskapen är större och mer inflytelserik än för ett år sedan. Under 2016 höll vi föredrag i Hadoop Summit och i HBase/Spark Meetup och skrev detaljerade bloggar. I takt med att antalet SHC-användare ökar, får vi ett högre antal användarfrågor. Vi är mycket glada över att se ökad användning av SHC och om du har några tankar om hur du kan förbättra det ytterligare, vänligen ge oss feedback via Hortonworks Community Connection.
BEKRÄFTELSE
Vi vill tacka Bloomberg-teamet för att vägleda oss i detta arbete och även hjälpa oss att validera detta arbete. Vi vill också tacka HBase-communityt för att de har gett feedback och gjort detta bättre. Slutligen har detta arbete utnyttjat lärdomarna från tidigare Spark HBase-integrationer och vi vill tacka deras utvecklare för att de banade vägen.
REFERENS:
SHC: https://github.com/hortonworks-spark/shc
Apache HBase: https://hbase.apache.org/
Apache Spark: http://spark.apache.org/
Apache Phoenix: https://phoenix.apache.org/