Ten post został pierwotnie opublikowany za pośrednictwem blogs.apache.org, dla Twojej wygody publikujemy go ponownie tutaj w nieco zmodyfikowanej formie:
Na pierwszy rzut oka architektura Apache HBase wydaje się podążać za modelem master/slave, w którym master otrzymuje wszystkie żądania, ale prawdziwą pracę wykonują slaves. W rzeczywistości tak nie jest i w tym artykule opiszę, jakie zadania są w rzeczywistości wykonywane przez mistrza i niewolników.
Regiony i serwery regionalne
HBase to menedżer pamięci masowej Hadoop, który zapewnia losowe odczyty i zapisy o niskim opóźnieniu w systemie HDFS i może obsługiwać petabajty danych. Jedną z interesujących możliwości w HBase jest auto-sharding, co oznacza po prostu, że tabele są dynamicznie dystrybuowane przez system, gdy stają się zbyt duże.
Podstawowa jednostka skalowalności poziomej w HBase nazywa się Region . Regiony są podzbiorem danych tabeli i zasadniczo stanowią ciągły, posortowany zakres wierszy, które są przechowywane razem.
Początkowo na stół jest tylko jeden region. Jak pokazano poniżej, gdy regiony stają się zbyt duże po dodaniu większej liczby rzędów, region jest dzielony na dwie części przy środkowym klawiszu, tworząc dwie mniej więcej równe połówki.
W HBase urządzenia podrzędne nazywają się serwerami regionalnymi . Każdy serwer regionu jest odpowiedzialny za obsługę zestawu regionów, a jeden region (tj. zakres wierszy) może być obsługiwany tylko przez jeden serwer regionu.
Architektura HBase ma dwie główne usługi:HMaster odpowiedzialny za koordynację klastra i wykonywanie operacji administracyjnych oraz HRegionServer odpowiedzialny za obsługę podzbioru danych tabeli.
HMaster, przypisanie regionu i równoważenie
Jak wcześniej wspomniano, HBase Master koordynuje klaster HBase i jest odpowiedzialny za operacje administracyjne.
Serwer regionu może obsługiwać jeden lub więcej regionów. Każdy region jest przypisywany do serwera regionu podczas uruchamiania, a system główny może zdecydować o przeniesieniu regionu z jednego serwera regionu na inny w wyniku operacji równoważenia obciążenia. Master obsługuje również awarie serwera regionalnego, przypisując region do innego serwera regionalnego.
Mapowanie regionów i serwerów regionów jest przechowywane w tabeli systemowej o nazwie META. Czytając META, możesz określić, który region jest odpowiedzialny za Twój klucz. Oznacza to, że w przypadku operacji odczytu i zapisu master nie jest w ogóle zaangażowany, a klienci mogą przejść bezpośrednio do serwera regionalnego odpowiedzialnego za obsługę żądanych danych.
Lokalizowanie klucza wiersza:który serwer regionu jest odpowiedzialny?
Aby umieścić lub pobrać wiersz, klienci nie muszą kontaktować się z serwerem głównym, klienci mogą bezpośrednio skontaktować się z serwerem regionu obsługującym określony wiersz lub w przypadku skanowania klienta mogą bezpośrednio skontaktować się z zestawem serwerów regionalnych odpowiedzialnych za obsługę zestawu klawiszy:
Aby zidentyfikować serwer regionu, klient wykonuje zapytanie w tabeli META.
META to tabela systemowa służąca do śledzenia regionów. Zawiera nazwę serwera i identyfikator regionu składający się z nazwy tabeli i początkowego klucza wiersza. Patrząc na klucz startowy i kolejny region, klienci z kluczem startowym są w stanie zidentyfikować zakres wierszy zawartych w określonym regionie.
Klient przechowuje pamięć podręczną dla lokalizacji regionu. Dzięki temu klienci nie będą trafiać do tabeli META za każdym razem, gdy wydawana jest operacja w tym samym regionie. W przypadku podziału regionu lub przeniesienia na inny serwer regionu (z powodu równoważenia lub zasad przypisania), klient otrzyma wyjątek jako odpowiedź, a pamięć podręczna zostanie odświeżona przez pobranie zaktualizowanych informacji z tabeli META:
Ponieważ META jest tabelą jak inne, klient musi określić, na którym serwerze znajduje się META. Lokalizacje META są przechowywane w węźle ZooKeeper po przypisaniu przez administratora, a klient odczytuje bezpośrednio węzeł, aby uzyskać adres serwera regionu, który zawiera META.
Oryginalny projekt HBase opierał się na BigTable, z inną tabelą o nazwie -ROOT- zawierającą lokalizacje META i wskazującą ją Apache ZooKeeper. HBase 0.96 usunął ten układ na korzyść tylko ZooKeeper, ponieważ META nie może być podzielona i dlatego składa się z jednego regionu.
Client API:Obowiązki Master i Regionów
Interfejs API klienta Java HBase ma dwa główne interfejsy:
- HBaseAdmin umożliwia interakcję ze „schematem tabeli” poprzez tworzenie/usuwanie/modyfikowanie tabel oraz umożliwia interakcję z klastrem poprzez przypisywanie/cofanie przypisania regionów, łączenie regionów, wywoływanie opróżniania i tak dalej. Ten interfejs komunikuje się z Masterem.
- HTable umożliwia klientowi manipulowanie danymi z określonej tabeli przy użyciu operacji get, put, delete i wszystkich innych operacji na danych. Ten interfejs komunikuje się bezpośrednio z serwerami regionu odpowiedzialnymi za obsługę żądanego zestawu kluczy.
Te dwa interfejsy mają oddzielne obowiązki:HBaseAdmin jest używany tylko do wykonywania operacji administracyjnych i komunikowania się z Masterem, podczas gdy HTable służy do manipulowania danymi i komunikacji z regionami.
Wniosek
Jak widzieliśmy tutaj, posiadanie architektury Master/Slave nie oznacza, że każda operacja przechodzi przez mastera. Aby odczytać i zapisać dane, klient HBase w rzeczywistości przechodzi bezpośrednio do określonego serwera regionu odpowiedzialnego za obsługę kluczy wierszy dla wszystkich operacji na danych (HTable). Master jest używany przez klienta tylko do tworzenia, modyfikowania i usuwania tabel (HBaseAdmin).
Chociaż istnieje koncepcja Mastera, klient HBase nie jest od niego zależny w przypadku operacji na danych, a klaster może nadal obsługiwać dane, nawet jeśli master ulegnie awarii.
Matteo Bertozzi jest inżynierem oprogramowania w zespole Platformy i odpowiedzialnym za HBase.
Jeśli interesuje Cię HBase, zarejestruj się na HBaseCon 2013 (13 czerwca, San Francisco) – wydarzenie społecznościowe dla współtwórców, programistów, administratorów i użytkowników HBase. Przestrzeń jest ograniczona!
