W dzisiejszym poście omówimy architekturę HBase. Odświeżmy nasze podstawy HBase, zanim zagłębimy się w architekturę HBase.
różnica między przeciążeniem a nadpisywaniem
HBase - podstawy:
HBase to rozproszony, nierelacyjny, wersjonowany, wielowymiarowy, zorientowany na kolumny sklep typu open source, NoSQL, oparty na Google BigTable, który działa na HDFS. „NoSQL” to szerokie pojęcie, które oznacza, że baza danych nie jest systemem RDBMS, który obsługuje SQL jako podstawowy język dostępu. Ale istnieje wiele typów baz danych NoSQL, a Berkeley DB jest dobrym przykładem lokalnej bazy danych NoSQL, podczas gdy HBase jest bardzo rozproszona baza danych.
HBase zapewnia wszystkie funkcje Google BigTable. Zaczęło się jako projekt firmy Powerset dotyczący przetwarzania ogromnych ilości danych na potrzeby wyszukiwania w języku naturalnym. Został opracowany jako część projektu Hadoop Apache i działa na bazie HDFS (rozproszony system plików Hadoop). Zapewnia odporne na błędy sposoby przechowywania dużych ilości rzadkich danych. HBase jest bardziej „magazynem danych” niż „bazą danych”, ponieważ brakuje w nim wielu funkcji dostępnych w RDBMS, takich jak wpisywane kolumny, dodatkowe indeksy, wyzwalacze i zaawansowane języki zapytań itp.
W bazach danych zorientowanych na kolumny tabela danych jest przechowywana jako sekcje kolumn danych, a nie jako wiersze danych. Model danych kolumnowej bazy danych składa się z nazwy tabeli, klucza wiersza, rodziny kolumn, kolumn, znacznika czasu. Podczas tworzenia tabel w HBase wiersze będą jednoznacznie identyfikowane za pomocą kluczy wierszy i znacznika czasu. W tym modelu danych rodzina słupów jest statyczna, podczas gdy słupy są dynamiczne. Przyjrzyjmy się teraz architekturze HBase.
Kiedy wybrać HBase?
HBase jest dobrą opcją tylko wtedy, gdy istnieją setki milionów lub miliardy wierszy. HBase może być również używany w niektórych miejscach, gdy rozważa się przejście z RDBMS do HBase jako całkowite przeprojektowanie, w przeciwieństwie do portu. Innymi słowy, HBase nie jest zoptymalizowany pod kątem klasycznych aplikacji transakcyjnych ani nawet analizy relacyjnej. Nie zastępuje również HDFS podczas wykonywania dużych partii MapReduce. W takim razie dlaczego warto wybrać HBase? Jeśli Twoja aplikacja ma zmienny schemat, w którym każdy wiersz jest nieco inny, powinieneś spojrzeć na HBase.
Architektura HBase:
Poniższy rysunek jasno wyjaśnia architekturę HBase.
W HBase istnieją trzy główne komponenty: Mistrz, serwer regionalny i opiekun zoo . Pozostałe składniki to Memstore, HFile i WAL.
Ponieważ HBase działa na HDFS, wykorzystuje architekturę Master-Slave, w której HMaster będzie węzłem głównym, a serwery regionu są węzłami podrzędnymi. Gdy klient wysyła żądanie zapisu, HMaster otrzymuje to żądanie i przekazuje je do odpowiedniego serwera regionu.
Serwer regionu:
Jest to system, który działa podobnie jak węzeł danych. Gdy serwer regionu (RS) otrzymuje żądanie zapisu, kieruje żądanie do określonego regionu. Każdy region przechowuje zestaw wierszy. Dane wierszy można podzielić na wiele rodzin kolumn (CF). Dane konkretnego CF są przechowywane w HStore, który składa się z Memstore i zestawu HFiles.
Co robi Memstore?
Memstore śledzi wszystkie dzienniki operacji odczytu i zapisu, które zostały wykonane na serwerze danego regionu. Na tej podstawie możemy powiedzieć, że zachowuje się podobnie do węzła nazw w Hadoop. Memstore jest magazynem w pamięci, dlatego Memstore wykorzystuje pamięć w pamięci każdego węzła danych do przechowywania dzienników. Po osiągnięciu określonych progów dane Memstore są przesyłane do HFile.
Głównym celem korzystania z Memstore jest potrzeba przechowywania danych w DFS uporządkowanych według klucza wiersza. Ponieważ HDFS jest przeznaczony do sekwencyjnych odczytów / zapisów, bez możliwości modyfikacji plików, HBase nie może efektywnie zapisywać danych na dysku podczas ich odbierania: zapisane dane nie będą sortowane (gdy dane wejściowe nie są sortowane), co oznacza, że nie są zoptymalizowane pod kątem przyszłości wyszukiwanie. Aby rozwiązać ten problem, HBase buforuje ostatnio odebrane dane w pamięci (w Memstore), „sortuje” je przed opróżnieniem, a następnie zapisuje do HDFS przy użyciu szybkich zapisów sekwencyjnych. Dlatego HFile zawiera listę posortowanych wierszy.
Za każdym razem, gdy Flush Memstore ma miejsce, jeden HFile tworzony dla każdego CF i częste rzuty mogą tworzyć tony HFiles. Ponieważ podczas czytania HBase będzie musiał spojrzeć na wiele HFiles, prędkość odczytu może ucierpieć. Aby zapobiec otwieraniu zbyt wielu plików HFiles i uniknąć pogorszenia wydajności odczytu, stosowany jest proces zagęszczania HFiles. HBase będzie okresowo (po spełnieniu określonych konfigurowalnych progów) kompaktować wiele mniejszych plików HFiles w jeden duży. Oczywiście im więcej plików utworzonych przez Memstore zostanie opróżnionych, tym więcej pracy (dodatkowe obciążenie) dla systemu. Co więcej, podczas gdy proces kompaktowania jest zwykle wykonywany równolegle z obsługą innych żądań i gdy HBase nie może nadążyć za kompaktowaniem HFiles (tak, są też skonfigurowane progi), ponownie zablokuje zapisy na RS. Jak omówiliśmy powyżej, jest to wysoce niepożądane.
Nie możemy być pewni, że dane będą trwałe w Memstore. Załóżmy, że określony węzeł danych nie działa. Następnie dane znajdujące się w pamięci tego węzła danych zostaną utracone.
Aby przezwyciężyć ten problem, gdy żądanie pochodzi od kapitana, zostało również przesłane do WAL. WAL to nic innego Zapisuj dzienniki z wyprzedzeniem który znajduje się na HDFS, trwałym magazynie. Teraz możemy się upewnić, że nawet jeśli węzeł danych nie działa, dane nie zostaną utracone, tj. mamy kopię wszystkich czynności, które masz wykonać w WAL. Gdy węzeł danych zostanie uruchomiony, ponownie wykona wszystkie czynności. Po zakończeniu operacji wszystko jest usuwane z Memstore i WAL i zapisywane w HFile, aby upewnić się, że nie zabraknie nam pamięci.
Weźmy prosty przykład, że chcę dodać wiersz 10, a następnie przychodzi żądanie zapisu, które mówi, że przekazuje wszystkie metadane do Memstore i WAL. Gdy ten konkretny wiersz zostanie zapisany w HFile, wszystko w Memstore i WAL zostanie opróżnione.
Zoo Keeper:
HBase jest zintegrowany z Zoo Keeper. Kiedy uruchamiam HBase, uruchamiana jest również instancja Zoo Keeper. Powodem jest to, że opiekun zoo pomaga nam w śledzeniu wszystkich serwerów regionalnych, które są dostępne dla HBase. Opiekun zoo śledzi, ile jest serwerów regionalnych, które serwery regionalne przechowują, z którego węzła danych do którego węzła danych. Śledzi mniejsze zestawy danych, w których brakuje Hadoop. Zmniejsza narzut na Hadoop, który śledzi większość danych Meta. Dlatego HMaster uzyskuje szczegółowe informacje o serwerach regionalnych, kontaktując się z opiekunem zoo.
Masz do nas pytanie? Wspomnij o nich w sekcji komentarzy, a my skontaktujemy się z Tobą.
Powiązane posty: