Co masz na myśli mówiąc „Mamy klaster Hadoopa”? Najczęściej w dużym uproszczeniu nazywamy tak jedną z dystrybucji Cloudera lub Hortonworks albo MapR. Jakie usługi potrzebujesz do uruchomienia klastra Hadoop?
W poniższym wpisie opowiem Tobie o podstawowych i kluczowych usługach, których potrzebujesz do uruchomienia klastra Hadoop.
Nagrałem również do tego podcast w oparciu o poniższy materiał. Jeżeli preferujesz wersję audio możesz odsłuchać poniżej lub na Spotify na kanale iLoveData – Podcast o danych.
Do najpopularniejszych dystrybucji Hadoop należą właśnie te trzy:
- Cloudera Distribution Hadoop(CDH)
- Hortonworks Data Platform(HDP)
- MapR Converged Data Platform
W przypadku Cloudera i Hortonworks to obecnie jedna firma. Ze względu na dalej funkcjonujące różne dystrybucje, które mają wsparcie będę używać tego rozróżnienia.
Generalnie gama usług na potrzeby Big Data jest szeroka. W zależności od dystrybucji, są pewne różnice, np. sposób zarządzania klastrem z użyciem różnego GUI. Wykonywanie zapytań SQL czy to z użyciem Impali czy Hive. W tym momencie nie będziemy rozmawiać o różnicach czy wydajności, ale skupię się na klasycznej sytuacji klastra bez dodatków.
Usługi, z którymi zapoznasz się to:
- HDFS
- YARN
- Apache Zookeeper
- Apache Hive Metastore
Jakie są wymagane właściwości takiego systemu Big Data:
- Skalowalność – ponieważ architektura Hadoop jest klastrowa, możemy w łatwy sposób zwiększać wydajność naszego klastra poprzez dodawanie kolejnych zasobów do systemu. W związku z tym, że mamy tutaj do czynienia ze skalowaniem poziomym to odbywa się ono poprzez dodawanie kolejnych maszyn.
- Niezawodność i odporność na błędy – bez względu na losowe awarie maszyn nasz system powinien funkcjonować bez zakłóceń. Replikacja danych jest jednym z kluczowych elementów takie rozwiązania. Dzięki narzędziom umożliwiającym pracę w trybie High Availability(HA) mamy możliwość nieprzerwanego dostępu do danych pomimo awarii jednego z serwerów. W kontekście replikacji danych jest taki parametr replication_factor, który domyślnie ma wartość 3. Co znaczy, że każdy z bloków jest w trzech miejscach.
- Elastyczność – Ilość usług, które wchodzą w skład całego ecosystemu Hadoop sprawia, że mamy możliwość przetwarzania danych ustrukturyzowanych oraz nieustrukturyzowanych.
- Mądre zarządzanie zasobami – mądre i wydajne, ponieważ zadania dzielone są odpowiednio pomiędzy maszyny, tak, aby wykorzystać pełną moc obliczeniową klastra.
HDFS
Rozwinięcie skrótu dla tej usługi to Hadoop Distributed File System. Przede wszystkim to rozproszony system plików. Sam w sobie zoptymalizowany do przechowywania bardzo dużych ilości danych. Podczas przechowywania plików, HDFS dzieli je na bloki, których domyślny rozmiar to 128MB. Oczywiście przechowuje replikę każdego bloku na pozostałych serwerach. To jest to o czym wspomniałem wcześniej – parametr replication_factor.
Każdy WorkerNode, czyli ta maszyna, na której będą przechowywane dane uruchamia usługę o nazwie DataNode. Usługa ta jest odpowiedzialna za przyjmowanie nowych bloków danych i przechowywanie ich na dyskach lokalnych.
Konkretny DataNode ma tylko wiedzę o blokach i identyfikatorach, które przechowuje u siebie. Nie ma wiedzy na temat replik danego bloku. Tą funkcję przejmuje NameNode, który jest odpowiedzialny za mapowanie plików na bloki i przechowywanie metadanych dotyczących samych plików. Takich jak nazwy, uprawnienia, atrybuty i współczynnik replikacji. Muszę wspomnieć, że o ile replication_factor jest ustawiany na poziomie globalnym to możesz zmodyfikować ilość replik dla konkretnego pliku.
HDFS jest odporny na uszkodzenia, ponieważ awaria pojedynczego dysku nie zagraża bezpieczeństwu danych. Jeżeli taka sytuacja nas spotka to NameNode przekieruje z jednego DataNode replikę danych, w celu skopiowania bloku do innego DataNode. Proces będzie powtarzany tak długo, aż współczynnik replikacji nie zostanie przywrócony. Oczywiście nie mówię tutaj o skrajnych przypadkach i klastrach w stylu „Big Data for small business”, ale klastrach o wystarczającej pojemności i nadmiarowości.
HDFS jest skalowalny, system plików możemy po prostu zwiększyć poprzez dodanie nowego DataNode do naszego klastra.
Oczywiście, aby skorzystać z udogodnień w postaci odporności na uszkodzenia i skalowalności musimy też przyłożyć do tego rękę, poprzez dobranie odpowiednich serwerów (niezależnie od tego czy będzie to cloud czy on-premise) oraz zaprojektować odpowiednią architekturę naszego klastra, aby w pełni korzystać z możliwości, które oferuje HDFS. W dużym skrócie mam na myśli konfiguracji wysokiej dostępności dla takich usługa jak np. NameNode, wydzielenie DataNode itd.
YARN
Pomówmy teraz o YARNie, czyli Yet Another Resource Negotiator. Nie myl proszę z YARN’em, który występuje w web developmencie będąc managerem pakietów.
YARN w Hadoop jest niczym innym jak usługą do zarządzania zasobami w klastrze. Efektywne wykonywanie obliczeń na klastrze, przydział zasobów to wszystko zasługa YARN.
Każdy zadanie(eng. job) przetwarza różnej wielkości dane i w zależności od złożoności tego zadania potrzebuje różnych mocy obliczeniowych i pamięci. Aby dało się to wszystko ogarnąć potrzebujemy scentralizowanego managera klastra, który wie, jakie są aktualne dostępne zasoby i przeciążenie – to jest właśnie zadanie dla YARN.
YARN uruchamia daemon na każdym WorkerNode nazywany NodeManager, który informuje do głównego procesu zwanego ResourceManager. Informacje jakie przekazuje to, np. ile vcores jest wolnych lub wolnej pamięci na jego węźle(ang. node). Co ważne takie zasoby są rozdzielane w formie kontenerów, z który każdy z nich ma określone zasoby.
Dajmy na to 5 kontenerów, gdzie każdy ma po 4 vcores i 12GB RAM. NodeManagery są odpowiedzialne za uruchamianie oraz monitorowanie tych kontenerów w ramach swojego hosta. Dodatkowo w przypadku przekroczenia przydzielonych zasobów, taki kontener zostanie „zabity”.
Generalnie schemat działania jest taki:
- Aplikacja, która będzie uruchamiana na klastrze musi poprosić RM o pojedynczy kontener, w którym uruchamia własny proces koordynacji o nazwie ApplicationMaster(AM).
- Po uruchomieniu Application Mastera, żąda on od RM dodatkowych kontenerów, aby móc przejść już do właściwego procesu obliczania/wykonywania naszej aplikacji.
Co dalej? ResourceManager uruchamia specjalny wątek, który jest odpowiedzialny za zapewnienie równego alokowania kontenerów pomiędzy aplikacjami i użytkownikami w klastrze. Oczywiście scheduler stara się w miarę sprawiedliwie przydzielać zasoby pomiędzy aplikacje. Warto pamiętać również o tym, że możemy definiować kolejki, w których przypisujemy procentowy udział zasobów dla danej aplikacji. Suma powinna dać 100%.
Zauważ, że tak na prawdę YARN nie wykonuje żadnych obliczeń. Służy raczej do uruchamiania aplikacji rozproszonych po klastrze.
Zookeeper
Przejdźmy do kolejnej usługi w ramach obowiązkowego elementu stacku Hadoop, ale wcześniej wyobraźmy sobie taką kwestię. Mamy dwa NameNode’y i któryś z nich musi być w trybie Active, a drugi pozostać w trybie Standby. Co zrobić, w jaki sposób zdecydować?
No właśnie do tego służy Zookeeper. Jest to nic innego jak usługa, która dąży do konsensusu, który serwer bądź usługa, staje się masterem a która przechodzi w tryb standby. Rozproszone procesy nawiązują komunikację poprzez hierarchiczną przestrzeń nazw, która składa się z rejestrów danych zwanych znodami, z których każdy może przechowywać dane i być rodzicem dla potomnego. Działa to na zasadzie drzewa.
Zookeeper działa na zasadzie konsensusu większości i do utworzenia kworum wymagana jest nieparzysta liczba serwerów. Generalnie możesz posiadać parzystą liczbę serwerów, np. 4, ale dołożenie jednego serwera nie zapewni dodatkowej odporności na awarię. Każdy serwer na identyczną funkcjonalność, ale jeden z serwerów staje się liderem, a pozostałe są jego obserwatorami(eng. followers).
Jakie usługi z ecosystemu Hadoop potrzebują Zookeepera?
- Dla YARN i MapReduce, Zookeeper używamy w celu obsługi High Availability dla ResourceManagera.
- Dla HDFS również dla koordynacji wysokiej dostępności.
- W przypadku HBase, Zookeeper używamy do wyboru Master serwera i koordynacji pracy pomiędzy serwerami.
- W przypadku Flume’a, używamy go do współdzielania konfiguracji.
To oczywiście tylko wybrane usługi dla których Zookeepera robi dobrą robotę 🙂
Hive Metastore
Hive Metastore jest usługą, która przechowuje szczegółowe dane dotyczące metadanych. Czyli kolumny, typy danych, zastosowana kompresja danych, formaty wejściowe i wyjściowe itd. dla tabel i baz danych, które zlokalizowane są na HDFS. Możemy to nazwać centralnym repozytorium schematów, które używane jest przez narzędzia takie jak Apache Spark, Interactive Query(LLAP).
W rezultacie każde zapytanie wykonane przez Hive’a będzie odpytywać NameNode, w celu uzyskania metadanych – tzn. informacje o plikach, katalogach oraz odpowiadających im blokach.
Podsumowanie
W ramach tego wpisu omówiłem najważniejsze komponenty występujące w każdym klastrze Hadoop. Pamiętaj, że do postawienia klastra Hadoop usługi takie jak te wspomniane wcześniej są niezbędne:
- HDFS
- YARN
- Apache Zookeeper
- Apache Hive Metastore
Odrębną kwestią oczywiście jest odpowiednia konfiguracja w kontekście wysokiej dostępności. O tym będę opowiadać w innym odcinku podcastu oraz wpisie.
PS W dobie wzrostu zachorowań na COVID-19, uważaj na siebie! Jeżeli przyjdzie Tobie pracować z domu, przeczytaj wpis, który przygotowałem jakiś czas temu jak pracować zdalnie, ale efektywnie.