Dette blogindlæg blev offentliggjort på Hortonworks.com før fusionen med Cloudera. Nogle links, ressourcer eller referencer er muligvis ikke længere nøjagtige.
I 2016 udgav vi den anden version v1.0.1 af Spark HBase Connector (SHC). I denne blog vil vi gennemgå de vigtigste funktioner, vi har implementeret i år.
Support Phoenix-koder
SHC kan bruges til at skrive data ud til HBase-klyngen til yderligere downstream-behandling. Den understøtter Avro-serialisering til input- og outputdata og er standard til en brugerdefineret serialisering ved hjælp af en simpel indbygget kodningsmekanisme. Ved læsning af inputdata presser SHC filtre ned til HBase for effektive scanninger af data. I betragtning af Phoenix-datas popularitet i HBase, forekommer det naturligt at understøtte Phoenix-data som input til HBase ud over Avro-data. Det ser også ud til, at misligholdelse af den simple native binære kodning er modtagelig for fremtidige ændringer og er en risiko for brugere, der skriver data fra SHC til HBase. For eksempel, med SHC fremadrettet, skal bagudkompatibilitet håndteres korrekt. Så standarden, SHC skal ændres til et mere standard og gennemtestet format som Phoenix.
For den sammensatte nøgleunderstøttelse skulle værdilængden af hver dimension forud for denne funktion være fast - med undtagelse af den sidste dimension af den sammensatte nøgle. Denne begrænsning er blevet fjernet af Phoenix coder. Hvis brugere i øjeblikket vælger Phoenix som datakoder, behøver de ikke at angive længden af hver del af den sammensatte nøgle i kataloget.
Da Phoenix er standardkoderen, er den eneste ændring for brugerne, at hvis de vil bruge PrimitiveType som datakoder, skal de angive "tableCoder":"PrimitiveType" i deres kataloger for at meddele SHC, at de vil bruge PrimitiveType i stedet for. af Phoenix som "tableCoder".
def catalog =s”””{
|”table”:{“namespace”:”default”, “name”:”table1″, “tableCoder”:”PrimitiveType”},
|”rowkey ”:”key”,
|”columns”:{
|”col0″:{“cf”:”rowkey”, “col”:”key”, “type”:”string”} ,
|”col1″:{“cf”:”cf1″, “col”:”col1″, “type”:”boolean”},
|”col2″:{“cf”:”cf2″, “col”:”col2″, “type”:”double”},
|”col3″:{“cf”:”cf3″, “col”:”col3″, “type” :”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”:”streng”},
|”col8″:{“cf”:”cf8″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
Cache Spark HBase-forbindelser
SHC cachelagde ikke forbindelsesobjekter til HBase før. Specifikt blev opkaldet til 'ConnectionFactory.createConnection' foretaget hver gang, når SHC skulle besøge HBase-tabeller og -regioner. Brugere kunne se dette blot ved at se på eksekveringsloggene og observere dyrepasserforbindelser, der etableres for hver anmodning. I dokumentationen for interface Connection står der, at oprettelsen af forbindelsen er en tung operation, og forbindelsesimplementeringerne er trådsikre. For langlivede processer ville det derfor være meget nyttigt for SHC at holde en forbindelse cachelagret. Med denne funktion reducerer SHC antallet af oprettede forbindelser drastisk og forbedrer i høj grad dens ydeevne i processen.
Støt duplikerede kolonnefamilier
SHC har understøttet støtte til duplikerede kolonnefamilier. Nu kan brugere definere deres kataloger sådan her:
def catalog =s”””{
|”table”:{“namespace”:”default”, “name”:”table1″, “tableCoder”:”PrimitiveType”},
|”rowkey ”:”key”,
|”columns”:{
|”col0″:{“cf”:”rowkey”, “col”:”key”, “type”:”string”} ,
|”col1″:{“cf”:”cf1″, “col”:”col1″, “type”:”boolean”},
|”col2″:{“cf”:”cf1″, “col”:”col2″, “type”:”dobbelt”},
|”col3″:{“cf”:”cf1″, “col”:”col3″, “type” :”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”:”streng”},
|”col8″:{“cf”:”cf3″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
I katalogdefinitionen ovenfor har kolonne 'col0', 'col1' og 'col2' den samme kolonnefamilie 'cf1'.
Brug Spark UnhandledFilters API
SHC har også implementeret Spark API unhandledFilters, som er en effektiv optimering. Denne API fortæller Spark om filtre, som SHC ikke implementerer i modsætning til at returnere alle filtrene. Den tidligere adfærd, i dette tilfælde, var at genanvende alle filtrene, når data er trukket i Spark. Dette burde være idempotent, så det ændrer ikke nogen data, men kan være dyrt, hvis filtrene er komplicerede.
SHC-fællesskab
SHC-fællesskabet er større og mere indflydelsesrigt end for et år siden. I 2016 holdt vi foredrag i Hadoop Summit og i HBase/Spark meetup og skrev detaljerede blogs. Med antallet af SHC-brugere stigende, modtager vi et højere antal brugerspørgsmål. Vi er meget glade for at se øget brug af SHC, og hvis du har nogen tanker om, hvordan du kan forbedre det yderligere, bedes du give os feedback via Hortonworks Community Connection.
ANKENDELSE
Vi vil gerne takke Bloomberg-teamet for at vejlede os i dette arbejde og også hjælpe os med at validere dette arbejde. Vi vil også gerne takke HBase-fællesskabet for at give deres feedback og gøre dette bedre. Endelig har dette arbejde udnyttet erfaringerne fra tidligere Spark HBase-integrationer, og vi vil gerne takke deres udviklere for at have banet vejen.
REFERENCE:
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/