Dowiedz się o decyzjach projektowych stojących za nowym wsparciem HBase dla MOBów.
Apache HBase to rozproszona, skalowalna, wydajna, spójna baza danych kluczowych wartości, która może przechowywać różne typy danych binarnych. Doskonale sprawdza się w przechowywaniu wielu stosunkowo małych wartości (<10K) oraz zapewnianiu odczytów i zapisów o niskim opóźnieniu.
Jednak rośnie zapotrzebowanie na przechowywanie dokumentów, obrazów i innych obiektów umiarkowanych (MOB) w HBase przy jednoczesnym zachowaniu niskich opóźnień dla odczytów i zapisów. Jednym z takich przypadków użycia jest bank, który przechowuje podpisane i zeskanowane dokumenty klientów. Inny przykład:agencje transportowe mogą chcieć przechowywać zdjęcia ruchu i poruszających się samochodów. Te MOBy są zazwyczaj jednokrotnego zapisu.
Niestety, wydajność może ulec pogorszeniu w sytuacjach, w których przechowywanych jest wiele wartości średniej wielkości (100K do 10MB) ze względu na stale rosnące ciśnienie we/wy wytwarzane przez kompaktowanie. Rozważ przypadek, w którym 1 TB zdjęć z kamer drogowych, każdy o rozmiarze 1 MB, jest codziennie przechowywanych w HBase. Części przechowywanych plików są wielokrotnie kompaktowane przez kompaktowanie mniejsze, a ostatecznie dane są ponownie zapisywane przez kompaktowanie większe. Wraz z akumulacją tych MOBów, operacje we/wy tworzone przez kompaktowanie spowalniają kompaktowanie, dodatkowo blokują opróżnianie pamięci i ostatecznie blokują aktualizacje. Duży sklep MOB spowoduje częste podziały regionów, zmniejszając dostępność dotkniętych regionów.
Aby wyeliminować te wady, inżynierowie Cloudera i Intel wdrożyli obsługę MOB w gałęzi HBase (hbase-11339:HBase MOB). Ta gałąź zostanie połączona z masterem w HBase 1.1 lub 1.2 i jest już obecna i obsługiwana w CDH 5.4.x.
Operacje na obiektach MOB zazwyczaj wymagają intensywnego zapisu, z rzadkimi aktualizacjami lub usuwaniem oraz stosunkowo rzadkimi odczytami. MOBy są zwykle przechowywane razem z ich metadanymi. Metadane związane z MOBami mogą obejmować na przykład numer samochodu, prędkość i kolor. Metadane są bardzo małe w porównaniu z MOBami. Metadane są zwykle dostępne do analizy, podczas gdy MOB są zwykle dostępne losowo tylko wtedy, gdy są wyraźnie żądane za pomocą kluczy wierszy.
Użytkownicy chcą odczytywać i zapisywać obiekty MOB w HBase z małymi opóźnieniami w tych samych interfejsach API i chcą silnej spójności, zabezpieczeń, migawek i replikacji HBase między klastrami i tak dalej. Aby osiągnąć te cele, MOB zostały przeniesione z głównej ścieżki I/O HBase na nową ścieżkę I/O.
W tym poście dowiesz się o tym podejściu do projektowania i dlaczego zostało ono wybrane.
Możliwe podejścia
Istniało kilka możliwych podejść do tego problemu. Pierwszym podejściem, które rozważyliśmy, było przechowywanie obiektów MOB w HBase z dostrojonymi zasadami podziału i kompaktowania — większy pożądany MaxFileSize zmniejsza częstotliwość podziału regionu, a mniejsza lub żadna kompaktacja pozwala uniknąć kary za wzmocnienie zapisu. Takie podejście znacznie poprawiłoby opóźnienia zapisu i przepustowość. Jednak wraz ze wzrostem liczby przechowywanych plików w jednym sklepie byłoby zbyt wiele otwartych czytników, nawet więcej niż pozwala na to system operacyjny. W rezultacie zużyłoby się dużo pamięci, a wydajność odczytu uległaby pogorszeniu.
Innym podejściem było użycie modelu HBase + HDFS do oddzielnego przechowywania metadanych i MOBów. W tym modelu pojedynczy plik jest połączony wpisem w HBase. Jest to rozwiązanie klienckie, a transakcja jest kontrolowana przez klienta — żadne pamięci po stronie HBase nie są zużywane przez MOB. To podejście działałoby w przypadku obiektów większych niż 50 MB, ale w przypadku MOB wiele małych plików prowadzi do nieefektywnego wykorzystania HDFS, ponieważ domyślny rozmiar bloku w HDFS to 128 MB.
Załóżmy na przykład, że NameNode ma 48 GB pamięci, a każdy plik ma 100 KB z trzema replikami. Każdy plik zajmuje więcej niż 300 bajtów w pamięci, więc NameNode z 48 GB pamięci może pomieścić około 160 milionów plików, co ograniczyłoby nas do przechowywania tylko 16 TB plików MOB.
Jako ulepszenie moglibyśmy złożyć małe pliki MOB w większe — to znaczy, że plik może zawierać wiele wpisów MOB — i przechowywać przesunięcie i długość w tabeli HBase w celu szybkiego odczytu. Jednak utrzymanie spójności danych i zarządzanie usuniętymi plikami MOB i małymi plikami MOB w skompaktowaniu jest trudne.
Co więcej, gdybyśmy mieli zastosować to podejście, musielibyśmy wziąć pod uwagę nowe zasady bezpieczeństwa, stracić właściwości atomowe zapisów i potencjalnie stracić kopię zapasową i odzyskiwanie po awarii zapewniane przez replikację i migawki.
Projekt HBase MOB
Ostatecznie, ponieważ większość obaw związanych z przechowywaniem MOBów w HBase dotyczy operacji we/wy utworzonych przez kompaktowanie, kluczem było usunięcie MOBów z zarządzania przez normalne regiony, aby uniknąć podziału regionów i ich kompaktowania.
Projekt HBase MOB jest podobny do podejścia HBase + HDFS, ponieważ przechowujemy osobno metadane i MOB. Jednak różnica polega na projekcie po stronie serwera:memstore buforuje MOBy przed ich opróżnieniem na dysk, MOB są zapisywane w HFile o nazwie „plik MOB” w każdym opróżnieniu, a każdy plik MOB ma wiele wpisów zamiast pojedynczego pliku w HDFS dla każdego MOB. Ten plik MOB jest przechowywany w specjalnym regionie. Cały odczyt i zapis może być używany przez obecne interfejsy API HBase.
Pisanie i czytanie
Każdy MOB ma próg:jeśli długość komórki jest większa niż ten próg, ta komórka jest uważana za komórkę MOB.
Gdy komórki MOB są aktualizowane w regionach, są zapisywane w WAL i pamięci, tak jak normalne komórki. Podczas opróżniania pliki MOB są opróżniane do plików MOB, a metadane i ścieżki plików MOB są opróżniane w celu przechowywania plików. Spójność danych i funkcje replikacji HBase są natywne dla tego projektu.
Edycje MOB są większe niż zwykle. W synchronizacji odpowiednie wejścia/wyjścia są również większe, co może spowolnić operacje synchronizacji WAL. Jeśli istnieją inne regiony, które współużytkują tę samą warstwę WAL, może to mieć wpływ na opóźnienie zapisu w tych regionach. Jeśli jednak wymagana jest spójność i niezmienność danych, WAL jest koniecznością.
Komórki mogą poruszać się między przechowywanymi plikami a plikami MOB w zagęszczeniu poprzez zmianę progu. Domyślny próg to 100 KB.
Jak pokazano poniżej, komórki zawierające ścieżki plików MOB są nazywane komórkami referencyjnymi . Tagi są zachowywane w komórkach, więc możemy nadal polegać na mechanizmie bezpieczeństwa HBase.
Komórki referencyjne mają znaczniki referencyjne, które odróżniają je od normalnych komórek. Znacznik referencyjny implikuje komórkę MOB w pliku MOB, a zatem do czytania potrzebne jest dalsze rozwiązanie.
Podczas czytania skaner sklepu otwiera skanery do przechowywania pamięci i przechowywania plików. Jeśli zostanie osiągnięta komórka odniesienia, skaner odczytuje ścieżkę pliku z wartości komórki i szuka tego samego klucza wiersza z tego pliku. Pamięć podręczną bloków można włączyć dla skanowanych plików MOB, co może przyspieszyć wyszukiwanie.
Nie jest konieczne otwieranie czytników na wszystkie pliki MOB; w razie potrzeby potrzebny jest tylko jeden. Na ten losowy odczyt nie ma wpływu liczba plików MOB. Nie musimy więc ciągle kompaktować plików MOB, gdy są wystarczająco duże.
Nazwa pliku MOB jest czytelna i składa się z trzech części:MD5 klucza startowego, ostatniej daty komórek w tym pliku MOB oraz identyfikatora UUID. Pierwsza część to klucz startowy regionu, z którego usuwany jest plik MOB. Zazwyczaj MOB mają zdefiniowany przez użytkownika TTL, więc możesz znaleźć i usunąć wygasłe pliki MOB, porównując drugą część z TTL.
Migawka
Aby być bardziej przyjaznym dla zrzutów, pliki MOB są przechowywane w specjalnym regionie fikcyjnym, dzięki czemu zrzut, eksport/klon tabeli i archiwum działają zgodnie z oczekiwaniami.
Podczas przechowywania migawki w tabeli tworzy się region MOB w migawce i dodaje istniejące pliki MOB do manifestu. Podczas przywracania zrzutu utwórz łącza do plików w regionie MOB.
Czyszczenie i zagęszczanie
Istnieją dwie sytuacje, w których pliki MOB powinny zostać usunięte:gdy plik MOB wygasł i gdy plik MOB jest zbyt mały i powinien zostać scalony w większe, aby poprawić wydajność HDFS.
HBase MOB ma zadanie w master:skanuje pliki MOB, znajduje te, które wygasły, określone przez datę w nazwie pliku i usuwa je. W ten sposób miejsce na dysku jest okresowo odzyskiwane przez starzenie się wygasłych plików MOB.
Pliki MOB mogą być stosunkowo małe w porównaniu z blokiem HDFS, jeśli piszesz wiersze, w których tylko kilka wpisów kwalifikuje się jako MOB; również mogą być usunięte komórki. Musisz upuścić usunięte komórki i połączyć małe pliki w większe, aby poprawić wykorzystanie HDFS. Kompresja MOB kompaktuje tylko małe pliki, a duże pliki nie są dotykane, co pozwala uniknąć wielokrotnego kompaktowania do dużych plików.
Kilka innych rzeczy, o których należy pamiętać:
- Wiedz, które komórki zostały usunięte. W każdym głównym kompaktowaniu HBase znaczniki usuwania są zapisywane w pliku del przed ich usunięciem.
- W pierwszym kroku kompaktowania MOB, te pliki del są łączone w większe.
- Zostaną wybrane wszystkie małe pliki MOB. Jeśli liczba małych plików jest równa liczbie istniejących plików MOB, to kompaktowanie jest uważane za główne i nazywane jest kompaktowaniem ALL_FILES.
- Te wybrane pliki są podzielone na partycje według klucza startowego i daty w nazwie pliku. Małe pliki w każdej partycji są kompaktowane za pomocą plików del, dzięki czemu usunięte komórki mogą zostać usunięte; w międzyczasie generowany jest nowy plik HFile z nowymi komórkami referencyjnymi, kompaktor zatwierdza nowy plik MOB, a następnie zbiorczo ładuje ten plik HFile do HBase.
- Po zakończeniu kompaktowania na wszystkich partycjach, jeśli w grę wchodzi kompaktowanie ALL_FILES, pliki del są archiwizowane.
Cykl życia plików MOB zilustrowano poniżej. Zasadniczo są one tworzone, gdy memstore jest opróżniany, i usuwane przez HFileCleaner z systemu plików, gdy nie ma do nich odniesienia w migawce lub gdy wygasły w archiwum.
Wniosek
Podsumowując, nowy projekt HBase MOB przenosi MOB z głównej ścieżki we/wy HBase, zachowując większość funkcji bezpieczeństwa, kompaktowania i tworzenia migawek. Dostosowuje się do cech operacji w MOB, sprawia, że wzmocnienie zapisu MOB jest bardziej przewidywalne i utrzymuje niskie opóźnienia zarówno podczas czytania, jak i pisania.
Jincheng Du jest inżynierem oprogramowania w firmie Intel i współpracownikiem HBase.
Jon Hsieh jest inżynierem oprogramowania w Cloudera i członkiem HBase/PMC. Jest także założycielem Apache Flume i współpracownikiem Apache Sqoop.
