Po co w ogóle wybierać format pliku w analityce Big Data
Format pliku w analityce Big Data działa jak „kształt” danych, z którym mierzy się każdy element architektury – od systemu strumieniowego, przez klaster obliczeniowy, aż po narzędzia BI i notebooki analityczne. Ten wybór wpływa zarówno na wygodę pracy zespołu, jak i na rachunek za infrastrukturę oraz czas odpowiedzi zapytań.
Przy niewielkich wolumenach danych i prostych raportach CSV czy JSON wydają się wystarczające. Gdy jednak dane rosną do terabajtów i petabajtów, a zapytania odpalane są jednocześnie przez wielu użytkowników, format pliku zaczyna być jednym z głównych czynników decydujących o tym, czy klaster i budżet przetrwają.
Format pliku w całym łańcuchu przetwarzania danych
Łańcuch przetwarzania danych można ująć w kilku głównych etapach: ingest (pozyskiwanie), przechowywanie, przetwarzanie wsadowe i strumieniowe, udostępnianie do analizy (BI, ad hoc SQL, modele ML). Format pliku wchodzi w grę prawie na każdym z tych poziomów, ale w różny sposób.
W warstwie ingest często pojawiają się formaty „transportowe” – JSON, CSV, czasem Avro lub protobuf, zależnie od protokołu komunikacji. W tej warstwie liczy się głównie zgodność pomiędzy usługami i łatwość debugowania. Gdy dane trafiają do systemu składowania (HDFS, S3, GCS, Azure Data Lake), zaczyna być kluczowe, w jakiej postaci będą utrwalone na dłużej: czy pozostaną jako surowe pliki tekstowe, czy zostaną przekonwertowane do formatu kolumnowego, takiego jak Parquet lub ORC.
Na etapie przetwarzania wsadowego i interaktywnego (Spark, Presto, Trino, Hive, Flink) format drastycznie wpływa na to, ile danych trzeba fizycznie odczytać z dysku/sieci, żeby policzyć agregacje czy dołączyć kilka tabel. To tutaj kolumnowe Parquet i ORC zwykle deklasują formaty wierszowe w typowo analitycznych scenariuszach.
Na końcu łańcucha stoją narzędzia BI (Power BI, Tableau, Superset, Looker) oraz zespoły data science. Jeżeli dane w warstwie analitycznej są w formacie, z którym te narzędzia radzą sobie dobrze (często Parquet lub ORC poprzez warstwę silnika SQL), użytkownicy odczują krótszy czas oczekiwania i mniejsze ryzyko „zamrożenia” zapytania na kilkanaście minut.
Wpływ formatu na koszty: storage, I/O, CPU, sieć
Format danych wpływa na kilka podstawowych kosztów technicznych:
- Storage – kompresja i organizacja danych przekłada się na to, ile fizycznie zajmą na dyskach lub w obiektowej pamięci masowej. Parquet i ORC potrafią zredukować rozmiar danych względem CSV kilkukrotnie dzięki kolumnowej kompresji.
- I/O (wejście/wyjście) – w formatach kolumnowych można odczytać tylko wybrane kolumny bez dotykania reszty. W CSV czy Avro row-based odczyt dotyczy całych wierszy.
- CPU – mniej danych do dekodowania i deserializacji oznacza mniejszy narzut na procesor. Dodatkowo formaty binarne mają bardziej efektywną reprezentację typów niż tekstowe CSV/JSON.
- Sieć – w systemach rozproszonych (Spark, Presto, Hive) część danych musi być przesuwana między węzłami. Mniejsza ilość danych wejściowych i wyjściowych ogranicza też koszty transferów między strefami czy regionami w chmurze.
W praktyce wiele zespołów zaczyna optymalizację od skalowania klastra lub tuningu Spark/Hive, podczas gdy zmiana formatu z CSV/JSON na Parquet lub ORC potrafi dać większy efekt niż wszystkie te zabiegi razem.
Dlaczego „surowy CSV wszędzie” zaczyna boleć
Scenariusz jest bardzo typowy: zespół zaczyna z prostym pipeline’em, który ściąga dane z systemów źródłowych, zapisuje je w CSV na HDFS/S3, a następnie czyta je Spark/Hive do raportów. Początkowo to działa bez zarzutu – wolumen danych jest niewielki, a architektura prosta. Z czasem jednak zbieranych danych przybywa, schemat tabel się rozrasta, liczba raportów rośnie, a do systemu dołączają kolejni użytkownicy.
Nagle pojawiają się symptomy:
- czas wykonywania zapytań idzie w górę z minut do dziesiątek minut,
- koszty klastra rosną, bo trzeba zwiększać liczbę węzłów lub ich parametry,
- krótkie analizy ad hoc stają się uciążliwe, bo każde zapytanie skanuje setki gigabajtów CSV, nawet jeśli potrzebne są dwie kolumny,
- zmiana schematu (dodanie kolumny) wymaga ostrożnego zarządzania wersjami plików i transformacji.
Najczęściej okazuje się, że głównym wąskim gardłem jest właśnie rozsypana warstwa plików tekstowych, a nie sam klaster obliczeniowy. Konwersja tej warstwy do Parquet lub ORC, często z prostą partycją po dacie lub innej kluczowej kolumnie, potrafi radykalnie zmienić profil wydajności bez jakichkolwiek zmian w logice zapytań.
Miejsce formatu w architekturze data lake i lakehouse
W nowoczesnych architekturach data lake i lakehouse zwykle wyróżnia się kilka warstw logicznych, które często wykorzystują różne formaty plików:
- Warstwa RAW (landing / bronze) – miejsce, gdzie dane są przechowywane jak najbliżej formy źródłowej, często jako JSON, CSV lub Avro. Tu chodzi o szybki ingest i pełną wierność danych źródłowych.
- Warstwa CURATED (silver) – dane oczyszczone, znormalizowane, częściowo zintegrowane, zwykle w formacie analitycznym (Parquet/ORC). To z tej warstwy korzysta większość procesów wsadowych i przygotowujących dane do dalszego użytku.
- Warstwa ANALYTICAL (gold) – dane pod konkretne case’y biznesowe, gotowe tabele faktów i wymiarów, zoptymalizowane pod szybkie zapytania BI i modele ML. Tu dominują formaty kolumnowe i dodatkowe mechanizmy (delta/iceberg/hudi) wspierające zarządzanie wersjami, upsertami i time travel.
Avro bardzo często pojawia się w warstwie RAW (szczególnie w połączeniu z Kafką i rejestrem schematów), natomiast Parquet i ORC są typowym wyborem dla warstw CURATED i ANALYTICAL. Rzadko spotyka się Avro jako główny format tabel analitycznych – o ile nie ma ku temu silnego powodu związanego np. z przesyłaniem danych lub specyficznymi wymaganiami narzędzi.
Wiersz kontra kolumna – fundament decyzji o formacie
Najważniejszą różnicą pomiędzy Avro a Parquet/ORC jest sposób organizacji danych: wierszowy kontra kolumnowy. Ten wybór kształtuje wszystko inne – od rozmiaru pliku, przez możliwości kompresji, po typowe czasy zapytań.
Dostęp wierszowy (row-based) w praktyce
W formatach wierszowych każdy rekord (wiersz) przechowywany jest jako spójna całość. Avro, protokoły RPC czy wiele tradycyjnych systemów bazodanowych stosuje tego typu podejście. Podczas odczytu danych odczytywany jest kolejny rekord, deserializowany do obiektu w pamięci i przekazywany do dalszego przetwarzania.
Przydaje się to wszędzie tam, gdzie przetwarzanie naturalnie odbywa się rekord po rekordzie:
- logi zdarzeń w czasie rzeczywistym,
- komunikaty w systemach mikroserwisowych,
- dane time-series analizowane „w locie”,
- API, które przyjmują i wysyłają pojedyncze rekordy, a nie skany całych tabel.
Row-based daje również przewagę w przypadkach, kiedy większość logiki przetwarzania dotyczy dużej liczby pól w rekordzie. Jeśli w każdym kroku analizy potrzebna jest większość kolumn, korzyść z kolumnowości spada. Wtedy prostota odczytu całego rekordu bywa korzystniejsza, zwłaszcza w systemach strumieniowych.
W kontekście kompresji formaty wierszowe działają zwykle gorzej niż kolumnowe przy danych silnie powtarzalnych w poszczególnych kolumnach, ale lepiej radzą sobie z rekordami o zróżnicowanej strukturze i dużej liczbie pól opcjonalnych.
Dostęp kolumnowy (columnar) i jego konsekwencje
Formaty kolumnowe, takie jak Parquet i ORC, grupują dane po kolumnach, a nie po wierszach. Oznacza to, że wartości z jednej kolumny zapisane są obok siebie, często w większych blokach (row group/stripe), a każda kolumna ma osobną sekcję z danymi, metadanymi i statystykami.
Taki układ jest kluczowy dla analityki:
- zapytania typu „scan + agregacja po kilku kolumnach” odczytują tylko potrzebne kolumny, pomijając resztę,
- można efektywnie stosować kompresję specyficzną dla typu kolumny (RLE, dictionary encoding, bit packing),
- statystyki kolumnowe (min, max, liczba wartości null itp.) pozwalają w ogóle nie czytać fragmentów plików, które na pewno nie spełnią warunków WHERE.
W praktyce oznacza to, że zapytanie, które w CSV musiałoby przeskanować np. 100 GB danych, w Parquet lub ORC może fizycznie przeczytać ułamek tej wartości, jeśli dotyczy tylko kilku kolumn i zawiera filtr, który pozwala odrzucić znaczną część bloków.
Minusem formatu kolumnowego jest gorsza wydajność w scenariuszach, w których potrzebna jest szybka obsługa pojedynczych rekordów lub niskie opóźnienia przy zapisie/odczycie niewielkich porcji danych. Kolumnowe formaty są zoptymalizowane pod duże, sekwencyjne skany, a nie pod przypadkowy dostęp do pojedynczych wierszy.
Wpływ organizacji danych na kompresję i I/O
Efektywność kompresji silnie zależy od korelacji i powtarzalności danych w obrębie bloku, który jest kompresowany. W formatach kolumnowych dane z tej samej kolumny, często o podobnej naturze (np. daty, kody krajów, statusy), są blisko siebie. Pozwala to stosować algorytmy kompresji zorientowane na typ danych, takie jak:
- Run-Length Encoding (RLE) dla powtarzających się wartości,
- Dictionary encoding dla powtarzających się ciągów tekstowych lub kodów,
- Delta encoding dla rosnących liczb i timestampów.
W row-based, gdzie w obrębie jednego bloku znajdują się wszystkie pola z wielu rekordów, skuteczność tego typu technik jest zwykle niższa. Często jedynym sensownym wyborem pozostaje klasyczna kompresja ogólnego przeznaczenia (np. gzip, snappy), która nie zna struktury danych w środku.
Mniejszy rozmiar danych na dysku przekłada się bezpośrednio na ilość danych odczytywanych z dysku i przesyłanych po sieci. W systemach Big Data to właśnie I/O, a nie CPU, bywa głównym ograniczeniem. Format kolumnowy, dzięki selektywnemu odczytowi kolumn i dobrej kompresji, zmniejsza łączny wolumen danych wymagających przetworzenia.
Kiedy wiersz wygrywa z kolumną i odwrotnie
Nie istnieje format, który byłby optymalny we wszystkich scenariuszach. Kilka typowych reguł praktycznych:
- Format wierszowy (np. Avro) jest sensowny, gdy:
- dane napływają w postaci zdarzeń i są przetwarzane strumieniowo,
- aplikacje konsumują pojedyncze rekordy (mikroserwisy, systemy kolejkowe),
- schemat musi często ewoluować przy zachowaniu kompatybilności wstecznej i przyszłej,
- liczba kolumn jest wysoka, a typowe operacje dotykają większości pól.
- Format kolumnowy (Parquet/ORC) wygrywa, gdy:
- dominują zapytania analityczne typu „scan + filtr + agregacja/łączenia”,
- użytkownicy rzadko korzystają ze wszystkich kolumn w tabeli,
- koszt storage i I/O jest istotny z punktu widzenia budżetu,
- dane mają być podstawą raportowania BI i modeli ML.
W dojrzałych środowiskach często stosuje się oba podejścia: Avro w warstwie transportowej i surowej, a Parquet/ORC w warstwach analitycznych. Klucz tkwi w zrozumieniu, gdzie który format wykorzystuje swoje mocne strony.
Krótka charakterystyka Avro, Parquet i ORC – DNA każdego formatu
Avro, Parquet i ORC powstały w podobnym ekosystemie, ale rozwiązują nieco inne problemy. Zrozumienie ich „DNA” znacznie ułatwia dopasowanie formatu do konkretnego zastosowania.
Avro – row-based, binarny, schemat na zewnątrz
Avro to binarny format wierszowy stworzony głównie z myślą o efektywnej serializacji danych w systemach rozproszonych. Jego główne cechy:
- Format binarny i row-based – dane są przechowywane rekord po rekordzie, z wydajną binarną reprezentacją typów.
- Schemat zewnętrzny – definicja schematu (pliki .avsc) jest przechowywana niezależnie, a dane zawierają tylko minimalne informacje pozwalające na ich interpretację.
- Dobra integracja z Kafką i streamingiem – Avro stał się de facto standardem w wielu środowiskach, które używają Apache Kafka wraz z rejestrem schematów.
- Wsparcie dla ewolucji schematu – możliwość dodawania, usuwania i zmiany pól przy jasno zdefiniowanych regułach kompatybilności (backward/forward/full).
- Dobra współpraca z językami programowania – narzędzia do generowania klas z definicji schematu oraz wygodnej serializacji/deserializacji.
- Pliki kontenerowe – możliwość zapisu wielu rekordów Avro w jednym pliku wraz z nagłówkiem i metadanymi, co ułatwia batchowe przetwarzanie w Hadoop/Spark.
Avro dobrze sprawdza się jako format „na drut” (w transporcie) oraz w warstwie RAW/Staging, zwłaszcza gdy dane są silnie zorientowane na zdarzenia i intensywnie wykorzystywana jest ewolucja schematu. Deweloperzy doceniają przewidywalność i jasno opisane reguły kompatybilności – dzięki rejestrowi schematów można kontrolować zmiany kontraktów między usługami bez zgadywania, jak wygląda aktualna struktura danych.
W porównaniu z Parquet i ORC, Avro rzadziej bywa ostatecznym formatem tabel analitycznych. Tam, gdzie dominują zapytania typu „scan + agregacje”, przegrywa głównie przez gorszą kompresję i brak kolumnowego dostępu. Nadal jednak bywa obecny w całym łańcuchu: od ingestu przez Kafkę, przez składowanie surowych danych, aż po okresowy „zrzut” do formatu kolumnowego.
Sensowne jest myślenie o Avro jak o „języku kontraktów danych” między systemami i warstwami, a nie o narzędziu do optymalizacji kosztu storage i szybkości zapytań SQL. Gdy głównym kryterium jest spójność schematów, śledzenie zmian i niezawodność integracji między usługami – Avro często będzie pierwszym wyborem.
Parquet – kolumnowy koń pociągowy w ekosystemie analitycznym
Parquet zaprojektowano z myślą o wydajnym przetwarzaniu analitycznym w rozproszonych silnikach obliczeniowych. To kolumnowy, silnie skompresowany format, który stał się standardem w ekosystemie Spark, Presto/Trino, Snowflake, BigQuery (jako format zewnętrzny) czy wielu silnikach lakehouse’owych.
Najważniejsze cechy Parquet to kolumnowe przechowywanie danych, rozbudowany zestaw enkodowania (RLE, dictionary, delta, bit packing), a także bogate metadane i statystyki na poziomie row group i kolumn. Dzięki temu silnik zapytań może agresywnie pomijać całe fragmenty plików, które nie spełniają filtrów, oraz odczytywać wyłącznie potrzebne kolumny. W typowej tabeli faktów, gdzie zapytania dotykają kilku-kilkunastu kolumn spośród kilkudziesięciu, różnica w ilości fizycznie czytanych danych potrafi być drastyczna.
Parquet dobrze radzi sobie z szerokimi tabelami, mieszanką typów danych oraz scenariuszami, gdzie dane są pisane rzadziej, ale czytane wielokrotnie w różnych przekrojach. Nie jest natomiast szczególnie komfortowy przy intensywnym, drobnoziarnistym zapisie (małe pliki, częste appendy pojedynczych rekordów) ani przy przypadkowym dostępie do pojedynczych wierszy. Tam lepiej wypadną formaty wierszowe lub systemy OLTP.
W praktyce Parquet wygrywa w hurtowniach danych w chmurze, lakehouse’ach i wszędzie tam, gdzie SQL-owe zapytania analityczne są głównym sposobem korzystania z danych. Jeśli narzędzia BI i analitycy pracują na tabelach logicznie zdefiniowanych jako „Parquet pod spodem”, zwykle oznacza to rozsądny kompromis między kosztami storage, czasem zapytań i zgodnością z ekosystemem narzędzi.
ORC – wyspecjalizowany format z rodowodem Hadoop/Hive
ORC powstał w świecie Hadoop/Hive jako odpowiedź na problemy skalowania klasycznych formatów tekstowych i RCFile. Podobnie jak Parquet jest formatem kolumnowym, ale ma kilka charakterystycznych cech, które szczególnie dobrze współgrają z Hivem i jego potomkami.
Najbardziej widoczna przewaga ORC ujawnia się przy ścisłej współpracy z Hivem: zaawansowane statystyki kolumnowe, precyzyjne indeksowanie stripe’ów i wbudowane wsparcie dla typów złożonych (struct, array, map) zostały skrojone pod optymalizator zapytań Hive. W środowiskach, gdzie Hive jest głównym silnikiem SQL lub stanowi ważną warstwę pośrednią (np. pod narzędzia BI), ORC potrafi dać zauważalnie lepszą redukcję danych niż Parquet przy podobnym profilu zapytań.
W praktyce ORC często dominuje w starszych, ale wciąż rozbudowanych klastrach Hadoop z silną orientacją na Hive oraz w produktach, które historycznie wyrastały z tego ekosystemu (np. niektóre dystrybucje Cloudera/Hortonworks). Lepiej niż Parquet radzi sobie z bardzo szerokimi tabelami w stylu „enterprise data warehouse na HDFS”, gdzie z jednej strony występuje sporo kolumn technicznych, a z drugiej – duża liczba zapytań grupujących i filtrujących po dobrze zdefiniowanych wymiarach. Tam, gdzie dominują te właśnie scenariusze, przewaga ORC nad Parquetem w zakresie kompresji i pushdownu filtrów może przełożyć się na realne oszczędności sprzętowe.
Jeśli spojrzeć porównawczo, Parquet wygrywa ekosystemem i wszechstronnością – jest wspierany praktycznie wszędzie: od Spark SQL i Presto/Trino po większość silników lakehouse’owych i chmurowych DWH. ORC z kolei jest bardziej „wyspecjalizowany”: błyszczy w połączeniu z Hivem, Tezem czy niektórymi instalacjami Impali, ale poza tym kręgiem bywa wspierany gorzej lub tylko częściowo. W nowych projektach, które nie są mocno przywiązane do Hive’a, częściej wybiera się Parquet jako bezpieczniejszą i bardziej przenośną opcję.
Wybór między Parquet a ORC ma sens głównie wtedy, gdy środowisko jest silnie zdefiniowane z góry. Jeżeli trzonem platformy jest Hive+Hadoop, zespoły znają ORC, a istniejące procesy są już wokół niego zbudowane – trzymanie się ORC bywa po prostu rozsądniejsze. Jeżeli natomiast analityka rozproszona bazuje na Spark/Trino, w miks wchodzą narzędzia SaaS i różne chmurowe silniki SQL, Parquet zapewnia mniejsze tarcie integracyjne. W obu przypadkach zysk w porównaniu z formatami tekstowymi czy stricte wierszowymi i tak bywa o rząd wielkości większy niż drobne różnice między nimi.
Cała gra o formaty sprowadza się ostatecznie do dopasowania narzędzia do dominujących wzorców użycia: Avro do kontraktów między usługami i surowych strumieni zdarzeń, Parquet/ORC do trwałego składowania i intensywnej analityki kolumnowej. Świadome łączenie tych klocków, zamiast szukania jednego „złotego” formatu, najczęściej daje najbardziej przewidywalną wydajność i najmniej przykrych niespodzianek przy skalowaniu platformy danych.
Jak format wpływa na koszt zapytań, storage i sieci
Wybór formatu bardzo szybko przekłada się na twarde metryki: czas trwania zapytań, obciążenie klastra, koszty storage’u i transferu między strefami czy usługami. Różnice, które na małych zbiorach wydają się kosmetyczne, przy dziesiątkach terabajtów potrafią zmienić rachunek za chmurę o całe rzędy wielkości.
Najłatwiej zobaczyć to na trzech osiach: objętość danych na dysku, ilość rzeczywiście odczytanych bajtów oraz liczba przerobionych rekordów.
- Avro – kompresja jest sensowna, ale bez kolumnowego upakowania. Dla tabel szerokich, z licznymi kolumnami o małej entropii, przegrywa z Parquet/ORC zarówno rozmiarem, jak i realnym I/O. Jeżeli zapytania dotykają 5 z 80 kolumn, Avro wymusza de facto odczyt wszystkiego.
- Parquet – zwykle najlepszy kompromis między rozmiarem a uniwersalnością. Dobrze dobrana wielkość row group (zwykle 128–512 MB) i kodeki kompresji (snappy, zstd) powodują, że ilość odczytanych danych przy typowych zapytaniach analitycznych jest niewielka w stosunku do całej tabeli.
- ORC – w środowiskach Hive/Hadoop potrafi kompresować jeszcze agresywniej niż Parquet, szczególnie na danych silnie ustrukturyzowanych i z dobrym podziałem na partycje. Hive umie lepiej wykorzystać stripe-level statystyki ORC niż Parquetowe metadane.
Jeżeli rozliczanie odbywa się „per skan danych” (modele typu pay-per-scan w chmurowych DWH), kolumnowe formaty prawie zawsze wygrywają. Nawet jeżeli Avro jako warstwa RAW jest nieco tańszy w ingestcie, to długoterminowo koszt odpytywania takich danych będzie wielokrotnie wyższy. Sensowny kompromis to trzymanie krótkiej historii w Avro (np. ostatnie tygodnie pod kątem reprocessingu) i długiej historii w Parquet/ORC.
Różnica pojawia się również w kosztach sieci. Dla pipeline’ów, które replikują dane między regionami lub chmurami, mocniejsza kompresja Parquet/ORC może realnie zmniejszyć rachunek za transfer. Przy takich scenariuszach nawet niewielkie zyski procentowe przekładają się na dużą oszczędność, jeśli replikacja jest stała i dotyczy wielu tabel.
Strategie warstwowania formatów w jeziorze danych
Jedno środowisko rzadko opiera się na pojedynczym formacie; dużo częściej widać spójne kombinacje. Kluczową rolę odgrywa tu architektura warstwowa: od ingestu, przez „brudne” dane surowe, po strefę oczyszczoną i modele analityczne.
Popularny jest wzorzec trzech–czterech warstw, gdzie każdy poziom ma nieco inne wymagania i – co za tym idzie – inne preferencje formatowe.
- Warstwa RAW / Landing – dominują Avro, JSON lub format natywny źródła (np. CSV z systemu legacy). Dane są zrzucane możliwie szybko i wiernie, bez ingerencji w strukturę. Avro z rejestrem schematów ułatwia tu zachowanie kontraktów w czasie oraz późniejszą reinterpretację zdarzeń.
- Warstwa Cleansed / Curated – tu zaczynają królować formaty kolumnowe: Parquet albo ORC. Schematy są uporządkowane, pola znormalizowane, typy dopasowane do analityki. Pliki bywają przepisane do większych „segmentów”, aby unikać problemu małych plików.
- Warstwa Semantic / Mart – format najczęściej pozostaje kolumnowy, ale oprócz „gołego” Parquet/ORC wchodzą w grę warstwy zarządzające tabelami: Delta Lake, Apache Iceberg, Apache Hudi. To one dokładają transakcyjność, time travel, updaty i delety.
Różne warianty tej architektury rozkładają akcenty nieco inaczej. W środowiskach nastawionych na streaming pierwsza warstwa jest w praktyce strumieniem w Avro, Snapshoty RAW powstają z kompaktowania tych strumieni, a Parquet/ORC jest celem okresowych jobów agregujących i denormalizujących.
Jeżeli natomiast dominują batchowe integracje z systemów ERP/CRM (pliki dzienne, eksporty z baz), czasem szybciej jest przejść bezpośrednio z CSV/JSON do Parquet, a Avro traktować tylko jako pomocniczy format w nielicznych integracjach streamingowych.
Format a ewolucja schematu: teoria kontra praktyka
Ewolucja schematu to obszar, gdzie różnice między Avro, Parquet i ORC są szczególnie wyraźne. Sama możliwość dodania kolumny to jedno; drugie pytanie brzmi: kto i jak rozumie te zmiany – producent, konsument i silnik zapytań.
Avro ma wbudowaną, formalnie opisaną logikę kompatybilności schematów. Definiuje jasne zasady: kiedy nowy schemat jest kompatybilny wstecz, wprzód lub w pełni. Dzięki temu rejestr schematów może automatycznie odrzucić niebezpieczną zmianę (np. usunięcie obowiązkowego pola bez wartości domyślnej), zanim jeszcze dane trafią do Kafki.
Parquet i ORC patrzą na ewolucję bardziej z perspektywy tabeli niż transportu. Z technicznego punktu widzenia dopisywanie nowych kolumn do istniejących plików jest możliwe, ale najczęściej kończy się powstaniem nowej wersji schematu na poziomie metadanych tabeli (Glue, Hive Metastore, katalog Iceberg/Delta). Starsze pliki fizycznie nie znają nowych kolumn, więc silniki interpretują brakujące wartości jako NULL.
W praktyce rozwijają się dwa modele:
- „Schema-on-read” – nowe kolumny pojawiają się w definicji tabeli, a silnik przy odczycie mapuje fizyczne pliki do aktualnego schematu. Starsze pliki mają mniej kolumn, ale to warstwa SQL-owa troszczy się o wypełnienie braków NULL-ami. Tak działają klasyczne tabele Parquet/ORC w Hive czy Glue.
- „Schema-on-write” z kontrolą wersji – warstwa zarządzająca tabelami (Iceberg, Hudi, Delta) śledzi zmiany schematu, wersjonuje je i pilnuje, aby operacje DML były spójne z aktualnym kontraktem. To zbliża świat kolumnowy do „avrowej” dyscypliny schematów, ale przenosi kontrolę z warstwy transportowej na storage.
W systemach z silnym naciskiem na zgodność kontraktów między mikroserwisami wygodniej zarządza się schematem na wejściu, czyli w Avro + Registry. Tam powstaje „źródłowa” definicja rekordu zdarzenia. Świat Parquet/ORC, razem z Icebergiem czy Deltą, przejmuje pałeczkę, gdy dane wchodzą w życie jako tabele analityczne i zaczynają podlegać innym regułom – deprecjacjom kolumn, migracjom typów, zmianom granularity.
Format a silnik tabel transakcyjnych w jeziorze danych
Nowoczesne lakehouse’y rzadko operują na „gołym” Parquet/ORC. Najczęściej do gry wchodzą formaty tabelaryczne, które dodają warstwę metadanych i transakcyjność: Delta Lake, Apache Iceberg, Apache Hudi. Sam wybór Avro/Parquet/ORC staje się wtedy jednym z parametrów, ale nie jedynym rozstrzygającym o wydajności.
Podejście tych silników jest podobne: logiczna tabela składa się z wielu plików w formacie kolumnowym (zazwyczaj Parquet, czasami ORC lub Avro), a obok stoi dziennik commitów opisujący, które pliki wchodzą aktualnie w skład „widoku” tabeli. Różnice pojawiają się w zdarzeniach typu upsert, delete, merge oraz obsłudze time travel.
Delta Lake i Iceberg niemal domyślnie opierają się na Parquet. Dzięki temu korzystają z uniwersalności Parquetu w różnych silnikach: Spark, Trino, Flink, Dremio i wielu komercyjnych platformach. ORC bywa obsługiwany, lecz zwykle jako opcja mniej eksponowana – wygodniejsza, jeśli ekosystem i tak jest „hadoopowy”.
Hudi jest bardziej elastyczny, ale w praktyce również dominuje wariant z Parquet jako formatem fizycznym i czasem Avro jako formatem dla logów zmian. To kolejny przykład świadomego łączenia zalet: Parquet jako magazyn dla „snapshotów”, Avro jako nośnik strumieni zmian do szybkiego odtwarzania historii.
W tego typu architekturach decyzja „Parquet czy ORC” rzadko jest strategiczna sama w sobie. Istotniejsze jest, czy dany silnik tabel transakcyjnych dobrze wspiera wybrany format, czy optymalizator zapytań potrafi wykorzystać jego metadane, oraz jaki jest ekosystem narzędzi do zarządzania i obserwowalności. Format staje się wtedy elementem układanki zamiast głównego bohatera.
Wpływ formatu na wzorce partycjonowania i organizację plików
Kwestia formatu nie kończy się na tym, w jakim pliku zapisany jest jeden rekord. Równie ważna jest organizacja plików na poziomie katalogów, partycji i rozmiarów. Parquet i ORC dają tu szersze pole manewru niż Avro, bo ich kolumnowa natura lepiej znosi szerokie rekordy i rzadziej karze za dodatkowe kolumny techniczne.
Typowe problemy to:
- Małe pliki – setki tysięcy małych plików Parquet/ORC dramatycznie obciążają metastore i system plików. Silniki muszą otworzyć, sprawdzić metadane i ewentualnie odrzucić każdy plik, nawet jeśli ostatecznie nie wczytają z niego ani jednego wiersza.
- Zbyt drobne partycje – dzielenie po dacie+godzinie+regionie+kanale szybko prowadzi do partycji, w których znajdują się pojedyncze pliki. W Avro objawia się to marnowaniem miejsca na nagłówki kontenerów i narzut operacyjny, w Parquet/ORC dodatkowo podcina efektywność kompresji i statystyk.
- Brak kompaktowania – szczególnie przy ingestcie streamingowym dane dopisują się w małych porcjach. Bez okresowego scalania w większe pliki row group/stripe silniki tracą zalety kolumnowości i zaczynają zachowywać się tak, jakby czytały „losową kupkę małych plików”.
W środowiskach, gdzie miksuje się Avro i Parquet/ORC, często pojawia się podział ról: Avro w warstwie RAW akceptuje „brudny” podział na małe pliki dochodzące z Kafki, natomiast w warstwie analitycznej joby ETL/ELT dokonują kompaktowania i przejścia do dużych plików kolumnowych z logicznym partycjonowaniem (np. po dacie i wybranych wymiarach biznesowych).
Różnica między Parquet a ORC bywa subtelna, ale w niektórych środowiskach Hive ORC radzi sobie lepiej z szerokimi stripe’ami i statystykami na ich poziomie. Parquet z kolei daje większą swobodę w mieszanych środowiskach, gdzie część zapytań pochodzi z narzędzi BI przez Presto/Trino, część ze Sparka, a część z platform SaaS. W takich warunkach łatwiej dobrać wspólne konwencje partycjonowania i kompaktowania wokół Parquetu.
Bezpieczeństwo, maskowanie i zgodność z regulacjami
Format pliku wpływa również na to, jak łatwo wdrożyć maskowanie danych, szyfrowanie oraz mechanizmy spełniające wymagania RODO lub innych regulacji. Sam fakt, że dane są w Avro czy Parquet, nie decyduje o zgodności, ale może ułatwiać lub utrudniać konkretne wdrożenia.
W obszarze szyfrowania na poziomie storage’u (KMS, szyfrowanie bucketów) wszystkie formaty są traktowane podobnie. Różnice ujawniają się przy bardziej granularnych mechanizmach, jak szyfrowanie wybranych kolumn czy dynamiczne maskowanie.
- Avro – jako format wierszowy, jest wygodny do operacji na poziomie całego rekordu (np. pseudonimizacja całego eventu). Manipulacja pojedynczymi polami w środku rekordu wymaga jednak deserializacji i ponownej serializacji, co przy budowie systemów near-real-time może zwiększać opóźnienia.
- Parquet/ORC – kolumnowa natura ułatwia rozdzielenie danych wrażliwych i niewrażliwych. Można np. przechowywać identyfikatory użytkowników w osobnej kolumnie lub nawet w osobnym pliku/partycji, stosować inne polityki kompresji, szyfrowania i kontroli dostępu właśnie na poziomie kolumn czy partycji.
W praktyce często spotykany jest wzorzec: w Avro przechowywane są surowe zdarzenia z możliwie ograniczonym zestawem danych wrażliwych (lub ich natychmiastową pseudonimizacją), natomiast w warstwie Parquet/ORC buduje się „widoki” dopasowane do konkretnych ról – zmaskowane wersje kolumn, osobne tabele dla zespołów z różnymi poziomami uprawnień, a nad tym wszystkim – polityki row/column-level security w narzędziach BI lub silnikach lakehouse’owych.
Formaty kolumnowe współgrają tu dobrze z narzędziami do zarządzania danymi (Data Governance). Statystyki kolumnowe pomagają zidentyfikować zakres wartości, wycieki wyjątków czy próby nieautoryzowanego użycia rzadkich identyfikatorów. W Avro równie dużo informacji da się wyciągnąć, ale wymaga to intensywniejszego przetwarzania całości rekordów, co z kolei podnosi koszt audytów i profilowania.
Porównanie typowych scenariuszy zastosowań
Różnice między Avro, Parquet i ORC najlepiej widać, gdy zestawi się je w konkretnych scenariuszach. Każdy z nich zyskuje przewagę w innych warunkach.
W praktyce najczęściej pojawiające się scenariusze to:
- Event sourcing i kolejki zdarzeń – Avro jest tu naturalnym wyborem. Dobrze kompresuje się w sekwencjach wielu małych rekordów, integruje się z rejestrami schematów i pozwala negocjować kontrakt między producentem a konsumentem. Parquet ani ORC nie są projektowane pod miliony drobnych zdarzeń w locie; ich siła ujawnia się dopiero po zmaterializowaniu zdarzeń w postaci większych batchy.
- Hurtownie i zapytania ad-hoc – Parquet i ORC wyraźnie wygrywają, gdy użytkownicy wykonują zmienne zapytania z filtrami po wielu kolumnach, agregacjami, joinami. Kolumnowość redukuje I/O, a statystyki minimalizują zakres czytanych danych. Avro staje się wtedy głównie formatem pośrednim lub archiwalnym, bo wymaga wczytania całych rekordów, nawet gdy potrzebne są 2–3 kolumny.
- Analityka czasu rzeczywistego – gdy liczy się małe opóźnienie i prosty pipeline (Kafka → Flink/Spark → widok operacyjny), Avro sprawdza się na wejściu, a na wyjściu coraz częściej i tak pojawia się Parquet lub ORC dla „prawie on-line” raportów. Jeśli system raportowy ma operować bezpośrednio na gorących danych, wygodniej mieć je już w formacie kolumnowym.
- Ekosystem zdominowany przez Hive/Hadoop – ORC potrafi dać nieco lepsze osiągi niż Parquet dzięki głębszej integracji z Hive, zwłaszcza w przypadku szerokich tabel i silnie zdenormalizowanych modeli. Tam, gdzie prym wiodą Spark, Trino lub narzędzia BI, bezpieczniejszym wyborem jest Parquet ze względu na szersze wsparcie.
Na poziomie zespołu często powstają dwa uzupełniające się „standardy złotej ścieżki”. Pierwszy dotyczy przetwarzania zdarzeń: Avro, schematy wersjonowane w Schema Registry, kontrakty API, zasady kompatybilności i retencji. Drugi opisuje świat analityki: Parquet (lub ORC) jako format bazowy, konwencje partycjonowania, minimalne i maksymalne rozmiary plików, sposób kompaktowania oraz reguły ewolucji schematu w tabelach. Świadome trzymanie się dwóch ścieżek pozwala uniknąć chaosu, w którym każdy strumień i każda tabela ma inne, nieprzemyślane parametry.
Dobierając format, opłaca się osobno zadać trzy pytania: jak dane powstają, jak będą używane dziś i jak mogą być używane za rok. Gdy źródłem są mikrousługi i kolejki – presja rośnie w stronę Avro i czytelnej kontroli schematu. Gdy dominują analitycy BI, którzy filtrują po kilkunastu kolumnach, zwykle wygrywa Parquet lub ORC, spięte z delta/icebergowym silnikiem tabel. Gdy pojawia się mieszany scenariusz – strumień + batch + uczenie maszynowe – najczęściej kończy się na trio: Avro w ingestcie, Parquet jako warstwa „prawdy analitycznej”, a nad nimi lakehouse z zarządzaniem wersjami.
Świat Big Data rzadko nagradza jednolite, dogmatyczne decyzje. Format pliku jest jednym z kluczowych parametrów, ale dopiero w zestawieniu z silnikiem zapytań, sposobem ewolucji schematu, partycjonowaniem i wymaganiami regulacyjnymi widać pełny obraz. Dobrze dobrane połączenie Avro, Parquet i ORC nie tyle „przyspiesza” system, co usuwa zbędne tarcia – pozwala skupić się na problemach biznesowych, a nie na walce z infrastrukturą.
Format pliku a uczenie maszynowe i feature store’y
Modele ML zazwyczaj nie trenują się bezpośrednio na surowych eventach, tylko na przetworzonych, zintegrowanych cechach. Na tym etapie wybór formatu ma inne priorytety niż przy ingestcie czy klasycznym BI: liczy się powtarzalność, szybkość ładowania danych do pamięci oraz możliwość pracy na wielu wersjach cech jednocześnie.
Przy bliższym spojrzeniu różnice między formatami są wyraźne:
- Avro częściej pojawia się w warstwie „operacyjnej” ML – przy strumieniowym wyliczaniu cech, przekazywaniu ich między systemami (np. między Flinkiem a online feature store’em) oraz archiwizacji zdarzeń treningowych. Pliki Avro dobrze nadają się do odtwarzania historii zdarzeń, z której ponownie konstruuje się cechy.
- Parquet jest naturalnym wyborem do offlinowego trenowania modeli. Kolumnowy układ pasuje do sposobu, w jaki biblioteki ML (Spark MLlib, XGBoost, LightGBM czy biblioteki Pythonowe przez Arrow) ładują wybrane cechy do pamięci. Filtruje się wtedy zarówno po czasie, jak i po wybranych kolumnach – Parquet skraca ten proces.
- ORC lepiej współgra z ekosystemem Hive’owym używanym w starszych platformach analitycznych, gdzie także trenuje się modele, ale jego znaczenie w nowoczesnych feature store’ach bywa mniejsze niż Parquet, głównie przez słabsze wsparcie poza światem Hadoop/Hive.
W praktyce często powstaje dualny układ: zdarzenia w Avro, z których silniki streamowe wyliczają cechy w locie, oraz warstwa Parquet jako „offline feature store” – zmaterializowane, zdenormalizowane cechy, gotowe do szybkiego podpięcia pod trenowanie. ORC bywa wykorzystywany zwłaszcza tam, gdzie już istnieją duże klastry Hive i łatwiej dopasować się do istniejącej infrastruktury niż ją przeprojektować.
Różnica między Parquet a Avro staje się szczególnie widoczna przy iteracyjnym trenowaniu. Przy każdym nowym eksperymencie trzeba kilkukrotnie odczytać ten sam zestaw cech. Ładowanie ich z Parquetu oznacza mniejszy ruch I/O i krótszy czas startu eksperymentów, co przy kilkudziesięciu iteracjach dziennie przekłada się na realne oszczędności czasu i kosztów klastrowych.
Formaty a silniki lakehouse’owe i tabele z zarządzaniem wersjami
Lakehouse’y (Delta Lake, Apache Iceberg, Apache Hudi) zmieniły dyskusję o formatach, ale jej nie zastąpiły. Te systemy w większości opierają się na kolumnowych formatach fizycznych, a różnice kryją się w warstwie metadanych, zarządzania transakcjami i wersjonowania tabel.
Dwa układy spotykane najczęściej to:
- Parquet jako format bazowy + warstwa lakehouse’owa – najpopularniejszy wariant, szczególnie przy Delta Lake i Iceberg. Parquet pełni rolę „nośnika kolumn”, a zarządzanie transakcjami, wersjami i schema evolution obsługuje silnik tabel. W tym modelu większość decyzji o formacie zostaje „zamrożona” na Parquecie, a optymalizację przesuwa się na poziom układu plików (clustering, z-order, sortowanie).
- ORC w ekosystemach silnie powiązanych z Hive – Hudi i Iceberg potrafią pracować z ORC, co bywa atrakcyjne w długowiecznych instalacjach Hadoopowych. Tam, gdzie dominują narzędzia typu Spark/Trino/BI SaaS, i tak zwykle wygrywa Parquet, ze względu na bardziej zrównoważone wsparcie w wielu runtime’ach.
Avro w lakehouse’ach spełnia raczej rolę formatu wejściowego lub archiwalnego. Dane trafiają w Avro do strefy RAW, następnie batch lub mikro-batch przepisuje je do Parquet/ORC zarządzanych przez silnik lakehouse’owy. Rzadko buduje się tabele Delta/Hudi/Iceberg z Avro jako formatem fizycznym, bo kolumnowy layout jest zbyt dużą przewagą w codziennych zapytaniach.
Jeśli zespół przechodzi z „czystego” data lake’a do lakehouse’a, dobrym krokiem jest inwentaryzacja formatów. Zwykle kończy się to na dwóch decyzjach: uniformizacja formatu kolumnowego (Parquet lub ORC) oraz ograniczenie Avro do ingestu i kilku wybranych przypadków archiwizacji. Takie porządkowanie redukuje liczbę kombinacji: zamiast „format × engine × warstwa” zostaje świadoma siatka: Avro+Schema Registry na wejściu, Parquet/ORC+lakehouse w analityce.
Wpływ wyboru formatu na koszty chmury
W środowiskach on-prem decyzje o formacie są często napędzane wydajnością. W chmurze równie istotny staje się rachunek finansowy: liczba odczytów z obiektowego storage’u, czas pracy klastrów obliczeniowych, koszty przechowywania kopii oraz klasy storage’u (Standard, Infrequent Access, Glacier/Archive).
Kontrast między formatami widać w kilku obszarach.
- Wielkość danych na dysku – Avro, jako format wierszowy, kompresuje się gorzej w scenariuszach analitycznych, gdzie występuje wiele powtarzalnych wartości w kolumnach. Parquet i ORC potencjalnie osiągają mniejszy rozmiar końcowy przy dobrze dobranym kodeku (SNAPPY, ZSTD, GZIP) i grupowaniu kolumn, co zmniejsza koszty storage’u.
- Odczyty z S3/GCS/ADLS – w formatach kolumnowych silniki wczytują mniej bloków z dysku dla tego samego zapytania. Mniej odczytanych bajtów to mniejsze opłaty za I/O i krótszy czas działania jobów, co przekłada się na niższe koszty klastrów (EMR, Dataproc, Synapse, Databricks).
- Retencja długoterminowa – dla archiwów, do których rzadko się zagląda, Avro ma przewagę prostoty. Jedna kopia eventów w Avro, zrzucana do klasy „archive”, bywa tańsza niż utrzymywanie równoległych warstw Parquet/ORC, o ile nikt nie wykonuje na tych danych regularnych zapytań.
W projektach, gdzie co miesięczny rachunek z chmury jest tematem zarządczym, proste eksperymenty A/B z formatami potrafią przynieść kilkunastoprocentowe różnice w kosztach. Ten sam raport wczytywany z Avro vs Parquet może wymagać innych rozmiarów klastra i innej liczby odczytów z obiektowego storage’u.
Strategie migracji między formatami
Rzadko udaje się „od razu” trafić w idealny format. Częściej startuje się z jednym (np. Avro wszędzie), a po kilku miesiącach rosnących wolumenów i nowych wymagań zapadnie decyzja o migracji do Parquet lub ORC na warstwie analitycznej. Taka zmiana bywa bolesna, jeśli zabraknie planu.
W praktyce stosowane są trzy główne podejścia.
Przepisywanie historyczne jednym dużym jobem
Ta strategia zakłada uruchomienie jednorazowego, dużego joba, który odczyta wszystkie dane z istniejącego formatu i zapisze w nowym. Daje najszybszy efekt, ale generuje skokowe obciążenie klastrów i storage’u.
- Zalety – prosta logika, łatwe testy spójności (stare vs nowe), jednoznaczny moment przełączenia. Łatwiej też od razu wprowadzić poprawne partycjonowanie i kompaktowanie.
- Wady – wysoki jednorazowy koszt obliczeniowy, ryzyko ograniczeń przepustowości (limity API w S3/GCS), konieczność zsynchronizowania przełączki ze wszystkimi konsumentami danych.
To podejście sprawdza się, gdy wolumen historyczny jeszcze nie jest ogromny, a liczba tabel/strumieni ograniczona. Typowy przykład: 2–3 lata zdarzeń logowych w Avro, które można przeliczyć na Parquet w ciągu jednego lub kilku dni na powiększonym klastrze.
Migracja przyrostowa z „podwójnym zapisem”
Wersja bardziej ostrożna polega na tym, że od pewnego dnia nowe dane są zapisywane równolegle w dwóch formatach, a historia jest migrowana przyrostowo w tle, porcjami. Konsumenci stopniowo przechodzą na nowy format, tabela po tabeli.
- Zalety – mniejsze ryzyko dużej awarii, brak konieczności jednego „freeze” produkcji. Można równolegle weryfikować różnice w wynikach zapytań, zanim całkowicie odetnie się stary format.
- Wady – czasowo rośnie powierzchnia storage’u (podwójny zapis), a zespół musi utrzymywać dwa warianty pipeline’u. Ryzyko pomyłek w analizach, gdy część użytkowników pracuje na starym, a część na nowym formacie.
W tym modelu Avro często zostaje na wejściu (Kafkowe eventy), natomiast przetwarzanie batch zmienia się tak, aby z jednego strumienia RAW generować zarówno starą, jak i nową warstwę analityczną przez okres przejściowy.
Selektor formatu na poziomie widoków
Trzecia opcja polega na wprowadzeniu abstrakcji: użytkownicy i aplikacje odwołują się nie do plików, lecz do widoków lub tabel logicznych. Pod spodem administrator stopniowo podmienia format i lokalizację danych, zachowując ten sam „adres” logiczny.
W wariancie z Hive/Metastore oznacza to migrację plików i aktualizację definicji tabel. W światach lakehouse’owych polega na zbudowaniu nowej tabeli (np. Iceberg) z Parquetem i przekierowaniu zapytań z poprzedniej lokalizacji na nową. Dzięki temu migracja może przebiegać tabelami i nie wymaga jednego globalnego przełącznika.
Formaty a integracja z narzędziami BI i eksploracją ad-hoc
Klasyczne narzędzia BI (Tableau, Power BI, Looker, Superset) dobrze dogadują się z Parquetem i ORC przez warstwę silników SQL (Presto/Trino, Spark SQL, Hive, BigQuery External Tables, Athena). Różnice między formatami wpływają więc na komfort pracy analityków pośrednio – przez szybkość odpowiedzi i stabilność zapytań.
Porównując doświadczenie „końcowego” użytkownika:
- Avro jako format źródłowy raportów – wymaga wczytania pełnych rekordów przez silnik i prowokuje do budowy dodatkowych warstw pośrednich (widoki materializowane, tabele agregujące). Zapytania ad-hoc na surowych plikach Avro są możliwe, ale powolne, co zniechęca do eksploracji.
- Parquet – umożliwia szybkie prototypowanie raportów. Analityk może rozpocząć od prostych filtrów, a potem stopniowo dodawać joiny i agregacje. Silniki kolumnowe skutecznie ograniczają zakres skanowanych bloków, więc koszt błędnych lub eksperymentalnych zapytań jest niższy.
- ORC – w środowiskach Hive’owych bywa równie szybki co Parquet, a czasem lepszy przy bardzo szerokich tabelach. Jednak poza tym światem wielu dostawców narzędzi BI najpierw optymalizuje pod Parquet, co powoduje, że ORC zostaje w lekkim cieniu.
Jeżeli zespół BI narzeka na „wolny lake”, jedną z pierwszych diagnoz bywa sprawdzenie, ile zapytań uderza bezpośrednio w Avro, a ile w Parquet/ORC. Nawet częściowe przeniesienie najczęściej wykorzystywanych zestawów danych do formatu kolumnowego potrafi wyraźnie poprawić odczuwaną wydajność.
Specyfika obsługi typów złożonych i półstrukturalnych
Współczesne dane rzadko są idealnie tabelaryczne. Pojawiają się gniazdowe struktury JSON, mapy, listy, czasem wręcz całe dokumenty XML osadzone w jednym polu. Format i jego implementacja mają spory wpływ na to, jak wygodnie będzie się na nich pracowało.
- Avro ma naturalne wsparcie dla rekordów zagnieżdżonych, union types, map i array. Świetnie pasuje do eventów zawierających np. listę atrybutów produktu, dynamiczne pola kontekstowe czy opcjonalne części payloadu. To dlatego często staje się „kontenerem” dla tego, co pochodzi z REST-ów lub JSON-ów.
- Parquet obsługuje typy złożone (LIST, MAP, STRUCT), ale ich reprezentacja w konkretnych silnikach bywa różna. Spark, Hive, Presto czy Impala mają własne niuanse, np. w obsłudze pustych list czy nulli w zagnieżdżonych polach. To powoduje, że modelowanie złożonych struktur wymaga dyscypliny schematowej i testów między-silnikowych.
- ORC również radzi sobie z typami zagnieżdżonymi, a w parze z Hive’em jest dobrze dopracowany pod kątem operacji na strukturach i mapach. Jednak, podobnie jak przy Parque-cie, przenoszenie tych samych plików ORC między różnymi runtime’ami może odsłonić różnice w interpretacji typów.
W projektach, gdzie dane półstrukturalne są standardem, sprawdza się następujące podejście: przechowywanie surowych zdarzeń w Avro z pełnym, bogatym schematem, a w warstwie Parquet/ORC – selektywne „spłaszczanie” tylko tych pól, które rzeczywiście są potrzebne analitykom lub modelom ML. Pozostała część oryginalnego payloadu może zostać przeniesiona do jednej kolumny JSON jako pole dodatkowe, ale wtedy traci się korzyści z kolumnowości dla tej części danych.
Dobór kodeków kompresji w zależności od formatu
Format pliku jest ściśle związany z wyborem kodeka kompresji. Ten sam kodek (np. SNAPPY) zachowuje się inaczej w układzie wierszowym (Avro) niż kolumnowym (Parquet/ORC). Przydatne jest zrozumienie ogólnych trendów, nawet jeśli ostateczny wybór i tak trzeba potwierdzić testami.
W praktyce najczęściej testuje się kilka kombinacji: AVRO+SNAPPY vs AVRO+DEFLATE, PARQUET+SNAPPY vs PARQUET+ZSTD itd., porównując trzy liczby jednocześnie – wagę danych, czas zapisu oraz szybkość typowych zapytań.
Avro w połączeniu ze SNAPPY lub DEFLATE sprawdza się w strumieniach, gdzie ważna jest przyzwoita kompresja bez dramatycznego obciążenia CPU. SNAPPY bywa preferowany tam, gdzie zapis/odczyt odbywa się często i krótko (mikro-batche, kompaktowanie topiców), natomiast DEFLATE daje lepszy współczynnik kompresji kosztem wolniejszego przetwarzania. Przy dużej liczbie małych plików różnice w narzucie CPU są bardziej odczuwalne niż przy rzadkich, dużych batchach.
Parquet najczęściej łączy się z SNAPPY lub ZSTD. W wielu klastrach SNAPPY jest „bezpiecznym domyślnym” wyborem: umiarkowany poziom kompresji, szybki odczyt, dobre wsparcie narzędzi. ZSTD wchodzi do gry, gdy priorytetem staje się zmniejszenie kosztów storage’u i przesyłu sieciowego przy relatywnie ciężkich kolumnach (np. długie stringi, JSON-y w kolumnie). Przy szerokich tabelach faktów z setkami miliardów rekordów różnica w zajętości może przełożyć się na istotne oszczędności, choć czas zapisu batcha bywa nieco dłuższy.
W ORC często wykorzystuje się ZLIB lub ZSTD, zwłaszcza w klasycznych instalacjach Hive’a, gdzie długotrwałe joby ETL są akceptowalne, a kluczowy jest mały rozmiar danych w HDFS. Tam, gdzie ORC stanowi warstwę do interaktywnych zapytań przez Trino lub Presto, wiele zespołów świadomie przestawia się na SNAPPY, godząc się na nieco większe pliki w zamian za szybsze skany. Widać więc typowy kompromis: kodeki „cięższe” (ZLIB, ZSTD przy wysokim poziomie kompresji) wygrywają na dysku, lecz przegrywają na CPU w scenariuszach interaktywnych.
Przy wyborze kodeka praktycznym podejściem bywa rozdzielenie strategii na warstwy: w RAW/bronze – raczej lekkie kodeki, bo dane często się przemielają; w warstwie raportowej i archiwalnej – agresywniejsza kompresja, skoro dane są rzadziej przepisywane. Takie proste rozdzielenie pomaga utrzymać rozsądny balans pomiędzy kosztami chmury, responsywnością zapytań a złożonością konfiguracji.
Świadomy wybór formatu pliku i kodeka kompresji przestaje być detalem technicznym, gdy skala rośnie z gigabajtów do petabajtów. To decyzje, które wpływają na rachunki za infrastrukturę, komfort pracy analityków i tempo eksperymentów danych. Im wcześniej zostaną oparte na konkretnych testach, a nie tylko na domyślnych ustawieniach narzędzi, tym stabilniej zachowa się cały ekosystem Big Data pod rosnącym obciążeniem.
Format pliku a koszty chmury i model rozliczeń
Format danych wpływa nie tylko na czas zapytań, lecz także na rachunki za chmurę. W modelach pay-per-query (Athena, BigQuery External Tables, niektóre warianty serverless) każdy niepotrzebnie zeskanowany gigabajt to realny koszt. W wariantach z długotrwale uruchomionymi klastrami (EMR, Dataproc, on‑prem Hadoop) silniejszy nacisk przechodzi z opłat za każde skanowanie na wykorzystanie CPU, RAM i powierzchni dyskowej.
Patrząc stricte ekonomicznie, formaty można porównać w trzech wymiarach: stopień kompresji, ilość danych czytanych „nadmiarowo” oraz koszt obliczeniowy odczytu.
- Avro – przyzwoita kompresja, ale brak kolumnowości powoduje, że przy prostych zapytaniach (kilka kolumn, wąski zakres filtrów) silnik często czyta cały rekord. Skala kosztów rośnie szybciej, gdy większość kolumn tabeli jest „martwa” z perspektywy analityki, ale i tak musi zostać wczytana.
- Parquet – najczęściej wygrywa w modelu pay-per-query. Skany ograniczają się do faktycznie używanych kolumn, a dodatkowo statystyki w ramach row-group pomagają ominąć całe bloki. Mniej danych przesłanych z S3/GCS/ADLS to niższe rachunki i krótszy czas zapytań.
- ORC – pod względem kompresji i redukcji rozmiaru plików potrafi być nawet lepszy od Parquet, zwłaszcza w klasycznych, szerokich tabelach faktów z danymi numerycznymi. Różnice w kosztach widać szczególnie w środowiskach, które pobierają opłaty za skanowanie danych w HDFS/S3, ale mniej za sam compute.
W praktyce widać dwa skrajne scenariusze. Zespoły o wysokiej intensywności eksploracji (wielu analityków BI, dużo zapytań ad‑hoc) bardziej odczuwają zalety formatu kolumnowego. W projektach nastawionych na batchowe przetwarzanie dużych porcji danych „raz na jakiś czas” koszty jednostkowego skanu są mniej istotne, a większe znaczenie ma prostota pipeline’u i niezawodność odczytu – tu Avro pozostaje atrakcyjne jako warstwa pośrednia.
Formaty a zarządzanie jakością i spójnością danych
W świecie rozproszonym błąd danych rzadko wynika z jednego spektakularnego incydentu. Częściej to drobne różnice w interpretacji typów, stref czasowych, nulli czy wartości domyślnych. Format pliku może minimalizować lub potęgować takie ryzyka.
Avro, Parquet i ORC reprezentują dwa różne podejścia do dyscypliny schematowej:
- Avro kładzie nacisk na jawny schemat, wyposażony w union types i wartości domyślne. Dzięki temu nietrudno wymusić, by każdy producent danych deklarował dokładnie, co wysyła, a konsument ma precyzyjną informację, jak odczytać stare i nowe rekordy. Sprawdzanie jakości danych (np. czy wszystkie eventy zawierają kluczowe pola) można wykonywać już na poziomie deserializacji.
- Parquet i ORC przechowują metadane schematu wewnątrz pliku, ale silniki SQL mają swoje własne warstwy mapowania typów. To rodzi dwa poziomy potencjalnych rozjazdów: interpretacja typu w pliku oraz interpretacja typu w tabeli (Hive/Metastore, katalog lakehouse’owy). Niewielka zmiana – np. konwersja INT na BIGINT – potrafi wyglądać niegroźnie, a w praktyce prowadzi do niespodzianek w joinach czy castach.
W podejściu „schemat jako kontrakt” często stosuje się mieszankę: Avro definiuje pierwszy, twardy kontrakt eventu lub rekordu źródłowego, a Parquet/ORC stają się artefaktami po transformacji już „ułożonej” pod analitykę. W takim modelu zmiany w Avro są ściśle kontrolowane przez data governance, a warstwa kolumnowa odpowiada za stabilność raportów i modeli ML.
Formaty w kontekście Lakehouse i tabel transakcyjnych
Pojawienie się warstw lakehouse’owych (Delta Lake, Apache Iceberg, Apache Hudi) przesunęło dyskusję z poziomu „jaki plik” na poziom „jaka tabela transakcyjna”, ale pod spodem wciąż leży konkretny format – najczęściej Parquet, rzadziej ORC. Avro w tej układance bywa używane w warstwie RAW lub jako format wejściowy, podczas gdy same tabele lakehouse’owe budowane są na kolumnowych blokach.
Porównując typowe połączenia:
- Delta Lake + Parquet – silna integracja ze Spark, popularne narzędzie do budowy warstw złota/srebra. Parquet zapewnia dobrą kompresję i wydajność skanów, a Delta dodaje ACID, time travel i mechanizmy vacuum. W wielu projektach jest to domyślna kombinacja dla głównego jeziora danych.
- Iceberg + Parquet/ORC – Iceberg pozwala świadomie wybrać format. Parquet dominuje w środowiskach z Trino/Presto i Flinkiem, ORC bywa wybierany w instalacjach głęboko osadzonych w ekosystemie Hive’a. Możliwość przełączania się między formatami ułatwia migracje i eksperymenty wydajnościowe.
- Hudi + Parquet – skierowany do przypadków z dużą ilością upsertów i powtarzających się aktualizacji. Parquet pozwala utrzymać rozsądny balans między kompresją a czasem zapisu, natomiast Avro pojawia się często jako format dla logów zdarzeń wspomagających re‑ingestion.
Format pliku w lakehouse przestaje być samodzielną decyzją – staje się parametrem całego systemu tabelarycznego. Zmiana z Parquet na ORC lub odwrotnie wymaga nie tylko przepisania danych, ale również ponownej analizy statystyk, partycjonowania, indeksów dodatkowych czy strategii compaction.
Wpływ formatu na projekt partycjonowania i layout plików
Partycjonowanie i layout plików to drugie pół decyzji wydajnościowych obok wyboru formatu. Nawet najlepszy format kolumnowy nie pomoże, jeśli cały rok danych trafi do jednego katalogu bez sensownego podziału, a każda partycja składa się z tysięcy malutkich plików.
Format narzuca kilka praktycznych różnic:
- Avro jest odporny na drobniejsze pliki, bo każda jednostka wiersza jest samodzielna. Jednak przesada w drugą stronę (setki tysięcy małych plików) zabija NameNode/HDFS i spowalnia listowanie katalogów w chmurze. Przy Avro granica akceptowalnej liczby plików bywa nieco wyżej niż przy Parquet/ORC, ale problem „small files” i tak wraca.
- Parquet i ORC preferują większe, gorzej „fragmentowane” pliki, ponieważ row-groups lub stripe’y zyskują wtedy na efektywności statystyk i kompresji. Typowe rekomendacje mówią o setkach megabajtów na plik, ale realne optimum zależy od narzędzi i charakterystyki zapytań.
Parquet i ORC umożliwiają dodatkową optymalizację w ramach pliku: układ sortowania wierszy wewnątrz row-group/stripe’u ma znaczenie. Jeśli dane są zgrupowane po najczęściej używanych filtrach (np. data, region), selektywne skany potrafią czytać znacznie mniej bloków. Avro nie korzysta z takiej kolumnowej lokalności – sortowanie pomaga głównie na poziomie partycji, a nie wewnątrz pliku.
W projektach, gdzie czas odpytywania ma priorytet, często stosuje się dwa komplementarne zabiegi:
- W RAW – Avro z prostym partycjonowaniem (np. data_ingest, system), aby maksymalnie uprościć ingest.
- W warstwie analitycznej – Parquet/ORC z możliwie stabilnym kluczem partycjonowania i świadomie dobranym rozmiarem plików, generowanym przez dedykowane joby compactujące.
Takie rozdzielenie pozwala łączyć zalety szybkiego przyjmowania dowolnych zdarzeń (Avro) z wydajnym skanowaniem w raportach i w modelach ML (Parquet/ORC), bez przerzucania całej złożoności na jedną warstwę.
Format pliku a przetwarzanie strumieniowe i batchowe
Podział „stream vs batch” nie pokrywa się idealnie z „Avro vs Parquet/ORC”, ale granice są dość wyraźne. W strumieniach liczy się nie tylko rozmiar danych, lecz także opóźnienie, liczba rekordów na sekundę, latencja w systemach kolejkowych i możliwość szybkiej ewolucji schematu.
W systemach typu Kafka, Pulsar czy Kinesis:
- Avro z rejestrem schematów (Confluent Schema Registry, Apicurio) jest jednym z najbardziej praktycznych formatów dla eventów: zdefiniowane typy, wbudowane zasady kompatybilności, kompaktowa binarna reprezentacja. Wsparcie w ekosystemie (connectory, serializery) upraszcza zarówno produkcję, jak i konsumpcję zdarzeń.
- Parquet/ORC praktycznie nie występują w samym strumieniu. Pojawiają się dopiero jako wynik mikro‑batchy (np. Structured Streaming w Sparku zapisujący co minutę) lub jako efekt compactowania logów do warstw analitycznych.
W wymiarze batchowym obraz jest inny: tam, gdzie liczą się długotrwałe przetworzenia dużych wolumenów, Avro ma sens jako format pośredni (np. pliki tymczasowe, staging), ale finalna warstwa raportowa zwykle korzysta z Parquet lub ORC, bo zyski z kolumnowości są bardziej wyraźne.
Dodatkowym czynnikiem jest wsparcie w narzędziach strumieniowych: Flink, Spark Structured Streaming, ksqlDB, Beam. Wszystkie dobrze „rozumieją” Avro na wejściu, ale ich natywne konektory do jezior danych preferują Parquet jako format docelowy. Zmuszanie strumieni do bezpośredniego zapisu ORC bywa możliwe, ale wymaga więcej pracy integracyjnej i nie zawsze przynosi mierzalny zysk.
Porównanie Avro, Parquet i ORC w typowych scenariuszach
Uproszczony sposób myślenia o tych trzech formatach to przypisanie im „typowych ról” w architekturze danych. Rzeczywistość jest bardziej złożona, ale takie mapowanie pomaga wstępnie wybrać kierunek.
Dla kilku często spotykanych scenariuszy:
- Event sourcing, logi aplikacyjne, integracja mikroserwisów
Avro wygrywa dzięki wsparciu dla ewolucji schematu, dobrej integracji z Kafka Connect i toolingiem do walidacji. Parquet/ORC pojawiają się dopiero na etapie odwzorowania logów na fakty/zdarzenia biznesowe. - Hurtownie analityczne, tabele faktów i wymiarów
Parquet jest najszerszym standardem, szczególnie gdy w grze są Spark, Trino/Presto, Hive, systemy lakehouse’owe czy silniki MPP w chmurze. ORC prezentuje pełnię możliwości w instalacjach heavily-Hive’owych, gdzie główne obciążenie realizują zapytania batchowe i długie joby ETL. - Eksploracja ad‑hoc, data discovery, eksperymenty ML
Parquet sprzyja iteracji – łatwo podłącza się do różnych narzędzi, jest dobrze wspierany przez środowiska notebookowe (PySpark, Pandas przez czytniki Arrow/Parquet), a kolumnowy układ daje szybkie czasy odpowiedzi przy filtrowaniu i selekcji niewielu kolumn. - Archiwizacja długoterminowa
ORC i Parquet oferują podobne, wysokie poziomy kompresji, zwłaszcza z agresywnymi kodekami. Wybór zależy bardziej od tego, który format jest naturalny dla głównego silnika zapytań, aby nie trzeba było stale wykonywać konwersji w locie.
W jednym z projektów e‑commerce prosty zabieg – przejście z Avro na Parquet w warstwie, z której korzysta BI – skrócił czas typowego zapytania raportowego z minut do kilkunastu sekund, przy jednoczesnym obniżeniu wolumenu danych w S3. Eventy dalej płynęły jako Avro, ale wszystko, co miało służyć agregacji i raportowaniu, zostało świadomie przełączone na format kolumnowy.
Strategie mieszane: łączenie formatów w jednej architekturze
Rzadko który system Big Data polega na jednym formacie „od wejścia do raportu”. Dużo częściej widać warstwowe podejście: inny format dla ingestu, inny dla przechowywania danych surowych, jeszcze inny dla raportów czy warstwy servingowej modeli.
Najczęstsze kombinacje:
- Avro w ingest + Parquet w warstwie oczyszczonej
Klasyczny duet. Avro z rejestrem schematów gwarantuje, że zdarzenia wejściowe są kontrolowane i walidowane. Po ETL/ELT dane lądują w Parquet, co otwiera drogę do szybkiej analityki i łatwej integracji z BI oraz narzędziami ML. - JSON/CSV w ingest + Avro jako pierwszy „poważny” format + Parquet/ORC w analityce
Spotykane tam, gdzie źródła są „legacy” i trudno wymusić wdrożenie Avro bezpośrednio na producentach. JSON/CSV szybko zamienia się jednak w Avro, aby przejść na bardziej uporządkowany tor, a dopiero kolejne kroki przygotowują kolumnową warstwę raportową. - ORC jako format domyślny dla Hive + Parquet dla narzędzi spoza świata Hadoop
W środowiskach, gdzie Hive jest głównym „koniem roboczym”, ORC daje najlepsze osiągi. Dla systemów zewnętrznych (np. silniki MPP w chmurze, niektóre narzędzia ML) utrzymuje się jednak kopie Parquet, aby uniknąć konwersji on‑the‑fly i problemów z kompatybilnością typów.
- Warstwa featurów / feature store
W przypadku cech dla modeli ML wygodny bywa kompromis: Parquet jako główny format referencyjny, a na brzegu – lekkie serializacje (Avro, JSON) dla serwisów on‑line. Ten sam zestaw cech może być więc trzymany kolumnowo pod batchowe trenowanie modeli, a jednocześnie udostępniany w bardziej „API‑przyjaznym” formacie dla inferencji w czasie rzeczywistym.
Strategie mieszane wymagają dyscypliny katalogowej i spójnego nazewnictwa. Jeśli jedna tabela ma trzy fizyczne reprezentacje (Avro RAW, Parquet CLEANSed, ORC AGG), przydają się jasne reguły: który katalog jest referencyjny, które ścieżki są tylko cache’em pod konkretny silnik, jak długo trzymamy duplikaty i co robić przy zmianach schematu. Chaos w tej warstwie szybko zjada zyski z dobrze dobranych formatów.
Dobrym wzorcem jest rozdzielenie odpowiedzialności: zespół platformowy definiuje dozwolone formaty i minimalne standardy (kompresja, ewolucja schematu, rejestr typów), a zespoły domenowe wybierają z tego katalogu, dostosowując wybór do własnych przepływów. Zamiast „każdy po swojemu” mamy ograniczony, ale elastyczny zestaw klocków, które da się składać w przewidywalny sposób.
Granica między formatami często przebiega też po osi „czas vs koszt”. Jeśli celem jest możliwie tani storage przy akceptowalnie wolnych zapytaniach, bardziej agresywna kompresja w Parquet/ORC i rzadkie przeliczenia mają sens. Gdy priorytetem jest niski czas odpowiedzi na analitykę samoobsługową, zwykle kończy się na większej liczbie materializowanych widoków w Parquet i częstszej przebudowie danych wyjściowych. Ten sam zestaw surowych eventów Avro może więc zasilać dwie zupełnie różne „twarze” hurtowni.
Świadome dobranie ról dla Avro, Parquet i ORC – zamiast ślepego trzymania się jednego „ulubionego” formatu – ułatwia projektowanie stabilnych, przewidywalnych platform danych. Format staje się wtedy narzędziem optymalizacji pod konkretne obciążenie, a nie przypadkowym skutkiem ubocznym użytego frameworka.
Najczęściej zadawane pytania (FAQ)
Jaki format pliku wybrać do analityki Big Data: Parquet, Avro czy ORC?
Do typowych hurtowni/analityki SQL lepszym wyborem jest format kolumnowy – Parquet albo ORC. Pozwalają one czytać tylko potrzebne kolumny, lepiej się kompresują i znacząco skracają czas zapytań oraz zmniejszają koszt klastra.
Avro sprawdza się głównie jako format „transportowy” i warstwa RAW: w integracjach z Kafką, w strumieniach zdarzeń i tam, gdzie dane są przetwarzane rekord po rekordzie. Jako główny format tabel analitycznych stosuje się go rzadziej, bo zwykle przegrywa wydajnością z Parquet/ORC w scenariuszach BI.
Czym różni się format kolumnowy (Parquet, ORC) od wierszowego (Avro) w praktyce?
W formatach wierszowych (Avro) każdy rekord jest zapisywany i odczytywany „w całości”. To wygodne, gdy logika przetwarzania operuje na większości pól jednocześnie lub dane płyną w strumieniu (np. logi zdarzeń z aplikacji).
W formatach kolumnowych (Parquet, ORC) dane są grupowane po kolumnach. Silnik zapytań może wtedy odczytać tylko te kolumny, które widnieją w SELECT i filtrach. To drastycznie ogranicza I/O, przyspiesza agregacje i joiny oraz poprawia kompresję, zwłaszcza przy dużych, szerokich tabelach.
Dlaczego Parquet i ORC są szybsze od CSV/JSON przy dużych danych?
CSV i JSON są tekstowe i wierszowe – do przetworzenia zapytania trzeba zaczytać i sparsować całe wiersze, nawet jeśli potrzebne są dwie kolumny. Dodatkowo brakuje w nich statystyk kolumnowych i optymalizacji pod skanowanie analityczne.
Parquet i ORC:
- przechowują dane binarnie, z bogatym schematem i typami,
- umożliwiają odczyt tylko wybranych kolumn,
- zawierają metadane i statystyki, które pozwalają silnikowi omijać całe bloki danych.
To zwykle przekłada się na wielokrotne skrócenie czasu zapytań względem „surowego” CSV/JSON.
Kiedy Avro jest lepszym wyborem niż Parquet lub ORC?
Avro wygrywa wtedy, gdy priorytetem jest przesyłanie i przechowywanie danych rekord po rekordzie, a nie szybkie skanowanie tabel. Typowe przypadki to: komunikacja między mikroserwisami, zdarzenia w Kafce, logi aplikacyjne, dane time-series analizowane „w locie”.
Jeśli większość operacji dotyczy wszystkich lub prawie wszystkich pól rekordu, korzyść z kolumnowości jest mniejsza. W takim scenariuszu prostszy odczyt całego rekordu z Avro bywa efektywniejszy, zwłaszcza w systemach strumieniowych.
Jak format pliku wpływa na koszty storage i klastra Big Data?
Format decyduje o tym, ile danych faktycznie leży na dysku i ile musi zostać przeczytane przez klaster. Parquet/ORC zwykle redukują rozmiar względem CSV kilkukrotnie dzięki kompresji kolumnowej, a podczas zapytań ograniczają I/O do niezbędnych kolumn.
Mniejszy rozmiar to:
- niższy koszt storage (HDFS, S3, GCS, ADLS),
- mniej transferu sieciowego między węzłami,
- mniejszy narzut CPU na parsowanie i deserializację.
Często zmiana formatu z CSV/JSON na Parquet/ORC daje większy spadek kosztów niż dalsze skalowanie klastra czy tuning Sparka.
Jakiego formatu użyć w różnych warstwach data lake / lakehouse?
W warstwie RAW (landing/bronze) dominują formaty zbliżone do źródła – JSON, CSV lub Avro. Liczy się tu szybki ingest i zachowanie pełnej wierności danych, często 1:1 względem systemu źródłowego lub strumienia zdarzeń.
Warstwy CURATED (silver) i ANALYTICAL (gold) najczęściej opiera się na Parquet lub ORC, często w połączeniu z tabelami typu Delta/Iceberg/Hudi. W CURATED przechowuje się oczyszczone i znormalizowane dane, a w ANALYTICAL – gotowe tabele faktów i wymiarów, zoptymalizowane pod BI i modele ML.
Jak rozpoznać, że „surowy CSV wszędzie” stał się problemem wydajności?
Typowe symptomy to:
- czasy zapytań rosną z minut do dziesiątek minut,
- konieczność ciągłego zwiększania rozmiaru klastra,
- zapytania ad hoc skanują setki gigabajtów, choć potrzebują kilku kolumn,
- zarządzanie zmianą schematu (nowe kolumny) staje się ryzykowne i uciążliwe.
W takich sytuacjach najczęściej wąskim gardłem jest warstwa plików tekstowych, a nie sam silnik obliczeniowy.
Typową i skuteczną reakcją jest konwersja dużych tabel z CSV/JSON do Parquet lub ORC, z jednoczesnym wprowadzeniem rozsądnego partycjonowania (np. po dacie). Zmiana formatu często od razu odczuwalnie skraca zapytania bez modyfikacji ich logiki.
Najważniejsze punkty
- Wybór formatu pliku w Big Data nie jest detalem technicznym, tylko decyzją wpływającą na wydajność całego łańcucha przetwarzania – od ingestu, przez storage i obliczenia, aż po narzędzia BI i notebooki analityczne.
- Formaty tekstowe (CSV, JSON) sprawdzają się przy małych wolumenach i prostych raportach, ale przy terabajtach danych i wielu równoległych zapytaniach stają się głównym wąskim gardłem wydajności.
- Formaty kolumnowe (Parquet, ORC) radykalnie redukują koszty storage, I/O, CPU i sieci, ponieważ kompresują dane efektywniej i pozwalają czytać tylko potrzebne kolumny zamiast całych wierszy.
- Skok z „wszędzie surowy CSV” na Parquet/ORC często daje większe przyspieszenie zapytań i spadek kosztów klastra niż dokładanie nowych węzłów czy agresywny tuning Sparka/Hive.
- W architekturze data lake/lakehouse różne warstwy korzystają z różnych formatów: RAW zwykle trzyma dane w JSON/CSV/Avro, natomiast warstwy CURATED i ANALYTICAL stawiają na kolumnowe Parquet/ORC zoptymalizowane pod analitykę.
- Avro dominuje w warstwie ingest/RAW (np. z Kafką i rejestrem schematów) dzięki dobrej obsłudze schematów i kompatybilności systemów, natomiast rzadko jest głównym formatem tabel analitycznych, gdzie lepiej sprawdzają się formaty kolumnowe.
- Reorganizacja warstwy danych (np. konwersja CSV → Parquet z prostym partycjonowaniem po dacie) jest często najtańszym i najbardziej efektywnym sposobem poprawy czasu odpowiedzi zapytań oraz stabilności pracy narzędzi BI.
