DEV Community: Andrzej Klusiewicz

Apache Spark kontra Apache Hive - które narzędzie Big Data wybrać

Andrzej Klusiewicz — Fri, 18 Sep 2026 07:01:21 +0000

Apache Spark vs Apache Hive na żywych silnikach i tych samych danych: identyczne wyniki, architektura, model in-memory, plany wykonania, panel Spark UI, uczciw…

Big Data · Porównanie

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

To samo pytanie, dwa silniki, ten sam wynik. Hive i Spark policzą identyczną analizę na tych samych danych - różni ich to, jak dochodzą do wyniku. Ten artykuł rozkłada te różnice na czynniki pierwsze.

Apache Spark i Apache Hive to dwa najczęściej mylone ze sobą narzędzia świata Big Data. Oba potrafią przeliczyć ogromne zbiory danych zwykłym SQL, oba pochodzą z ekosystemu Hadoop - a mimo to są zupełnie inne. W tym przewodniku pokażemy różnice nie na sucho, lecz na żywym Sparku i żywym Hive uruchomionych w kontenerach, na tym samym zbiorze 53 031 transakcji sprzedaży. Zobaczysz identyczne wyniki, realne plany wykonania, prawdziwy panel Spark UI i uczciwy pomiar czasów - a na końcu jasną odpowiedź, kiedy wybrać które (i dlaczego często warto mieć oba).

Z tego artykułu dowiesz się

Czym jest Hive, a czym Spark

Najkrótsza możliwa odpowiedź brzmi: Apache Hive to hurtownia danych z dostępem przez SQL, a Apache Spark to uniwersalny silnik obliczeniowy, który SQL ma tylko jako jedną z wielu możliwości. To rozróżnienie tłumaczy niemal wszystkie dalsze różnice, więc warto je dobrze osadzić.

Dwa różne pomysły na przetwarzanie danych. Hive daje analitykom SQL nad plikami w Hadoopie; Spark to ogólny silnik, który liczy w pamięci i obsługuje SQL, strumienie i uczenie maszynowe jednym narzędziem.

Hive powstał w Facebooku, by analitycy mogli odpytywać dane w Hadoopie zwykłym SQL, zamiast pisać ręcznie kod MapReduce. Jego sercem jest Metastore (katalog tabel i partycji) oraz serwer HiveServer2. Hive myśli tabelami - dokładnie jak klasyczna hurtownia. Jeśli chcesz poznać go od podszewki, opisaliśmy to w osobnym artykule o tym, czym jest Apache Hive i jak działa od środka.

Spark narodził się na uniwersytecie Berkeley jako odpowiedź na wolność MapReduce. Jego kluczowy pomysł to przetwarzanie w pamięci (in-memory) zamiast zapisywania każdego kroku na dysk. Spark nie jest przywiązany do Hadoopa - czyta dane z HDFS, chmury (S3), plików czy baz - i udostępnia jeden silnik do SQL, potoków ETL, strumieni danych i uczenia maszynowego. To dlatego stał się domyślnym wyborem inżynierów danych. Jeśli chcesz poznać samo narzędzie od zera - jego architekturę, pierwsze uruchomienie i możliwości - napisaliśmy osobny kompletny przewodnik po Apache Spark dla początkujących. Szerszy kontekst obu narzędzi znajdziesz w przeglądzie współczesnych rozwiązań Big Data.

Ta sama analiza, dwa silniki, ten sam wynik

Zamiast opowiadać, pokażmy. Przygotowaliśmy jeden zbiór - 53 031 transakcji sprzedaży i mały wymiar 20 produktów - i załadowaliśmy dokładnie te same pliki CSV do Hive i do Sparka. Zacznijmy od strony Sparka: wczytujemy plik i nakładamy na niego schemat (to znany z Hive model schema-on-read, czyli schemat przy odczycie).

Start sesji Spark i podgląd danych. Spark, podobnie jak Hive, nakłada schemat na surowy plik dopiero przy odczycie - te same 53 031 wierszy, ten sam zbiór.

Teraz najważniejszy dowód. Zadajmy oba pytania analityczne - agregację sprzedaży według regionu - najpierw w Sparku, potem w Hive. Zwróć uwagę na liczby: są co do jednego identyczne.

Po lewej Spark (DataFrame API), po prawej Hive (HiveQL). Ten sam zbiór, to samo pytanie, identyczny wynik: Śląskie 8 839 transakcji i 17 841 sztuk. Silnik jest inny, odpowiedź ta sama.

To samo dzieje się przy bardziej złożonym zapytaniu ze złączeniem (JOIN) tabel sprzedaży i produktów, liczącym przychód według kategorii. Elektronika daje ponad 42 miliony złotych - i tę samą kwotę co do grosza policzą oba silniki.

Złączenie dwóch tabel i przychód według kategorii - Spark (po lewej) i Hive (po prawej). Elektronika: 42 395 195,00 zł w obu. Skoro wynik jest ten sam, pozostaje pytanie o to, jak każdy silnik do niego dochodzi.

Architektura obok siebie

Oba narzędzia mają warstwę klienta, optymalizator zapytań, warstwę wykonania i warstwę zasobów - ale rozkładają akcenty inaczej. Poniższa infografika stawia obie architektury obok siebie.

Architektura Hive kontra Spark. Hive stoi na Hadoopie (YARN + HDFS) i myśli tabelami z Metastore. Spark to samodzielny silnik: Driver planuje, Executory liczą dane w pamięci, a źródłem może być cokolwiek - HDFS, chmura, pliki, bazy.

Kluczowa różnica jest taka: Hive to warstwa SQL nad Hadoopem - potrzebuje YARN do zasobów i HDFS do danych, a swój plan oddaje silnikowi (dziś zwykle Tez). Spark jest samodzielny: sam zarządza wykonaniem przez Driver i Executory, dane trzyma w pamięci procesów wykonawczych, a zasobami może dzielić YARN, Kubernetes albo jego własny menedżer. Spark nie potrzebuje Hive ani nawet Hadoopa, żeby działać.

Model wykonania: dysk kontra pamięć

Tu leży serce różnicy w wydajności. Klasyczny MapReduce, na którym wyrósł Hive, po każdym kroku zapisywał wynik pośredni na dysk i czytał go z powrotem w kroku następnym. Przy wielokrokowych obliczeniach to mnóstwo operacji wejścia-wyjścia. Spark zaprojektowano tak, by dane pomiędzy krokami zostawały w pamięci (RAM), co przy złożonych i iteracyjnych potokach potrafi dać ogromną oszczędność.

Dysk kontra pamięć. MapReduce zrzucał wynik każdego kroku na dysk i czytał go ponownie; Spark przekazuje dane między krokami w pamięci. Nowoczesny Tez też skraca te zapisy - dlatego przy pojedynczych zapytaniach różnica bywa mała, a przy wielokrokowych rośnie.

Najlepiej widać to na mechanizmie cache. Gdy wracasz do tych samych danych - co jest normą przy raportach, iteracjach i uczeniu maszynowym - Spark potrafi trzymać je w pamięci i nie czytać ponownie z dysku. W naszym demo to samo zapytanie z pamięci policzyło się ponad jedenaście razy szybciej niż z dysku.

Model in-memory w liczbach. Pierwszy odczyt z dysku: 1,39 s. Po wywołaniu cache() te same dane z pamięci: 0,12 s - czyli 11,4 raza szybciej. Hive przy każdym zapytaniu czyta dane od nowa.

To właśnie ta cecha zbudowała pozycję Sparka. Jeśli chcesz nauczyć się budować takie potoki w praktyce - z realnymi zadaniami na dużych zbiorach, a nie tylko w teorii - to najkrótsza droga do tego, by z Big Data zacząć realnie korzystać.

Chcesz przetwarzać duże zbiory danych w praktyce? Szkolenie Big Data: Przetwarzanie danych Big Data z Apache Spark ma terminy gwarantowane.

SQL czy kod: HiveQL kontra DataFrame API

W Hive masz jeden język: HiveQL, czyli dialekt SQL. To jego wielka zaleta - każdy, kto zna SQL, jest w domu. Spark daje wybór. Możesz pisać identyczny SQL, a możesz sięgnąć po DataFrame API w Pythonie, Scali czy Javie, które pozwala budować transformacje jak w kodzie. Poniżej to samo pytanie zadane w Sparku czystym SQL - składnia praktycznie nie różni się od HiveQL.

Spark SQL: to samo pytanie, składnia jak w HiveQL. Jeśli znasz SQL z Hive, w Sparku możesz pisać dokładnie tak samo - albo przełączyć się na DataFrame API, gdy potrzebujesz więcej kontroli.

W praktyce oba style łączy się swobodnie. Poniższy fragment pokazuje, że w Sparku ten sam wynik osiągniesz i przez API, i przez SQL - to kwestia wygody, nie ograniczeń.

Kopiuj

# Spark: nakładamy schemat na surowy plik CSV (schema-on-read)
sprzedaz = spark.read.csv("sprzedaz.csv", schema=schemat)
sprzedaz.createOrReplaceTempView("sprzedaz")

# to samo pytanie można zadać dwoma stylami:
# 1) DataFrame API
sprzedaz.groupBy("region").agg(sum("ilosc")).show()
# 2) czysty SQL - składnia jak w HiveQL
spark.sql("SELECT region, SUM(ilosc) FROM sprzedaz GROUP BY region").show()

Ta wszechstronność bywa też pułapką dla początkujących: więcej możliwości to większa krzywa wejścia. Dlatego solidne podstawy SQL opłacają się niezależnie od silnika - to wspólny mianownik Hive, Spark SQL i każdej hurtowni danych. Wyniki takich zapytań często trafiają potem do dalszej analizy danych w Pythonie z biblioteką pandas albo do narzędzi raportowych.

Chcesz opanować Apache Hive i język HiveQL w praktyce - od podstaw po techniki zaawansowane? Zajrzyj na Szkolenie Big Data: Apache Hive - HiveQL od podstaw do technik zaawansowanych.

Jak silnik liczy: plany wykonania

Oba narzędzia pokazują, jak zamierzają policzyć zapytanie, zanim je uruchomią. W Hive robi to polecenie EXPLAIN - poniżej plan na silniku Tez, z optymalizatorem kosztowym (CBO) i wektoryzacją.

Plan wykonania w Hive (EXPLAIN) na silniku Tez. Widać zależność wierzchołków (Reducer zależy od Map) i optymalizator kosztowy CBO - to graf zadań, który Tez uruchomi na klastrze.

Spark ma swój optymalizator - Catalyst - i pokazuje plan fizyczny poleceniem explain. Zwróć uwagę na AdaptiveSparkPlan: to mechanizm AQE (Adaptive Query Execution), który potrafi zmieniać plan w trakcie, gdy pozna faktyczne rozmiary danych.

Plan wykonania w Spark (Catalyst). AdaptiveSparkPlan na szczycie to adaptacyjne wykonanie zapytań - Spark dostraja plan w locie. Niżej te same operacje co w Hive: skan, agregacja, wymiana danych (Exchange).

Największą przewagą Sparka w codziennej pracy jest jednak jego panel WWW (Spark UI). Uruchamia się automatycznie i pokazuje każde zadanie na żywo. Poniżej realny zrzut z naszego demo - lista szesnastu zakończonych zadań z czasami wykonania.

Panel Spark UI (zakładka Jobs) z naszego środowiska. Widać wszystkie uruchomione zadania, ich czas i liczbę etapów - bezcenne przy diagnozowaniu, co i dlaczego trwa.

Jeszcze ciekawszy jest podgląd pojedynczego zapytania jako grafu (DAG). Poniżej realny plan naszego zapytania ze złączeniem. Spark rozpoznał, że tabela produktów jest mała, i zastosował BroadcastHashJoin - rozesłał ją do wszystkich zadań zamiast kosztownie przetasowywać dużą tabelę sprzedaży.

Graf wykonania (DAG) zapytania JOIN w panelu Spark UI. Mały wymiar produktów (20 wierszy) trafia do BroadcastExchange i BroadcastHashJoin, a duża tabela sprzedaży (53 031) nie musi być przetasowywana - to typowa optymalizacja Sparka.

Partycjonowanie: oba pomijają zbędne dane

Podstawą wydajności w obu narzędziach jest partycjonowanie - fizyczny podział danych, dzięki któremu zapytanie czyta tylko potrzebny fragment. Hive robi to na tabelach ORC, Spark - na przykład na plikach Parquet. W Sparku zapisaliśmy sprzedaż podzieloną według roku i miesiąca, a potem zapytaliśmy o jeden miesiąc.

Spark zapisuje dane do Parquet z podziałem na rok i miesiąc, a następnie pyta o jedną partycję (grudzień 2024): 2 831 wierszy. Tak samo jak Hive, Spark potrafi pominąć resztę danych.

Że faktycznie pomija resztę, potwierdza plan wykonania. W sekcji skanu Parquet widać PartitionFilters z warunkiem na roku i miesiącu - Spark z góry wie, których katalogów nie musi otwierać. To jest partition pruning, dokładnie ten sam mechanizm, który w Hive skraca skanowanie ogromnych tabel.

Plan potwierdza pominięcie partycji. Linia PartitionFilters z warunkiem rok = 2024 i miesiąc = 12 oznacza, że Spark otworzy tylko jeden katalog danych zamiast całego zbioru.

Ile naprawdę trwają te same zapytania

Przejdźmy do liczb - ale uczciwie. Uruchomiliśmy te same cztery zapytania na obu silnikach, na tym samym zbiorze, w jednowęzłowym demo w Dockerze. To nie jest benchmark klastrowy i nie służy do ogłaszania zwycięzcy - służy pokazaniu, jak każdy silnik się zachowuje.

Realny pomiar na 53 031 wierszach. Na tak małych danych różnice w sekundach są drugorzędne. Ważniejsze jest to, co po bokach: Hive płaci jednorazowy koszt startu sesji (~28 s przy pierwszym zapytaniu), a Spark nagradza powtarzane odczyty pamięcią (11,4 raza).

Wnioski są dwa i oba są ważniejsze niż same słupki. Po pierwsze, Hive płaci koszt zimnego startu: pierwsze zapytanie po otwarciu sesji Tez trwało u nas prawie 28 sekund, bo silnik musiał wystartować na klastrze - kolejne schodziły do 1-2 sekund. Widać to na realnym zrzucie z Hive poniżej.

Silnik Tez w Hive uruchamia zapytanie na klastrze YARN. Pierwsze uruchomienie po starcie sesji jest najwolniejsze - to jednorazowy koszt, który przy kolejnych zapytaniach znika.

Po drugie, Spark nagradza powtarzalność: przy pierwszym odczycie z dysku jest porównywalny z Hive, ale gdy dane wpadną do pamięci (cache), kolejne zapytania są wielokrotnie szybsze. Dlatego na małych, pojedynczych zapytaniach wsadowych różnice są niewielkie, a przewaga Sparka rośnie tam, gdzie liczysz iteracyjnie i wielokrotnie na tych samych danych.

Pełne porównanie w jednej tabeli

Zbierzmy wszystko w jednym miejscu. Poniższa tabela zestawia oba narzędzia w dziewięciu wymiarach, które realnie decydują o wyborze.

Macierz cech Hive kontra Spark. Żaden nie jest lepszy w oderwaniu od zadania: Hive wygrywa prostotą tam, gdzie wystarczy SQL wsadowy, Spark - wszechstronnością tam, gdzie potrzebny jest jeden silnik do ETL, strumieni i uczenia maszynowego.

Kiedy Hive, kiedy Spark, a kiedy oba

Skoro znamy już różnice, decyzja robi się prosta. Co ważne, w praktyce najczęściej nie jest to wybór albo-albo.

Prosta decyzja w trzech kolumnach. Hive dla wsadowego SQL i prostoty, Spark dla wszechstronności i iteracji, a bardzo często - oba naraz, bo świetnie się uzupełniają.

Wybierz Hive, gdy zespół zna SQL, robicie wsadowe raporty z hurtowni, a dane leżą już w HDFS. Wybierz Spark, gdy budujesz wielokrokowe potoki, potrzebujesz strumieni lub uczenia maszynowego albo wracasz do tych samych danych. A jeśli rozważasz rozwiązanie w chmurze zamiast własnego klastra, warto poznać też w pełni zarządzaną hurtownię, jaką jest Google BigQuery - to trzecia droga obok Hive i Sparka.

Spark i Hive potrafią pracować razem

Najczęstszym nieporozumieniem jest traktowanie tego jak pojedynku. W dojrzałej architekturze danych Hive i Spark współpracują: Hive (a właściwie jego Metastore) pełni rolę wspólnego katalogu tabel, a Spark jest silnikiem, który te tabele liczy.

Hive i Spark w jednej architekturze. Ten sam Metastore opisuje pliki jako tabele, analitycy pytają je w SQL, a inżynierowie budują potoki w Spark na tych samych danych. Nikt niczego nie przepisuje.

W typowej firmie wygląda to tak: pliki leżą w HDFS lub w chmurze, Hive Metastore opisuje je jako tabele, analitycy odpytują je w SQL, a inżynierowie budują potoki i modele w Spark - na tych samych tabelach. Spark potrafi uruchomić spark.sql(...) wprost na tabelach zdefiniowanych w Hive, więc migrację można robić stopniowo, bez rewolucji.

Jak uruchomić oba u siebie

Najlepszy sposób, żeby to wszystko poczuć, to odpalić oba na własnym komputerze. Dokładnie tak przygotowaliśmy to demo - dwoma poleceniami Dockera. Najpierw Hive z serwerem zapytań i konsolą Beeline:

Kopiuj

# Apache Hive: serwer zapytań w jednym kontenerze
docker run -d -p 10000:10000 -p 10002:10002 \
  --env SERVICE_NAME=hiveserver2 \
  --name hive apache/hive:4.0.1

# konsola Beeline (klient SQL)
docker exec -it hive beeline -u 'jdbc:hive2://localhost:10000/'

A obok Spark, który tę samą analizę policzy zadaniem spark-submit albo interaktywnie w powłoce PySpark:

Kopiuj

# Apache Spark: uruchomienie zadania na tych samych danych
docker run --rm -v "$PWD:/work" \
  apache/spark:3.5.3 \
  /opt/spark/bin/spark-submit /work/analiza.py

# albo interaktywnie w powłoce PySpark
docker run --rm -it apache/spark:3.5.3 /opt/spark/bin/pyspark

Od tego momentu możesz ładować dane i pisać zapytania w obu - i na własne oczy porównać, jak każdy z nich dochodzi do tego samego wyniku.

Podsumowanie

Apache Hive i Apache Spark nie są konkurentami w prostym sensie. Hive to hurtownia danych z dostępem przez SQL - prosta, dojrzała, idealna do wsadowej analityki dla zespołów, które znają SQL. Spark to uniwersalny silnik obliczeniowy - liczy w pamięci, obsługuje SQL, DataFrame, strumienie i uczenie maszynowe, i nie potrzebuje Hadoopa. Na tych samych danych oba policzą identyczny wynik; różni je to, jak i jak szybko do niego dochodzą. Spark błyszczy przy iteracjach i złożonych potokach dzięki modelowi in-memory, Hive - prostotą i stabilnością w czystym SQL. A ponieważ Spark potrafi czytać tabele Hive przez wspólny Metastore, w praktyce najlepszą odpowiedzią bywa: użyj obu. Najlepsze jest to, że całość przećwiczysz dziś na własnym laptopie w dwóch kontenerach - a stąd już blisko do pracy z prawdziwym Big Data.

Szkolenie Big Data: Przetwarzanie danych Big Data z Apache Spark -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR. Ma terminy gwarantowane.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Big Data: Apache Hive - HiveQL od podstaw do technik zaawansowanych -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

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

Andrzej Klusiewicz — Fri, 18 Sep 2026 07:00:58 +0000

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.

Szkolenie Apache Hive - HiveQL od podstaw do technik zaawansowanych -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Big Data: Przetwarzanie danych Big Data z Apache Spark -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR. Ma terminy gwarantowane.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

Czym jest Apache Spark - kompletny przewodnik dla początkujących

Andrzej Klusiewicz — Fri, 18 Sep 2026 07:00:36 +0000

Czym jest Apache Spark, jak działa od środka i kiedy warto go użyć. Architektura, RDD i DataFrame, leniwe wykonanie, model in-memory, Catalyst oraz moduły Spar…

Big Data · Przewodnik

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

Jak Apache Spark zamienia zwykły kod na obliczenia rozproszone w pamięci i zwraca wynik. Tę drogę - od kodu po executory - rozłożymy w tym artykule na czynniki pierwsze.

Apache Spark to dziś jeden z najważniejszych silników przetwarzania danych na świecie. Stoi za analityką, uczeniem maszynowym i potokami danych w tysiącach firm, a jego największą zaletą jest to, że ogromne zbiory potrafi przetwarzać znacznie szybciej niż starsze narzędzia - bo liczy dane w pamięci. W tym przewodniku wyjaśnimy prostym językiem, czym Spark jest, jak działa od środka i kiedy naprawdę warto po niego sięgnąć. Wszystko pokażemy na żywym Sparku w wersji 3.5.3, uruchomionym w kontenerze, na realnym zbiorze 53 031 transakcji sprzedaży.

Z tego artykułu dowiesz się

Czym jest Apache Spark

Apache Spark to otwarty silnik do przetwarzania dużych zbiorów danych, który potrafi rozłożyć obliczenia na wiele maszyn i policzyć je równolegle. Mówiąc najprościej: piszesz zwykły kod, który wygląda, jakby działał na jednym komputerze, a Spark w tle dzieli pracę na kawałki i uruchamia je na całym klastrze (grupie połączonych maszyn). Nie musisz się martwić, jak podzielić dane ani jak zsynchronizować obliczenia - tym zajmuje się Spark.

Kluczowe słowo, które warto od razu oswoić, to in-memory, czyli przetwarzanie w pamięci. Starsze narzędzia z rodziny Big Data po każdym etapie obliczeń zapisywały wyniki pośrednie na dysk, a odczyt z dysku jest wolny. Spark, gdzie tylko może, trzyma dane w pamięci operacyjnej (RAM) i dzięki temu przy powtarzanych operacjach potrafi być wielokrotnie szybszy. To była jego przełomowa cecha i do dziś jest głównym powodem, dla którego się go wybiera.

Druga ważna cecha to uniwersalność. Spark to nie jest osobne narzędzie do każdego zadania - to jeden silnik, którym zrobisz zapytania SQL, przetworzysz dane napływające na żywo, wytrenujesz model uczenia maszynowego czy policzysz graf powiązań. Wszystko na tych samych danych i w tym samym API. Do Sparka najczęściej pisze się w Pythonie (interfejs nazywa się PySpark), ale dostępne są też Scala, Java i R. W tym artykule wszystkie przykłady są w PySpark.

Po co powstał Spark

Żeby zrozumieć Spark, trzeba cofnąć się do jego poprzednika. Przez lata standardem przetwarzania Big Data był MapReduce - model obliczeń z ekosystemu Hadoop, w którym każde zadanie dzielono na fazę mapowania i fazę redukcji. MapReduce miał jedną dużą wadę: po każdym etapie zapisywał wyniki pośrednie na dysk. Przy prostym zliczaniu to jeszcze uchodziło, ale przy obliczeniach iteracyjnych (na przykład w uczeniu maszynowym, gdzie ten sam zbiór przelicza się setki razy) ciągłe pisanie i czytanie z dysku zabijało wydajność.

Spark narodził się w laboratorium AMPLab na Uniwersytecie Kalifornijskim w Berkeley około 2009 roku właśnie jako odpowiedź na ten problem. Pomysł był prosty i genialny: skoro dysk jest wąskim gardłem, trzymajmy dane pośrednie w pamięci. Efekt przerósł oczekiwania - te same zadania działały wielokrotnie szybciej. Projekt szybko trafił pod skrzydła fundacji Apache i stał się jednym z najaktywniej rozwijanych narzędzi Big Data. Jeśli chcesz zobaczyć szerszy obraz tego, jak Spark wpisuje się w dzisiejszy krajobraz danych, opisaliśmy go w artykule o współczesnych rozwiązaniach Big Data.

Architektura Spark: z czego to się składa

Spark to aplikacja rozproszona, więc żeby ją zrozumieć, trzeba zobaczyć, kto właściwie wykonuje pracę. Są trzy główne role: program sterujący, zarządca zasobów i procesy robocze. Poniższa infografika pokazuje, jak współpracują.

Architektura Spark w skrócie. Driver planuje pracę, Cluster Manager przydziela zasoby, a executory liczą dane równolegle - każdy swoją część (partycję).

Prześledźmy te elementy po kolei:

Driver Program - serce aplikacji. To tutaj działa Twój kod. Driver tworzy SparkContext (punkt wejścia do Sparka), buduje plan obliczeń i dzieli pracę na drobne zadania.
Cluster Manager - zarządca zasobów klastra. Przydziela pamięć i moc obliczeniową. Może to być tryb Standalone (wbudowany w Spark), YARN znany z Hadoopa albo Kubernetes.
Executory - procesy robocze uruchomione na maszynach klastra. To one wykonują zadania i liczą dane. Każdy executor obrabia inną partycję, czyli fragment zbioru - i tu właśnie rodzi się równoległość.
Partycje - Spark dzieli dane na kawałki zwane partycjami i rozdziela je między executory. Im więcej partycji i executorów, tym więcej obliczeń dzieje się jednocześnie.

Cała sztuczka polega na tym, że Ty piszesz kod tak, jakby dane były jedną kolekcją, a Spark sam rozbija ją na partycje i rozsyła do executorów. Kiedy uruchomisz zadanie lokalnie na laptopie (tryb local[*], którego użyjemy w tym artykule), rolę klastra przejmują rdzenie Twojego procesora - każdy działa jak mały executor.

RDD, DataFrame i Dataset: trzy sposoby na dane

Pracując ze Sparkiem, spotkasz trzy nazwy, które na początku bywają mylące: RDD, DataFrame i Dataset. To trzy warstwy abstrakcji nad tymi samymi danymi - od najniższego, najbardziej surowego poziomu, po najwygodniejszy.

Trzy warstwy Spark. RDD to fundament, DataFrame to wygodna, optymalizowana warstwa tabelaryczna, a Dataset dokłada kontrolę typów w Scali i Javie.

RDD (Resilient Distributed Dataset, czyli odporny rozproszony zbiór danych) to najniższy poziom - rozproszona kolekcja obiektów, na której wykonujesz operacje takie jak map czy reduce. Daje pełną kontrolę, ale sam nie jest optymalizowany. Zobaczmy RDD w akcji: policzmy liczbę sprzedanych sztuk w podziale na regiony, operując bezpośrednio na surowych liniach pliku.

RDD w praktyce. Wczytujemy plik jako zbiór linii, rozbijamy każdą na pola i sumujemy sztuki po regionie za pomocą reduceByKey. To ten sam wynik, który za chwilę policzymy wygodniej DataFrame'em.

Widać, że kod RDD jest dość niskopoziomowy - sami dzielimy tekst, wybieramy pola po numerach i ręcznie sumujemy. Działa, ale jest sporo pracy i łatwo o pomyłkę. Dlatego na co dzień sięgamy po warstwę wyżej.

DataFrame to najczęstszy wybór. Dane widzisz jak tabelę z nazwanymi kolumnami i typami, dokładnie jak w bazie danych. Piszesz czytelny kod, a wbudowany optymalizator Catalyst sam układa najlepszy plan wykonania. To jego będziemy używać w większości artykułu. Dataset to trzecia opcja - łączy zalety RDD i DataFrame, dokładając sprawdzanie typów już na etapie pisania kodu, ale dostępny jest tylko w Scali i Javie (nie w Pythonie). Dla początkującego w Pythonie zasada jest prosta: używaj DataFrame.

Pierwszy kontakt: sesja i dane

Pracę ze Sparkiem zaczynasz od utworzenia sesji - obiektu, przez który rozmawiasz z silnikiem. Potem wczytujesz dane. Co ważne, tak jak w hurtowni Apache Hive, Spark stosuje model schema-on-read (schemat przy odczycie): schemat danych podajesz dopiero w momencie wczytywania pliku, a nie z góry przy jego zapisie. Oto jak w kilku linijkach tworzymy sesję, definiujemy schemat i wczytujemy plik sprzedaży.

Kopiuj

from pyspark.sql import SparkSession
from pyspark.sql.types import StructType, StructField, IntegerType, StringType

spark = SparkSession.builder.master("local[*]").getOrCreate()

# schemat: nazwy kolumn i ich typy - nakladamy go dopiero przy odczycie
schemat = StructType([
    StructField("id",         IntegerType()),
    StructField("data",       StringType()),
    StructField("product_id", IntegerType()),
    StructField("region",     StringType()),
    StructField("ilosc",      IntegerType()),
    StructField("kanal",      StringType()),
])

sprzedaz = spark.read.csv("sprzedaz.csv", schema=schemat)

Zmienna schemat to właśnie nasza deklaracja struktury danych - lista sześciu kolumn wraz z typami (liczba całkowita albo tekst). Przekazujemy ją do read.csv w parametrze schema i to dzięki niej Spark wie, jak rozumieć surowy plik CSV. Podejrzyjmy pierwsze wiersze wczytanych danych.

Start sesji Spark i podgląd danych. Metoda show wyświetla pierwsze wiersze - to surowy plik CSV widziany przez Spark jako tabela z nazwanymi kolumnami.

Skoro nałożyliśmy na plik schemat, możemy go podejrzeć. Polecenie printSchema pokazuje kolumny i ich typy - Spark zna je nie dlatego, że przeanalizował plik, ale dlatego, że sami tak zadeklarowaliśmy przy wczytywaniu.

Schemat nałożony na dane przy odczycie. Sześć kolumn z typami - to my zadeklarowaliśmy tę strukturę, wczytując surowy plik CSV.

Sprawdźmy jeszcze, ile w ogóle mamy danych. Jedno proste wywołanie count i już wiemy, że pracujemy na ponad pięćdziesięciu tysiącach transakcji.

Zbiór liczy 53 031 transakcji. Na tak małym wolumenie Spark to armata na muchę - ale dokładnie te same operacje zadziałają na miliardach wierszy rozłożonych na klastrze.

Leniwe wykonanie: transformacje kontra akcje

Teraz najważniejszy koncept Sparka, który odróżnia go od zwykłego programowania i którego zrozumienie oszczędzi Ci wielu niespodzianek. W Sparku operacje dzielą się na dwa rodzaje: transformacje i akcje. Transformacja (na przykład filter, select, groupBy) opisuje, co chcesz zrobić z danymi - ale niczego nie liczy. Spark tylko zapamiętuje przepis. Dopiero akcja (na przykład count, show lub zapis wyniku) uruchamia całe obliczenie. Ten mechanizm nazywa się leniwym wykonaniem (lazy evaluation).

Leniwe wykonanie w akcji. Kolejne transformacje tylko budują plan (graf zadań, tak zwany DAG). Dane pozostają nietknięte, dopóki nie wywołasz akcji - dopiero ona uruchamia cały łańcuch naraz.

Po co ta komplikacja? Bo dzięki niej Spark widzi cały plan, zanim zacznie liczyć, i może go zoptymalizować - na przykład pominąć kolumny, których i tak nikt nie użyje, albo połączyć kilka kroków w jeden. To fundament wydajności Sparka. Zobaczmy to na realnym pomiarze: budujemy łańcuch transformacji i mierzymy czas, a potem wywołujemy akcję i mierzymy ponownie.

Dowód leniwego wykonania. Zbudowanie łańcucha transformacji zajęło 0,05 s - Spark tylko zapisał plan. Dopiero akcja count uruchomiła obliczenia i zajęła 0,87 s, zwracając 8 839 wierszy.

Różnica jest wymowna: samo zbudowanie planu to ułamek sekundy, bo Spark niczego wtedy nie liczy - dopiero akcja czyta 53 tysiące wierszy i wykonuje pracę. Gdy zaczynasz ze Sparkiem, dobrze mieć w głowie tę zasadę: dopóki nie wywołasz akcji, nic się nie dzieje.

Zapytania analityczne: agregacje, JOIN i Spark SQL

Skoro mamy dane, zadajmy im pytania biznesowe. Zacznijmy od agregacji na DataFrame: ile transakcji i ile sprzedanych sztuk przypada na każdy region. Metoda groupBy w połączeniu z agg odpowiada za grupowanie.

Kopiuj

(sprzedaz.groupBy("region")
        .agg(count("*").alias("transakcje"),
             sum("ilosc").alias("sztuki"))
        .orderBy(desc("sztuki"))
        .show())

Agregacja sprzedaży według regionu na DataFrame. Spark rozłożył pracę na partycje, policzył je równolegle i zebrał wynik - a kod czyta się jak zdanie.

Prawdziwa moc analityki to łączenie tabel. Obok sprzedaży mamy drugą, mniejszą tabelę - listę produktów z cenami. Połączmy je (operacja join) po kluczu product_id, żeby policzyć przychód w podziale na kategorie.

Kopiuj

(sprzedaz.join(produkty, "product_id")
        .groupBy("kategoria")
        .agg(count("*").alias("transakcje"),
             round(sum(col("ilosc") * col("cena")), 2).alias("przychod_pln"))
        .orderBy(desc("przychod_pln"))
        .show())

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

Najlepsze w Sparku jest to, że jeśli wolisz zwykły SQL, wcale nie musisz uczyć się nowego API. Ten sam wynik dostaniesz, pisząc klasyczne zapytanie w Spark SQL - składnia jest praktycznie taka sama jak w każdej bazie.

To samo pytanie zadane zwykłym SQL. Spark SQL i DataFrame to dwie drogi do tego samego celu - pod spodem trafiają do tego samego optymalizatora.

To jest właśnie codzienna praca ze Sparkiem: analityczne pytania do dużych zbiorów, zadawane albo wygodnym API DataFrame, albo znanym wszystkim SQL. Chcesz opanować to od podstaw, na realnych danych i pod okiem praktyka?

Chcesz nauczyć się przetwarzać duże zbiory danych w Sparku w praktyce? Szkolenie Big Data: Przetwarzanie danych Big Data z Apache Spark ma terminy gwarantowane.

Dlaczego Spark jest szybki: model in-memory

Wróćmy do najważniejszej cechy Sparka - liczenia w pamięci. Najlepiej widać ją w zestawieniu z MapReduce. Poniższa infografika pokazuje, na czym polega różnica.

MapReduce zapisuje wynik na dysk po każdym etapie, Spark trzyma dane pośrednie w pamięci. Dlatego przy powtarzanych operacjach Spark jest znacznie szybszy.

Ten model in-memory daje o sobie znać zwłaszcza wtedy, gdy ten sam zbiór odpytujesz wielokrotnie. Spark pozwala wtedy jawnie poprosić, żeby dane zostały w pamięci - służy do tego metoda cache. Zmierzyliśmy to: pierwszy przebieg zapytania (zimny, z odczytem danych) kontra ten sam przebieg po zbuforowaniu danych w pamięci.

Kopiuj

q.collect()                 # zimny odczyt danych
sprzedaz.cache(); sprzedaz.count()   # zaladuj do pamieci
q.collect()                 # ponowny odczyt - juz z pamieci

Wynik jest jednoznaczny: po zbuforowaniu danych powtórne zapytanie policzyło się w naszym demo ponad 11 razy szybciej (spadek z około 1,39 do 0,12 sekundy). To dokładnie ta przewaga, dla której powstał Spark - unikanie kosztownych odczytów z dysku tam, gdzie dane można trzymać w pamięci. Warto pamiętać, że cache ma sens wtedy, gdy ten sam zbiór wykorzystujesz kilka razy; przy jednorazowym przejściu przez dane nic nie zyskasz.

Catalyst i plan wykonania

Skąd Spark wie, jak najlepiej policzyć Twoje zapytanie? Odpowiada za to Catalyst - wbudowany optymalizator, który zamienia kod DataFrame lub Spark SQL w zoptymalizowany plan fizyczny. Zanim Spark cokolwiek policzy, układa graf kroków, wybiera najtańszy sposób wykonania i dopiero wtedy rozsyła zadania do executorów. Ten plan możesz podejrzeć poleceniem explain.

Plan wykonania z polecenia explain. Widać kolejne kroki, które Catalyst ułożył: skan pliku, agregacje częściowe, wymianę danych między partycjami (Exchange) i sortowanie.

Ten plan nie jest tylko teorią - Spark faktycznie go realizuje, a cały przebieg możesz obejrzeć w graficznym panelu Spark UI, który silnik udostępnia przez przeglądarkę. Widać w nim wykonane zadania i to, jak Spark rozbił zapytanie na etapy.

Panel Spark UI na naszym środowisku. Lista wykonanych zadań (jobs) wraz z czasem trwania i liczbą etapów - bezcenne narzędzie do zrozumienia i optymalizacji obliczeń.

Ten sam przebieg jako graf zadań (DAG) w Spark UI. To wizualne odzwierciedlenie planu, który zbudował Catalyst - od skanu danych po wynik.

Partycjonowanie i szybsze odczyty

Gdy dane rosną, opłaca się je fizycznie podzielić, żeby zapytania nie musiały czytać całości. Spark, podobnie jak hurtownie Big Data, wspiera partycjonowanie - zapis danych w podziale na katalogi według wybranej kolumny. Zapiszmy naszą sprzedaż w formacie Parquet (wydajny format kolumnowy) z podziałem na rok i miesiąc, a potem zapytajmy o jeden konkretny miesiąc.

Kopiuj

(sprzedaz.withColumn("rok", year("data"))
        .withColumn("miesiac", month("data"))
        .write.partitionBy("rok", "miesiac").parquet("sprzedaz_part"))

parq = spark.read.parquet("sprzedaz_part")
parq.where((col("rok") == 2024) & (col("miesiac") == 12)).count()

Zapytanie do jednej partycji zwraca 2 831 wierszy. Spark odczytał tylko właściwy katalog, zamiast przeglądać cały zbiór.

Że tak się właśnie stało, potwierdza plan wykonania. W sekcji PartitionFilters widać, że Spark z góry wiedział, które partycje pominąć - ten mechanizm nazywa się partition pruning (przycinanie partycji).

Plan potwierdza przycinanie partycji. Warunek na roku i miesiącu trafił do sekcji PartitionFilters - Spark czyta tylko potrzebne katalogi, oszczędzając odczyty z dysku.

Partycjonowanie, format kolumnowy Parquet i cache to trzy pierwsze narzędzia optymalizacji, których uczy się każdy inżynier danych pracujący ze Sparkiem. Jeśli te przykłady w Pythonie Cię wciągnęły, to naturalny kierunek dalszej nauki.

Wolisz uczyć się Sparka od strony Pythona? Szkolenie PySpark: rozproszone przetwarzanie danych w Sparku za pomocą Pythona pokazuje to na realnych zadaniach.

Moduły Spark: jeden silnik do wszystkiego

Do tej pory pracowaliśmy z danymi tabelarycznymi, ale Spark to znacznie więcej. Jego siłą jest to, że jest ujednoliconym silnikiem - na tych samych danych i w tym samym API robisz zupełnie różne rzeczy. Poniższa infografika pokazuje główne moduły.

Moduły Spark stoją na wspólnym fundamencie - Spark Core. Dzięki temu ten sam DataFrame przetworzysz zapytaniem SQL, puścisz przez strumień danych albo nakarmisz nim model uczenia maszynowego.

Spark SQL - zapytania SQL i praca na DataFrame'ach. To z niego korzystaliśmy w tym artykule.
Structured Streaming - przetwarzanie danych napływających na żywo (na przykład zdarzeń ze strumienia), tym samym kodem, którym obrabiasz dane wsadowe.
MLlib - biblioteka uczenia maszynowego: klasyfikacja, regresja, rekomendacje i grupowanie, gotowe do działania na dużą skalę.
GraphX - analiza grafów, czyli danych o powiązaniach (na przykład sieci społecznościowych czy zależności między produktami).

Wszystko to opiera się na Spark Core - silniku, który zarządza pamięcią, dzieli zadania i pilnuje ich wykonania na klastrze. Ta jednorodność to praktyczna przewaga: nie musisz spinać kilku różnych narzędzi ani przenosić danych między nimi.

Spark w ekosystemie Big Data

Spark rzadko działa sam. Najczęściej jest silnikiem obliczeniowym w większej układance: czyta dane z rozproszonych magazynów, przetwarza je i oddaje gotowe wyniki dalej. Poniższa infografika pokazuje jego miejsce.

Gdzie w Big Data siedzi Spark. Czyta dane ze źródeł takich jak HDFS, chmura czy Kafka, liczy je na klastrze i oddaje wyniki do raportów, modeli i hurtowni.

Spark świetnie współpracuje z resztą świata danych. Dane odczytuje z rozproszonego systemu plików HDFS, z magazynów chmurowych czy ze strumieni. Często stoi obok hurtowni Apache Hive, z której korzysta jako katalogu tabel, i coraz częściej zapisuje dane w formacie Delta Lake, tworząc nowoczesną hurtownię typu lakehouse. Wyniki jego pracy trafiają dalej - do analizy danych w Pythonie z biblioteką pandas, do narzędzi typu Power BI, czy do hurtowni w chmurze takich jak BigQuery. Spark jest w tym łańcuchu tym elementem, który potrafi przemielić naprawdę duże wolumeny. Skoro Spark tak często stoi obok Hive, warto wiedzieć, kiedy który się sprawdzi - rozkładamy to na czynniki pierwsze w artykule Apache Spark kontra Apache Hive - które narzędzie Big Data wybrać.

Kiedy używać Spark, a kiedy nie

Skoro wiemy już, co Spark potrafi, odpowiedzmy na pytanie, które zadaje sobie każdy początkujący: czy to narzędzie dla mnie? Poniższa infografika podsumowuje decyzję.

Prosta decyzja oparta na skali i typie zadań. Spark opłaca się przy dużych danych i złożonych potokach, a nie przy małych zbiorach i pojedynczych operacjach.

Reguła kciuka jest prosta. Sięgnij po Spark, gdy dane nie mieszczą się wygodnie na jednej maszynie, gdy budujesz złożone potoki przetwarzania (wsadowe albo strumieniowe), gdy robisz uczenie maszynowe na dużą skalę albo gdy zależy Ci na szybkości dzięki liczeniu w pamięci. Poszukaj czegoś innego, gdy zbiory są małe i spokojnie mieszczą się na jednym serwerze - wtedy zwykła baza danych albo biblioteka pandas w Pythonie będzie prostsza. Spark nie zastąpi też bazy transakcyjnej tam, gdzie potrzebujesz odpowiedzi w milisekundach i wielu pojedynczych zapisów - to zupełnie inny rodzaj pracy.

Jak zacząć z Apache Spark krok po kroku

Dobra wiadomość jest taka, że Spark można dziś odpalić na własnym laptopie w kilka minut, bez stawiania klastra. Wystarczy Python i jedno polecenie instalacji.

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

Cały Spark z API DataFrame i Spark SQL dostaniesz jednym poleceniem w Pythonie:

Kopiuj

# instalacja PySpark w srodowisku Python
pip install pyspark

# w kodzie: utworz sesje i wczytaj dane
from pyspark.sql import SparkSession
spark = SparkSession.builder.master("local[*]").getOrCreate()
df = spark.read.csv("sprzedaz.csv", header=True, inferSchema=True)
df.show()

Zapis local[*] mówi Sparkowi, żeby uruchomił się lokalnie i wykorzystał wszystkie rdzenie Twojego procesora - każdy zadziała jak mały executor. Od tego momentu możesz wczytywać dane, pisać transformacje i wywoływać akcje dokładnie tak, jak pokazaliśmy w tym artykule. To najprostszy sposób, żeby poznać Spark bez inwestowania w infrastrukturę.

Podsumowanie

Apache Spark to szybki, rozproszony silnik do przetwarzania dużych zbiorów danych, którego przewagą jest liczenie w pamięci (in-memory) zamiast ciągłego zapisywania na dysk. Jego fundamenty to architektura z Driverem i executorami, warstwy abstrakcji nad danymi (RDD, DataFrame i Dataset), leniwe wykonanie (transformacje budują plan, dopiero akcja go uruchamia) oraz optymalizator Catalyst, który układa najlepszy plan zapytania. Spark to jednocześnie jeden silnik do wielu zadań - SQL, strumieni, uczenia maszynowego i grafów - a jego przykłady najwygodniej pisze się w Pythonie przez PySpark. Najlepsze w tym wszystkim jest to, że całość możesz dziś przećwiczyć na własnym komputerze po jednym poleceniu instalacji - a stąd już blisko do pracy z prawdziwym Big Data.

Szkolenie Przetwarzanie danych Big Data z Apache Spark -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR. Ma terminy gwarantowane.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie PySpark i Spark SQL -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

BigQuery kontra Snowflake - czym się różnią i co wybrać?

Andrzej Klusiewicz — Fri, 18 Sep 2026 07:00:10 +0000

Praktyczne porównanie dwóch chmurowych hurtowni danych: model obliczeniowy, koszty, multi-chmura i podpowiedź, którą wybrać. Z prawdziwymi zrzutami z obu konso…

BigQuery i Snowflake w pigułce. Obie to chmurowe hurtownie danych, w których pytasz zwykłym SQL - ale filozofia pracy jest wyraźnie inna. Poniżej rozkładamy te różnice na czynniki pierwsze.

Jeśli szukasz chmurowej hurtowni danych, prędzej czy później staniesz przed pytaniem: BigQuery czy Snowflake? Obie nazwy słychać w tym samym zdaniu, obie robią pozornie to samo - trzymają ogromne ilości danych i pozwalają je analizować zwykłym SQL. A jednak różnią się w sposobie, który realnie wpływa na rachunek i na to, jak się z nimi pracuje. W tym artykule przeprowadzimy Cię przez te różnice bez marketingu: pokażemy, jak każde z nich liczy zapytanie, ile kosztuje i kiedy wybrać które - a wszystko na prawdziwych zrzutach z obu konsol.

Z tego artykułu dowiesz się:

To samo, a jednak inne

Zanim wypunktujemy różnice, warto zobaczyć, jak wiele te dwa narzędzia łączy - bo to tłumaczy, czemu tak często są zestawiane. Oba są chmurowymi hurtowniami danych. Hurtownia danych (po angielsku data warehouse) to szczególny rodzaj bazy zaprojektowany nie do obsługi aplikacji, lecz do analizy: liczenia sum, średnich, trendów i raportów na wielkich zbiorach. Fachowo mówi się o pracy w trybie OLAP (przetwarzanie analityczne) w odróżnieniu od zwykłych baz transakcyjnych.

Poza tym oba są kolumnowe (trzymają dane kolumnami, nie wierszami, więc zapytanie czyta z dysku tylko te kolumny, o które pyta), oba rozmawiają standardowym SQL i oba rozdzielają składowanie danych od mocy obliczeniowej - dane leżą tanio w jednym miejscu, a liczenie odbywa się osobno i skaluje niezależnie. Jeśli chcesz najpierw poznać każde z nich z osobna, opisaliśmy je w osobnych przewodnikach: czym jest BigQuery i jak działa hurtownia danych w chmurze oraz prosty przewodnik po Snowflake. Szerszy obraz całej układanki - hurtownie, jeziora danych i strumienie - znajdziesz w tekście o współczesnych rozwiązaniach Big Data.

Skoro tyle je łączy, gdzie tkwi różnica? Cała reszta artykułu to odpowiedź na to pytanie. Zaczniemy od najważniejszego - od tego, skąd biorą moc obliczeniową do liczenia Twoich zapytań.

Model obliczeniowy: bezserwerowy kontra hurtownie wirtualne

To jest sedno całego porównania i różnica, z której wynika większość pozostałych. Chodzi o to, skąd bierze się moc, która przelicza Twoje zapytanie.

BigQuery jest bezserwerowy (po angielsku serverless). Nie ma tam nic, co włączasz. Piszesz zapytanie, klikasz Uruchom, a Google sam - na czas jego wykonania - dokłada moc z tysięcy maszyn i zwalnia ją, gdy skończysz. Te jednostki mocy nazywają się slotami, ale nie musisz o nich myśleć: przydzielane są automatycznie, w tle. Nie ma czego rozmiarować ani wyłączać.

Snowflake idzie inną drogą - daje Ci hurtownie wirtualne (po angielsku virtual warehouses). Hurtownia wirtualna to klaster obliczeniowy, który sam włączasz i któremu sam nadajesz rozmiar - od najmniejszego X-Small, przez Small, Medium, aż po wielkie rozmiary. Większy klaster liczy szybciej, ale zużywa więcej mocy na godzinę. Na liście hurtowni widać to od razu: każda ma swój rozmiar i status (uśpiona albo uruchomiona):

Snowflake

Lista hurtowni wirtualnych w konsoli Snowflake (Snowsight). Zwróć uwagę na kolumnę Size - to Ty decydujesz, jak dużą moc uruchamiasz. W BigQuery takiej listy nie ma, bo nie ma czym zarządzać.

Po wejściu w konkretną hurtownię widać wszystkie pokrętła, którymi w Snowflake sterujesz: rozmiar, liczbę klastrów, a przede wszystkim automatyczne wyłączanie po bezczynności (auto-suspend) oraz automatyczne wznawianie przy pierwszym zapytaniu (auto-resume). To ważny szczegół kosztowy - o nim za chwilę.

Snowflake

Szczegóły hurtowni w Snowflake. Rozmiar X-Small, wyłączanie po 5 minutach bezczynności, wznawianie automatyczne - to wszystko elementy, którymi w BigQuery nie musisz się zajmować, bo tam moc pojawia się i znika sama.

A gdy zakładasz nową hurtownię, jej rozmiar wybierasz wprost z listy - od X-Small po 4X-Large. To jedyne miejsce w całym porównaniu, w którym sam decydujesz o wielkości mocy obliczeniowej:

Snowflake

Zakładanie hurtowni w Snowflake. Rozmiar wybierasz z listy - od X-Small po 4X-Large. Większy liczy szybciej, ale zużywa proporcjonalnie więcej kredytów. W BigQuery takiego wyboru nie ma, bo moc dobiera się sama.

Najlepiej widać tę różnicę, gdy prześledzisz drogę jednego zapytania w obu narzędziach. U góry BigQuery: zapytanie po prostu dostaje moc w locie. U dołu Snowflake: hurtownia najpierw wstaje, liczy, a po chwili bezczynności sama się wyłącza:

Ta sama praca, inne podejście do mocy. BigQuery przydziela ją niewidzialnie na czas zapytania. Snowflake daje Ci nad nią kontrolę - w zamian za odrobinę zarządzania.

Którą filozofię wolisz, to w dużej mierze kwestia tego, czy cenisz sobie zero zachodu (BigQuery), czy pełną kontrolę nad mocą i jej kosztem (Snowflake). Ta kontrola daje Snowflake jeszcze jedną, sztandarową zaletę - opisujemy ją zaraz.

Izolacja obciążeń: wiele hurtowni na tych samych danych

Skoro w Snowflake sam tworzysz hurtownie, możesz mieć ich kilka naraz - i każda pracuje niezależnie na tych samych danych. To rozwiązuje bolączkę zwykłych baz, w których ciężki import albo ktoś liczący gigantyczny raport potrafi spowolnić wszystkich pozostałych. Fachowo mówi się o izolacji obciążeń (po angielsku workload isolation): różne rodzaje pracy nie wchodzą sobie w drogę, bo liczą je osobne klastry.

W Snowflake każdy zespół może dostać własną hurtownię o dobranym rozmiarze. Wszystkie czytają te same tabele, ale nie rywalizują o moc - import nie spowalnia raportów, a raporty nie spowalniają importu.

W praktyce wygląda to tak: zespół analityków dostaje swoją hurtownię, nocne ładowanie danych - swoją, a pulpity BI - jeszcze inną. Każda ma osobny rozmiar i osobny rachunek, więc od razu widać, kto ile mocy zużywa. BigQuery osiąga podobny efekt inną drogą: jest bezserwerowy, więc nie tworzysz osobnych hurtowni - Google sam skaluje moc pod równoległe zapytania, a gdy potrzebujesz gwarancji wydajności dla konkretnego zespołu, wydzielasz mu pulę slotów przez rezerwacje. Cel ten sam, mechanika inna.

Chcesz opanować Snowflake od strony praktycznej - hurtownie, izolację obciążeń, wydajność i koszty? Szkolenie Przetwarzanie danych z użyciem Snowflake prowadzi przez to na realnych danych i ma terminy gwarantowane.

A jeśli bliżej Ci do świata Google, Szkolenie Google BigQuery - podstawy pokazuje BigQuery od zera - konsolę, zapytania i panowanie nad kosztami.

Zapytania i wyniki: prawie identycznie

Tu obie hurtownie są zaskakująco podobne, bo obie rozmawiają zwykłym SQL. Napiszmy to samo zapytanie w jednym i drugim - policzmy, ilu klientów przypada na każdy segment rynku w przykładowym zbiorze danych. Zapytanie jest dokładnie takie, jakie napisałbyś w dowolnej innej bazie:

SELECT c_mktsegment AS segment,
       COUNT(*) AS customers,
       ROUND(AVG(c_acctbal), 2) AS avg_balance
FROM snowflake_sample_data.tpch_sf1.customer
GROUP BY c_mktsegment
ORDER BY customers DESC;

W Snowflake wpisujesz je do arkusza, wybierasz hurtownię, która ma je policzyć, i klikasz Uruchom. Wynik pojawia się pod spodem jako tabela - tutaj w ułamku sekundy, mimo że zbiór ma 150 tysięcy wierszy:

Snowflake

Arkusz w konsoli Snowflake. U góry zapytanie i wybór hurtowni (COMPUTE_WH, rozmiar X-Small), poniżej gotowa tabela wyników. Zapytanie policzyło się w 121 milisekund.

W BigQuery ta sama historia wygląda niemal tak samo: edytor z zapytaniem, przycisk Uruchom, tabela wyników pod spodem. Nie ma tu jednak wyboru hurtowni, bo moc dokłada się sama:

BigQuery

Konsola BigQuery przy pracy nad innym przykładem. Ten sam schemat: edytor u góry, wynik pod spodem - tyle że bez wskazywania, skąd wziąć moc obliczeniową.

Oba narzędzia potrafią też od razu zamienić tabelę wyników w wykres, bez wychodzenia z konsoli. W Snowflake wystarczy przełączyć zakładkę na wykres i wskazać, co ma być na osiach:

Snowflake

Wynik jako wykres słupkowy w Snowflake. Po lewej konfiguracja osi, po prawej gotowy wykres. BigQuery ma dokładnie taką samą możliwość w swojej zakładce wizualizacji.

Wniosek z tej sekcji jest prosty: od strony pisania zapytań przesiadka z jednego na drugie jest niemal bezbolesna. Kto zna SQL, ruszy w obu od pierwszej minuty. Różnice, które naprawdę bolą lub cieszą, siedzą gdzie indziej - w tym, co dzieje się pod maską i na rachunku.

Co pod maską: jak liczą Twoje zapytanie

Oba narzędzia biorą Twoje jedno zapytanie i tną je na drobne zadania liczone równolegle na wielu maszynach - stąd ich prędkość na wielkich zbiorach. Oba pozwalają też podejrzeć, jak zapytanie faktycznie się policzyło. To bardzo pomaga, gdy coś działa wolno albo kosztuje więcej, niż powinno.

W BigQuery służy do tego graf wykonania (po angielsku execution graph): pokazuje, skąd zapytanie wzięło dane i ile rekordów przeszło przez kolejne etapy przetwarzania.

BigQuery

Graf wykonania w BigQuery. Widać, jak zapytanie przeszło od źródła danych przez kolejne etapy aż do wyniku i gdzie zeszło najwięcej pracy.

Snowflake ma swój odpowiednik - profil zapytania (po angielsku query profile). To drzewo operatorów: odczyt tabeli, agregacja, sortowanie, wynik. Do tego panel z najbardziej kosztownymi krokami, czasem wykonania i liczbą przeczytanych partycji danych:

Snowflake

Profil zapytania w Snowflake. Drzewo pokazuje kolejne operacje: odczyt tabeli (TableScan) na 150 tysiącach wierszy, agregację, sortowanie i wynik. Po prawej najkosztowniejsze kroki i statystyki.

Oba widoki mówią o tym samym: gdzie zeszła praca i za co realnie zapłacisz. Zajrzenie tutaj to najlepszy pierwszy krok, gdy chcesz przyspieszyć zapytanie albo obniżyć jego koszt - a jak liczony jest ten koszt, różni się między narzędziami zasadniczo.

Ile to kosztuje: za dane kontra za czas

To najważniejsza różnica praktyczna i najczęstsze źródło niespodzianek na rachunku. Modele rozliczeń są zbudowane wokół dwóch zupełnie różnych rzeczy.

Dwa różne modele płacenia. To do nich sprowadza się większość decyzji o kosztach - i to je najłatwiej źle oszacować.

BigQuery liczy koszt od ilości danych, które przeskanowało zapytanie - nie od czasu ani liczby zapytań. Co ważne, konsola mówi Ci to z góry, jeszcze przed uruchomieniem, więc nigdy nie liczysz w ciemno:

BigQuery

BigQuery pokazuje szacunek przeskanowanych danych, zanim klikniesz Uruchom. Ponieważ dane leżą kolumnami, płacisz tylko za te kolumny, o które faktycznie pytasz.

Snowflake liczy koszt od czasu pracy włączonej hurtowni, wyrażonego w kredytach (wewnętrznej jednostce rozliczeniowej Snowflake). Liczy się każda sekunda, gdy hurtownia jest uruchomiona, z minimalnym naliczeniem 60 sekund przy każdym wznowieniu. Większy rozmiar klastra liczy szybciej, ale zjada proporcjonalnie więcej kredytów na godzinę. Dlatego tak ważny jest wspomniany auto-suspend: hurtownia, która sama się wyłącza po bezczynności, nie spala kredytów za nic.

Skąd biorą się niespodzianki na rachunku.

W BigQuery zdradliwe jest SELECT * - każe przeczytać wszystkie kolumny, także te niepotrzebne, a płacisz właśnie za przeczytane dane. W Snowflake zdradliwa jest zapomniana, wciąż włączona hurtownia - albo zbyt duży klaster do prostych zapytań. W obu przypadkach lekarstwo jest tanie: wybieraj konkretne kolumny zamiast gwiazdki i pilnuj, żeby moc wyłączała się, gdy nie pracuje.

Która hurtownia wyjdzie taniej, zależy więc od charakteru pracy. Przy nieregularnych, rzadkich analizach zwykle wygrywa BigQuery - płacisz tylko za to, co realnie przeskanujesz, i nic, gdy nie pytasz. Przy stałym, przewidywalnym obciążeniu, gdzie moc jest wykorzystywana w pełni przez większość dnia, dobrze zestrojony Snowflake bywa tańszy i daje lepszą kontrolę nad wydatkiem.

Chcesz poznać BigQuery od podstaw i od początku panować nad kosztami zapytań? Szkolenie Google BigQuery - podstawy prowadzi przez konsolę, zapytania i model rozliczeń krok po kroku na realnych danych.

Po stronie Snowflake koszty i wydajność przećwiczysz na Szkolenie Przetwarzanie danych z użyciem Snowflake, które ma terminy gwarantowane.

Na jakiej chmurze to działa

Tu różnica jest krótka do opisania, ale dla wielu firm decydująca. BigQuery działa wyłącznie w chmurze Google (Google Cloud). To zaleta, jeśli Twoje dane i narzędzia już tam są - na przykład Google Ads, Google Analytics czy Looker - bo wszystko siedzi blisko siebie. To wada, jeśli reszta Twojej firmy stoi na innej chmurze.

Snowflake jest niezależny od dostawcy chmury - ten sam produkt działa na Amazon AWS, Microsoft Azure albo Google Cloud. BigQuery jest związany z Google.

Snowflake działa na wszystkich trzech dużych chmurach: Amazon AWS, Microsoft Azure oraz Google Cloud. Wybierasz jedną przy zakładaniu konta, a ten sam Snowflake wygląda i działa na każdej tak samo. Dla firm, które nie chcą przywiązywać się do jednego dostawcy (albo już stoją na AWS lub Azure), to jeden z głównych argumentów za Snowflake. Przy okazji Snowflake ma też własny rynek danych (marketplace), przez który organizacje udostępniają i kupują gotowe zbiory - to obszar, w którym idzie o krok dalej niż klasyczna hurtownia.

Wizualizacja i ekosystem

Hurtownia to dopiero połowa drogi - dane trzeba jeszcze pokazać. Tu oba narzędzia grają podobnie: wynik z jednego i drugiego podłączysz do popularnych narzędzi analitycznych i pulpitów. BigQuery ma naturalne, ścisłe połączenie z ekosystemem Google (darmowe Looker Studio, Arkusze, a dalej Vertex AI do uczenia maszynowego). Snowflake stawia na niezależność i integruje się z całym rynkiem - od narzędzi do wizualizacji po własne środowisko Snowpark do przetwarzania danych w Pythonie.

W jedno i drugie świetnie wpina się Power BI - jeśli interesuje Cię właśnie budowanie czytelnych pulpitów na danych z hurtowni, zajrzyj do naszego przewodnika czym jest Power BI, Power Query i DAX. To w praktyce najczęstszy dalszy krok po tym, jak dane wylądują w BigQuery albo w Snowflake.

Porównanie cecha po cesze

Zbierzmy najważniejsze różnice w jednym miejscu. Tam, gdzie oba wiersze brzmią podobnie, diabeł tkwi w szczegółach opisanych wyżej:

BigQuery kontra Snowflake, cecha po cesze. Pełny opis każdej pozycji znajdziesz w sekcjach powyżej.

Kiedy BigQuery, a kiedy Snowflake

Nie ma tu lepszego i gorszego - jest lepiej dopasowany do Twojej sytuacji. Poniższa ściągawka podsumowuje, w którą stronę zwykle warto się skłonić:

Skrót decyzji. Żadna z tych list nie jest sztywną regułą - to punkty, które najczęściej przeważają szalę na jedną albo drugą stronę.

Wybierz BigQuery, jeśli

Jesteś już w Google Cloud albo korzystasz z Google Ads i Analytics
Chcesz zero administracji i najszybszy start
Masz zapytania nieregularne, ad-hoc, o zmiennym natężeniu
Zależy Ci na tym, by płacić wyłącznie za to, co realnie przeskanujesz

Wybierz Snowflake, jeśli

Chcesz niezależności od jednej chmury lub stoisz na AWS albo Azure
Potrzebujesz izolacji obciążeń - wiele zespołów, przewidywalna wydajność
Masz stałe, ciężkie i przewidywalne obciążenie
Zależy Ci na pełnej kontroli nad rozmiarem i kosztem mocy oraz na współdzieleniu danych między firmami

Najprostsza podpowiedź na start.

Jeśli wahasz się, od czego zacząć naukę - zacznij od tego, gdzie już masz dane. Siedzisz w Google? Otwórz darmowy sandbox BigQuery. Stoisz na AWS lub Azure, albo chcesz poczuć ideę hurtowni wirtualnych? Załóż 30-dniowe darmowe konto próbne Snowflake. W obu i tak ćwiczysz ten sam SQL, więc żadna godzina nie jest zmarnowana.

Fundament obu narzędzi jest wspólny i znasz go już z tego artykułu: dane w chmurze plus zwykłe zapytanie SQL, bez własnego serwera po Twojej stronie. Różni je to, skąd biorą moc i za co każą płacić - a to, którą wybrać, wynika wprost z tego, jak i gdzie pracujesz.

Rozumiesz już, czym różnią się obie chmurowe hurtownie - czas zamienić to w praktyczną umiejętność.

Na praktycznych szkoleniach JSystems przećwiczysz to na żywych danych - jedno prowadzi przez BigQuery, drugie przez Snowflake:

Szkolenie Google BigQuery - podstawy -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Przetwarzanie danych z użyciem Snowflake -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR. To szkolenie ma terminy gwarantowane.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

Co to jest BigQuery? Kompletny przewodnik dla początkujących

Andrzej Klusiewicz — Fri, 18 Sep 2026 00:03:41 +0000

BigQuery wytłumaczony od zera: czym jest chmurowa hurtownia danych Google, jak działa, ile kosztuje i jak zadać pierwsze zapytanie SQL. Z prawdziwymi zrzutami …

Konsola BigQuery w działaniu. U góry zapytanie SQL, poniżej gotowa tabela wyników - a nad nią zakładki do wykresu i szczegółów wykonania. Wszystko w przeglądarce, bez instalowania czegokolwiek.

Jeśli zaczynasz przygodę z analizą danych, prędzej czy później usłyszysz nazwę BigQuery. Dla jednych to tajemnicza usługa Google, do której firmy wrzucają terabajty danych. W rzeczywistości to jedno z najprostszych wejść w świat wielkich danych: piszesz zwykłe zapytanie SQL, klikasz i w kilka sekund dostajesz odpowiedź przeliczoną na tysiącach maszyn - a sam nie zarządzasz żadnym serwerem. W tym przewodniku wytłumaczymy od zera, czym jest BigQuery, po co powstał, jak działa i ile kosztuje, a wszystko pokażemy na prawdziwych zrzutach z konsoli.

Z tego artykułu dowiesz się:

Czym jest BigQuery?

Najprościej: BigQuery to chmurowa hurtownia danych Google - miejsce, w którym trzymasz ogromne ilości danych i przeszukujesz je zwykłym językiem SQL, nie martwiąc się o żaden serwer. Hurtownia danych (po angielsku data warehouse) to specjalny rodzaj bazy przystosowany nie do obsługi aplikacji, lecz do analizy: liczenia sum, średnich, trendów i raportów na wielkich zbiorach.

Najważniejsze w BigQuery jest słowo bezserwerowy (po angielsku serverless). Nie instalujesz bazy, nie kupujesz maszyny, nie pilnujesz aktualizacji. Otwierasz stronę w przeglądarce, piszesz zapytanie, a Google na czas jego wykonania sam dokłada moc obliczeniową z tysięcy komputerów i zwalnia ją, gdy skończysz. Dzięki temu zapytanie, które na jednym serwerze liczyłoby się godzinami, tutaj kończy się w sekundy.

Cztery cechy, które najlepiej oddają, czym jest BigQuery i czym różni się od zwykłej bazy danych.

Cała reszta wynika z tych czterech cech. BigQuery jest kolumnowy, czyli trzyma dane kolumnami, a nie wierszami - dzięki temu czyta z dysku tylko te kolumny, o które pytasz. Rozmawiasz z nim zwykłym SQL, więc jeśli znasz podstawy zapytań z jakiejkolwiek innej bazy, od razu ruszasz. I działa w skali petabajtów: te same zapytania równie sprawnie chodzą na tysiącu wierszy, jak i na miliardach.

Po co komu BigQuery? Kto z niego korzysta

Można pomyśleć, że hurtownia danych to zabawka wyłącznie dla wielkich korporacji. Tak było kilkanaście lat temu, gdy trzeba było kupić drogie serwery. Dziś próg wejścia jest tak niski, że BigQuery przydaje się bardzo różnym osobom:

Analitycy i managerowie

Liczą sprzedaż, ruch i wskaźniki na danych z wielu lat naraz
Budują raporty i pulpity, które odświeżają się automatycznie
Odpowiadają na pytania biznesowe w minuty, nie w dni

Firmy i zespoły produktowe

Zbierają w jednym miejscu dane ze sklepu, aplikacji i reklam
Nie utrzymują własnej infrastruktury bazodanowej
Płacą za tyle mocy, ile realnie zużyją

Inżynierowie danych

Przetwarzają surowe dane w gotowe tabele do analizy
Budują potoki ładowania danych i strumienie na żywo
Trenują proste modele uczenia maszynowego wprost w SQL

Marketing i e-commerce

Łączą dane z Google Ads, sklepu i analityki w jeden obraz
Sprawdzają, które kampanie naprawdę się zwracają
Segmentują klientów na podstawie realnych zachowań

Wspólny mianownik jest jeden: BigQuery oszczędza czas i pieniądze. Zadanie, które kiedyś wymagało zespołu administratorów i tygodni przygotowań, dziś sprowadza się do napisania kilku linijek SQL. Zanim jednak napiszemy pierwsze zapytanie, warto zrozumieć, czym hurtownia różni się od zwykłej bazy - bo to najczęstsze źródło nieporozumień.

Hurtownia danych a zwykła baza

To pytanie pada najczęściej: skoro mam już bazę danych, po co mi jeszcze BigQuery? Odpowiedź jest taka, że to dwa narzędzia do dwóch różnych zadań. Fachowo mówi się o dwóch trybach pracy: OLTP i OLAP.

Zwykła baza obsługuje bieżącą pracę aplikacji, hurtownia danych analizuje historię. BigQuery jest po tej drugiej stronie.

OLTP (przetwarzanie transakcji, po angielsku Online Transaction Processing) to zwykła baza za Twoją aplikacją - PostgreSQL, MySQL, Oracle. Jej zadanie to obsługa mnóstwa drobnych, szybkich operacji: dodaj zamówienie, zmień status, pobierz dane jednego klienta. Pracuje na wierszach i musi odpowiadać błyskawicznie tysiącom użytkowników jednocześnie.

OLAP (przetwarzanie analityczne, po angielsku Online Analytical Processing) to właśnie hurtownia danych jak BigQuery. Tu nie chodzi o pojedynczy rekord, tylko o pytania w rodzaju: ile sprzedaliśmy w każdym miesiącu przez ostatnie pięć lat, w podziale na regiony. Takie zapytanie dotyka milionów wierszy naraz i liczy z nich agregaty. Więcej o tym, kiedy sięgać po bazę relacyjną, a kiedy po inne rozwiązanie, znajdziesz w naszym porównaniu baz danych SQL kontra NoSQL.

W praktyce te dwa światy współpracują: aplikacja zapisuje bieżące dane do zwykłej bazy, a co jakiś czas ich kopia trafia do hurtowni, gdzie analitycy spokojnie liczą ciężkie raporty, nie obciążając bazy produkcyjnej.

Pierwsze kroki: darmowy sandbox i konsola

Najlepsze w BigQuery jest to, że możesz go dotknąć od ręki i za darmo. Google udostępnia tryb sandbox (piaskownica) - konto do zabawy, które nie wymaga podawania karty płatniczej. Wystarczy konto Google. Cała droga od zera do pierwszego wyniku ma tylko cztery kroki:

Od zera do pierwszego wyniku w BigQuery wystarczą cztery kroki - każdy w przeglądarce.

Żeby nie zaczynać od pustej hurtowni, Google udostępnia dziesiątki gotowych publicznych zbiorów danych (projekt bigquery-public-data) - od imion nadawanych dzieciom, przez dane pogodowe, po statystyki z serwisu Stack Overflow. Możesz je od razu przeszukiwać, nie wgrywając niczego swojego. Po lewej stronie konsoli widać drzewo z tymi zbiorami, a po kliknięciu tabeli - jej strukturę:

Po lewej publiczne zbiory danych Google. Po prawej schemat tabeli z imionami: widać nazwy kolumn, ich typy i opisy.

Zakładka Schema (schemat) to metryczka tabeli - mówi, jakie ma kolumny i jakiego są typu. W naszej przykładowej tabeli z amerykańskimi imionami są kolumny state (stan), gender (płeć), year (rok), name (imię) i number (liczba nadań). Obok, w zakładce Details (szczegóły), BigQuery pokazuje między innymi, ile tabela ma wierszy i ile miejsca zajmuje:

Szczegóły tabeli. Ta konkretna ma ponad 6,3 miliona wierszy - a mimo to zapytania na niej liczą się w sekundy.

Ponad sześć milionów wierszy, a mimo to za chwilę przeszukamy je w ułamku sekundy. To dobry moment, żeby napisać pierwsze zapytanie.

Twoje pierwsze zapytanie SQL

W BigQuery pytasz zwykłym SQL. Zobaczmy najprostszy przykład: sprawdźmy dziesięć najpopularniejszych imion w Kalifornii w całej historii tego zbioru. Wpisujemy zapytanie do edytora:

SELECT name, gender, SUM(number) AS total
FROM `bigquery-public-data.usa_names.usa_1910_current`
WHERE state = 'CA'
GROUP BY name, gender
ORDER BY total DESC
LIMIT 10;

Jeśli pisałeś kiedykolwiek zapytanie SQL, wszystko tu jest znajome. Jedyny nietypowy element to nazwa tabeli w odwrotnych apostrofach: projekt.zbior.tabela. To pełny adres tabeli w BigQuery - najpierw projekt (bigquery-public-data), potem zbiór danych (usa_names), na końcu sama tabela. Klikamy Uruchom i po chwili dostajemy wynik, który widać było na pierwszym zrzucie na górze artykułu. Ten sam wynik możemy jednym kliknięciem pokazać jako wykres:

Zakładka wizualizacji zamienia tabelę wyników w wykres bez wychodzenia z konsoli. Po prawej ustawiasz, co ma być na osiach.

Zanim w ogóle napiszesz zapytanie, możesz też po prostu zajrzeć do danych. Zakładka Preview (podgląd) pokazuje pierwsze wiersze tabeli jak arkusz kalkulacyjny - i co ważne, taki podgląd nic nie kosztuje, bo nie uruchamia żadnego zapytania:

Podgląd danych bez pisania zapytania. Wygodny sposób, żeby zobaczyć, co w ogóle siedzi w tabeli, zanim zaczniesz liczyć.

Chcesz przejść przez BigQuery krok po kroku, na żywych danych i pod okiem praktyka? Szkolenie Google BigQuery - podstawy prowadzi od pierwszego zapytania do analizy danych w chmurze.

Jak to działa pod maską

Skąd bierze się prędkość BigQuery? Z dwóch pomysłów, które warto znać, nawet jeśli na co dzień o nich nie myślisz. Pierwszy to zrównoleglenie: gdy klikasz Uruchom, Twoje jedno zapytanie nie liczy się na jednej maszynie, tylko zostaje pocięte na drobne zadania rozdane setkom jednostek roboczych, które pracują naraz.

Droga zapytania: od Twojego SQL, przez podział na zadania i równoległe liczenie, po gotowy wynik. To dlatego duże zapytania kończą się w sekundy.

Te jednostki robocze to sloty (po angielsku slots) - jednostki mocy obliczeniowej BigQuery. Nie musisz nimi zarządzać, Google przydziela je na czas zapytania. Po drodze następuje jeszcze wymiana danych między etapami (fachowo shuffle), czyli przekazanie wyników cząstkowych tam, gdzie trzeba je zsumować. Cały ten plan zobaczysz w zakładce Execution graph (graf wykonania):

Graf wykonania pokazuje, jak zapytanie faktycznie się policzyło: skąd wzięło dane, ile rekordów przeszło przez kolejne etapy i gdzie zeszło najwięcej czasu.

Drugi pomysł to wspomniane już składowanie kolumnowe. Zwykła baza trzyma dane wierszami: cały rekord jednego imienia leży razem. BigQuery odwraca to i trzyma każdą kolumnę osobno. Dzięki temu, gdy pytasz tylko o kolumny name i number, silnik czyta z dysku wyłącznie te dwie kolumny, a pozostałe w ogóle nie rusza:

Składowanie kolumnowe w praktyce. Zapytanie dotyka tylko kolumn name i number - trzy pozostałe zostają na dysku nietknięte. To nie tylko przyspiesza, ale też wprost obniża koszt, o czym za chwilę.

Ile to kosztuje?

To pytanie zwykle pada zaraz po pierwszym zachwycie. Dobra wiadomość jest taka, że na naukę BigQuery jest w praktyce darmowy, a płatne modele są proste i przewidywalne. Są dwa sposoby rozliczeń:

Dwa modele rozliczeń BigQuery. Na start liczy się przede wszystkim to, że darmowy limit obejmuje 1 terabajt zapytań miesięcznie.

W modelu na żądanie (po angielsku on-demand), domyślnym i najwygodniejszym na start, płacisz nie za liczbę zapytań ani za czas, tylko za ilość danych, którą zapytanie przeskanowało. Co najważniejsze, konsola mówi Ci to z góry - jeszcze przed uruchomieniem pokazuje szacunek u dołu edytora:

Zanim klikniesz Uruchom, BigQuery mówi, ile danych przeskanuje zapytanie (tutaj około 138 megabajtów). Nigdy nie liczysz w ciemno.

Po wykonaniu zapytania te same liczby znajdziesz w zakładce Job information (informacje o zadaniu). Nasze przykładowe zapytanie przetworzyło niecałe 138 megabajtów i policzyło się w 377 milisekund:

Podsumowanie wykonanego zapytania: przetworzone dane, dane rozliczone i czas trwania. To na podstawie pola z przetworzonymi danymi naliczana jest opłata w modelu na żądanie.

Drugi model, pojemnościowy (sloty), to stała opłata za zarezerwowaną moc obliczeniową. Opłaca się dużym firmom z ciągłym, przewidywalnym obciążeniem, ale na początek prawie na pewno go nie potrzebujesz. Do rozliczeń dochodzi jeszcze niski koszt składowania danych. W darmowym limicie mieści się 1 terabajt zapytań miesięcznie oraz 10 gigabajtów składowania - do nauki i większości małych projektów to bardzo dużo. Orientacyjnie, po przekroczeniu limitu skanowanie danych kosztuje kilka dolarów za terabajt, ale konkretne stawki najlepiej sprawdzić w aktualnym cenniku Google, bo bywają aktualizowane.

Najczęstszy błąd początkującego: SELECT gwiazdka.

Zapytanie SELECT * każe BigQuery przeczytać wszystkie kolumny, także te, których wcale nie potrzebujesz - a płacisz właśnie za przeczytane dane. Na szerokiej tabeli to różnica między groszami a sporym rachunkiem. Zasada na całe życie z BigQuery: wybieraj konkretne kolumny, których naprawdę używasz, zamiast gwiazdki.

Skąd wziąć dane? Ładowanie i integracje

Publiczne zbiory są świetne do nauki, ale prawdziwa wartość zaczyna się, gdy wrzucisz do BigQuery własne dane. Nie trzeba do tego żadnego skomplikowanego programu - w konsoli jest przycisk dodawania danych, a pod nim całkiem długa lista źródeł:

Katalog źródeł danych w BigQuery. Najprościej wgrać plik z dysku albo z Google Cloud Storage, ale gotowe konektory sięgają też po dane z reklam czy innych hurtowni.

Dla początkującego najprostsze są dwie drogi: wgranie pliku CSV (albo JSON) prosto z komputera oraz wczytanie danych z Google Cloud Storage (chmurowy magazyn plików Google). Bardziej zaawansowane zespoły podłączają gotowe konektory do reklam, systemów sklepowych czy innych hurtowni, żeby dane spływały automatycznie. Cała ta układanka wygląda tak:

Miejsce BigQuery w świecie danych: dane wpływają ze źródeł, BigQuery je składuje i przelicza, a wynik trafia do narzędzi analitycznych i pulpitów.

Na wyjściu podłączasz wynik do narzędzi, w których dane się ogląda i prezentuje: darmowego Looker Studio od Google, arkuszy albo Power BI. Jeśli interesuje Cię właśnie ta strona - budowanie czytelnych pulpitów na danych z hurtowni - zajrzyj do naszego przewodnika czym jest Power BI, Power Query i DAX.

BigQuery a inne narzędzia

BigQuery nie jest jedyną chmurową hurtownią danych. Warto wiedzieć, w jakim towarzystwie się porusza, bo nazwy tych usług często słychać obok siebie:

Narzędzie	Co to jest	Dla kogo
BigQuery	Bezserwerowa hurtownia danych Google. Płacisz za przeskanowane dane.	Zespoły w chmurze Google, marketing, szybki start bez administracji
Snowflake	Chmurowa hurtownia działająca na wielu chmurach naraz. Rozdziela składowanie od mocy.	Firmy, które nie chcą przywiązywać się do jednego dostawcy chmury
Amazon Redshift	Hurtownia danych w chmurze Amazona (AWS).	Zespoły, które już siedzą w ekosystemie AWS
PostgreSQL, Oracle	Klasyczne bazy relacyjne (OLTP) do obsługi aplikacji.	Systemy transakcyjne, gdzie liczy się pojedynczy rekord

Najbliższym kuzynem BigQuery jest Snowflake - też chmurowa hurtownia, też rozmawia SQL, tylko z inną filozofią rozliczeń i niezależnością od jednej chmury. Jeśli zastanawiasz się, który z nich wybrać, zestawiliśmy je wprost w artykule BigQuery kontra Snowflake - czym się różnią i co wybrać. Jeśli chcesz zobaczyć drugą stronę tego świata, opisaliśmy ją osobno: co to jest Snowflake. A szerszy obraz całej układanki - hurtownie, jeziora danych i strumienie - znajdziesz w tekście o współczesnych rozwiązaniach Big Data.

Dobre praktyki na start

Na koniec kilka nawyków, które warto wyrobić sobie od pierwszego dnia. Nie są trudne, a oszczędzą Ci pieniędzy i nerwów.

Cztery zasady, które opłaca się znać od początku:

Wybieraj kolumny, nie gwiazdkę. Skoro płacisz za przeczytane dane, pytaj tylko o te kolumny, których używasz. To najprostszy sposób na niższy rachunek.
Patrz na szacunek przed uruchomieniem. Konsola zawsze mówi, ile danych przetworzy zapytanie. Jeśli widzisz gigabajty tam, gdzie spodziewasz się megabajtów, coś jest nie tak.
Poznaj partycjonowanie i klastrowanie. To sposoby ułożenia tabeli tak, by zapytania czytały tylko potrzebny fragment danych (na przykład jeden dzień), a nie całą historię. Na większych tabelach potrafią wielokrotnie obniżyć koszt.
Zacznij od sandbox. Darmowy tryb pozwala przećwiczyć wszystko bez ryzyka. Kartę płatniczą podłączysz dopiero, gdy naprawdę będziesz jej potrzebować.

Tyle wystarczy, żeby ruszyć. BigQuery należy do tych narzędzi, w których pierwszy wynik dostajesz w kilka minut, a potem stopniowo odkrywasz kolejne możliwości: partycje, funkcje analityczne, uczenie maszynowe w SQL czy strumienie danych na żywo. Fundament jednak jest prosty i znasz go już z tego artykułu: dane w chmurze plus zwykłe zapytanie SQL, bez żadnego serwera po Twojej stronie.

Rozumiesz już, czym jest hurtownia danych w chmurze - czas zamienić to w praktyczną umiejętność.

Najkrótsza droga to przejść przez BigQuery na żywych danych, pod okiem trenera:

Szkolenie Google BigQuery - podstawy -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

Co to jest Oracle Database i czym różni się od innych baz danych

Andrzej Klusiewicz — Mon, 14 Sep 2026 08:57:27 +0000

Oracle Database to jedna z tych baz, o której każdy słyszał, ale mało kto potrafi jasno powiedzieć czym różni się od reszty. Rozkładam to na konkrety.

Oracle Database 26ai w akcji - zapytanie łączące dwie tabele i grupujące wyniki, uruchomione w przeglądarkowym narzędziu Database Actions (SQL Developer Web). Widać czas wykonania i gotową siatkę wyników.

Oracle Database to jeden z najbardziej rozpoznawalnych systemów baz danych na świecie i od dekad standard w bankowości, telekomunikacji oraz dużych systemach firmowych. W tym przewodniku wyjaśnimy prostym językiem, czym Oracle jest, jak jest zbudowany i - co najważniejsze - czym rzeczywiście różni się od PostgreSQL, MySQL/MariaDB oraz Microsoft SQL Server. Pokażemy też, gdzie Oracle jest dziś: w chmurze i w erze sztucznej inteligencji.

Z tego artykułu dowiesz się

Co to jest Oracle Database?

Oracle Database to system zarządzania relacyjną bazą danych (po angielsku RDBMS - relational database management system), czyli oprogramowanie, które przechowuje dane w tabelach powiązanych ze sobą relacjami i udostępnia je przez język zapytań SQL. Mówiąc prosto - to silnik, któremu firma powierza swoje najważniejsze dane (klientów, zamówienia, transakcje) i który pilnuje, żeby te dane były spójne, bezpieczne i dostępne nawet przy tysiącach jednoczesnych użytkowników.

Bazę Oracle rozwija firma Oracle Corporation. Pierwsza komercyjna wersja pojawiła się w 1979 roku i od tego czasu system przeszedł drogę od wersji 7, przez słynne 8i, 9i, 10g i 11g, aż po dzisiejsze wydania oznaczane rokiem: 19c, 21c, a następnie 23ai i 26ai. Litera w nazwie zawsze zdradzała kierunek epoki - i jak internet, g jak grid (sieć serwerów), c jak cloud (chmura), a najnowsze ai jak sztuczna inteligencja. Więcej o różnicach między tymi wydaniami opisaliśmy w osobnym tekście o nowościach w Oracle od wersji 19c po 26ai.

Do czego służy Oracle w praktyce? Najczęściej stoi pod systemami, w których błąd lub przestój kosztuje najwięcej - pod systemami bankowymi i ubezpieczeniowymi, systemami ERP (zarządzanie firmą) i CRM (obsługa klienta), platformami telekomunikacyjnymi, systemami rezerwacji czy rozliczeń. To baza, którą zaprojektowano z myślą o dużej skali, wysokiej dostępności i twardych wymaganiach dotyczących spójności danych.

Architektura Oracle w pigułce: instancja i baza danych

Żeby zrozumieć Oracle (i późniejsze różnice wobec innych baz), trzeba poznać jedno kluczowe rozróżnienie: instancja to nie to samo co baza danych. Baza danych to zbiór plików na dysku, w których trwale mieszkają dane. Instancja to zestaw obszarów pamięci i procesów działających w tle, które te pliki obsługują. Dopiero instancja podłączona do bazy daje działający system, do którego można się połączyć i wykonać zapytanie.

Droga zapytania w Oracle - aplikacja trafia do instancji (pamięć wspóldzielona SGA i procesy tła), a dane trwałe zapisywane są w plikach bazy. Instancja plus baza danych to razem działający system Oracle.

Pamięć: SGA i PGA

Sercem instancji jest SGA (System Global Area) - wspóldzielony obszar pamięci, z którego korzystają wszyscy użytkownicy. Składają się na niego między innymi Database Buffer Cache (bufor z blokami danych trzymanymi w pamięci, żeby nie czytać ich ciągle z dysku), Shared Pool (miejsce na gotowe plany wykonania zapytań i słownik danych) oraz Redo Log Buffer (bufor zapisujący każdą zmianę, dzięki któremu bazę da się odtworzyć po awarii). Obok SGA istnieje jeszcze PGA (Program Global Area) - prywatna pamięć przypisana do pojedynczej sesji, gdzie odbywają się na przykład sortowania.

Procesy tła

Za kulisami pracuje zestaw wyspecjalizowanych procesów. Najważniejsze z nich to DBWn (Database Writer - zapisuje zmienione bloki z pamięci na dysk), LGWR (Log Writer - zapisuje zmiany do dzienników redo), CKPT (Checkpoint - wyznacza punkty spójności), SMON (System Monitor - odzyskuje bazę po awarii instancji), PMON (Process Monitor - sprząta po zerwanych sesjach) oraz ARCn (Archiver - archiwizuje dzienniki redo). Ten podział obowiązków sprawia, że użytkownik nie czeka na zapis na dysk - jego zmiana najpierw trafia do pamięci, a procesy tła dbają o resztę.

Pliki bazy danych

Na trwałe dane składają się głównie pliki danych (z tabelami i indeksami), pliki kontrolne (opisujące strukturę bazy) oraz dzienniki redo (log zmian potrzebny do odtwarzania). Logiczne odpowiedniki tych plików to przestrzenie tabel (tablespaces), segmenty i bloki - ale z punktu widzenia początku wystarczy zapamiętać, że dane realnie leżą w plikach, a Oracle zarządza nimi w tle.

Architektura wielodostępna: kontenery CDB i PDB

Od wersji 12c Oracle wprowadził architekturę wielodostępną (multitenant). Zamiast stawiać osobny serwer bazy dla każdej aplikacji, tworzymy jeden kontener CDB (Container Database), a wewnątrz niego wiele niezależnych, wpinanych baz PDB (Pluggable Database). Każda PDB zachowuje się jak osobna baza - ma własne tabele i użytkowników - ale wspóldzieli z innymi zasoby i procesy kontenera.

Architektura wielodostępna Oracle - jeden kontener CDB może zawierać wiele niezależnych baz PDB. Łatwiej je konsolidować, przenosić i utrzymywać niż osobne serwery.

Dlaczego to ważne? Bo upraszcza zarządzanie i obniża koszty. Aktualizacje i kopie zapasowe robi się na poziomie kontenera, a poszczególne bazy PDB można przenosić między serwerami niemal jak pliki. To właśnie ten model stoi za bazą Oracle w chmurze, gdzie tysiące baz klientów działa na wspólnej, zarządzanej infrastrukturze. Na potrzeby tego przewodnika wystarczy zapamiętać skrót: CDB to kontener, PDB to baza w środku.

Edycje Oracle i licencjonowanie

Oracle to nie jeden produkt, lecz rodzina edycji o różnej mocy i cenie. Dla początkującego najważniejsza wiadomość jest taka, że Oracle można używać za darmo - do nauki, prototypów i małych wdrożeń służy bezpłatna edycja.

Edycje Oracle - od darmowej bazy na laptopa po samozarządzającą się bazę w chmurze. Podstawy SQL i PL/SQL działają tak samo w każdej z nich.

Oracle Database Free (dawniej Express Edition, XE) - w pełni bezpłatna, z limitami zasobów (do 2 rdzeni CPU, 2 GB pamięci i 12 GB danych użytkownika). Idealna do nauki i prototypowania.
Standard Edition 2 (SE2) - płatna edycja dla mniejszych i średnich wdrożeń, z prostszym modelem licencji i bez części zaawansowanych opcji.
Enterprise Edition (EE) - pełnia możliwości: partycjonowanie, przetwarzanie w pamięci (In-Memory), klastry RAC, Active Data Guard, zaawansowane bezpieczeństwo. To tu płaci się za dodatkowe opcje, co potrafi mocno podnieść koszt.
Autonomous Database - baza w chmurze Oracle (OCI), która sama się stroi, aktualizuje i tworzy kopie zapasowe. Ma też wariant Always Free, całkowicie darmowy.

Właśnie licencjonowanie to jedna z pierwszych rzeczy, które odróżniają Oracle od baz open source. Enterprise Edition rozlicza się zwykle za rdzenie procesora, a wybrane opcje dolicza się osobno - dlatego Oracle bywa najdroższym wyborem, ale też najbogatszym w funkcje klasy korporacyjnej. Aktualne stawki i zasady znajdziesz w oficjalnym cenniku Oracle.

Język bazy: SQL i PL/SQL

Z Oracle rozmawiamy przez SQL - ten sam standardowy język zapytań, który znają wszystkie bazy relacyjne. Poniższe zapytanie to dokładnie to, które widać na zrzucie otwierającym artykuł - łączy tabelę produktów i sprzedaży, a następnie grupuje przychód według kategorii i regionu.

Kopiuj

SELECT p.category, s.region,
       COUNT(*)                  AS tx_count,
       SUM(s.quantity)           AS total_units,
       SUM(s.quantity * p.price) AS revenue
  FROM products p
  JOIN sales s ON s.product_id = p.product_id
 GROUP BY p.category, s.region
 ORDER BY revenue DESC;

Poza czystym SQL Oracle ma własny język programowania w bazie - PL/SQL (Procedural Language/SQL). Pozwala pisać procedury, funkcje i wyzwalacze, czyli logikę, która działa bezpośrednio przy danych, bez wysyłania ich do aplikacji. To jeden z powodów wysokiej wydajności dużych systemów na Oracle. Prosta funkcja PL/SQL wygląda tak:

Kopiuj

CREATE OR REPLACE FUNCTION region_revenue(p_region IN VARCHAR2)
RETURN NUMBER IS
  v_total NUMBER := 0;
BEGIN
  SELECT SUM(s.quantity * p.price) INTO v_total
    FROM products p
    JOIN sales s ON s.product_id = p.product_id
   WHERE s.region = p_region;
  RETURN NVL(v_total, 0);
END;
/

Odpowiedniki PL/SQL w innych bazach to PL/pgSQL w PostgreSQL oraz T-SQL w SQL Server. Jeśli chcesz poznać T-SQL od podstaw, mamy o nim bezpłatny kurs T-SQL w SQL Server na blogu. Jeśli znasz jeden z tych języków, przesiadka bywa łatwiejsza, niż się wydaje.

Czym Oracle różni się od innych baz danych

To pytanie pada najczęściej i nie ma na nie jednej odpowiedzi typu "lepsza-gorsza". Wszystkie liczące się bazy relacyjne - Oracle, PostgreSQL, MySQL/MariaDB i SQL Server - robią to samo w rdzeniu: przechowują dane w tabelach i udostępniają je przez SQL. Różnice widać dopiero w licencji, ekosystemie, mechanizmach wysokiej dostępności i typowych zastosowaniach.

Oracle a inne bazy danych - najkrótsze zestawienie różnic wobec PostgreSQL, MySQL/MariaDB i Microsoft SQL Server.

Poniżej rozwijamy ten skrót - pełniejsze zestawienie obejmuje także pierwsze wydanie, model danych, partycjonowanie, przetwarzanie w pamięci, bezpieczeństwo, wersje bezpłatne i narzędzia administracyjne:

	Oracle	PostgreSQL	MySQL / MariaDB	SQL Server
Właściciel	Oracle Corporation	społeczność (PostgreSQL Global Dev. Group)	Oracle (MySQL) / MariaDB Foundation	Microsoft
Pierwsze wydanie	1979	1996	1995 / 2009	1989
Licencja	komercyjna, jest też Free/XE	wolna, open source	GPL / komercyjna (MariaDB: GPL)	komercyjna, jest też Express
Koszt wejścia	wysoki dla Enterprise Edition	zerowy	zerowy lub niski	średni, darmowy Express
Wersja bezpłatna i limity	Free/XE: 2 rdzenie, 2 GB RAM, 12 GB danych	pełna, bez limitów	pełna (Community / MariaDB)	Express: ~1 rdzeń, 1 GB RAM, 10 GB/bazę
Język proceduralny	PL/SQL	PL/pgSQL (i PL/Python, PL/Perl)	SQL/PSM (uboższy)	T-SQL
Model danych	relacyjny + JSON, XML, przestrzenny, graf, wektory	relacyjny + JSON, PostGIS, rozszerzenia	relacyjny + JSON	relacyjny + JSON, graf, przestrzenny
Partycjonowanie	wbudowane (opcja Enterprise)	deklaratywne, wbudowane	ograniczone	wbudowane
Przetwarzanie w pamięci	Database In-Memory (opcja)	brak natywnego	ograniczone	In-Memory OLTP i columnstore
Wysoka dostępność	RAC + Data Guard	replikacja + Patroni	replikacja + Galera / Group Replication	Always On Availability Groups
Bezpieczeństwo	TDE, VPD, Label Security, audyt	role, RLS, szyfrowanie	role, szyfrowanie	TDE, role, Always Encrypted
Baza dla AI (wektory)	AI Vector Search (23ai/26ai)	pgvector (rozszerzenie)	ograniczone	wektory od 2025
Chmura zarządzana	Autonomous Database (OCI)	RDS, Cloud SQL, Azure, Aurora	MySQL HeatWave, RDS	Azure SQL
Narzędzie administracyjne	SQL Developer, Database Actions	pgAdmin, psql	MySQL Workbench, DBeaver	SQL Server Management Studio
Typowe zastosowanie	korporacje, ERP, banki	uniwersalna, nowe aplikacje	web, CMS, sklepy	ekosystem Microsoft i .NET

Oracle kontra PostgreSQL. PostgreSQL to najsilniejszy darmowy konkurent - dojrzały, rozszerzalny i bez opłat licencyjnych. Oracle wygrywa tam, gdzie liczy się najbogatszy zestaw funkcji klasy korporacyjnej i wsparcie producenta, PostgreSQL - tam, gdzie budżet i otwartość są priorytetem. Wiele firm rozważa dziś przejście z jednej bazy na drugą, dlatego opisaliśmy krok po kroku, jak wygląda migracja z Oracle do PostgreSQL w praktyce - co przenosi się samo, a co trzeba przepisać.

Oracle kontra MySQL/MariaDB. MySQL (również własność Oracle) i jego odgałęzienie MariaDB królują w aplikacjach webowych i sklepach internetowych. Są lekkie, szybkie w starcie i darmowe, ale ich język proceduralny i mechanizmy klasy korporacyjnej są skromniejsze niż w Oracle.

Oracle kontra SQL Server. Microsoft SQL Server to najbliższy odpowiednik Oracle po stronie komercyjnej, mocno osadzony w ekosystemie Microsoftu i języku T-SQL. Jeśli chcesz poznać go od podstaw, mamy osobny wpis wprowadzenie do MS SQL Server. Warto też pamiętać, że nie każde dane pasują do modelu relacyjnego - o tym, kiedy sięgnąć po bazę nierelacyjną, piszemy w przewodniku SQL kontra NoSQL.

Wysoka dostępność i skalowanie: RAC, Data Guard, Exadata

Tu Oracle pokazuje pełnię możliwości i to jeden z głównych powodów, dla których trzyma się w najbardziej wymagających systemach. Dwa filary to RAC i Data Guard.

Dwa filary niezawodności Oracle - RAC pozwala wielu serwerom obsługiwać jedną bazę, a Data Guard trzyma aktualną kopię w innej lokalizacji na wypadek awarii.

Real Application Clusters (RAC) pozwala wielu instancjom na różnych serwerach obsługiwać jedną, wspóldzieloną bazę danych. Daje to jednocześnie skalowanie poziome (więcej serwerów to większa wydajność) i wysoką dostępność - awaria jednego węzła nie zatrzymuje bazy, bo pozostałe pracują dalej.

Data Guard to mechanizm odtwarzania po awarii (disaster recovery). Utrzymuje bazę zapasową (standby) w innej lokalizacji, do której na bieżąco wysyłane są zmiany z bazy podstawowej. Gdy główna padnie, zapasowa przejmuje ruch. W wariancie Active Data Guard baza zapasowa może dodatkowo obsługiwać zapytania odczytu. Na samym szczycie stoi Exadata - dedykowana platforma sprzętowa Oracle zoptymalizowana pod ekstremalną wydajność bazy.

Oracle w chmurze: OCI i Autonomous Database

Oracle to dziś nie tylko oprogramowanie instalowane na własnych serwerach. W chmurze Oracle Cloud Infrastructure (OCI) działa Autonomous Database - baza, która sama się stroi, łata i tworzy kopie zapasowe, a administrator nie musi zajmować się rutynową obsługą. Poniższy zrzut pochodzi z realnej, darmowej instancji Autonomous w wydaniu 26ai, którą postawiliśmy na potrzeby tego artykułu.

Realna, darmowa baza Autonomous Database (26ai, Always Free) w konsoli Oracle Cloud. Identyfikatory konta zostały zasłonięte. Baza jest gotowa do pracy bez ręcznej administracji.

Autonomous Database występuje w kilku wariantach - transakcyjnym (do aplikacji), hurtownianym (do analityki), dokumentowym JSON oraz pod aplikacje low-code Oracle APEX. Do bazy w chmurze nie trzeba nawet instalować żadnego programu - wystarczy przeglądarka i wbudowane narzędzie Database Actions, które widzieliśmy na pierwszym zrzucie. Autonomiczną bazę wypróbujesz bezpłatnie w ramach Oracle Cloud Free Tier.

Oracle Database Actions w przeglądarce - jedno miejsce, z którego korzystamy z SQL, modelowania danych, REST, JSON, uczenia maszynowego, aplikacji APEX i grafów.

Oracle 23ai i 26ai: baza dla ery sztucznej inteligencji

Zmiana litery na ai nie jest tylko marketingiem. Najnowsze wydania Oracle wniosły funkcje, których próba znalezienia w przewodniku sprzed dwóch lat spełznie na niczym. Dwie zmieniają najwięcej.

AI Vector Search w Oracle 23ai/26ai - dane zamieniamy na wektory, a baza wyszukuje po znaczeniu (podobieństwie) zwykłym zapytaniem SQL. To fundament wyszukiwania semantycznego i systemów RAG.

AI Vector Search. Oracle wprowadził nowy typ danych VECTOR, dedykowane indeksy wektorowe i operator VECTOR_DISTANCE. Dzięki temu w bazie można przechowywać wektory (liczbowe reprezentacje znaczenia tekstu, obrazu czy dokumentu) i wyszukiwać po podobieństwie - obok zwykłych danych, jednym zapytaniem SQL. To baza pod wyszukiwanie semantyczne i systemy typu RAG (odpowiedzi generowane na podstawie firmowych danych).

Kopiuj

-- tabela z kolumną wektorową i indeks wektorowy
CREATE TABLE docs (
  id        NUMBER PRIMARY KEY,
  title     VARCHAR2(200),
  embedding VECTOR(768, FLOAT32)
);

CREATE VECTOR INDEX docs_vec_idx ON docs (embedding)
  ORGANIZATION INMEMORY NEIGHBOR GRAPH
  DISTANCE COSINE WITH TARGET ACCURACY 95;

-- wyszukanie 5 najbliższych znaczeniowo dokumentów
SELECT title
  FROM docs
 ORDER BY VECTOR_DISTANCE(embedding, :question, COSINE)
 FETCH APPROX FIRST 5 ROWS ONLY;

Realny wynik z Oracle 26ai - zapytanie z VECTOR_DISTANCE (metryka COSINE) zwraca dokumenty uszeregowane od najbardziej podobnego znaczeniowo do zapytania.

Wyszukiwanie wektorowe to zaledwie czubek góry lodowej nowych funkcji AI - baza potrafi też integrować się z modelami językowymi i zamieniać pytania w naturalnym języku na SQL. Całą tę warstwę opisaliśmy szerzej w artykule o AI w bazie danych Oracle: Vector Search, Select AI i uczeniu maszynowym.

JSON Relational Duality. Druga przełomowa funkcja rozwiązuje stary spór: dane relacyjne czy dokumenty JSON? W Oracle 23ai/26ai nie trzeba wybierać. Te same dane, zapisane wydajnie w tabelach relacyjnych, można czytać i modyfikować jako spójne dokumenty JSON - przez tak zwany widok dualny. Deweloper dostaje wygodę dokumentów, a firma zachowuje porządek i wydajność modelu relacyjnego.

Kopiuj

-- ten sam rekord widoczny jako dokument JSON i jako wiersze tabel
CREATE JSON RELATIONAL DUALITY VIEW orders_dv AS
SELECT JSON {
  '_id'      : o.order_id,
  'status'   : o.status,
  'customer' : (SELECT JSON {'id': c.customer_id, 'name': c.name}
                 FROM customers c WITH NOCHECK
                WHERE c.customer_id = o.customer_id),
  'items'    : (SELECT JSON_ARRAYAGG(JSON {'product': i.product_id, 'qty': i.quantity})
                 FROM order_items i WITH INSERT UPDATE
                WHERE i.order_id = o.order_id)
}
FROM orders o WITH INSERT UPDATE DELETE;

Efekt widać od razu. Zamówienie zapisane w trzech tabelach (klient, zamówienie, pozycje) odczytujemy jako jeden, spójny dokument JSON - bez pisania kodu sklejającego dane po stronie aplikacji.

Realny wynik z Oracle 26ai - zapytanie do widoku dualnego orders_dv zwraca dane z trzech tabel relacyjnych jako jeden dokument JSON.

Kopiuj

{
  "_id" : 1001,
  "_metadata" : { "etag" : "F13FB37E10D60DEEA414005070C50FF2", "asof" : "00002DDBB6E3436D" },
  "status" : "W realizacji",
  "customer" : { "id" : 1, "name" : "Firma Nordvik" },
  "items" : [
    { "itemId" : 1, "product" : "Router Aurora X1", "qty" : 2 },
    { "itemId" : 2, "product" : "Switch Nimbus 24", "qty" : 1 }
  ]
}

Kiedy wybrać Oracle, a kiedy inną bazę

Nie ma jednej najlepszej bazy - jest baza najlepiej dopasowana do wymagań, skali i budżetu. Poniższa ściąga pomaga podjąć decyzję.

Kiedy Oracle, a kiedy inna baza - decyzja zależy przede wszystkim od skali, wymagań dostępności i budżetu.

Oracle ma najwięcej sensu, gdy budujesz lub utrzymujesz duży, krytyczny system (bankowość, ERP, telekomunikacja), potrzebujesz maksymalnej dostępności i skali, przetwarzasz ogromne wolumeny danych albo chcesz korzystać z AI Vector Search i JSON bezpośrednio przy danych transakcyjnych - i masz zespół oraz budżet na bazę klasy korporacyjnej.

Warto rozważyć PostgreSQL lub MySQL/MariaDB, gdy budżet jest ograniczony, a licencja ma być wolna, budujesz nową aplikację webową lub usługową, wystarczają standardowe funkcje relacyjne, a zespół zna ekosystem open source. Aby świadomie porównać obie strony, warto znać też podstawy alternatywy - zebraliśmy je w tekście o najważniejszych pojęciach PostgreSQL.

Wybierz Microsoft SQL Server, gdy Twoja firma działa w ekosystemie Microsoftu i .NET, korzysta z chmury Azure, a zespół zna język T-SQL oraz narzędzia takie jak SQL Server Management Studio. To najbliższy komercyjny odpowiednik Oracle, wybierany najczęściej tam, gdzie liczy się spójność z resztą stosu Microsoft.

Jak zacząć z Oracle - krok po kroku

Wbrew opinii, że Oracle jest trudny w starcie, pierwsze kroki są dziś banalnie proste i darmowe.

Uporządkowana ścieżka nauki Oracle - od postawienia darmowej bazy po funkcje chmurowe i AI. Każdy krok bazuje na poprzednim.

Postaw bazę. Najszybciej założyć darmową Autonomous Database Always Free w chmurze Oracle (nic nie instalujesz) albo pobrać lokalnie Oracle Database Free (na przykład w kontenerze Docker).
Otwórz narzędzie. W chmurze wystarczy przeglądarkowe Database Actions. Lokalnie możesz użyć bezpłatnego SQL Developera lub innego klienta SQL.
Naucz się SQL. Zapytania SELECT, łączenie tabel (JOIN), funkcje i grupowanie - to fundament, który działa tak samo w każdej bazie.
Wejdź w PL/SQL. Procedury, funkcje i wyzwalacze pozwolą przenieść logikę do bazy.
Poznaj administrację i wydajność. Kopie zapasowe, użytkownicy, indeksy, plany zapytań, a dalej RAC i Data Guard.

Podsumowanie

Oracle Database to dojrzały, relacyjny system bazodanowy zaprojektowany pod dużą skalę, wysoką dostępność i twarde wymagania korporacyjne. Od innych baz odróżniają go przede wszystkim komercyjny model licencji, najbogatszy zestaw mechanizmów wysokiej dostępności (RAC, Data Guard), silny język PL/SQL oraz - w najnowszych wydaniach 23ai i 26ai - wbudowane funkcje AI, takie jak wyszukiwanie wektorowe i widoki dualne JSON. PostgreSQL, MySQL/MariaDB i SQL Server pozostają świetnymi alternatywami tam, gdzie priorytetem są koszt, otwartość lub konkretny ekosystem. Najlepsza baza to zawsze ta dopasowana do Twojego projektu - a dobra wiadomość jest taka, że Oracle można dziś poznawać w całości za darmo.

Szkolenie Oracle SQL: Kompleksowe szkolenie SQL w Oracle -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR. Ma terminy gwarantowane.

★★★★★
Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Oracle PL/SQL: Kompleksowe szkolenie programowanie w PL/SQL w Oracle -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR. Ma terminy gwarantowane.

★★★★★
Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

Chcesz pogłębić temat na żywym szkoleniu z trenerem? Zobacz kurs Podstawy Oracle SQL w JSystems — termin gwarantowany.

Więcej zrzutów ekranu i przykładów: blog.jsystems.pl

Szkolenia IT: stacjonarne, online czy hybrydowe? Ranking efektywności metod nauczania

Andrzej Klusiewicz — Mon, 14 Sep 2026 07:02:38 +0000

Stacjonarnie, online na żywo czy nagranie do obejrzenia we własnym tempie - która forma szkolenia IT faktycznie daje najwięcej wiedzy na złotówkę i godzinę? Porównaliśmy metody nauczania pod kątem realnej efektywności.

Jeszcze dekadę temu sprawa była prosta: chcesz się nauczyć programować - idziesz na salę szkoleniową. Chcesz "liznąć" temat - kupujesz książkę. Dziś granice się zatarły. Mamy bootcampy, kursy wideo na Udemy, mentoring 1:1, a także profesjonalne szkolenia VILT (Virtual Instructor-Led Training). Czy nauka zdalna może być równie skuteczna co spotkanie twarzą w twarz? Jako firma szkoleniowa z korzeniami w "twardej" inżynierii systemowej, przeanalizowaliśmy dane z tysięcy ankiet naszych absolwentów. Wnioski mogą Cię zaskoczyć: to nie lokalizacja decyduje o sukcesie, ale infrastruktura i interakcja.

Mitologia E-learningu: Dlaczego "kurs wideo" to za mało?

Na wstępie musimy rozróżnić dwa pojęcia, które często są mylone: Self-paced Learning (kursy wideo, np. Pluralsight, Udemy) oraz VILT (szkolenia online z trenerem na żywo, jakie oferuje JSystems).

Kursy wideo są świetne do zdobycia wiedzy encyklopedycznej ("jaką składnię ma ta metoda"). Jednak zawodzą, gdy pojawia się problem (tzw. "ściana"). Statystyki branżowe są bezlitosne: tylko 5-15% osób kończy zakupione kursy wideo. Dlaczego? Brak presji zewnętrznej i brak wsparcia w momencie kryzysu. Gdy Twój kod nie działa, a wideo leci dalej - frustracja narasta i w końcu rezygnujesz.

W profesjonalnym IT liczy się transfer wiedzy ukrytej (Tacit Knowledge). To te momenty, gdy trener mówi: "Dokumentacja zaleca metodę A, ale w praktyce produkcyjnej stosujemy B, bo A powoduje wycieki pamięci". Tego nie nauczysz się z nagranego rok temu filmu.

Rewolucja Technologiczna: Cloud Labs zamiast "u mnie działa"

Największą barierą szkoleń online przez lata była konfiguracja środowiska. Uczestnik tracił pierwsze 4 godziny szkolenia na instalację Dockera, Javy, IDE czy bazy danych na swoim (często firmowym i zablokowanym) laptopie. Trener zamiast uczyć, bawił się w helpdesk.

W JSystems rozwiązaliśmy to radykalnie: eliminując lokalne środowisko. Stosujemy podejście Cloud-First:

Gotowe Hosty: Każdy uczestnik otrzymuje dedykowaną maszynę wirtualną w chmurze, skonfigurowaną pod konkretne szkolenie.
Brak VPN-ów i blokad: Łączysz się przez przeglądarkę, RDP lub SSH. Nie interesuje nas, czy masz Windowsa, Maca czy Linuxa.
Podgląd trenera: W sali stacjonarnej trener podchodzi do biurka. Na naszych warsztatach online, możesz udostępnić ekran trenerowi. Widzi on wtedy, kto utknął, kto skończył zadanie, i może przejąć kontrolę nad Twoją myszką, by poprawić błąd.

Dzięki temu szkolenie VILT osiąga skuteczność warsztatową bliską 100% czasu efektywnego.

Ranking Efektywności Metod (Perspektywa 2026)

Oto nasze zestawienie oparte na obserwacji postępów kursantów (zdolność do samodzielnego wykonania projektu końcowego):

A które certyfikaty IT realnie pomagają w karierze, a które są tylko papierem, sprawdzamy w osobnym zestawieniu.

Metoda	Poziom Immersji	Wsparcie Eksperta	Dla kogo?
Stacjonarnie (Warsztat)	Bardzo Wysoki (10/10)	Bezpośrednie, fizyczne	Początkujący (Junior), Zespoły projektowe, Osoby ceniące fokus.
VILT (Online z Trenerem + Cloud Labs)	Wysoki (8/10)	Zdalne (Współdzielenie ekranu)	Specjaliści (Mid/Senior), Freelancerzy, Zespoły rozproszone.
Hybryda (Część na sali, część zdalnie)	Zmienny (Trudny dla trenera)	Mieszane	Firmy w okresie transformacji, sytuacje losowe.
E-learning (Wideo)	Niski (3/10)	Brak / Forum dyskusyjne	Hobbyści, nauka bardzo wąskich zagadnień "na już".

Dlaczego JSystems stawia na "Gwarantowane Terminy"?

Niezależnie od formy (Online/Offline), największą plagą rynku szkoleń jest odwoływanie zajęć "z powodu niewystarczającej liczby uczestników". Dla profesjonalisty, który zaplanował urlop szkoleniowy lub dla firmy, która zamknęła sprint pod szkolenie, to katastrofa.

Wprowadziliśmy politykę Terminów Gwarantowanych. Jeśli termin jest oznaczony jako gwarantowany, oznacza to, że szkolenie odbędzie się na 100%, nawet jeśli będziesz jedynym uczestnikiem na sali (wtedy zyskujesz ekskluzywny mentoring 1:1). Ryzyko biznesowe bierzemy na siebie.

Podsumowanie: Nie pytaj "gdzie", pytaj "jak"

Wybierając szkolenie w 2026 roku, przestań martwić się o to, czy jest online, czy stacjonarnie. Zapytaj organizatora o dwie rzeczy: "Czy dostanę gotowe środowisko laboratoryjne?" oraz "Czy trener jest praktykiem?". Jeśli odpowiedzi brzmią TAK, nauczysz się skutecznie niezależnie od tego, czy siedzisz w naszej sali w Warszawie, czy na tarasie na Maderze.

Jak wygląda taka praktyczna nauka na żywym kodzie, pokazujemy na konkretnym przykładzie w samouczku o wielowątkowości w Pythonie krok po kroku.

Gotowy na dawkę praktycznej wiedzy? Sprawdź listę naszych szkoleń i wybierz formę, która pasuje do Twojego stylu życia. Zobacz Terminy Gwarantowane w JSystems.

FAQ - Metody Szkoleniowe

Jakie łącze internetowe jest potrzebne do szkolenia VILT?

Standardowe łącze światłowodowe lub stabilne LTE wystarczy. Ponieważ ciężka praca odbywa się na zdalnych maszynach (Cloud Labs), Twój komputer służy głównie jako terminal wyświetlający obraz. Nie musisz mieć "superkomputera" z 32GB RAM, by szkolić się z Big Data.

Czy na szkoleniu stacjonarnym muszę mieć własnego laptopa?

Zazwyczaj zapewniamy w pełni wyposażone stanowiska komputerowe w naszych salach. Jeśli jednak wolisz pracować na swoim sprzęcie (bo masz ulubioną klawiaturę i skróty), jest to możliwe - pomożemy Ci podłączyć się do naszej infrastruktury chmurowej.

Powiązane artykuły

SQL vs NoSQL: wielkie porównanie baz danych - kiedy wybrać którą? (2026)

Andrzej Klusiewicz — Mon, 14 Sep 2026 07:02:18 +0000

"Bierzemy Mongo, bo jest szybsze" - zdanie, które wiele zespołów żałowało pół roku później. Wybór bazy danych to jedna z decyzji, które trudno cofnąć - zobacz, jak podejść do niej racjonalnie.

SQL vs NoSQL
Kiedy wybrać relacyjną, a kiedy nierelacyjną - przewodnik architekta

SQL - Katedra Spójności
NoSQL - Bazar Skalowalności
idklientsaldo1001Nowak1 240 zł1002Kowal890 zł1003Wiśniewska2 505 zł
{ }
ACIDSchematJOIN
SkalaElastycznośćDostępność

VS
JSYSTEMS · PRZEWODNIK ARCHITEKTA

SQL kontra NoSQL: relacyjna „Katedra Spójności” (sztywny schemat, ACID) obok nierelacyjnego „Bazaru Skalowalności” (rozproszone węzły, elastyczne dokumenty).

Przez dekady świat baz danych był prosty: miałeś dane, więc wrzucałeś je do tabel w Oracle lub SQL Server. Potem nadeszła era Big Data, Facebooka i Google, a wraz z nią rewolucja NoSQL. Nagle relacje stały się "przestarzałe", a deweloperzy zachłysnęli się swobodą wrzucania JSON-ów do Mongo. Dziś, gdy kurz opadł, wiemy, że nie ma jednego zwycięzcy. Wybór bazy danych to jedna z najważniejszych decyzji architektonicznych, której skutki (i dług technologiczny) odczuwa się latami. W JSystems uczymy, jak podejmować te decyzje świadomie, w oparciu o Twierdzenie CAP i modele spójności, a nie o modę (Hype Driven Development).

Paradygmat Relacyjny (SQL): Katedra Spójności

Bazy RDBMS (Relational Database Management Systems) jak PostgreSQL, MySQL, Oracle czy MS SQL to fundament bankowości, e-commerce i systemów ERP. Ich siłą jest Schemat i ACID.

Atomowość (Atomicity): Wszystko albo nic. Przelew bankowy musi obciążyć jedno konto i uznać drugie w tej samej milisekundzie.
Spójność (Consistency): Baza pilnuje reguł. Nie usuniesz klienta, jeśli ma aktywne zamówienia (Klucze obce).
Izolacja (Isolation): Dwie transakcje nie widzą swoich pośrednich stanów.
Trwałość (Durability): Gdy baza powie "Zapisano", to dane są na dysku, nawet jak wyciągniesz wtyczkę z prądu.

PARADYGMAT RELACYJNY (SQL)

Cztery filary gwarancji ACID
Fundament, na którym stoi każda baza relacyjna (RDBMS)

PostgreSQL · Oracle · MySQL · MS SQL
AAtomowośćWszystko albo nic - przelewobciąża jedno konto iuznaje drugie w jednejtransakcji.CSpójnośćBaza pilnuje reguł i kluczyobcych - nie usunieszklienta z aktywnymzamówieniem.IIzolacjaRównoległe transakcje niewidzą swoich stanówpośrednich.DTrwałośćPo „Zapisano” dane są nadysku, nawet po zanikuzasilania.

jsystems.pl
Szkolenia z baz danych

ACID w praktyce: atomowość, spójność, izolacja i trwałość to cztery filary, dzięki którym baza relacyjna nadaje się do finansów i stanów magazynowych.

W JSystems zawsze powtarzamy: jeśli Twoje dane mają ścisłą strukturę i są cenne (finanse, stany magazynowe), SQL jest domyślnym wyborem. Język SQL jest potężnym, ustandaryzowanym narzędziem do zadawania pytań, którego optymalizacji uczymy na zaawansowanych warsztatach.

Jeśli chcesz opanować sam język zapytań od podstaw, przygotowaliśmy bezpłatny kurs SQL w Microsoft SQL Server, który przeprowadzi Cię przez składnię krok po kroku.

Rewolucja NoSQL: Bazar Skalowalności

NoSQL (Not Only SQL) powstał, by rozwiązać problemy, z którymi SQL radził sobie słabo: ogromna skala danych i zmienna struktura. Tu nie ma tabel. Są dokumenty, klucze-wartości, grafy czy kolumny.

Główne typy NoSQL:

Dokumentowe (MongoDB, Couchbase): Dane to JSON-y. Idealne do CMS-ów, katalogów produktów, gdzie jeden produkt ma "rozmiar", a inny "napięcie zasilania". Zmiana struktury nie wymaga migracji całej bazy.
Klucz-Wartość (Redis, DynamoDB): Ekstremalnie szybkie. Używane do cache'owania, sesji użytkowników, koszyków zakupowych. Proste zapytania: "Daj mi dane dla klucza X".
Grafowe (Neo4j): Stworzone do analizy relacji (social media, systemy rekomendacji, wykrywanie fraudów). SQL przy 5-stopniowym złączeniu (JOIN) "klęka". Baza grafowa robi to w ułamku sekundy.

REWOLUCJA NOSQL

Cztery rodziny baz NoSQL
Nie ma jednego NoSQL - każdy typ rozwiązuje inny problem
DokumentoweMongoDB, CouchbaseDane jako dokumenty JSON.Idealne do katalogów produktówi CMS - zmiana struktury niewymaga migracji.Klucz - WartośćRedis, DynamoDBEkstremalnie szybkie. Cache,sesje użytkowników, koszyki.Proste zapytanie: podaj wartośćdla klucza X.GrafoweNeo4jAnaliza relacji: social media,rekomendacje, wykrywanienadużyć. Głębokie połączeniabez kosztownych JOIN.KolumnoweCassandra, HBaseZapis ogromnych wolumenów pokolumnach. Szeregi czasowe,logi, telemetria w dużej skali.

jsystems.pl
Szkolenia z baz danych (SQL i NoSQL)

Rodziny NoSQL: dokumentowe, klucz-wartość, grafowe i kolumnowe. Każda dobierana jest do konkretnego zadania, a nie jako uniwersalny zamiennik SQL.

Inżynierski kompromis: Twierdzenie CAP

Aby zrozumieć różnicę na poziomie "Deep Dive", musimy przywołać Erica Brewera i jego Twierdzenie CAP. Mówi ono, że system rozproszony może spełnić tylko dwie z trzech cech jednocześnie:

Consistency (Spójność): Każdy odczyt zwraca najnowszy zapis lub błąd.
Availability (Dostępność): Każde zapytanie otrzymuje odpowiedź (niekoniecznie najnowszą).
Partition Tolerance (Tolerancja podziału): System działa mimo awarii sieci między serwerami.

INŻYNIERSKI KOMPROMIS

Twierdzenie CAP: wybierasz 2 z 3
W systemie rozproszonym awaria sieci (P) jest nieunikniona - zostaje wybór CP albo AP

CP = Bazy SQLspójność ponad dostępność
AP = Bazy NoSQLdostępność ponad spójność
CA - niemożliwe
CConsistencySpójność odczytu
AAvailabilityZawsze odpowiada
PPartition tol.Odporny na podział

jsystems.pl
Szkolenia z baz danych

Twierdzenie CAP Erica Brewera: skoro tolerancja podziału sieci (P) jest obowiązkowa, w praktyce wybierasz między spójnością (CP, bazy SQL) a dostępnością (AP, bazy NoSQL).

Ponieważ w systemach rozproszonych awarie sieci są nieuniknione (P jest stałe), musisz wybrać między CP a AP.

Bazy SQL (CP): Wybierają spójność. Jeśli klaster się rozpadnie, baza przestanie przyjmować zapisy, by nie dopuścić do rozbieżności danych. Bezpieczeństwo ponad dostępność.

Bazy NoSQL (AP): Wybierają dostępność. System działa dalej, ale użytkownik A może widzieć inne dane niż użytkownik B przez kilka sekund (Eventual Consistency). Idealne dla liczników lajków - czy to ważne, że widzisz 100 lajków, a jest ich już 102?

Nowy Król: Polyglot Persistence

Współczesna architektura (szczególnie mikroserwisy) odchodzi od monolitycznej bazy danych. Stosujemy podejście Polyglot Persistence - używamy odpowiedniego narzędzia do odpowiedniego zadania.

Przykład architektury omawianej na szkoleniach JSystems:

PostgreSQL: Przechowuje dane o użytkownikach i transakcjach finansowych (ACID).
MongoDB: Przechowuje elastyczny katalog produktów i opinie.
Redis: Trzyma sesje zalogowanych użytkowników i cache najczęstszych zapytań (szybkość).
Elasticsearch: Służy do zaawansowanego wyszukiwania tekstowego (Search Engine).

NOWY KRÓL ARCHITEKTURY

Polyglot Persistence: narzędzie do zadania
Jedna aplikacja, kilka baz - każda tam, gdzie jest najlepsza
PostgreSQLTransakcje iużytkownicy (ACID)MongoDBElastyczny katalogproduktówRedisSesje i cache zapytańElasticsearchWyszukiwanie tekstowe

Aplikacja
warstwa mikroserwisów
kieruje dane do właściwego magazynu

jsystems.pl
Szkolenia z baz danych

Polyglot Persistence: aplikacja rozkłada dane między PostgreSQL (transakcje), MongoDB (katalog), Redis (sesje i cache) oraz Elasticsearch (wyszukiwanie). Kropki pokazują przepływ danych do właściwej bazy.

Taka architektura jest trudniejsza w utrzymaniu, ale daje niesamowitą wydajność i skalowalność.

SQL kontratakuje: PostgreSQL i JSONB

Granice się zacierają. Nowoczesne bazy SQL (zwłaszcza PostgreSQL) wprowadziły typy danych JSON i JSONB, które pozwalają trzymać dokumenty wewnątrz tabeli relacyjnej i - co najważniejsze - wydajnie je indeksować. Dla wielu projektów jest to "Sweet Spot": masz transakcyjność SQL i elastyczność NoSQL w jednym pudełku. Na naszych warsztatach uczymy, jak hybrydowo wykorzystywać te możliwości, unikając wprowadzania nowej technologii do stacku bez potrzeby.

SQL KONTRATAKUJE

PostgreSQL i JSONB: złoty środek
Transakcyjność SQL i elastyczność dokumentów w jednej bazie

SQL
ACID
transakcje
złączenia JOIN
NoSQL
elastyczny
schemat
dokumenty JSON

PostgreSQL

JSONB Sweet Spot CREATE INDEX ... USING GIN (dane jsonb)

jsystems.pl
Szkolenia z baz danych

Nowoczesny PostgreSQL z typem JSONB łączy transakcyjność SQL z elastycznością dokumentów NoSQL i indeksuje je (indeks GIN) - dla wielu projektów to złoty środek.

Podsumowanie: Nie kieruj się modą

Decyzja o wyborze bazy danych powinna wynikać z charakterystyki danych (Data Shape) i wymagań biznesowych (SLA), a nie z tego, co jest "trendy" na Hacker News. W JSystems nasi trenerzy to praktycy, którzy widzieli systemy padające pod własnym ciężarem przez złe decyzje bazodanowe. Uczymy nie tylko składni zapytań, ale przede wszystkim myślenia o danych.

PODSUMOWANIE

Decyduje kształt danych i SLA, nie moda
Szybka ściąga, od czego zacząć wybór bazy
Wybierz SQL, gdy...Wybierz NoSQL, gdy...STRUKTURA DANYCHŚcisła, stabilna (tabele)Zmienna, różnorodna (dokumenty)SPÓJNOŚĆBezwzględna, transakcyjnaDocelowa (eventual)ZŁĄCZENIA (JOIN)Naturalne i częsteUnikane, dane denormalizowaneSKALA ZAPISUPionowa (mocniejszy serwer)Pozioma (wiele węzłów)PRZYKŁADFinanse, ERP, magazynKatalog, cache, IoT, social

jsystems.pl
Szkolenia z baz danych

Ściąga decyzyjna: SQL wybieramy przy ścisłej strukturze, bezwzględnej spójności i częstych złączeniach; NoSQL - przy zmiennym schemacie, skali poziomej i danych denormalizowanych.

Chcesz zrozumieć bazy danych od podszewki? Zapisz się na zaawansowane szkolenia z baz danych (SQL i NoSQL) w JSystems. Pokażemy Ci, jak projektować wydajne systemy.

FAQ - Bazy Danych

Kiedy NIE używać NoSQL?

Unikaj NoSQL, jeśli Twoje dane są silnie relacyjne, wymagają skomplikowanych złączeń (JOIN) lub bezwzględnej spójności transakcyjnej (np. systemy księgowe). Wymuszanie relacji w bazie nierelacyjnej to anty-wzorzec, który prowadzi do skomplikowanego kodu aplikacji.

Czy migracja z Oracle do PostgreSQL jest trudna?

Jest to proces złożony, ale coraz popularniejszy ze względu na koszty licencji Oracle. PostgreSQL oferuje ogromną zgodność ze standardami SQL, a narzędzia takie jak ora2pg ułatwiają migrację schematu. Największym wyzwaniem jest zazwyczaj migracja logiki biznesowej zaszytej w procedurach składowanych (PL/SQL do PL/pgSQL).

Co dokładnie przenosi się automatycznie, a co trzeba przepisać ręcznie, rozkładamy na czynniki pierwsze w praktycznym przewodniku o migracji z Oracle do PostgreSQL.

Czym jest NewSQL?

NewSQL (np. CockroachDB, Google Spanner) to nowa klasa baz danych, która próbuje łączyć skalowalność horyzontalną NoSQL z gwarancjami ACID znanymi z SQL. To obiecujący kierunek dla systemów globalnych, które muszą być spójne i skalowalne jednocześnie.

Powiązane artykuły

Najlepsze certyfikaty IT w Polsce - które papiery realnie podnoszą stawkę godzinową

Andrzej Klusiewicz — Mon, 14 Sep 2026 07:01:58 +0000

Certyfikat w CV to nie magiczny klucz do wyższej stawki - ale niektóre naprawdę robią różnicę, a inne to strata czasu i pieniędzy. Sprawdziliśmy, które papiery faktycznie przekładają się na wyższe stawki B2B w Polsce.

W branży IT panuje dwoiste podejście do certyfikatów. Część programistów uważa je za "drogi kawałek papieru dla korporacji", inni widzą w nich najszybszą windę do stanowisk seniorskich i stawek B2B powyżej średniej rynkowej. Kto ma rację? Prawda, jak zwykle w inżynierii, zależy od kontekstu. Jako firma szkoleniowa, która od 2008 roku przygotowała tysiące specjalistów do egzaminów Oracle, Microsoft czy AWS, widzimy twarde dane. Certyfikat sam w sobie nie pisze kodu, ale otwiera drzwi, które dla innych pozostają zamknięte. Oto szczery przewodnik po certyfikacji, która się opłaca.

Certyfikat vs Umiejętności: Obalamy mit "Papierowego Tygrysa"

W środowisku rekrutacyjnym istnieje pojęcie "Paper Tiger" - kandydata, który ma 15 certyfikatów w stopce maila, ale wykłada się na prostym zadaniu praktycznym. To zjawisko sprawiło, że część firm patrzy na dyplomy z rezerwą. Jednakże, w profesjonalnym ekosystemie (Software House'y, Banki, Telekomy), certyfikaty pełnią rolę walidacji zewnętrznej.

Dla klienta z USA czy Niemiec, który szuka wykonawcy projektu, informacja, że zespół posiada "5 certyfikowanych architektów AWS", jest gwarancją, że ludzie ci znają wspólny standard i nie będą "wymymyślać koła na nowo". W JSystems wyznajemy zasadę: Egzamin jest skutkiem ubocznym zdobywania praktyki. Nasze szkolenia nie polegają na "zakuwaniu bazy pytań" (tzw. braindumps). Uczymy technologii w boju, na laboratoriach, a zdany egzamin jest tylko formalnym potwierdzeniem kompetencji, które już posiadasz.

Kategoria 1: Chmura i DevOps (AWS, Azure, GCP) - "Must Have" w B2B

Jeśli celujesz w stawki seniorskie, chmura nie jest opcją - jest obowiązkiem. Dostawcy chmurowi (Cloud Providers) stworzyli ekosystemy, w których certyfikacja jest ściśle powiązana z poziomem partnerstwa firmy wdrażającej.

AWS Certified Solutions Architect (Associate/Professional): To obecnie "złoty standard" w infrastrukturze. Potwierdza, że rozumiesz, jak zaprojektować bezpieczną, skalowalną i (co ważne) opłacalną architekturę. Pracodawcy szukają tego certyfikatu, bo błędnie zaprojektowana chmura potrafi generować gigantyczne koszty.
Microsoft Certified: Azure Administrator / Developer: Dla firm osadzonych w ekosystemie Microsoftu (a jest ich w Polsce większość) to podstawa. Szczególnie cenione są ścieżki specjalistyczne, np. związane z AI czy Security w Azure.

W JSystems zauważamy, że kursanci wracający ze zdany egzaminem chmurowym najszybciej awansują na stanowiska typu Cloud Engineer czy DevOps.

Jak wygląda cała ścieżka wejścia do tego zawodu, opisujemy krok po kroku w przewodniku o karierze DevOps Engineera od zera.

Kategoria 2: Technologie Backendowe (Java, .NET) - Dowód głębokiej wiedzy

O ile w świecie JavaScriptu certyfikaty są rzadkością, o tyle w technologiach "Enterprise" (Java, C#) mają się świetnie.

Oracle Certified Professional (OCP) Java Developer

To jeden z najtrudniejszych egzaminów na rynku. Wymaga zrozumienia mechanizmów języka na poziomie atomowym (wątki, strumienie, zarządzanie pamięcią). Posiadanie OCP sygnalizuje rekruterowi: "Ten człowiek nie tylko używa frameworka Spring, on rozumie, jak działa Java pod maską". To często przepustka do projektów high-performance w sektorze finansowym.

Kategoria 3: Zarządzanie i Procesy (ITIL, Scrum, Agile)

Tech Lead czy Senior Developer to nie tylko kod. To rozumienie biznesu. Tutaj certyfikaty pełnią rolę "wspólnego języka".

ITIL® 4 Foundation: Standard w korporacjach. Uczy, jak zarządzać usługami IT, incydentami i zmianą. Bez tego trudno o awans na menedżera w dużej strukturze.
Professional Scrum Master (PSM) / Product Owner (PSPO): Nawet jeśli jesteś programistą, certyfikat PSM I pokazuje, że rozumiesz proces wytwórczy. To sygnał, że będziesz wsparciem dla zespołu, a nie blokerem kwestionującym sens Daily czy Retrospektywy.

Kategoria 4: Cyberbezpieczeństwo (CISSP, CEH, CISM)

To obecnie najlepiej opłacana nisza. Certyfikaty takie jak CISSP (Certified Information Systems Security Professional) czy CEH (Certified Ethical Hacker) są trudne do zdobycia, drogie, ale ich posiadacze są rozchwytywani. Wymagają nie tylko wiedzy, ale często udokumentowanego stażu pracy. W JSystems organizujemy szkolenia przygotowujące do bezpiecznego programowania (Secure Coding), które są świetnym wstępem do tej ścieżki.

Podsumowanie: Inwestuj w wartościowe papiery

Nie rób certyfikatu "dla kolekcji". Wybierz ścieżkę zgodną z Twoim planem kariery. Jeśli chcesz być Architektem - idź w chmurę. Jeśli chcesz pisać systemy transakcyjne - zrób OCP z Javy. Pamiętaj, że certyfikat to inwestycja, która zwraca się zazwyczaj przy pierwszej zmianie pracy lub renegocjacji kontraktu.

Jak układać ten plan, gdy część codziennej roboty przejmują narzędzia AI, tłumaczymy w artykule o tym, jak doświadczony programista utrzymuje się w branży.

Planujesz certyfikację? Nie ryzykuj oblanego egzaminu. Sprawdź nasze szkolenia IT i przygotuj się pod okiem ekspertów.

FAQ - Certyfikacja w IT

Czy certyfikaty mają termin ważności?

Większość tak. Technologie chmurowe zmieniają się tak szybko, że certyfikaty AWS czy Azure są ważne zazwyczaj 2-3 lata. Wymaga to tzw. recertyfikacji (często krótszy egzamin lub zebranie punktów edukacyjnych). Certyfikaty z konkretnych wersji języków (np. Java 11) są ważne bezterminowo, ale tracą na znaczeniu wraz z wejściem nowych standardów.

Ile kosztuje egzamin certyfikacyjny?

Ceny wahają się od 100 USD (podstawowe egzaminy chmurowe) do nawet 700-1000 USD za zaawansowane certyfikaty z bezpieczeństwa czy architektury.

Czy pracodawcy zwracają koszty certyfikacji?

W modelu B2B zazwyczaj pokrywasz to sam (i wrzucasz w koszty firmy). W przypadku Umowy o Pracę, większość dojrzałych firm IT posiada budżet szkoleniowy i chętnie finansuje certyfikaty, ponieważ podnosi to prestiż firmy i pozwala jej startować w bardziej wymagających przetargach.

Powiązane artykuły

Monolit vs Mikroserwisy: kiedy dzielić aplikację, a kiedy tego nie robić? (2026)

Andrzej Klusiewicz — Mon, 14 Sep 2026 07:01:38 +0000

"Przepiszmy to na mikroserwisy" - zdanie, które w wielu firmach kończy się większym chaosem niż problem, który miało rozwiązać. Zanim podejmiesz tę decyzję architektoniczną, zobacz, kiedy naprawdę się opłaca, a kiedy to kosztowna moda.

Przez ostatnią dekadę branża IT zachłysnęła się mikroserwisami. Konferencje pękały w szwach od prezentacji Netflixa czy Ubera, pokazujących tysiące współpracujących usług. Wiele firm, chcąc naśladować gigantów, pocięło swoje systemy na kawałki, tylko po to, by odkryć, że zamiast skalowalności zyskały chaos, problemy z transakcyjnością i koszmarne koszty infrastruktury. W JSystems, szkoląc architektów i Tech Leadów, widzimy powrót do rozsądku. Coraz częściej pada hasło "Modularny Monolit". Kiedy więc mikroserwisy mają sens, a kiedy są strzałem w stopę? Oto dogłębna analiza bez marketingowego pudru.

Wielki powrót Monolitu (Modularnego)

Słowo "Monolit" stało się w IT niemal obelgą. Niesłusznie. Monolit to po prostu aplikacja, w której wszystkie moduły są wdrażane jako jedna jednostka (np. jeden plik .jar, .dll czy kontener). Ma to potężne zalety, o których zapominamy:

Prostota wdrożenia: Masz jeden artefakt. Wrzucasz go na serwer i działa. Nie musisz martwić się o orkiestrację 50 kontenerów.
Łatwość debugowania: Śledzenie błędu odbywa się w jednym procesie. IDE pokazuje Ci cały stack trace. Nie musisz skakać po logach z dziesięciu serwerów.
Wydajność: Komunikacja między modułami to wywołanie metody w pamięci RAM (nanosekundy). W mikroserwisach to komunikacja sieciowa (milisekundy), która jest zawodna i wolna.
Transakcyjność (ACID): W monolicie masz jedną bazę danych. Zrobienie "Commit" lub "Rollback" transakcji obejmującej zamówienia, płatności i magazyn jest trywialne.

W JSystems promujemy koncepcję Modularnego Monolitu (Modulith). To architektura, w której logicznie dzielimy kod na domeny (np. Moduł Sprzedaży, Moduł Magazynu) z czystymi granicami, ale fizycznie wdrażamy to jako jedną aplikację. To złoty środek dla 90% firm, które nie mają skali Netflixa.

Mikroserwisy: Cena, którą musisz zapłacić

Mikroserwisy to styl architektoniczny, w którym aplikacja składa się z wielu małych usług, działających w osobnych procesach i komunikujących się przez sieć (zazwyczaj HTTP/REST lub kolejki wiadomości). Daje to ogromną autonomię zespołom (każdy zespół może pisać w innym języku i wdrażać się niezależnie), ale narzut operacyjny jest gigantyczny. Zanim zdecydujesz się na ten krok, odpowiedz sobie na pytania o tzw. "Distributed Computing Fallacies":

1. Sieć jest zawodna

W monolicie metoda zawsze wywoła metodę. W mikroserwisach request HTTP może zginąć, dostać timeout, albo serwer docelowy może być przeciążony. Musisz zaimplementować mechanizmy Retries, Circuit Breakers (np. Polly w .NET), i być gotowym na to, że część systemu po prostu nie działa.

2. Spójność ostateczna (Eventual Consistency)

To najtrudniejsza pigułka do przełknięcia dla biznesu. W świecie mikroserwisów nie ma globalnych transakcji ACID (Distributed Transactions są wolne i ryzykowne). Jeśli usługa "Zamówienia" pobierze pieniądze, a usługa "Magazyn" zgłosi błąd, nie możesz po prostu cofnąć transakcji bazy danych. Musisz zaimplementować tzw. Transakcje Kompensacyjne (Wzorzec SAGA). To drastycznie komplikuje kod. Czy Twój biznes zaakceptuje fakt, że przez 3 sekundy użytkownik widzi stan "Opłacone", a potem nagle "Anulowane"?

3. Piekło observability

Znalezienie przyczyny błędu w systemie rozproszonym wymaga zaawansowanej infrastruktury: Distributed Tracing (Jaeger, OpenTelemetry), centralnego logowania (ELK Stack, Splunk) i monitoringu (Prometheus, Grafana). Bez tego jesteś ślepy. Wdrożenie i utrzymanie tych narzędzi często wymaga osobnego zespołu DevOps.

Kiedy WIĘC warto iść w mikroserwisy?

Mimo wad, mikroserwisy są niezbędne w określonych scenariuszach. Decyzję o podziale należy podjąć, gdy:

Skalowanie zespołów: Masz 100+ programistów. Praca na jednym repozytorium (codebase) staje się koszmarem (merge conflicts). Podział na mikroserwisy pozwala zespołom pracować niezależnie.
Niejednorodne wymagania skalowalności: Moduł "Generowanie PDF" zużywa 90% CPU, a moduł "Logowanie" prawie nic. W mikroserwisach możesz postawić 50 instancji serwisu PDF i tylko 2 instancje Logowania. W monolicie musisz skalować całą kobyłę.
Technologia: Część systemu wymaga Pythona (Machine Learning), a część wydajnego C# lub Go. Mikroserwisy pozwalają na architekturę "Polyglot".
Time-to-market dla małych zmian: Jeśli zmiana jednej linijki w module promocji wymaga przebudowania i przetestowania całego gigantycznego systemu bankowego (co trwa 3 dni), to wydzielenie promocji do mikroserwisu pozwoli wdrażać go w 15 minut.

Antywzorzec: Rozproszony Monolit (Distributed Monolith)

To najgorszy z możliwych światów, przed którym ostrzegamy na naszych szkoleniach architektonicznych. Dzieje się to wtedy, gdy pociąłeś system na mikroserwisy, ale są one ze sobą tak silnie powiązane, że wdrożenie zmiany w jednym wymaga zmiany w trzech innych. Musisz je wdrażać w określonej kolejności, dzielą jedną bazę danych, a komunikacja jest "gadatliwa". Zyskałeś wszystkie problemy sieciowe mikroserwisów, a nie zyskałeś żadnej niezależności. Unikaj tego jak ognia.

Strategia przejścia: Strangler Fig Pattern

Jeśli masz stary system (Legacy) i chcesz go zmodernizować, nigdy nie rób "Wielkiego Przepisania" (Big Bang Rewrite) - to się zawsze kończy porażką. W JSystems uczymy wzorca Strangler Fig (Figowiec Dusiciel). Polega on na stopniowym wygaszaniu starego systemu:

Stawiasz "Fasadę" lub API Gateway przed starym monolitem.
Nowe funkcjonalności piszesz już jako mikroserwisy (lub moduły).
Powoli wycinasz kawałki logiki ze starego systemu i przekierowujesz ruch na nowe serwisy.
Po latach stary system (monolit) znika lub zostaje zredukowany do minimum.

To proces bezpieczny, pozwalający dostarczać wartość biznesową od pierwszego dnia transformacji.

Rola architektury w ofercie JSystems

Na naszych szkoleniach z Architektury Oprogramowania nie uczymy "rysowania pudełek". Nasi trenerzy to inżynierowie, którzy przeprowadzali transformacje systemów w bankach, telekomach i e-commerce. Pokazujemy praktyczne aspekty:

Jak zdefiniować granice usług (Bounded Contexts) przy użyciu Event Stormingu.
Jak konfigurować komunikację asynchroniczną (RabbitMQ, Kafka).
Jak zarządzać kontraktami API (Consumer Driven Contracts).
Jak konteneryzować aplikacje (Docker, Kubernetes).

Dzięki naszym gotowym środowiskom laboratoryjnym w chmurze, podczas szkolenia postawisz własny klaster mikroserwisów i zobaczysz, jak zachowuje się, gdy wyłączymy jeden z węzłów (Chaos Engineering).

Podsumowanie: Ewolucja, nie rewolucja

Nie zaczynaj nowego projektu od mikroserwisów. Zacznij od dobrze zaprojektowanego Modularnego Monolitu. Jeśli odniesiesz sukces i system urośnie - będziesz miał gotowe granice modułów, by łatwo wydzielić je do mikroserwisów. Jeśli zaczniesz od mikroserwisów bez zrozumienia domeny, skończysz z chaosem, którego utrzymanie pochłonie cały Twój budżet.

Stoisz przed wyborem architektury dla nowego systemu? Skonsultuj to z praktykiem. Sprawdź nasze szkolenia z architektury oprogramowania - systemów i mikroserwisów. Nauczymy Cię podejmować decyzje oparte na faktach, a nie na hype.

FAQ - Architektura Monolit vs Mikroserwisy

Czy mikroserwisy wymagają Kubernetesa?

Teoretycznie nie, ale w praktyce przy skali powyżej kilku serwisów, ręczne zarządzanie kontenerami jest niemożliwe. Kubernetes (K8s) stał się standardem orkiestracji, automatyzującym wdrażanie, skalowanie i zarządzanie aplikacjami kontenerowymi. Jednak próg wejścia w K8s jest bardzo wysoki.

Co to jest CAP Theorem?

Twierdzenie CAP mówi, że w systemie rozproszonym (takim jak mikroserwisy) możesz mieć jednocześnie tylko dwie z trzech cech: Spójność (Consistency), Dostępność (Availability) i Tolerancję na podział sieci (Partition Tolerance). Ponieważ podział sieci jest nieunikniony, w praktyce musisz wybierać między Spójnością (CP) a Dostępnością (AP). To kluczowa decyzja architektoniczna.

Jak komunikują się mikroserwisy?

Mamy dwa główne sposoby: synchroniczny (zazwyczaj REST lub gRPC) - gdzie jeden serwis czeka na odpowiedź drugiego, oraz asynchroniczny (kolejki wiadomości jak RabbitMQ, Kafka) - gdzie serwisy wymieniają zdarzenia (Events). W architekturze mikroserwisów preferuje się komunikację asynchroniczną, aby zmniejszyć powiązania (Coupling) między usługami.

Chcesz rozbić monolit na usługi i uruchamiać je w kontenerach na klastrze pod okiem praktyka? Szkolenie Docker i Kubernetes: od zera do bohatera ma terminy gwarantowane.

Powiązane artykuły

Linux w pracy programisty: dlaczego warto znać terminal Bash (2026)

Andrzej Klusiewicz — Mon, 14 Sep 2026 07:01:18 +0000

Krótkie pytanie na dzień dobry: kiedy ostatnio odpaliłeś terminal bez googlowania komendy? Jeśli odpowiedź brzmi "dawno", ten tekst jest dla Ciebie - bo produkcja i tak stoi na Linuxie, niezależnie od tego, w czym piszesz kod.

Wielu Junior Developerów, wychowanych na nowoczesnych IDE z pięknymi interfejsami graficznymi, traktuje czarny ekran terminala jak relikt z lat 90. To błąd, który hamuje ich rozwój na poziomie Mid/Senior. Prawda jest brutalna: Twój kod może powstawać na Windowsie, Linuxie lub macOS, ale ostatecznie i tak uruchomi się na Linuxie - w kontenerze Dockera, w chmurze AWS czy na klastrze Kubernetes. W JSystems od 2008 roku uczymy, że biegłość w Bashu to nie "hakerstwo", to podstawowa higiena pracy, która oddziela rzemieślników od inżynierów.

GUI jest dla użytkowników, CLI jest dla twórców

Interfejs graficzny (GUI) jest świetny do odkrywania funkcji, ale fatalny do automatyzacji. Wyobraź sobie zadanie: musisz znaleźć konkretny błąd w 50 plikach logów, z których każdy waży 1GB. W notatniku systemowym to niemożliwe - program się zawiesi. W terminalu Linuxa to jedna linijka kodu, która wykonuje się w kilka sekund.

Wiersz poleceń (CLI - Command Line Interface) daje Ci bezpośrednią kontrolę nad systemem operacyjnym. Nie jesteś ograniczony tym, co przewidział twórca interfejsu graficznego. Możesz łączyć małe, proste narzędzia w potężne potoki (pipelines) przetwarzania danych. To jest właśnie filozofia Unix: "Rób jedną rzecz i rób ją dobrze", a potem pozwól użytkownikowi łączyć te rzeczy.

5 sytuacji, w których Linux ratuje życie programisty

Na naszych szkoleniach "Linux dla Programistów" często słyszymy: "Ale ja jestem programistą .NET, po co mi to?". Odpowiedź przychodzi szybko, gdy omawiamy realne scenariusze awarii:

1. Debugowanie na produkcji (SSH)

Kiedy aplikacja na produkcji pada, nie podłączysz do niej Visual Studio w trybie Debug. Jedyne, co masz, to dostęp przez SSH (Secure Shell). Jeśli nie potrafisz poruszać się po katalogach (cd, ls), podglądać procesów (top, htop) i filtrować logów w czasie rzeczywistym (tail -f | grep), jesteś bezradny. Czekasz na DevOpsa, a firma traci pieniądze.

2. Docker i Konteneryzacja

Docker to w 99% Linux. Nawet jeśli używasz "Docker Desktop for Windows", pod spodem działa wirtualna maszyna Linuxa. Zrozumienie, czym są uprawnienia plików (chmod, chown), zmienne środowiskowe (env) czy system plików Linuxa, jest kluczowe, by pisać poprawne pliki Dockerfile. Bez tego będziesz walczył z błędami "Permission Denied" w nieskończoność.

3. Automatyzacja nudnych zadań (Bash Scripting)

Musisz zmienić nazwę 1000 plików, dodając do nich datę? Możesz klikać "Zmień nazwę" przez 4 godziny, albo napisać pętlę for w Bashu, która zrobi to w 4 sekundy. W JSystems kładziemy duży nacisk na skryptowanie - programista powinien być leniwy w inteligentny sposób.

4. Git pod maską

Graficzne klienty Gita są wygodne, dopóki coś się nie zepsuje. Skomplikowany rebase, usuwanie plików z historii czy bisect często wymagają użycia terminala. Git został stworzony przez twórcę Linuxa (Linusa Torvaldsa) i widać to w jego DNA. CLI daje pełną precyzję.

5. Regular Expressions (RegEx) + Grep/Sed/Awk

To "święta trójca" przetwarzania tekstu. Umiejętność wyciągnięcia z logów serwera WWW tylko tych linii, które zawierają kod błędu 500 i pochodzą z konkretnego IP, przy użyciu awk i grep, to supermoc, która imponuje każdemu Tech Leadowi.

WSL 2 - Koniec wymówek dla użytkowników Windows

Jeszcze kilka lat temu nauka Linuxa wymagała instalowania go jako drugiego systemu (Dual Boot) lub powolnej wirtualizacji. Dziś, dzięki WSL 2 (Windows Subsystem for Linux), masz pełnoprawnego Ubuntu zintegrowanego z Windowsem. Możesz pisać kod w Visual Studio Code na Windowsie, a kompilować go i uruchamiać w terminalu Linuxa w tym samym czasie. Na naszych szkoleniach pokazujemy, jak skonfigurować to hybrydowe środowisko, by czerpać to, co najlepsze z obu światów.

Czego uczymy w JSystems? Podejście praktyczne

Nie uczymy historii jądra Linuxa, bo to wiedza akademicka. Uczymy narzędzi potrzebnych "na wczoraj":

Zarządzanie procesami: Jak zabić zawieszony proces (kill, pkill) i jak sprawdzić, co zjada całą pamięć RAM.
Sieć: Jak sprawdzić, czy port jest otwarty (netstat, curl, telnet) - kluczowe przy mikroserwisach.
Edytory tekstowe: Dlaczego warto znać podstawy vim lub nano (bo na serwerze nie ma Notatnika!).
Uprawnienia: System rwx (Read-Write-Execute) - zmora początkujących, którą wyjaśniamy w 15 minut.

Każdy uczestnik szkolenia otrzymuje dostęp do własnego serwera w chmurze (Cloud Lab), gdzie może bezpiecznie "psuć" system i uczyć się go naprawiać.

Podsumowanie

Linux to "lingua franca" współczesnej infrastruktury IT. Niezależnie od tego, czy programujesz w Javie, Pythonie, C# czy Node.js - Twoja aplikacja zamieszka na Linuxie. Znajomość środowiska, w którym żyje Twój kod, to obowiązek każdego profesjonalisty.

Chcesz przestać bać się czarnego ekranu? Zapisz się na praktyczne warsztatowe szkolenia z Linuxa i Basha w JSystems. Poczuj moc pełnej kontroli nad systemem.

FAQ - Linux w pracy programisty

Czy muszę znać Linuxa, będąc Frontend Developerem?

Coraz częściej tak. Narzędzia takie jak Node.js, npm, Webpack czy kontenery Dockerowe najlepiej działają w środowisku unixowym. Znajomość podstawowych komend terminala znacznie przyspiesza pracę z narzędziami buildowania i wdrażania aplikacji frontendowych.

Jaka dystrybucja Linuxa jest najlepsza na początek?

Rekomendujemy Ubuntu. Jest najbardziej popularne, ma ogromne wsparcie społeczności i jest standardem w wielu firmach oraz w chmurach (AWS, Azure). Na szkoleniach w JSystems pracujemy głównie na systemach z rodziny Debian/Ubuntu lub RedHat/CentOS.

Szkolenie Administracja systemem Linux →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

Czysty kod (Clean Code) - 10 zasad, ktore odrozniaja kod Seniora od Juniora

Andrzej Klusiewicz — Sun, 13 Sep 2026 07:04:02 +0000

Czysty kod to nie kwestia gustu ani estetyki - to konkretna oszczednosc czasu przy kazdej kolejnej zmianie. Zebralismy 10 zasad, ktore najczesciej odrozniaja kod doswiadczonego programisty od poczatkujacego.

"Każdy głupiec potrafi napisać kod, który zrozumie komputer. Dobrzy programiści piszą kod, który zrozumieją ludzie." Ten słynny cytat Martina Fowlera to mantra, którą powtarzamy na każdym szkoleniu w JSystems. Wielu programistów traktuje Clean Code jako zbiór subiektywnych zasad estetycznych ("gdzie postawić nawias"). To błąd. Czysty kod to pojęcie ekonomiczne. To jedyny sposób na utrzymanie stałego tempa rozwoju projektu w czasie. Jeśli Twój zespół zwalnia z każdym kolejnym sprintem, to znak, że toniecie w długu technicznym. Oto kompendium zasad, które ratują projekty.

Ekonomia Kodu: Dlaczego "Szybko" znaczy "Wolno"?

Wyobraź sobie, że piszesz kod "na szybko", byle dowieźć funkcjonalność na piątek. Ignorujesz testy, kopiujesz fragmenty (Copy-Paste), tworzysz klasy-molochy. Na początku idzie świetnie. Ale po pół roku dodanie prostej zmiany (np. nowej stawki VAT) zajmuje tydzień, bo zmiana w jednym miejscu wywołuje błędy w pięciu innych.

To jest właśnie Dług Techniczny. Clean Code to spłacanie odsetek na bieżąco. Kod czyta się 10 razy częściej, niż się go pisze (podczas code review, debugowania, wdrażania nowych funkcji). Inwestycja godziny w napisanie czytelnego kodu zwraca się wielokrotnie w przyszłości. W JSystems uczymy, że profesjonalizm to umiejętność powiedzenia biznesowi: "Nie zrobimy tego szybciej, bo zrobimy to źle, a to was będzie kosztować więcej".

10 Przykazań Czystego Kodu (Wersja dla Praktyków)

1. Nazwy to dokumentacja (Intention-Revealing Names)

Najtrudniejsza rzecz w informatyce? Nazywanie rzeczy. Zmienna d nic nie znaczy. Zmienna daysSinceCreation mówi wszystko.

Zła nazwa: public List<int> Get() { ... }

Dobra nazwa: public List<Employee> GetActiveEmployees() { ... }

Kod powinien czytać się jak prozę. Jeśli musisz zaglądać do wnętrza funkcji, by wiedzieć, co ona robi - nazwa jest do zmiany.

2. Zasada Pojedynczej Odpowiedzialności (SRP - SOLID)

Klasa lub funkcja powinna mieć tylko jeden powód do zmiany. Jeśli Twoja klasa UserService zajmuje się: (1) walidacją peselu, (2) zapisem do bazy i (3) wysłaniem e-maila powitalnego - łamiesz SRP. Rozbij to na PeselValidator, UserRepository i EmailSender. Dzięki temu zmiana w sposobie wysyłki maili nie zepsuje logiki walidacji.

3. Funkcje: Krótkie i robiące jedną rzecz

Idealna funkcja ma 5-10 linii. Jeśli Twoja funkcja ma 200 linii i zawiera sekcje oddzielone komentarzami (// walidacja, // zapis), to prosi się o "Extract Method". Poziom wcięć (zagnieżdżone if-y) nie powinien przekraczać dwóch. To redukuje tzw. Złożoność Cyklomatyczną.

4. DRY (Don't Repeat Yourself) vs WET (Write Everything Twice)

Duplikacja kodu to źródło wszelkiego zła. Jeśli poprawiasz błąd w jednym miejscu, a zapominasz o jego kopii w innym pliku - masz buga. Ale uwaga! Na szkoleniach w JSystems uczymy też pragmatyzmu. Czasem lepiej powtórzyć kod, niż tworzyć sztuczną abstrakcję, która wiąże ze sobą niezależne moduły. Zasada WET (Write Everything Twice) mówi: poczekaj z refaktoryzacją, aż powtórzysz kod trzeci raz.

5. Komentarze kłamią

Kod się zmienia, komentarze rzadko. Nie ma nic gorszego niż komentarz, który mówi co innego niż kod.

Zamiast pisać: // Sprawdź czy pracownik ma prawo do premii

Wydziel metodę: if (employee.IsEligibleForBonus())

Komentarze są dopuszczalne tylko wtedy, gdy wyjaśniają DLACZEGO coś zrobiliśmy (np. "Używamy tego algorytmu, bo jest szybszy dla małych zbiorów"), a nie CO zrobiliśmy.

6. Obiekty vs Struktury Danych (Prawo Demeter)

Nie rozmawiaj z obcymi. Kod typu order.Customer.Address.ZipCode to łamanie enkapsulacji. Jeśli zmieni się struktura klienta, musisz poprawić kod w 50 miejscach. Lepiej: order.GetZipCode().

7. Testy Unitowe jako specyfikacja

W JSystems wyznajemy zasadę: Kod bez testów to kod legacy w momencie napisania. Testy dają Ci odwagę do refaktoryzacji. Jeśli boisz się dotknąć kodu, "żeby nie wybuchło", to znaczy, że brakuje testów. Clean Code jest nierozerwalnie związany z TDD.

8. Obsługa błędów (Exceptions over Return Codes)

Nie zwracaj -1 ani null jako błędu. Rzucaj wyjątkami. Wyjątki nie zaśmiecają głównego przepływu sterowania (Happy Path). I na litość boską - nigdy nie rób pustego catch!

9. Formatowanie i Konwencje

Zespół musi ustalić jeden styl (nawiasy w nowej linii czy tej samej?). Używajcie narzędzi typu Prettier, ESLint czy StyleCop, które formatują kod automatycznie przy zapisie. Dyskusje o wcięciach na Code Review to strata czasu.

10. Zasada Skauta

"Zostaw miejsce biwakowe czystszym, niż je zastałeś". Widzisz mały bałagan w pliku, który edytujesz? Zmień nazwę zmiennej, usuń nieużywany import. Te mikropoprawki kumulują się w czasie, zapobiegając gniciu kodu (Code Rot).

Code Review - poligon doświadczalny JSystems

Teoria jest prosta, praktyka boli. Dlatego nasze szkolenia opierają się na warsztatach z Code Review. Uczestnicy piszą kod, a następnie wspólnie (na rzutniku) go "masakrujemy" - w pozytywnym sensie. Szukamy złych nazw, łamania SOLID, braku testów. Uczymy, jak dawać i przyjmować feedback.

O tym, dlaczego taka praca na żywym środowisku z trenerem uczy więcej niż nagrane kursy wideo, piszemy w porównaniu skuteczności różnych form szkoleń IT.

Pokazujemy też, jak refaktoryzować kod krok po kroku, używając skrótów klawiszowych IDE (IntelliJ, Visual Studio), co sprawia, że czyszczenie kodu jest szybkie i bezpieczne.

Poza samym IDE dużą część tej sprawności daje biegłość w terminalu, o której piszemy w artykule o Linuksie i powłoce Bash w codziennej pracy programisty.

Podsumowanie: Jakość to nawyk

Czysty kod nie powstaje, gdy masz "więcej czasu". Czysty kod to nawyk, który budujesz codziennie. To szacunek do współpracowników i do samego siebie z przyszłości. Jeśli chcesz, by Twoja praca była przyjemnością, a nie walką z ogniem - zacznij dbać o higienę kodu już dziś.

Czujesz, że Twój kod mógłby być lepszy? Zapraszamy na warsztatowe szkolenia z zakresu architektury oprogramowania, w tym obejmujące clean code. Nauczymy Cię pisać kod, z którego będziesz dumny.

FAQ - Clean Code

Czy Clean Code nie stoi w sprzeczności z wydajnością?

Czasami tak. Wywołanie wielu małych funkcji ma minimalny narzut. Jednak w 99% przypadków "brzydki", zoptymalizowany kod jest potrzebny tylko w krytycznych pętlach (Hot Paths). W pozostałej części systemu czytelność jest ważniejsza. Zasada: "Make it work, make it right, make it fast" - w tej kolejności.

Jak przekonać szefa do inwestycji w refaktoryzację?

Nie używaj słowa "refaktoryzacja", bo dla biznesu brzmi to jak "płacenie za to samo". Używaj argumentów o ryzyku i prędkości. "Jeśli nie uporządkujemy teraz modułu płatności, wdrożenie nowej metody zajmie 2 tygodnie zamiast 2 dni i ryzykujemy błędy przy obciążaniu kart". Przeliczaj jakość na pieniądze.