HBase
 sql >> Baza danych >  >> NoSQL >> HBase

Przedstawiamy zasady partycji kompaktowania Apache HBase Medium Object Storage (MOB)

Wprowadzenie

Funkcja Apache HBase Medium Object Storage (MOB) została wprowadzona przez HBASE-11339. Ta funkcja poprawia dostęp do odczytu i zapisu z małymi opóźnieniami dla wartości o średniej wielkości (najlepiej od 100 KB do 10 MB na podstawie naszych wyników testów), dzięki czemu dobrze nadaje się do przechowywania dokumentów, obrazów i innych obiektów o średniej wielkości [1]. Funkcja Apache HBase MOB osiąga to ulepszenie, oddzielając ścieżki we/wy dla odwołań do plików i obiektów MOB, stosując różne zasady kompaktowania do obiektów MOB, a tym samym zmniejszając wzmocnienie zapisu tworzone przez kompaktowanie HBase. Obiekty MOB są przechowywane w specjalnym regionie, zwanym regionem MOB. Obiekty MOB dla jednej tabeli są przechowywane w regionie MOB jako pliki MOB, co oznacza, że ​​w tym regionie będzie wiele plików MOB. Zobacz Rysunek 1 z [1] dla architektury Apache HBase MOB.

Rysunek 1 Architektura Apache HBase MOB

Początkowo pliki MOB są stosunkowo małe (mniej niż 1 lub 2 bloki HDFS). Aby poprawić wydajność Apache HDFS, pliki MOB są okresowo łączone w większe pliki za pomocą operacji zwanej kompaktowaniem MOB , który jest niezależny od normalnego procesu zagęszczania. Początkowa wersja kompaktowania MOB przepisuje wiele plików MOB z określonego dnia na większe pliki MOB tego dnia. Użyjmy poniższej przykładowej listy plików, aby to było jaśniejsze. Tabela t1 ma dwa regiony (r1, r2), ma jedną rodzinę kolumn (f1) i włączoną funkcję MOB. Widać, że są dwa przedrostki; D279186428a75016b17e4df5ea43d080 odpowiada wartości skrótu klucza startowego dla regionu r1, a D41d8cd98f00b204e9800998ecf8427e odpowiada wartości skrótu klucza startowego dla regionu r2. Dla regionu r1 są dwa pliki MOB, każdy z 1.01.2016 i 1/2/2016 , a dla regionu r2 są 3 pliki MOB z 1.01.2016 w regionie MOB, czyli /hbase/data/ mobdir/data/default/t1/78e317a6e78a0fceb27b9fa0cb9dcf5b/f1.

>ls  /hbase/data/mobdir/data/default/t1/78e317a6e78a0fceb27b9fa0cb9dcf5b/f1

D279186428a75016b17e4df5ea43d08020160101 f9d9713ab2fb4a8b825485f6a8acfcd5

D279186428a75016b17e4df5ea43d08020160101 af7713ab2fbf4a8abc5135f6a8467ca8

D279186428a75016b17e4df5ea43d08020160102 9013ab2fceda8b825485f6a8acfcd515

D279186428a75016b17e4df5ea43d08020160102 9a7978013ab2fceda8b825485f6a8acf

D41d8cd98f00b204e9800998ecf8427e20160101 fc94af623c2345f1b241887721e32a48

D41d8cd98f00b204e9800998ecf8427e20160101 d0954af623c2345f1b241887721e3259

D41d8cd98f00b204e9800998ecf8427e20160101 439adf4af623c2345f1b241887721e32

Po skompaktowaniu MOB dwa pliki MOB w dniu 1.01.2016 i 1.01.2016 dla regionu r1 są kompaktowane w jeden plik na każdy dzień. Trzy pliki MOB w dniu 1.01.2016 dla regionu r2 zostały skompaktowane w jeden plik.

D279186428a75016b17e4df5ea43d08020160101 f49a9d9713ab2fb4a8b825485f6a8acf

D279186428a75016b17e4df5ea43d08020160102 bc9176d09424e49a9d9065caf9713ab2

D41d8cd98f00b204e9800998ecf8427e20160101 d9cb0954af623c2345f1b241887721e3

Ponieważ tylko pliki MOB z tego samego dnia dla regionu mogą być skompaktowane razem, minimalna granica plików MOB w jednym katalogu regionu MOB dla jednej konkretnej rodziny w ciągu jednego roku wyniesie 365 x liczba regionów. Z 1000 regionów, za 10 lat będzie 365 x 1000 x 10, 3,65 miliona plików po kompaktowaniu MOB, i to wciąż rośnie! Niestety, Apache HDFS ma ograniczony limit pamięci dotyczący liczby plików w jednym katalogu [2]. Gdy liczba plików MOB przekroczy ten limit HDFS, tablica MOB nie jest już zapisywalna. Domyślna maksymalna liczba plików w jednym katalogu dla Apache HDFS to 1 milion. W przypadku 1000 regionów osiągnie ten limit za około 3 lata. Im więcej regionów, tym szybciej osiągnie limit.

HBASE-16981 wprowadza tygodniowe i miesięczne zasady agregacji partycji kompaktowania MOB, aby poprawić ten problem skalowania liczby plików MOB odpowiednio o współczynniki 7 lub ~30.

Projektowanie tygodniowych i miesięcznych zasad partycji kompaktowania MOB (HBASE-16981)

Podstawową ideą HBASE-16981 jest kompaktowanie plików MOB w ciągu jednego tygodnia kalendarzowego lub jednego miesiąca kalendarzowego do mniejszej liczby większych plików. Tydzień kalendarzowy jest zdefiniowany przez ISO 8601, zaczyna się w poniedziałek, a kończy w niedzielę. Normalnie, z tygodniową polityką, po skompaktowaniu MOB będzie jeden plik na tydzień na region; z polityką miesięczną, po skompaktowaniu MOB będzie jeden plik na miesiąc na region. Liczba plików MOB w katalogu MOB region dla jednej konkretnej rodziny w ciągu jednego roku zostanie zmniejszona do 52 x liczba regionów z tygodniową polisą i 12 x liczba regionów z miesięczną polisą. To znacznie zmniejsza liczbę plików MOB po skompaktowaniu.

Początkowe proponowane podejście

Kiedy nastąpi kompaktowanie MOB, HBase master wybiera i agreguje pliki MOB w ciągu jednego miesiąca kalendarzowego lub jednego tygodnia kalendarzowego w mniejszą, większą liczbę plików. W zależności od tego, jak często ma miejsce kompaktowanie MOB, możliwe jest, że pliki są kompaktowane wielokrotnie. Jako przykład załóżmy, że operacja kompaktowania MOB odbywa się codziennie z miesięczną polityką agregacji. Pierwszego dnia funkcja kompaktowania MOB kompaktuje wszystkie pliki z pierwszego dnia w jeden plik. W dniu 2 kompaktowanie MOB kompaktuje plik z dnia 1 i pliki z dnia 2 do nowego pliku; w dniu 3, kompaktowanie MOB skompaktuje plik z dnia 2, a pliki z dnia 3 w nowy plik, będzie trwał do ostatniego dnia miesiąca. W tym przypadku pliki z pierwszego dnia są kompaktowane ponad 30 razy, co zwiększa ilość operacji we/wy zapisu o ponad 30x.

Celem projektowym Apache HBase MOB jest zmniejszenie wzmocnienia zapisu tworzonego przez kompaktowanie MOB. To naiwne podejście pokonuje cel projektowy.

Ostateczne wdrożone podejście

W celu przezwyciężenia niedoskonałości początkowo proponowanego podejścia, dla nowych tygodniowych i miesięcznych zasad w HBASE-16981 przyjęto stopniowe kompaktowanie MOB. Rysunek 2 pokazuje, jak działa z polityką miesięczną, działa podobnie w przypadku polityki tygodniowej.

Rysunek 2 Etapowe kompaktowanie MOB z miesięczną polityką

Jak pokazuje Rysunek 2, zagęszczenie MOB nastąpi 15.11.2016. Pliki w bieżącym tygodniu kalendarzowym są kompaktowane w oparciu o partycję dzienną ze skonfigurowanym progiem MOB. Na rysunku 2 pliki z dnia 14.11.2016 są kompaktowane razem, a pliki z dnia 15.11.2016 są kompaktowane razem. Pliki w ostatnich tygodniach kalendarzowych bieżącego miesiąca są kompaktowane na podstawie partycji tygodniowej z progiem tygodniowym (skonfigurowany próg MOB x 7). Na Rysunku 2 pliki od 11.01.2016 do 11.06.2016 są kompaktowane razem, a pliki od 11.07.2016 do 13.11.2016 są kompaktowane razem. Pliki z ostatnich miesięcy są kompaktowane na podstawie partycji miesięcznej z progiem miesięcznym (skonfigurowany próg MOB x 28). Na Rysunku 2 pliki od 1.10.2016 do 31.10.2016 są skompaktowane razem. Jak można zauważyć, pierwszy tydzień kalendarzowy w listopadzie 2016 r. trwa od 31.10.2016 do 06.11.2016. Ponieważ 31.10.2016 przypada w zeszłym miesiącu, pliki na ten dzień są kompaktowane w oparciu o partycję miesięczną, pozostaje tylko 6 dni dla partycji tygodniowej (11.01.2016 ~ 11.06.2016). Po skompaktowaniu jest 5 plików, jeśli próg kompaktowania MOB i rozmiar wsadu kompaktowania MOB są odpowiednio skonfigurowane.

Dzięki temu projektowi pliki MOB przechodzą przez kompaktowanie dwu- lub trzyetapowe. Na każdym etapie stosowana jest partycja dzienna, partycja tygodniowa lub partycja miesięczna z rosnącym progiem kompaktowania MOB. Pliki MOB są kompaktowane co najwyżej 3 razy normalnie z miesięczną polityką i co najwyżej 2 razy normalnie z tygodniową polityką w całym okresie ich istnienia.

Więcej informacji na temat projektu można znaleźć w [3].

Wykorzystanie

Domyślnie zasady partycji kompaktowania MOB są stosowane codziennie. Aby zastosować zasadę tygodniową lub miesięczną, dodano nowy atrybut MOB_COMPACT_PARTITION_POLICY dla rodziny kolumn MOB. Użytkownik może ustawić ten atrybut podczas tworzenia tabeli z powłoki HBase.

>create 't1', {NAME => 'f1', IS_MOB => true, MOB_THRESHOLD => 1000000, MOB_COMPACT_PARTITION_POLICY => 'weekly’}

Użytkownik może również zmienić istniejącą tabelę MOB_COMPACT_PARTITION_POLICY z powłoki HBase.

>alter 't1', {NAME => 'f1', MOB_COMPACT_PARTITION_POLICY => 'monthly'}

Jeśli zasada zmieni się z dziennej na tygodniową lub miesięczną lub z tygodniowej na miesięczną, następna kompaktacja MOB spowoduje ponowne skompaktowanie plików MOB, które zostały skompaktowane przy użyciu poprzedniej zasady. Jeśli zasada zmieni się z miesięcznej lub tygodniowej na dzienną lub z miesięcznej na tygodniową, już skompaktowane pliki MOB z poprzednią zasadą nie zostaną ponownie skompaktowane z nową zasadą.

Wniosek

HBASE-16981 rozwiązuje problem skalowania numerów plików w Apache HBase MOB. Będzie dostępny w wydaniu Apache HBase 2.0.0. CDH obsługuje Apache HBase MOB w CDH 5.4.0+. HBASE-16981 jest przeniesiony i będzie dostępny w CDH 5.11.0.

Podziękowania

Specjalne podziękowania dla Jingcheng Du i Anoop Sama Johna za pomoc w projektowaniu i przeglądzie HBASE-16981, Jonathana Hsieha i Seana Busbeya za zrecenzowanie bloga.

Referencje

[1] https://clouderatemp.wpengine.com/blog/2015/06/inside-apache-hbases-new-support-for-mobs/

[2] https://clouderatemp.wpengine.com/blog/2009/02/the-small-files-problem/

[3] https://issues.apache.org/jira/browse/HBASE-16981


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. How-to:Dodaj Cloudera Search do swojego klastra za pomocą Cloudera Manager

  2. Operacyjna replikacja baz danych Cloudera w skrócie

  3. Używanie Hive do interakcji z HBase, część 1

  4. Mapa HadoopReduce Schemat wykonywania zadań

  5. Jak HBase w CDP może wykorzystać S3 firmy Amazon?