Model zagęszczania zmienia się drastycznie z CDH 5/HBase 0,96. Oto, co musisz wiedzieć.
Apache HBase to rozproszony magazyn danych oparty na drzewie scalającym o strukturze dziennika, więc optymalna wydajność odczytu wynikałaby z posiadania tylko jednego pliku na magazyn (rodzina kolumn). Jednak ten ideał nie jest możliwy w okresach dużej liczby przychodzących zapisów. Zamiast tego HBase spróbuje połączyć HFiles, aby zmniejszyć maksymalną liczbę poszukiwań dysku potrzebnych do odczytu. Ten proces nazywa się zagęszczaniem .
Kompaktowanie wybiera niektóre pliki z jednego sklepu w regionie i łączy je. Ten proces obejmuje odczytywanie wartości KeyValues w plikach wejściowych i zapisywanie wszelkich wartości KeyValue, które nie są usuwane, znajdują się w czasie życia (TTL) i nie naruszają liczby wersji. Nowo utworzony połączony plik zastępuje następnie pliki wejściowe w regionie.
Teraz, gdy klient prosi o dane, HBase wie, że dane z plików wejściowych są przechowywane w jednym ciągłym pliku na dysku — stąd potrzebne jest tylko jedno wyszukiwanie, podczas gdy wcześniej może być wymagane jedno dla każdego pliku. Ale dyskowe IO nie jest darmowe i bez starannej uwagi ciągłe przepisywanie danych może prowadzić do poważnej nadmiernej subskrypcji sieci i dysku. Innymi słowy, kompaktowanie polega na wymianie niektórych dysków we/wy teraz na mniejszą liczbę zapytań później.
W tym poście dowiesz się więcej o wykorzystaniu i konsekwencjach zagęszczania w CDH 4, a także o zmianach w modelu zagęszczania w CDH 5 (który zostanie ponownie oparty na HBase 0.96).
Zagęszczanie w CDH 4
Idealne kompaktowanie wybrałoby pliki, które ograniczą najwięcej poszukiwań w nadchodzących odczytach, jednocześnie wybierając pliki, które będą wymagały najmniejszej ilości IO. Niestety tego problemu nie da się rozwiązać bez wiedzy o przyszłości. W związku z tym jest to po prostu ideał, do którego powinna dążyć HBase, a nie coś, co jest naprawdę osiągalne.
Zamiast niemożliwego ideału, HBase używa heurystyki, aby spróbować wybrać, które pliki w sklepie mogą być dobrymi kandydatami. Pliki są intuicyjnie wybierane, że podobne pliki powinny być łączone z podobnymi plikami – co oznacza, że pliki o tym samym rozmiarze powinny być łączone.
Domyślna polityka w HBase 0.94 (wysyłka w CDH 4) przegląda listę HFiles, próbując znaleźć pierwszy plik, który ma rozmiar mniejszy niż suma wszystkich plików pomnożona przez hbase.store.compaction.ratio. Po znalezieniu tego pliku, HFile i wszystkie pliki z mniejszymi identyfikatorami sekwencji są wybierane do kompaktowania.
W przypadku domyślnego przypadku, gdy największe pliki są najstarsze, to podejście działa dobrze:
Jednak to założenie o korelacji między wiekiem a rozmiarem plików jest w niektórych przypadkach błędne, co powoduje, że obecny algorytm wybiera nieoptymalny. Zamiast tego, pliki ładowane zbiorczo mogą i czasami sortują bardzo inaczej niż normalnie opróżniane HFiles, więc stanowią świetne przykłady:
Zmiany zagęszczenia w CDH 5
Zagęszczenia zmieniły się ostatnio w znaczący sposób. W przypadku HBase 0.96 i CDH 5 algorytm wyboru plików można było konfigurować za pomocą HBASE-7516 — dzięki czemu można teraz korzystać z dostarczonych przez użytkownika zasad kompaktowania. Ta zmiana umożliwia bardziej doświadczonym użytkownikom testowanie i powtarzanie sposobu, w jaki chcą uruchomić kompaktowanie.
Domyślny algorytm wyboru kompaktowania został również zmieniony na ExploringCompactionPolicy. Ta zasada różni się od starej domyślnej, ponieważ zapewnia, że każdy plik w proponowanym zagęszczeniu mieści się w określonym współczynniku. Ponadto nie tylko wybiera pierwszy zestaw plików, których rozmiary mieszczą się w zakresie współczynnika zagęszczenia; zamiast tego przygląda się wszystkim możliwym zestawom, które nie naruszają żadnych reguł, a następnie wybiera coś, co wydaje się mieć największy wpływ dla najmniejszej oczekiwanej ilości operacji we/wy. Aby to zrobić, ExploringCompactionPolicy wybiera kompaktowanie, które usunie większość plików w stosunku, a jeśli istnieje remis, pierwszeństwo ma zestaw plików o mniejszym rozmiarze:
Więcej zmian jest planowanych w przyszłych wydaniach, w tym kompaktowanie warstwowe, kompaktowanie rozłożone i kompaktowanie oparte na poziomach.
Wniosek
W niektórych przypadkach ta praca nie będzie miała żadnego wpływu. To dobrze, ponieważ zagęszczenie zostało już dość dobrze zbadane. Jednak w przypadku użytkowników, którzy mają duże skoki ruchu lub korzystają z obciążeń zbiorczych, ta praca może przynieść znaczną poprawę czasu oczekiwania na operacje we/wy i opóźnienia żądań. W konkretnym przypadku użycia masowego ładowania zaobserwowaliśmy 90% redukcję we/wy dysku ze względu na kompaktowanie.
Oto wyniki z przypadku testowego w PerfTestCompactionPolicies firmy HBase:
Sprawdź tę pracę w CDH 5 (w wersji beta w momencie pisania tego tekstu), jeśli chodzi o klaster w pobliżu.
Dalsze czytanie:
- Poznawanie polityki zagęszczania
- https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
- https://issues.apache.org/jira/browse/HBASE-7516
- https://issues.apache.org/jira/browse/HBASE-7678
- https://issues.apache.org/jira/browse/HBASE-7667
- https://issues.apache.org/jira/browse/HBASE-7055
- http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/
