Big data Hadoop – jak działa ekosystem i kiedy wdrożyć go w firmie

Big data Hadoop to fundament, na którym od lat opiera się przetwarzanie zbiorów danych liczonych w petabajtach, a nie w gigabajtach. Kiedy pojedynczy serwer przestaje mieścić logi, transakcje i zdarzenia z aplikacji, big data Hadoop pozwala rozłożyć ten ciężar na dziesiątki tanich maszyn, które działają jak jeden organizm. Ekosystem powstał w odpowiedzi na problem, którego klasyczne bazy relacyjne nie rozwiązywały: jak czytać terabajty sekwencyjnie, taniej niż z macierzy dyskowych, i jak przetrwać awarię pojedynczego węzła bez utraty ani jednego bajtu. Odpowiedzią był rozproszony system plików HDFS, warstwa zarządzania zasobami YARN oraz model obliczeniowy MapReduce. Wokół tego rdzenia narosły dziesiątki narzędzi: Hive, HBase, Sqoop, Oozie, Flume i Spark. Ten przewodnik pokazuje architekturę bez marketingowego lukru, realne koszty w złotówkach oraz sytuacje, w których wdrożenie klastra jest błędem. Znajdziesz tu również porównanie z alternatywami chmurowymi i listę kompetencji, których wymaga utrzymanie takiego środowiska.

Architektura klastra: HDFS, YARN i MapReduce

Rdzeniem jest HDFS, czyli rozproszony system plików dzielący każdy zbiór na bloki o rozmiarze 128 lub 256 MB. Każdy blok trafia domyślnie na trzy różne węzły, najlepiej w dwóch szafach rack. Utrata dysku, zasilacza czy całego serwera nie zatrzymuje odczytu, bo replika jest zawsze pod ręką.

NameNode przechowuje metadane, czyli mapę bloków i katalogów, w pamięci RAM, dlatego jego wielkość ogranicza liczbę plików w klastrze. DataNode raportują stan dysków co kilka sekund. Gdy sygnał ustaje, koordynator odtwarza brakujące repliki na innych maszynach, bez ingerencji administratora. Cały mechanizm działa w tle i jest niewidoczny dla aplikacji.

YARN pełni funkcję systemu operacyjnego klastra. ResourceManager przydziela kontenery z określonym limitem rdzeni i pamięci, a NodeManager pilnuje, by zadanie nie przekroczyło przydziału. Dzięki temu na jednym środowisku równolegle pracują zadania wsadowe, zapytania interaktywne i strumienie zdarzeń, bez wzajemnego zagłodzenia zasobów przez najbardziej zachłanny proces.

MapReduce dzieli obliczenie na fazę mapowania, sortowanie pośrednie i redukcję. Model jest prosty, ale zapis wyników pośrednich na dysk kosztuje czas, dlatego większość zespołów uruchamia dziś logikę w Sparku na tym samym klastrze. Sam paradygmat pozostaje jednak sercem tego, czym jest big data Hadoop w praktyce inżynierskiej.

Ekosystem narzędzi, który wyrósł wokół rdzenia

Sam rdzeń rzadko wystarcza. Sqoop przenosi tabele z baz relacyjnych do HDFS, Flume i Kafka zbierają strumienie zdarzeń, Oozie i Airflow planują przepływy, a ZooKeeper koordynuje usługi rozproszone. Dobór komponentów przypomina składanie serwera z podzespołów: każdy element musi pasować wersją i konfiguracją do reszty.

Format zapisu decyduje o wydajności bardziej niż liczba węzłów. Kolumnowy Parquet z kompresją Snappy potrafi zmniejszyć wolumen o 70 procent względem plików CSV i przyspieszyć zapytania kilkukrotnie, bo silnik czyta wyłącznie potrzebne kolumny. ORC daje podobne rezultaty w środowiskach opartych na Hive.

Największą pułapką jest problem małych plików. Milion dokumentów po 20 kB obciąża metadane bardziej niż jeden plik o rozmiarze 20 GB, a każde zadanie tworzy osobny task. Regularna kompakcja i sensowne partycjonowanie po dacie zdarzenia rozwiązują ten kłopot szybciej niż dokupienie kolejnych serwerów.

Hive, HBase i warstwa zapytań SQL

Hive udostępnia składnię zbliżoną do SQL i tłumaczy zapytania na zadania rozproszone. Analityk pisze SELECT z GROUP BY, a silnik sam decyduje o liczbie kontenerów. HBase odpowiada za odczyt pojedynczych rekordów w milisekundach, co czyni go bazą pod aplikacje operacyjne, a nie raporty wsadowe.

Przy projektowaniu warstwy zapytań role poszczególnych narzędzi rozkładają się następująco:

• Hive – raporty wsadowe i agregacje po dziesiątkach miliardów wierszy
• Impala lub Trino – zapytania interaktywne zwracające wynik w kilka sekund
• HBase – losowy dostęp do pojedynczych kluczy przy dużej liczbie zapytań na sekundę
• Spark SQL – transformacje, wzbogacanie danych i uczenie maszynowe w jednym silniku
• Kafka – bufor zdarzeń przed zapisem do magazynu rozproszonego

Rozdzielenie obowiązków chroni przed sytuacją, w której ciężki raport miesięczny blokuje panel operacyjny sprzedaży. Kolejki YARN z limitami procentowymi porządkują ruch, a osobna pula zasobów dla zadań ad hoc pozwala analitykom testować hipotezy bez zgody administratora. Taki podział ogranicza też liczbę awaryjnych zgłoszeń po godzinach.

Stacja robocza inżyniera danych i warstwa sprzętowa

Praca z klastrem to w 90 procentach terminal, edytor konfiguracji i dashboardy. Dobry monitor do komputera o przekątnej 27 cali i rozdzielczości 1440p mieści obok siebie logi YARN, kod PySpark i plan zapytania, co eliminuje ciągłe przełączanie okien. Koszt sensownego modelu zaczyna się od około 1200 zł.

Peryferia i lokalne środowisko testowe

Klawiatura mechaniczna z przełącznikami liniowymi to inwestycja rzędu 350–700 zł, która przy kilku tysiącach znaków dziennie realnie zmniejsza zmęczenie nadgarstków. Klawiatura gamingowa mechaniczna z podświetleniem i makrami sprawdza się równie dobrze, bo makra można przypisać do często powtarzanych poleceń klastra. Format tenkeyless zwalnia przy tym miejsce na biurku.

Zwolennicy minimalizmu wybierają układ 60 procent, choć klawiatura mechaniczna 60 wymaga przyzwyczajenia się do warstw funkcyjnych zamiast dedykowanych klawiszy strzałek. Tablet graficzny wacom bywa nieoczywistym dodatkiem: przy rysowaniu schematów przepływu danych i architektury klastra działa szybciej niż mysz i dowolny edytor diagramów.

Środowisko testowe nie wymaga serwerowni. Pojedynczy ovh vps z 8 GB RAM i czterema rdzeniami, w cenie kilkudziesięciu złotych miesięcznie, obsłuży tryb pseudorozproszony, kontenery Dockera z Hive Metastore oraz repozytorium kodu. To wystarczy, by przećwiczyć konfigurację przed sięgnięciem po prawdziwy klaster.

Koszty klastra: sprzęt, chmura, licencje i ludzie

Budżet klastra rozkłada się na trzy pozycje: sprzęt lub instancje, licencje wsparcia oraz czas ludzi. Węzeł roboczy z 12 dyskami po 4 TB, 128 GB RAM i dwoma procesorami kosztuje w Polsce mniej więcej 25–40 tys. zł netto. Minimalny sensowny klaster produkcyjny to sześć takich maszyn.

Największy koszt to jednak kompetencje. Inżynier danych z doświadczeniem w Sparku i Kafce oczekuje w Polsce 18–28 tys. zł brutto miesięcznie, a zespół utrzymaniowy potrzebuje minimum dwóch takich osób, żeby dyżury nie kończyły się wypaleniem po pół roku. Rekrutacja trwa zwykle kilka miesięcy.

W kalkulacji łatwo pominąć pozycje miękkie: licencje na narzędzia BI, konta pocztowe i dyski współdzielone. Tu google workspace cena zaczyna się od około 28 zł za użytkownika miesięcznie w wariancie podstawowym. Przy dwudziestoosobowym zespole analitycznym daje to kilkanaście tysięcy złotych rocznie, zanim ktokolwiek uruchomi pierwsze zapytanie na klastrze.

Decyzja o tym, czy big data Hadoop opłaca się we własnej serwerowni, sprowadza się do prostego porównania: jeśli przetwarzasz mniej niż kilkadziesiąt terabajtów i zadania mieszczą się w oknie nocnym, hurtownia chmurowa rozliczana za zapytanie wypada taniej. Powyżej tego progu rachunek zaczyna przechylać się w stronę własnego klastra.

Dane z klastra w analityce witryn i marketingu

Logi serwerowe i dane behawioralne to naturalne paliwo dla klastra. Sklep z milionem sesji miesięcznie generuje wolumen, którego arkusz kalkulacyjny nie udźwignie, a analiza ścieżek zakupowych wymaga łączenia zdarzeń z kilkunastu źródeł: kampanii, wyszukiwarki, newslettera i porównywarek cen. Klaster łączy te strumienie w jedną tabelę faktów.

Zespoły odpowiedzialne za pozycjonowanie strony wykorzystują takie zbiory do analizy logów robotów. Zestawienie budżetu indeksowania z realnymi wejściami pokazuje, które szablony marnują zasoby wyszukiwarki. Przy dużych serwisach informacyjnych takie raporty potrafią wskazać dziesiątki tysięcy adresów, których robot nigdy nie odwiedził. To materiał na konkretne decyzje techniczne, nie na domysły.

Po stronie e-commerce feed produktowy wysyłany do google merchant można walidować właśnie na klastrze: reguły cenowe, dostępność i zgodność EAN sprawdza się szybciej wsadowo niż w interfejsie panelu. Efekty tej pracy widać potem w rankingach, bo pozycjonowanie strony w google premiuje kompletne i spójne dane produktowe.

Warstwa prezentacji bywa zaskakująco prosta. Raport wraca do CMS-a przez API, więc wystarczy standardowe wordpress logowanie, żeby zobaczyć pulpit z metrykami. Agencje, których specjalnością jest projektowanie stron internetowych, coraz częściej dokładają taki moduł do wdrożeń, bo twarde dane ułatwiają rozmowę o budżecie.

Jak zacząć naukę Hadoopa bez dostępu do klastra produkcyjnego?

Najprostsza droga prowadzi przez tryb pseudorozproszony na jednej maszynie. Instalujesz dystrybucję Apache, uruchamiasz NameNode, DataNode i ResourceManager jako osobne procesy, a następnie ładujesz kilka gigabajtów publicznych danych, na przykład logów lotów albo zbiorów statystyki publicznej. Drugi krok to Docker Compose z Hive Metastore, Sparkiem i MinIO w roli magazynu obiektowego. Trzeci krok to napisanie realnego zadania: wczytanie plików CSV, konwersja do Parquet, partycjonowanie po dacie i agregacja z oknem czasowym. Dopiero taka sekwencja pokazuje, gdzie leżą prawdziwe problemy: skośne klucze, zbyt małe pliki, źle dobrana liczba partycji i pamięć egzekutorów. Kurs bez własnoręcznie zepsutego i naprawionego klastra niewiele daje.

Czy Hadoop został wyparty przez Sparka i hurtownie chmurowe?

Nie w całości, choć podział ról wyraźnie się przesunął. MapReduce jako silnik obliczeniowy przegrał ze Sparkiem, który trzyma dane pośrednie w pamięci i bywa kilkukrotnie szybszy przy zadaniach iteracyjnych. HDFS i YARN nadal jednak pracują w setkach dużych organizacji, zwłaszcza tam, gdzie dane nie mogą opuścić własnej infrastruktury z powodów regulacyjnych albo gdzie wolumen czyni transfer do chmury nieopłacalnym. Coraz częściej spotyka się modele mieszane: magazyn obiektowy zamiast HDFS, Kubernetes zamiast YARN i Spark jako jedyny silnik. Kompetencje zdobyte przy klasycznym klastrze przenoszą się na te architektury niemal jeden do jednego, bo problemy z partycjonowaniem i skośnością danych pozostają identyczne.

Co odróżnia klaster Hadoop od klasycznej hurtowni danych?

Hurtownia wymaga zdefiniowania schematu przed zapisem, a klaster pozwala zapisać surowe pliki i nadać im strukturę dopiero w momencie odczytu. To różnica między schema-on-write a schema-on-read i ma konsekwencje praktyczne: do jeziora danych wrzucisz pliki JSON z aplikacji mobilnej, nagrania zdarzeń i logi bez wcześniejszej normalizacji. Druga różnica dotyczy skali kosztowej, bo pojemność rośnie liniowo wraz z liczbą tanich serwerów, podczas gdy licencje hurtowni rosną skokowo. Trzecia to elastyczność obliczeń: obok SQL uruchomisz kod w Pythonie, Scali czy R na tych samych plikach. Dlatego big data Hadoop najczęściej nie zastępuje hurtowni, lecz stanowi warstwę poprzedzającą ją w architekturze.