Hadoop – klastrów nigdy za wiele?

Ciągły rozwój oprogramowania Apache Hadoop sprawił, że jego możliwości zaczynają wychodzić poza uruchamianie pojedynczego zadania MapReduce na dużym zbiorze danych. Takie projekty, jak YARN czy Flink rozszerzają listę zastosowań, w których Hadoop może pochwalić się efektywnością działania.

Nowe projekty i komponenty rozwijane wokół Hadoopa skłoniły praktyków do poszukiwania kreatywnych sposobów przechowywania, przetwarzania i udostępniania danych do analiz. Coraz częściej mówi się o koncepcji jeziora danych (data lake) – pojedynczego repozytorium danych przechowywanych w systemie plików HDFS (Hadoop Distributed File System), które jest dostępne dla wielu aplikacji realizujących różne zadania. Główni dostawcy Hadoopa pokazali już na przekonujących przykładach, jak działa taki model. Jednak w rzeczywistym świecie wysoki poziom skomplikowania wdrożenia sprawia, że trudno dostosować ten model do klasycznych założeń Hadoopa: jeden zbiór – jedna aplikacja.

Wąskie gardło

Z wykorzystaniem Hadoopa można ze standardowych serwerów zbudować klaster do analizowania bardzo dużych zbiorów danych. Sercem rozwiązania jest MapReduce, mechanizm, który dzieli zbiór danych na mniejsze kawałki, które następnie analizuje oddzielnie, ale równolegle, a na koniec łączy ze sobą otrzymane rezultaty. Początkowo pozostałe elementy Hadoopa koncentrowały się na logistyce zarządzania klastrem, np. rozdzielaniem zadań pomiędzy dostępne maszyny czy przywracaniem po awariach pojedynczych serwerów.

Zobacz również:

  • IDC CIO Summit – potencjał drzemiący w algorytmach

MapReduce wciąż jest potężnym narzędzie do przetwarzania wsadowego dużych, statycznych zbiorów danych, ale gorzej nadaje się do innych zadań analitycznych, wliczając w to analitykę interaktywną, przetwarzanie strumieni danych z czujników, danych z serwisów społecznościowych czy bardziej skomplikowanych zadań przetwarzania w pamięci (in-memory). Wraz ze wzrostem zainteresowania Hadoopem zaczęły się regularnie podnosić głosy o konieczności rozszerzenia możliwości tego rozwiązania poza przetwarzanie wsadowe. Szereg projektów i produktów odpowiedziało na to zapotrzebowanie, ale kluczowy komponent Hadoopa, MapReduce, stał się wąskim gardłem wydajności, które trudno było obejść.

Wyzwalacz

W drugiej wersji Hadoopa wprowadzono Yet Another Resource Negotiator (YARN). Jest to główny komponent spośród inicjatyw podejmowanych przez społeczność Hadoopa w celu rozszerzenia listy możliwych zastosowań tego projektu. Rolą YARN jest zarządzanie zasobami w klastrze w taki sposób, aby ograniczyć zależność projektu od MapReduce i umożliwić realizowanie w klastrze zadań, które nie nadają się do przetwarzania z użyciem MapReduce. Poza tym z modułu MapReduce usunięto funkcje zarządzania klastrem i skoncentrowano się wyłącznie na specyfice realizowania zadań. Natomiast specjalne interfejsy API zapewniają zgodność z wcześniejszymi wersjami Hadoopa.

YARN jest rozwiązaniem do elastycznego zarządzania zasobami, które umożliwia jednoczesne uruchamianie wielu aplikacji na jednym klastrze Hadoopa. Zadania MapReduce, przetwarzanie strumieni danych w Storm oraz analiza grafów w Giraph mogą być jednocześnie uruchamiane na jednym klastrze. W tym czasie YARN odpowiada za alokację i realokację zasobów, jeśli zmienia się zapotrzebowanie. Zarządzanie zasobami klastra funkcjonue lepiej niż we wcześniejszych wersjach Hadoopa, a firmy stosujące to oprogramowanie do różnych zadań czerpią korzyści z lepszego wykorzystania poczynionych inwestycji.

YARN jest powszechnie uważany za klucz do dalszej dywersyfikacji Hadoopa i wzrostu jego popularności. Jednak faktyczne wsparcie branży IT dla jego możliwości pozostaje niepełne. Hortonworks, zagorzały zwolennik projektu YARN, pozostaje chyba najgłośniejszym zwolennikiem tego rozwiązania i promuje go w ramach własnej dystrybucji Hadoopa. Konkurencyjne dystrybucje Hadoopa - Cloudera , MapR , Pivotal i inne - również zawierają to oprogramowanie, ale zajmie jeszcze nieco czasu, zanim wszystkie projekty i produkty w ekosystemie Hadoopa będą w pełni wykorzystywać zalety, którymi cechuje się YARN.

YARN odgrywa ważną role w zarządzaniu przetwarzaniem zadań w klastrze. Jednak za wszystkimi zadaniami MapReduce, analizą strumieni danych i innymi procesami związanymi z danymi, funkcjonuje jeszcze jeden współdzielony komponenty architektury Hadoopa: HDFS. Jest to rozproszony system plików mający przechowywać dane wymagane przez klaster Hadoopa. Ważną cechą HDFS jest możliwość skalowania, aby zapewnić przestrzeń do przechowywania niekiedy setek petabajtów danych na tysiącach węzłów. HDFS jest niezawodny i odporny na błędy, potrafi rozpoznawać awarie sprzętowe poszczególnych serwerów w klastrze. Dane przechowuje w przynajmniej trzech węzłach, co znacznie obniża ryzyko ich utraty. Hadoop wie, gdzie dane są przechowywane, co umożliwia optymalizację przydzielania zasobów (węzłów) do realizacji poszczególnych zadań. Z reguły zadania są przydzielane do bezczynnych węzłów znajdujących się najbliżej analizowanych danych, co ogranicza potrzebę przesyłania tych danych przez sieć i przekłada się na większą wydajność klastra.

Tzw. NameNode odpowiada za: przechowywanie metadanych o informacjach zapisanych w klastrze HDFS; śledzenie, gdzie dane są przechowywane; pilnowanie, żeby dane były replikowane oraz zarządzanie tym replikami. Z kolei poszczególne DataNode w klastrze odpowiadają za udostępnianie danych procesom Hadoopa.

Jezioro danych

Łącząc YARN I HDFS otrzymujemy bardzo duże możliwości, które można wykorzystać do realizowania rosnącego zakresu zadań związanych z przetwarzaniem danych. Połączenie niezawodności i skalowalności HDFS z rosnącymi możliwościami YARN powoduje wzrost zainteresowania koncepcją jeziora danych. Patrząc na sprawę czysto teoretycznie, jezioro danych to pojedyncze źródło wszystkich danych potrzebnych w określonym projekcie, przepływie pracy czy nawet w całej firmie. Zamiast przechowywania przez każdą aplikację własnych danych, co często prowadzi do powstania duplikatów, koncepcja jeziora danych zakłada, że wszystkie aplikacje zapisują dane do jednego zbioru i również z tego zbioru wspólnie odczytują dane.

Mając do dyspozycji HDFS odpowiedzialny za przechowywanie danych i YARN zajmujący się przydzielaniem dostępu różnym aplikacjom działającym w danym klastrze, producenci Hadoopa zapewniają, że są w stanie dostarczyć rozwiązania do budowy jeziora danych. Takie firmy, jak Pivotal, zaczynają dostrzegać zalety tego podejścia, np. skrócenie czasu potrzebnego do otrzymania wyników przetwarzania.

Szybszy zamiennik Hadoopa

Najnowszym projektem ze stajni Apache jest Flink. Podobnie jak Spark, Flink potrafi realizować zadania wsadowe lub operować na strumieniach danych. Według twórców charakteryzują się łatwością użycia i lepszą wydajnością niż Hadoop. Strumienie danych przetwarzania w trybie in-memory, co zwiększa wydajność. Jest więc świetnym zamiennikiem Hadoopa tam, gdzie potrzebna jest większa wydajność. Natomiast łatwość użycia zawdzięcza interfejsom programistycznym (API), które są łatwiejsze w użyciu niż programowanie zadań MapReduce. Oprogramowanie jest już testowane, m.in. przez Spotify.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200