Ten wpis na blogu został opublikowany na Hortonworks.com przed fuzją z Cloudera. Niektóre linki, zasoby lub odniesienia mogą nie być już dokładne.
W 2016 roku opublikowaliśmy drugą wersję v1.0.1 Spark HBase Connector (SHC). W tym blogu omówimy główne funkcje, które wdrożyliśmy w tym roku.
Obsługa kodera Phoenix
SHC może służyć do zapisywania danych do klastra HBase w celu dalszego przetwarzania. Obsługuje serializację Avro dla danych wejściowych i wyjściowych oraz domyślnie używa niestandardowej serializacji przy użyciu prostego natywnego mechanizmu kodowania. Podczas odczytu danych wejściowych SHC przesuwa filtry do HBase w celu wydajnego skanowania danych. Biorąc pod uwagę popularność danych Phoenix w HBase, naturalne wydaje się wspieranie danych Phoenix jako danych wejściowych do HBase oprócz danych Avro. Ponadto domyślne ustawienie prostego natywnego kodowania binarnego wydaje się podatne na przyszłe zmiany i stanowi ryzyko dla użytkowników, którzy zapisują dane z SHC do HBase. Na przykład, wraz z postępem SHC, kompatybilność wsteczna musi być odpowiednio obsługiwana. Tak więc domyślny SHC musi zmienić się na bardziej standardowy i dobrze przetestowany format, taki jak Phoenix.
W przypadku podpory wpustu kompozytowego, przed wprowadzeniem tej funkcji, długość każdego wymiaru musiała zostać ustalona – z wyjątkiem ostatniego wymiaru wpustu kompozytowego. To ograniczenie zostało usunięte przez programistę Phoenix. Obecnie, jeśli użytkownicy wybierają Phoenix jako koder danych, nie muszą określać długości każdej części klucza złożonego w katalogu.
Ponieważ Phoenix jest domyślnym koderem, jedyną zmianą dla użytkowników jest to, że jeśli chcą używać PrimitiveType jako kodera danych, muszą określić „tableCoder”:”PrimitiveType” w swoich katalogach, aby powiadomić SHC, że chcą zamiast tego użyć PrimitiveType Phoenix jako „tableCoder”.
def katalog =s”””{
|”table”:{„przestrzeń nazw”:”default”, „nazwa”:”tabela1″, „tableCoder”:”PrimitiveType”},
|”rowkey ”:”klucz”,
|”kolumny”:{
|”kol0″:{„cf”:”rowkey”, „kol”:”klucz”, „typ”:”ciąg”} ,
|”col1″:{„cf”:”cf1″, „col”:”col1″, „typ”:”boolean”},
|”col2″:{„cf”:”cf2″, „col”:”col2″, „typ”:”podwójny”},
|”col3″:{„cf”:”cf3″, „col”:”col3″, „typ” :”float”},
|”col4″:{„cf”:”cf4″, „col”:”col4″, „typ”:”int”},
|”col5″:{„cf”:”cf5″, „col”:”col5″, „typ”:”bigint”},
|”col6″:{„cf”:”cf6″, „col”:”col6 ″, „typ”:”smallint”},
|”col7″:{„cf”:”cf7″, „col”:”col7″, „typ”:”string”},
|”col8″:{„cf”:”cf8″, „col”:”col8″, „typ”:”tinyint”}
|}
|}”””.stripMargin
Buforuj połączenia Spark HBase
SHC nie buforował wcześniej obiektów połączeń do HBase. W szczególności wywołanie „ConnectionFactory.createConnection” było wykonywane za każdym razem, gdy SHC musiał odwiedzić tabele i regiony HBase. Użytkownicy mogli to zobaczyć po prostu patrząc na dzienniki wykonawców i obserwując połączenia zookeepera ustanawiane dla każdego żądania. W dokumentacji interfejsu Connection jest napisane, że tworzenie połączenia jest ciężką operacją, a implementacje połączeń są bezpieczne wątkowo. W związku z tym w przypadku długotrwałych procesów bardzo przydatne byłoby utrzymywanie połączenia w pamięci podręcznej przez SHC. Dzięki tej funkcji SHC drastycznie zmniejsza liczbę tworzonych połączeń i znacznie poprawia wydajność w tym procesie.
Obsługa zduplikowanych rodzin kolumn
SHC obsługuje obsługę zduplikowanych rodzin kolumn. Teraz użytkownicy mogą definiować swoje katalogi w następujący sposób:
def katalog =s”””{
|”table”:{„przestrzeń nazw”:”default”, „nazwa”:”tabela1″, „tableCoder”:”PrimitiveType”},
|”rowkey ”:”klucz”,
|”kolumny”:{
|”kol0″:{„cf”:”rowkey”, „kol”:”klucz”, „typ”:”ciąg”} ,
|”col1″:{„cf”:”cf1″, „col”:”col1″, „typ”:”boolean”},
|”col2″:{„cf”:”cf1″, „col”:”col2″, „typ”:”podwójny”},
|”col3″:{„cf”:”cf1″, „col”:”col3″, „typ” :”float”},
|”col4″:{„cf”:”cf2″, „col”:”col4″, „typ”:”int”},
|”col5″:{„cf”:”cf2″, „col”:”col5″, „typ”:”bigint”},
|”col6″:{„cf”:”cf3″, „col”:”col6 ″, „typ”:”smallint”},
|”col7″:{„cf”:”cf3″, „col”:”col7″, „typ”:”string”},
|”col8″:{„cf”:”cf3″, „col”:”col8″, „typ”:”tinyint”}
|}
|}”””.stripMargin
W powyższej definicji katalogu kolumny „col0”, „col1” i „col2” mają tę samą rodzinę kolumn „cf1”.
Użyj interfejsu Spark UnhandledFilters API
SHC zaimplementował również unhandledFilters Spark API, który jest skuteczną optymalizacją. Ten interfejs API informuje Spark o filtrach, których SHC nie implementuje, w przeciwieństwie do zwracania wszystkich filtrów. Poprzednie zachowanie w tym przypadku polegało na ponownym zastosowaniu wszystkich filtrów po ściągnięciu danych do platformy Spark. Powinno to być idempotentne, więc nie zmienia żadnych danych, ale może być kosztowne, jeśli filtry są skomplikowane.
Społeczność SHC
Społeczność SHC jest większa i bardziej wpływowa niż rok temu. W 2016 roku wygłosiliśmy prelekcje na Hadoop Summit i na spotkaniu HBase/Spark oraz pisaliśmy szczegółowe blogi. Wraz ze wzrostem liczby użytkowników SHC otrzymujemy coraz większą liczbę pytań użytkowników. Bardzo się cieszymy, że obserwujemy wzrost popularności SHC i jeśli masz jakiekolwiek myśli o tym, jak go jeszcze ulepszyć, prześlij nam swoją opinię za pośrednictwem Hortonworks Community Connection.
POTWIERDZENIE
Chcemy podziękować zespołowi Bloomberg za prowadzenie nas w tej pracy, a także pomoc w walidacji tej pracy. Chcemy również podziękować społeczności HBase za przekazanie opinii i ulepszenie tego. Wreszcie, ta praca wykorzystała lekcje z wcześniejszych integracji Spark HBase i chcemy podziękować ich programistom za utorowanie drogi.
ODNIESIENIE:
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/
