Andrzej Klusiewicz

Posted on Sep 18

Czym jest Apache Hive - kompleksowy przewodnik dla początkujących

#hive

Czym jest Apache Hive, jak działa od środka i kiedy warto go użyć. Architektura, HiveQL, schema-on-read, partycjonowanie, formaty ORC i Parquet oraz silniki Ma…

Big Data · Przewodnik

Zespół JSystems · przewodnik 2026 · czas czytania ok. 15 min

Jak Apache Hive zamienia zwykłe zapytanie SQL na zadania rozproszone i zwraca wynik. Tę drogę - od HiveQL po dane w HDFS - rozłożymy w tym artykule na czynniki pierwsze.

Apache Hive to jedno z tych narzędzi, które sprawiły, że świat Big Data przestał być zarezerwowany wyłącznie dla programistów Javy. Zamiast pisać skomplikowany kod, analityk może odpytać petabajty danych zwykłym językiem SQL. W tym przewodniku wyjaśnimy prostym językiem, czym Hive jest, jak działa od środka i kiedy naprawdę warto po niego sięgnąć. Wszystko pokażemy na żywym Hive uruchomionym w kontenerze, na realnym zbiorze 53 031 transakcji sprzedaży.

Z tego artykułu dowiesz się

Czym jest Apache Hive

Apache Hive to hurtownia danych zbudowana na platformie Hadoop, która pozwala odpytywać ogromne zbiory danych językiem bardzo zbliżonym do SQL. Mówiąc najprościej: Hive daje Ci znany interfejs bazy danych (tabele, kolumny, zapytania SELECT) nad danymi, które fizycznie leżą jako pliki w rozproszonym systemie plików. Nie musisz wiedzieć, na ilu maszynach te pliki są rozrzucone ani jak są przetwarzane równolegle - piszesz zapytanie, a Hive robi resztę.

Kluczowe pojęcie, które warto od razu oswoić, to Hadoop. To otwarta platforma do przechowywania i przetwarzania danych na wielu maszynach naraz (tak zwanym klastrze). Jej sercem jest HDFS (Hadoop Distributed File System), czyli rozproszony system plików - dane są dzielone na bloki i rozkładane na wielu serwerach, z kopiami na wypadek awarii. Hive dokłada do tego warstwę, dzięki której z tymi plikami rozmawiasz jak ze zwykłą bazą.

Językiem Hive jest HiveQL - dialekt SQL. Jeśli znasz SELECT, JOIN i GROUP BY, to w Hive poczujesz się od razu jak w domu. Różnice wobec klasycznego SQL są, ale dla początkującego kosmetyczne. To była zresztą główna idea Hive: pozwolić tysiącom analityków i osób znających SQL pracować na danych w Hadoopie, bez przepisywania wszystkiego na niskopoziomowy kod.

Po co powstał Hive

Hive narodził się w Facebooku pod koniec pierwszej dekady XXI wieku. Firma miała dane rosnące szybciej, niż nadążały klasyczne bazy, i przeniosła je do Hadoopa. Problem w tym, że jedynym sposobem odpytywania Hadoopa był wtedy MapReduce - model przetwarzania, w którym każde zadanie trzeba było napisać ręcznie w Javie jako parę funkcji (mapującą i redukującą). Policzenie czegoś tak prostego jak liczba wierszy w podziale na regiony potrafiło zająć dziesiątki linii kodu i sporo czasu programisty.

Hive rozwiązał to elegancko. Zamiast pisać MapReduce ręcznie, wpisujesz zapytanie SQL, a Hive sam tłumaczy je na zadania rozproszone. Nagle analityk, który nigdy nie napisał linijki Javy, mógł samodzielnie liczyć na danych ważących terabajty. To otworzyło Big Data na znacznie szersze grono odbiorców i do dziś jest to najmocniejszy argument za tym narzędziem. Jeśli chcesz zobaczyć szerszy obraz tego, jak Hive wpisuje się w dzisiejszy krajobraz przetwarzania danych, opisaliśmy go w artykule o współczesnych rozwiązaniach Big Data.

Architektura Hive: z czego to się składa

Żeby zrozumieć Hive, trzeba zobaczyć, że to nie jest jeden program, lecz kilka współpracujących elementów nałożonych na Hadoop. Poniższa infografika pokazuje sześć składników, które razem robią z Hadoopa hurtownię z dostępem przez SQL.

Sześć elementów architektury Hive. Dane leżą w HDFS, zasobami klastra dzieli YARN, a Hive dokłada serwer zapytań, katalog metadanych i silnik tłumaczący SQL na zadania rozproszone.

Prześledźmy te elementy po kolei, bo do każdego z nich będziemy jeszcze wracać:

Klient - stąd wysyłasz zapytania. Może to być konsolowy program Beeline, sterownik JDBC/ODBC albo narzędzie analityczne. W tym artykule pracujemy w Beeline.
HiveServer2 - serwer, który przyjmuje zapytania, kompiluje HiveQL i buduje plan wykonania. To z nim łączy się klient.
Metastore - katalog metadanych. Przechowuje definicje baz, tabel, kolumn i partycji oraz informację, gdzie fizycznie leżą pliki. To dlatego Hive wie, że tabela ma takie a nie inne kolumny. Metadane trzymane są zwykle w zwykłej bazie relacyjnej.
Silnik wykonawczy - zamienia plan zapytania na konkretne zadania liczące dane. Może to być MapReduce, Tez lub Spark. Do tego wątku wrócimy osobno.
YARN - zarządca zasobów klastra. Przydziela zadaniom pamięć i moc obliczeniową (procesor).
HDFS - rozproszony system plików, w którym fizycznie leżą dane.

Hive udostępnia też prosty panel WWW (Web UI serwera HiveServer2), w którym widać uruchomione i zakończone zapytania. Poniżej nasz działający Hive tuż po wykonaniu kilku zapytań demonstracyjnych - zwróć uwagę na kolumnę Execution Engine z wartością tez.

Panel WWW HiveServer2 na naszym środowisku demonstracyjnym. Widać listę zakończonych zapytań wraz z użytym silnikiem wykonawczym (tez) i czasem wykonania.

HiveQL i schema-on-read: najpierw dane, potem schemat

Tu pojawia się jedna z najważniejszych różnic między Hive a klasyczną bazą. Tradycyjna baza działa w modelu schema-on-write (schemat przy zapisie) - najpierw definiujesz tabelę, a potem baza sprawdza każdy ładowany wiersz i odrzuca dane niezgodne ze schematem. Hive domyślnie działa odwrotnie, w modelu schema-on-read (schemat przy odczycie): najpierw wrzucasz surowe pliki, a schemat nakładasz na nie dopiero w momencie tworzenia tabeli i odczytu.

Schema-on-read kontra schema-on-write. Klasyczna baza waliduje dane przy zapisie, Hive nakłada schemat dopiero przy odczycie - dzięki temu przyjmuje ogromne, surowe zbiory bez długiego przygotowania.

W praktyce wygląda to tak, że mamy w rozproszonym systemie plików zwykły plik CSV ze sprzedażą, a następnie tworzymy nad nim tabelę zewnętrzną (external table). Słowo zewnętrzna oznacza, że Hive tylko wskazuje na istniejące pliki i nimi zarządza, ale nie jest ich właścicielem - skasowanie tabeli nie usunie danych. Oto polecenie, którym nałożyliśmy schemat na nasz plik sprzedaży:

Kopiuj

CREATE EXTERNAL TABLE sprzedaz_raw (
  id          INT,
  data        STRING,
  product_id  INT,
  region      STRING,
  ilosc       INT,
  kanal       STRING
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
STORED AS TEXTFILE
LOCATION '/data/sprzedaz';

Po utworzeniu tabeli możemy podejrzeć jej strukturę poleceniem DESCRIBE. Hive zna kolumny nie dlatego, że przeanalizował plik, ale dlatego, że taki schemat sami zadeklarowaliśmy - i zapamiętał go Metastore.

Polecenie DESCRIBE zwraca schemat tabeli zewnętrznej. To metadane z Metastore, nałożone na surowy plik CSV.

Teraz najciekawsze: mimo że pod spodem leży zwykły plik tekstowy, możemy go odpytać jak każdą tabelę. Podejrzyjmy kilka pierwszych wierszy naszych realnych danych.

Zapytanie z ograniczeniem liczby wierszy zwraca surowe rekordy sprzedaży. To ten sam plik CSV, tylko widziany oczami Hive jako tabela.

Obok tabeli faktów ze sprzedażą mamy drugą, mniejszą tabelę - wymiar produktów. To klasyczny podział w hurtowni: duża tabela zdarzeń (transakcje) i małe tabele opisowe (produkty, kategorie), które za chwilę połączymy zapytaniem.

Wymiar produktów: dwadzieścia pozycji w pięciu kategoriach. Ta mała tabela posłuży nam do łączenia (JOIN) z dużą tabelą sprzedaży.

Ile w ogóle mamy danych? Jedno proste zapytanie liczące i już wiemy, że pracujemy na ponad pięćdziesięciu tysiącach transakcji.

Zbiór liczy 53 031 transakcji. Na tak małym wolumenie Hive to armata na muchę - ale dokładnie te same zapytania zadziałają na miliardach wierszy.

Zapytania analityczne: GROUP BY i JOIN

Skoro mamy tabele, zadajmy im pytania biznesowe. Zacznijmy od agregacji: ile transakcji i ile sprzedanych sztuk przypada na każdy region. To zwykły GROUP BY, identyczny jak w dowolnej bazie SQL.

Kopiuj

SELECT region,
       COUNT(*)      AS transakcje,
       SUM(ilosc)    AS sztuki
  FROM sprzedaz_raw
 GROUP BY region
 ORDER BY sztuki DESC;

Agregacja sprzedaży według regionu. Hive policzył 53 031 wierszy i zwrócił zestawienie w sekundy - a pod spodem uruchomił zadanie rozproszone.

Prawdziwa moc analityki to łączenie tabel. Połączmy sprzedaż z produktami, żeby policzyć przychód w podziale na kategorie. Mnożymy ilość przez cenę z tabeli produktów - to wymaga złączenia (JOIN) obu tabel po kluczu product_id.

Kopiuj

SELECT p.kategoria,
       COUNT(*)                       AS transakcje,
       ROUND(SUM(s.ilosc * p.cena), 2) AS przychod_pln
  FROM sprzedaz_raw s
  JOIN produkty p ON s.product_id = p.product_id
 GROUP BY p.kategoria
 ORDER BY przychod_pln DESC;

Złączenie dwóch tabel i przychód według kategorii. Elektronika odpowiada za ponad 42 miliony złotych przychodu w naszym zbiorze demonstracyjnym.

Widać od razu, że Elektronika z przychodem ponad 42 miliony złotych mocno wyprzedza pozostałe kategorie. Zejdźmy poziom niżej i sprawdźmy, które konkretne produkty sprzedają się najlepiej. To znów ten sam JOIN, tylko grupowany po nazwie produktu i ograniczony do pierwszej piątki.

Pięć produktów o najwyższym przychodzie. Laptop odpowiada za ponad 17 milionów złotych - takie rankingi to typowa robota dla Hive.

To jest właśnie codzienna praca w Hive: analityczne pytania do dużych zbiorów, zadawane zwykłym SQL.

Chcesz opanować HiveQL od podstaw? Szkolenie Big Data: Apache Hive - HiveQL od podstaw do technik zaawansowanych.

Partycjonowanie: jak przyspieszyć zapytania

Gdy dane rosną, przeszukiwanie całego zbioru przy każdym zapytaniu robi się kosztowne. Hive ma na to partycjonowanie - fizyczny podział tabeli na mniejsze części według wybranej kolumny. Każda partycja to osobny katalog plików. Naszą sprzedaż podzieliliśmy według roku i miesiąca, co dało 24 partycje (dwa lata po dwanaście miesięcy).

Kopiuj

CREATE TABLE sprzedaz_part (
  id INT, data STRING, product_id INT,
  region STRING, ilosc INT, kanal STRING
)
PARTITIONED BY (rok INT, miesiac INT)
STORED AS ORC;

-- wypelniamy partycje danymi z tabeli surowej
INSERT OVERWRITE TABLE sprzedaz_part PARTITION (rok, miesiac)
SELECT id, data, product_id, region, ilosc, kanal,
       YEAR(data), MONTH(data)
  FROM sprzedaz_raw;

Listę utworzonych partycji sprawdzimy poleceniem SHOW PARTITIONS. Każdy wpis to osobny katalog na dysku - Hive trzyma dane każdego miesiąca oddzielnie.

Lista 24 partycji tabeli. Każda z nich (na przykład rok=2024/miesiac=12) to osobny katalog plików w HDFS.

Po co ten podział? Dzięki niemu zapytanie z warunkiem na kolumnie partycjonującej czyta tylko potrzebne katalogi, a resztę pomija. Ten mechanizm nazywa się partition pruning (przycinanie partycji). Poniższa animacja pokazuje go w działaniu: pytanie o rok 2024 w ogóle nie dotyka danych z 2023.

Partition pruning w akcji. Zapytanie z warunkiem rok = 2024 skanuje tylko partycje z 2024 - zamiast 53 031 wierszy Hive czyta ich ułamek.

Zobaczmy to na liczbach. Zapytanie o grudzień 2024 zwraca 2 831 wierszy, a co ważniejsze - Hive nie musiał w tym celu przeglądać całego zbioru. To jest sedno optymalizacji zapytań w hurtowni Big Data.

Zapytanie do jednej partycji zwraca 2 831 wierszy. Warunek na kolumnie partycjonującej pozwala Hive pominąć wszystkie pozostałe partycje.

Partycjonowanie to jedna z pierwszych rzeczy, których uczy się każdy inżynier danych pracujący z Hive czy Spark. To wraz z formatami kolumnowymi i doborem silnika stanowi fundament optymalizacji zapytań na dużych zbiorach.

Formaty plików: TEXTFILE, ORC i Parquet

Zwróć uwagę, że tabelę partycjonowaną zapisaliśmy w formacie ORC, a nie jako zwykły tekst. Format pliku ma w Hive ogromne znaczenie dla wydajności i zajętości miejsca. Upraszczając, są dwa światy: formaty wierszowe (cały rekord zapisany po kolei, jak w CSV) oraz formaty kolumnowe (osobno zapisana każda kolumna).

Trzy najczęstsze formaty w Hive. TEXTFILE jest czytelny, ale wolny. ORC i Parquet to formaty kolumnowe - mocno się kompresują i czytają tylko potrzebne kolumny.

Dlaczego format kolumnowy jest tak istotny w analityce? Bo zapytanie zwykle pyta o kilka kolumn, a nie o wszystkie. Format kolumnowy pozwala odczytać z dysku tylko te kolumny, które są potrzebne, i pomija resztę. Do tego dochodzi silna kompresja (podobne wartości w jednej kolumnie ściskają się znakomicie) oraz statystyki zapisane wprost w pliku, które pomagają silnikowi pomijać zbędne fragmenty danych. Dla hurtowni na Hive standardem jest ORC, a Parquet to format uniwersalny, czytany przez cały ekosystem, w tym przez Spark.

Silniki wykonawcze: MapReduce, Tez i Spark

Wspominaliśmy, że Hive tłumaczy SQL na zadania rozproszone. Ale co je właściwie wykonuje? Tu wchodzi silnik wykonawczy. Historycznie pierwszy był MapReduce - stabilny, ale wolny, bo każdy etap zapisywał wynik pośredni na dysk. Jego następcą jest Tez, który układa zadania w graf zależności (tak zwany DAG, czyli skierowany graf acykliczny) i trzyma dane w pamięci między etapami. Trzecia opcja to Spark, silnik działający w pamięci, bardzo szybki przy złożonych potokach. Jeśli chcesz poznać ten silnik od podstaw, wyjaśniamy to w przewodniku czym jest Apache Spark.

Trzy silniki, ten sam SQL. Nowoczesny Hive domyślnie używa Tez, który jest znacznie szybszy od pierwotnego MapReduce.

To nie jest tylko teoria. Nasz Hive uruchomił zapytanie właśnie na silniku Tez. Poniżej realny zrzut z konsoli - widać, jak Tez buduje graf zadań i uruchamia je na klastrze (elementy Map i Reducer), pokazując pasek postępu.

Silnik Tez w akcji. Zapytanie zostało rozłożone na wierzchołki grafu (Map i Reducer) uruchomione na klastrze YARN - u dołu widać zakończony wynik.

Jeszcze ciekawszy jest podgląd samego planu wykonania. Polecenie EXPLAIN pokazuje, jak Hive zamierza policzyć zapytanie, zanim je faktycznie uruchomi. To bezcenne narzędzie do optymalizacji.

Kopiuj

EXPLAIN
SELECT region, SUM(ilosc)
  FROM sprzedaz_part
 WHERE rok = 2024
 GROUP BY region;

Plan wykonania z polecenia EXPLAIN. Widać optymalizator kosztowy (CBO), wektoryzację oraz to, że skanowanych jest tylko 26 522 wierszy z 2024 roku - a nie cały zbiór.

Zwróć uwagę na jeden szczegół w planie: przy skanowaniu tabeli (TableScan) Hive przewiduje 26 522 wiersze, a nie 53 031. To znów partition pruning - warunek na roku 2024 sprawił, że optymalizator z góry wie, że połowa danych jest nieistotna. Widać tu również skrót CBO, czyli optymalizator kosztowy (Cost-Based Optimizer), który wybiera najtańszy sposób wykonania zapytania na podstawie statystyk.

Jeśli spodobał Ci się silnik Spark i chcesz nauczyć się przetwarzać nim duże zbiory w praktyce - z realnymi zadaniami, a nie tylko teorią - to naturalny kolejny krok po Hive.

Chcesz wejść głębiej w przetwarzanie Big Data? Szkolenie Big Data: Przetwarzanie danych Big Data z Apache Spark ma terminy gwarantowane.

Hive w ekosystemie Hadoop

Hive rzadko występuje sam. To jedna z warstw większego ekosystemu Hadoop, w którym każda warstwa odpowiada za co innego. Poniższa infografika pokazuje, gdzie dokładnie siedzi Hive: na samym dole dane i zasoby, wyżej silniki obliczeń, a na górze narzędzia takie jak Hive, które udostępniają SQL.

Warstwy ekosystemu Hadoop. Hive i Spark to najwyższa warstwa narzędzi, oparta na silnikach obliczeń, zarządcy zasobów YARN i rozproszonym systemie plików HDFS.

W praktyce Hive często współpracuje z innymi narzędziami do analizy danych. Wyniki zapytań Hive bywają dalej przetwarzane w analizie danych w Pythonie z biblioteką pandas, ładowane do narzędzi typu Power BI albo do wizualnych platform analitycznych jak KNIME. Hive jest w tym łańcuchu tym elementem, który potrafi przemielić naprawdę duże wolumeny i oddać gotowe, zagregowane dane dalej.

Hive kontra tradycyjna baza danych

To jedno z najczęstszych nieporozumień u początkujących: Hive nie jest zamiennikiem zwykłej bazy. To narzędzie do innej pracy. Klasyczne bazy (na przykład bazy Oracle czy PostgreSQL) są zaprojektowane pod OLTP (przetwarzanie transakcyjne) - szybkie, pojedyncze operacje: dodaj zamówienie, zaktualizuj stan konta. Hive jest zaprojektowany pod OLAP (przetwarzanie analityczne) - wielkie zapytania przeliczające miliony wierszy naraz.

Hive kontra tradycyjna baza. Hive to analityka Big Data (OLAP) na plikach w HDFS, baza transakcyjna (OLTP) to szybkie operacje w milisekundach. To narzędzia do różnych zadań.

Najważniejsze różnice w skrócie: Hive liczy wsadowo (odpowiedź w sekundach lub minutach), baza OLTP odpowiada w milisekundach. Hive świetnie czyta i agreguje ogromne zbiory, ale słabo radzi sobie z pojedynczymi zmianami wiersza (UPDATE, DELETE) - baza transakcyjna robi to bez mrugnięcia. I wreszcie: w Hive dane leżą jako pliki w HDFS lub w chmurze, a w klasycznej bazie w jej własnym, wewnętrznym magazynie. Dlatego Hive nie zastępuje bazy, tylko ją uzupełnia.

Kiedy używać Hive, a kiedy nie

Skoro znamy już różnice, łatwo odpowiedzieć na pytanie, które zadaje sobie każdy początkujący: czy Hive to narzędzie dla mnie? Poniższa infografika podsumowuje decyzję.

Prosta decyzja oparta na skali danych i typie zapytań. Hive opłaca się przy dużych zbiorach i analityce wsadowej, a nie przy małych danych i pojedynczych transakcjach.

Reguła kciuka jest prosta. Sięgnij po Hive, gdy masz naprawdę duże zbiory (setki gigabajtów i więcej), robisz analitykę i raporty, Twój zespół zna SQL, a dane już leżą w HDFS lub w chmurze jako pliki. Poszukaj czegoś innego, gdy potrzebujesz odpowiedzi w milisekundach, masz dużo pojedynczych aktualizacji, zbiory są małe albo potrzebujesz interaktywnych zapytań - wtedy lepiej sprawdzą się bazy transakcyjne albo silniki takie jak Presto/Trino czy Spark SQL. Jeśli wahasz się między tymi dwoma narzędziami, pomoże Ci porównanie Apache Spark i Apache Hive.

Jak zacząć z Hive krok po kroku

Dobra wiadomość jest taka, że Hive można dziś odpalić na własnym laptopie w kilka minut, bez stawiania całego klastra. Dokładnie tak przygotowaliśmy środowisko do tego artykułu - jednym poleceniem Dockera. Jeśli nie miałeś jeszcze styczności z tą technologią, zacznij od przewodnika czym jest Docker i jak go używać.

Pięć kroków od pustego kontenera do zoptymalizowanych zapytań. Dokładnie tę drogę przeszliśmy w tym artykule na realnych danych.

Cały Hive z serwerem zapytań, metadanymi i konsolą Beeline uruchomisz jednym poleceniem:

Kopiuj

# uruchomienie HiveServer2 w kontenerze
docker run -d -p 10000:10000 -p 10002:10002 \
  --env SERVICE_NAME=hiveserver2 \
  --name hive apache/hive:4.0.1

# polaczenie konsola Beeline
docker exec -it hive beeline -u 'jdbc:hive2://localhost:10000/'

Od tego momentu możesz tworzyć bazy, tabele i pisać zapytania dokładnie tak, jak pokazaliśmy w tym artykule. Port 10000 to złącze JDBC dla klientów, a pod portem 10002 znajdziesz panel WWW serwera. To najprostszy sposób, żeby poznać Hive bez inwestowania w infrastrukturę.

Chcesz przejść tę drogę pod okiem praktyka, na gotowym środowisku i realnych danych? Szkolenie Big Data: Apache Hive - HiveQL od podstaw do technik zaawansowanych.

Podsumowanie

Apache Hive to warstwa SQL nad Hadoopem, która pozwala odpytywać ogromne zbiory danych znanym językiem zapytań, bez pisania niskopoziomowego kodu. Jego fundamenty to schema-on-read (schemat nakładany przy odczycie), dane trzymane jako pliki w HDFS, katalog metadanych w Metastore oraz silnik wykonawczy (dziś zwykle Tez), który tłumaczy SQL na zadania rozproszone. Partycjonowanie i formaty kolumnowe takie jak ORC sprawiają, że zapytania czytają tylko potrzebny ułamek danych. Hive nie zastępuje bazy transakcyjnej - to narzędzie do analityki wielkiej skali, które świetnie się z klasyczną bazą uzupełnia. Najlepsze w tym wszystkim jest to, że całość możesz dziś przećwiczyć na własnym komputerze w jednym kontenerze - a stąd już blisko do pracy z prawdziwym Big Data.