Tento blogový příspěvek byl publikován na Hortonworks.com před sloučením s Cloudera. Některé odkazy, zdroje nebo reference již nemusí být přesné.
V roce 2016 jsme zveřejnili druhou verzi v1.0.1 Spark HBase Connector (SHC). V tomto blogu si projdeme hlavní funkce, které jsme letos implementovali.
Podpora kodéru Phoenix
SHC lze použít k zápisu dat do clusteru HBase pro další následné zpracování. Podporuje Avro serializaci pro vstupní a výstupní data a výchozí nastavení je vlastní serializace pomocí jednoduchého mechanismu nativního kódování. Při čtení vstupních dat SHC odsune filtry do HBase pro efektivní skenování dat. Vzhledem k popularitě dat Phoenix v HBase se zdá přirozené podporovat data Phoenix jako vstup do HBase kromě dat Avro. Také výchozí nastavení jednoduchého nativního binárního kódování se zdá být náchylné k budoucím změnám a představuje riziko pro uživatele, kteří zapisují data z SHC do HBase. Například u SHC vpřed je třeba správně řešit zpětnou kompatibilitu. Výchozí SHC se tedy musí změnit na standardnější a dobře otestovaný formát, jako je Phoenix.
U složeného klíče bylo před touto funkcí požadováno, aby byla pevně stanovena délka hodnoty každého rozměru – s výjimkou posledního rozměru složeného klíče. Toto omezení bylo odstraněno programátorem Phoenix. V současné době, pokud uživatelé zvolí Phoenix jako datový kodér, nemusí v katalogu zadávat délku každé části složeného klíče.
Protože Phoenix je výchozím kodérem, jedinou změnou pro uživatele je, že pokud chtějí jako kodér dat použít PrimitiveType, musí ve svých katalozích zadat „tableCoder“:“PrimitiveType“, aby upozornili SHC, že chtějí místo toho použít PrimitiveType. společnosti Phoenix jako „tableCoder“.
def Catalog =s”””{
|”table”:{”namespace”:”default”, “name”:”table1″, “tableCoder”:”PrimitiveType”},
|”rowkey ”:”key”,
|”sloupce”:{
|”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”:”string”},
|”col8″:{”cf”:”cf8″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
Cache Spark HBase Connections
SHC dříve neukládalo do mezipaměti objekty připojení k HBase. Konkrétně bylo volání „ConnectionFactory.createConnection“ provedeno pokaždé, když SHC potřebovalo navštívit tabulky a regiony HBase. Uživatelé to mohli vidět jednoduše tím, že se podívali do protokolů exekutorů a pozorovali spojení chovatelů, která byla navázána pro každý požadavek. V dokumentaci rozhraní Connection se uvádí, že vytvoření připojení je náročná operace a implementace připojení jsou bezpečné pro vlákna. Pro procesy s dlouhou životností by tedy bylo velmi užitečné, aby SHC uchovalo připojení v mezipaměti. Díky této funkci SHC drasticky snižuje počet vytvořených připojení a výrazně zlepšuje svůj výkon v tomto procesu.
Podpora duplicitních rodin sloupců
SHC podporuje podporu duplicitních rodin sloupců. Nyní mohou uživatelé definovat své katalogy takto:
def Catalog =s”””{
|”table”:{”namespace”:”default”, “name”:”table1″, “tableCoder”:”PrimitiveType”},
|”rowkey ”:”key”,
|”sloupce”:{
|”col0″:{”cf”:”rowkey”, “col”:”key”, “type”:”string”} ,
|”col1″:{“cf”:”cf1″, “col”:”col1″, “type”:”boolean”},
|”col2″:{”cf”:”cf1″, “col”:”col2″, “type”:”double”},
|”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”:”string”},
|”col8″:{”cf”:”cf3″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
Ve výše uvedené definici katalogu mají sloupce ‚col0‘, ‚col1‘ a ‚col2‘ stejnou rodinu sloupců ‚cf1‘.
Použijte rozhraní Spark UnhandledFilters API
SHC také implementovalo Spark API unhandledFilters, což je efektivní optimalizace. Toto API říká Sparku o filtrech, které SHC neimplementuje, na rozdíl od vracení všech filtrů. Předchozím chováním v tomto případě bylo znovu použít všechny filtry, jakmile jsou data načtena ve Sparku. To by mělo být idempotentní, takže nemění žádná data, ale může být drahé, pokud jsou filtry složité.
Komunita SHC
Komunita SHC je větší a vlivnější než před rokem. V roce 2016 jsme vedli přednášky na Hadoop Summit a na setkání HBase/Spark a psali podrobné blogy. S rostoucím počtem uživatelů SHC dostáváme stále větší počet uživatelských dotazů. Jsme velmi rádi, že jsme svědky zvýšeného přijetí SHC, a pokud máte nějaké nápady, jak jej dále vylepšit, poskytněte nám zpětnou vazbu prostřednictvím Hortonworks Community Connection.
PODĚKOVÁNÍ
Chceme poděkovat týmu Bloomberg za to, že nás v této práci vedl a také nám pomohl tuto práci ověřit. Chceme také poděkovat komunitě HBase za poskytnutí zpětné vazby a zlepšení. A konečně, tato práce využila lekce z dřívějších integrací Spark HBase a chceme poděkovat jejich vývojářům za vydláždění cesty.
ODKAZ:
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/