Apache HBase to baza danych Hadoop i jest oparta na rozproszonym systemie plików Hadoop (HDFS ). HBase umożliwia losowy dostęp i aktualizację danych przechowywanych w HDFS, ale pliki w HDFS mogą być tylko dołączane i są niezmienne po ich utworzeniu. Możesz więc zapytać, w jaki sposób HBase zapewnia odczyty i zapisy o niskim opóźnieniu? W tym poście na blogu wyjaśniamy to, opisując ścieżkę zapisu HBase — jak dane są aktualizowane w HBase.
Ścieżka zapisu to sposób, w jaki HBase kończy operacje umieszczania lub usuwania. Ta ścieżka zaczyna się od klienta, przechodzi do serwera regionalnego i kończy się, gdy dane są ostatecznie zapisywane w pliku danych HBase o nazwie HFile . W projekcie ścieżki zapisu uwzględniono funkcje używane przez HBase w celu zapobiegania utracie danych w przypadku awarii serwera regionu. Dlatego zrozumienie ścieżki zapisu może zapewnić wgląd w natywny mechanizm zapobiegania utracie danych HBase.
Każda tabela HBase jest hostowana i zarządzana przez zestawy serwerów, które dzielą się na trzy kategorie:
- Jeden aktywny serwer główny
- Jeden lub więcej zapasowych serwerów głównych
- Wiele serwerów regionalnych
Serwery regionu przyczyniają się do obsługi tabel HBase. Ponieważ tabele HBase mogą być duże, są one podzielone na partycje zwane regionami. Każdy serwer regionu obsługuje co najmniej jeden z tych regionów. Należy pamiętać, że ponieważ serwery regionalne są jedynymi serwerami obsługującymi dane tabeli HBase, awaria serwera głównego nie może spowodować utraty danych.
Dane HBase są zorganizowane podobnie do posortowanej mapy, z posortowaną przestrzenią kluczy podzieloną na różne fragmenty lub regiony. Klient HBase aktualizuje tabelę, wywołując polecenia put lub delete. Gdy klient zażąda zmiany, to żądanie jest domyślnie od razu kierowane do serwera regionalnego. Jednak programowo klient może buforować zmiany po stronie klienta i opróżniać te zmiany na serwerach regionu w partii, wyłączając automatyczne opróżnianie. Jeśli automatyczne opróżnianie jest wyłączone, zmiany są buforowane do momentu wywołania poleceń opróżniania lub zapełnienia bufora w zależności od rozmiaru bufora ustawionego programowo lub skonfigurowanego za pomocą parametru „hbase.client.write.buffer”.
Ponieważ klucz wiersza jest posortowany, łatwo jest określić, który region serwer zarządza którym kluczem. Prośba o zmianę dotyczy określonego wiersza. Każdy klucz wiersza należy do określonego regionu, który jest obsługiwany przez serwer regionu. Tak więc na podstawie klucza put lub delete klient HBase może zlokalizować odpowiedni serwer regionu. Najpierw lokalizuje adres serwera regionu obsługującego region -ROOT- z kworum ZooKeeper. Z serwera regionu głównego klient znajduje lokalizację serwera regionu obsługującego region -META-. Z serwera metaregionu w końcu znajdujemy rzeczywisty serwer regionu, który obsługuje żądany region. Jest to proces trzyetapowy, więc lokalizacja regionu jest buforowana, aby uniknąć tej kosztownej serii operacji. Jeśli lokalizacja pamięci podręcznej jest nieprawidłowa (na przykład otrzymujemy wyjątek dotyczący nieznanego regionu), czas zmienić lokalizację regionu i zaktualizować pamięć podręczną.
Po odebraniu żądania przez właściwy serwer regionu zmiana nie może zostać natychmiast zapisana w HFile, ponieważ dane w HFile muszą być posortowane według klucza wiersza. Pozwala to na wydajne wyszukiwanie losowych wierszy podczas odczytu danych. Danych nie można losowo wstawiać do HFile. Zamiast tego zmiana musi zostać zapisana w nowym pliku. Jeśli każda aktualizacja zostałaby zapisana do pliku, powstałoby wiele małych plików. Takie rozwiązanie nie byłoby skalowalne ani wydajne do późniejszego łączenia lub odczytywania. Dlatego zmiany nie są natychmiast zapisywane w nowym pliku HFile.
Zamiast tego każda zmiana jest przechowywana w miejscu w pamięci zwanym memstore , który tanio i wydajnie obsługuje losowe zapisy. Dane w memstore są sortowane w taki sam sposób jak dane w HFile. Kiedy memstore zgromadzi wystarczającą ilość danych, cały posortowany zestaw jest zapisywany w nowym pliku HFile w HDFS. Wykonanie jednego dużego zadania zapisu jest wydajne i wykorzystuje mocne strony HDFS.
Chociaż zapisywanie danych do memstore jest wydajne, wprowadza również element ryzyka:Informacje przechowywane w memstore są przechowywane w pamięci ulotnej, więc w przypadku awarii systemu wszystkie informacje w memstore są tracone. Aby pomóc złagodzić to ryzyko, HBase zapisuje aktualizacje w dzienniku zapisu z wyprzedzeniem (WAL ) przed zapisaniem informacji do memstore. W ten sposób, jeśli serwer regionu ulegnie awarii, informacje przechowywane w pamięci tego serwera można odzyskać z jego WAL.
Uwaga:Domyślnie WAL jest włączony, ale proces zapisywania pliku WAL na dysku zużywa pewne zasoby. WAL może być wyłączony, ale należy to robić tylko wtedy, gdy ryzyko utraty danych nie jest problemem. Jeśli zdecydujesz się wyłączyć WAL, rozważ wdrożenie własnego rozwiązania do odzyskiwania po awarii lub przygotuj się na możliwość utraty danych.
Dane w pliku WAL są zorganizowane inaczej niż HFile. Pliki WAL zawierają listę edycji, z jedną edycją reprezentującą pojedyncze umieszczenie lub usunięcie. Edycja zawiera informacje o zmianie i regionie, którego dotyczy. Edycje są zapisywane chronologicznie, więc dla zachowania trwałości, dodatki są dołączane na końcu pliku WAL przechowywanego na dysku. Ponieważ pliki WAL są uporządkowane chronologicznie, nigdy nie ma potrzeby zapisywania w losowym miejscu w pliku.
W miarę rozrastania się warstw WAL są one ostatecznie zamykane i tworzony jest nowy, aktywny plik WAL umożliwiający akceptację dodatkowych zmian. Nazywa się to „rollingiem” pliku WAL. Po wycofaniu pliku WAL nie są wprowadzane żadne dodatkowe zmiany w starym pliku.
Domyślnie plik WAL jest rolowany, gdy jego rozmiar wynosi około 95% rozmiaru bloku HDFS. Możesz skonfigurować mnożnik za pomocą parametru:„hbase.regionserver.logroll.multiplier”, a rozmiar bloku za pomocą parametru:„hbase.regionserver.hlog.blocksize”. Plik WAL jest również odtwarzany okresowo w oparciu o skonfigurowany interwał „hbase.regionserver.logroll.period”, domyślnie godzinę, nawet rozmiar pliku WAL jest mniejszy niż skonfigurowany limit.
Ograniczenie rozmiaru pliku WAL ułatwia wydajne odtwarzanie pliku, jeśli wymagane jest odzyskanie. Jest to szczególnie ważne podczas odtwarzania pliku WAL regionu, ponieważ podczas odtwarzania pliku odpowiedni region jest niedostępny. Intencją jest ostateczne zapisanie wszystkich zmian z każdego pliku WAL na dysku i utrwalenie tej zawartości w pliku HFile. Po wykonaniu tej czynności plik WAL można zarchiwizować i ostatecznie usunąć przez wątek demona LogCleaner. Zauważ, że pliki WAL służą jako środek ochronny. Pliki WAL muszą być odtwarzane tylko w celu odzyskania aktualizacji, które w przeciwnym razie zostałyby utracone po awarii serwera regionu.
Serwer regionu obsługuje wiele regionów, ale nie ma pliku WAL dla każdego regionu. Zamiast tego jeden aktywny plik WAL jest współużytkowany przez wszystkie regiony obsługiwane przez serwer regionu. Ponieważ pliki WAL są wymieniane okresowo, jeden serwer regionu może mieć wiele plików WAL. Pamiętaj, że w danym momencie jest tylko jeden aktywny WAL na serwer regionu.
Zakładając, że domyślny katalog główny HBase to „/hbase”, wszystkie pliki WAL dla instancji serwera regionu są przechowywane w tym samym folderze głównym, który wygląda następująco:
/hbase/.logs/<host>, <port>,<startcode>
Na przykład:
/hbase/.logs/srv.example.com,60020,1254173957298
Pliki dziennika WAL mają następujące nazwy:
/hbase/.logs/<host>, <port>,<startcode>/<host>%2C <port>%2C<startcode>.<timestamp>
Na przykład:
/hbase/.logs/srv.example.com,60020,1254173957298/srv.example.com%2C60020%2C1254173957298.1254173957495
Każda zmiana w pliku WAL ma unikalny identyfikator sekwencji. Ten identyfikator zwiększa się, aby zachować kolejność edycji. Za każdym razem, gdy plik dziennika jest wyrzucany, następny identyfikator sekwencji i stara nazwa pliku są umieszczane w mapie w pamięci. Informacje te są używane do śledzenia maksymalnego identyfikatora sekwencji każdego pliku WAL, dzięki czemu możemy łatwo ustalić, czy plik można zarchiwizować w późniejszym czasie, gdy jakiś memstore zostanie przeniesiony na dysk.
Edycje i ich identyfikatory sekwencji są unikalne w obrębie regionu. Za każdym razem, gdy edycja jest dodawana do dziennika WAL, identyfikator sekwencji edycji jest również rejestrowany jako ostatni zapisany identyfikator sekwencji. Kiedy memstore jest opróżniany na dysk, ostatni identyfikator sekwencji zapisany dla tego regionu jest czyszczony. Jeśli ostatni identyfikator sekwencji zapisany na dysku jest taki sam, jak maksymalny identyfikator sekwencji pliku WAL, można stwierdzić, że wszystkie zmiany w pliku WAL dla tego regionu zostały zapisane na dysku. Jeśli wszystkie edycje dla wszystkich regionów w pliku WAL zostały zapisane na dysku, jasne jest, że nie będzie wymagane dzielenie ani odtwarzanie, a plik WAL można zarchiwizować.
Rolling pliku WAL i opróżnianie memstore to dwie oddzielne akcje i nie muszą odbywać się razem. Nie chcemy jednak przechowywać zbyt wielu plików WAL na serwer regionu, aby uniknąć czasochłonnego odzyskiwania w przypadku awarii serwera regionu. Dlatego, gdy plik WAL jest przewijany, HBase sprawdza, czy nie ma zbyt wielu plików WAL i decyduje, które regiony powinny zostać opróżnione, aby można było zarchiwizować niektóre pliki WAL.
W tym poście wyjaśniamy ścieżkę zapisu HBase, czyli sposób tworzenia i/lub aktualizowania danych w HBase. Niektóre ważne części to:
- Jak klient lokalizuje serwer regionalny,
- Memstore, który obsługuje szybkie losowe zapisy,
- Pliki WAL jako sposób na uniknięcie utraty danych w przypadku awarii serwera regionalnego.
W kolejnych postach porozmawiamy o formatach HFile, dzieleniu plików WAL i tak dalej.
