Тази публикация в блога е публикувана на Hortonworks.com преди сливането с Cloudera. Някои връзки, ресурси или препратки може вече да не са точни.
През 2016 г. публикувахме втората версия v1.0.1 на Spark HBase Connector (SHC). В този блог ще разгледаме основните функции, които внедрихме тази година.
Поддръжка на Phoenix кодер
SHC може да се използва за запис на данни в HBase клъстер за по-нататъшна обработка надолу по веригата. Той поддържа сериализация на Avro за входни и изходни данни и по подразбиране е персонализирана сериализация, използвайки прост механизъм за естествено кодиране. Когато чете входните данни, SHC изтласква филтрите към HBase за ефективно сканиране на данни. Като се има предвид популярността на данните от Phoenix в HBase, изглежда естествено да се поддържат данни от Phoenix като вход към HBase в допълнение към данните от Avro. Също така, неизпълнението на простото естествено двоично кодиране изглежда податливо на бъдещи промени и представлява риск за потребителите, които записват данни от SHC в HBase. Например, когато SHC върви напред, обратната съвместимост трябва да се обработва правилно. Така че по подразбиране SHC трябва да се промени на по-стандартен и добре тестван формат като Phoenix.
За поддръжката на съставен ключ преди тази функция се изискваше да бъде фиксирана дължината на стойността на всяко измерение – с изключение на последното измерение на съставния ключ. Това ограничение е премахнато от Phoenix coder. Понастоящем, ако потребителите изберат Phoenix като кодер на данни, те не трябва да посочват дължината на всяка част от съставния ключ в каталога.
Тъй като Phoenix е кодерът по подразбиране, единствената промяна за потребителите е, че ако искат да използват PrimitiveType като кодер на данни, те трябва да посочат “tableCoder”:”PrimitiveType” в своите каталози, за да уведомят SHC, че искат да използват PrimitiveType вместо това на Phoenix като „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”:”string”},
|”col8″:{“cf”:”cf8″, “col”:”col8″, “type”:”tinyint”}
|}
|}”””.stripMargin
Cache Spark HBase Connections
SHC не кешира обекти за връзка към HBase преди. По-конкретно, извикването към „ConnectionFactory.createConnection“ се извършваше всеки път, когато SHC трябваше да посети HBase таблици и региони. Потребителите могат да видят това, просто като гледат регистрационните файлове на изпълнителя и наблюдават връзките на zookeeper, които се установяват за всяка заявка. В документацията на интерфейса Connection се казва, че създаването на връзката е тежка операция и реализациите на връзката са безопасни за нишки. Следователно, за дълготрайни процеси, би било много полезно за SHC да поддържа кеширана връзка. С тази функция SHC намалява драстично броя на създадените връзки и значително подобрява производителността си в процеса.
Поддръжка на дублирани семейства колони
SHC поддържа поддръжка на дублирани семейства колони. Сега потребителите могат да дефинират своите каталози по следния начин:
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”:”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
В дефиницията на каталога по-горе колоните „col0“, „col1“ и „col2“ имат едно и също семейство колони „cf1“.
Използвайте API на Spark UnhandledFilters
SHC също така внедри Spark API unhandledFilters, което е ефективна оптимизация. Този API казва на Spark за филтрите, които SHC не прилага, за разлика от връщането на всички филтри. Предишното поведение в този случай беше повторното прилагане на всички филтри, след като данните бъдат изтеглени в Spark. Това трябва да е идемпотентно, така че не променя никакви данни, но може да бъде скъпо, ако филтрите са сложни.
SHC общност
SHC общността е по-голяма и по-влиятелна от преди една година. През 2016 г. изнесохме лекции в Hadoop Summit и HBase/Spark среща и написахме подробни блогове. С увеличаването на броя на потребителите на SHC получаваме по-голям брой потребителски въпроси. Много се радваме да видим засилено приемане на SHC и ако имате някакви мисли за това как да го подобрим допълнително, моля, изпратете ни обратна връзка чрез Hortonworks Community Connection.
ПРИЗНАНИЕ
Искаме да благодарим на екипа на Bloomberg, че ни напътства в тази работа и също така ни помага да потвърдим тази работа. Също така искаме да благодарим на общността на HBase, че ни предостави обратна връзка и направи това по-добро. И накрая, тази работа използва уроците от по-ранните интеграции на Spark HBase и искаме да благодарим на техните разработчици за проправянето на пътя.
СПРАВКА:
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/
