Apache Parquet: dlaczego rachunek za analitykę zależy od układu pliku

Dział finansów dystrybutora dodaje jeden pulpit: odsetek zwrotów po partii dostawcy, odświeżany co godzinę. Zapytanie dotyka trzech kolumn z czterdziestu w tabeli wysyłek. Następna faktura od silnika chmurowego jest wyraźnie wyższa, a oferowane wyjaśnienie brzmi „więcej zapytań”. Prawdziwe wyjaśnienie jest w plikach: tabelę zapisywał strumień w małych plikach, nigdy niekompaktowanych i niesortowanych, a każde godzinne odświeżenie czyta większość z nich.

Apache Parquet jest formatem plików pod niemal każdą tabelą lakehouse — Delta Lake, Apache Iceberg, Apache Hudi i Apache Paimon domyślnie przechowują w nim wiersze. Jego opinia taniej analityki jest zasłużona, ale warunkowa. Rachunek zależy od tego, jak pliki są ułożone, a układ to zestaw decyzji, które ktoś musi podjąć i podejmować dalej. Czym Parquet jest obok bazy operacyjnej i dlaczego lakehouse jest drugą pamięcią, a nie kopią pierwszej, opisuje przewodnik serii.

Co jest w środku pliku Parquet

Specyfikacja formatu ma wersję 2.14.0 (wrzesień 2026, sprawdzono 21.10.2026). Plik to ciąg grup wierszy. Każda grupa wierszy trzyma jeden kawałek kolumny na kolumnę, każdy kawałek to ciąg stron, a stopka — zapisywana na końcu, więc plik powstaje w jednym przebiegu — trzyma schemat, położenie każdego kawałka i jego statystyki. Dla kosztu liczą się jeszcze trzy struktury:

Statystyki i indeks stron. Każdy kawałek kolumny zapisuje minimum, maksimum i liczbę wartości pustych; indeks stron zapisuje to samo na stronę, razem z przesunięciami stron, więc silnik może pomijać strony, a nie tylko kawałki.

Filtry Blooma. Dla kolumn o wysokiej liczności, takich jak identyfikator zamówienia, filtr Blooma typu split-block na kawałek kolumny odpowiada „tej wartości na pewno tu nie ma” bez czytania kawałka.

Kodowania i kodeki. Wartości są najpierw kodowane — słownikowo, ciągami i upakowaniem bitów, kodowaniami delta, podziałem strumienia bajtów — a strony są potem kompresowane kodekiem: Snappy, GZIP, Brotli, ZSTD, LZ4_RAW. Wybór jest kompromisem między rozmiarem pliku a czasem procesora po obu stronach.

System typów logicznych wciąż rośnie: wersja 2.11 dodała typ VARIANT dla danych półstrukturalnych oraz GEOMETRY/GEOGRAPHY, 2.12 sfinalizowała shredding wariantów, a 2.14 dodała typ FILE i podgląd kodowania zmiennoprzecinkowego ALP, według bloga projektu. Dla systemu enterprise oznacza to, że ładunki JSON z ERP i dane położenia z floty mogą leżeć w tej samej tabeli co księga, z typami, a nie jako nieprzezroczyste ciągi znaków.

Co silnik pomija, a kiedy nie może

Silnik chmurowy liczy sobie za przeczytane bajty i zużyte sekundy. Parquet obniża jedno i drugie, dając silnikowi powody do pomijania. Każdy powód zależy od własności plików, która nie jest automatyczna.

Infografika

Co dobrze ułożona tabela pozwala silnikowi pominąć

1. 01Pliki, po partycjach i statystykach tabeliMetadane formatu tabeli wykluczają całe pliki; wymaga sensownych partycji i plików na tyle dużych, żeby warto było je listować.
2. 02Grupy wierszy, po statystykach min/maxDziała tylko wtedy, gdy dane w pliku są posortowane lub pogrupowane po kolumnie filtru; losowa kolejność to psuje.
3. 03Strony, po indeksie stronDrobniejsze pomijanie wewnątrz grupy wierszy; zapisują go nowoczesne biblioteki zapisu, używają nowoczesne biblioteki odczytu — oba warunki muszą być spełnione.
4. 04Kolumny, o które nie zapytanoZawsze dostępne w układzie kolumnowym; największa i najpewniejsza oszczędność.
5. 05Powtarzające się wartości, przez kodowanie słownikoweKody statusów, kanały i kategorie kompresują się do kilku bajtów na wartość; za darmo, jeśli słownik się nie przepełni.

Wróćmy do godzinnego pulpitu. Strumień zapisywał plik co minutę, więc miesiąc wysyłek to około czterdziestu tysięcy plików po kilkaset kilobajtów. Silnik listuje je wszystkie, otwiera każdą stopkę i stwierdza, że każda grupa wierszy obejmuje każdą partię dostawcy, bo wiersze przychodziły w kolejności czasu, nie partii. Nie da się pominąć niczego poza nieużywanymi kolumnami. Skompaktowanie miesiąca do kilkuset plików i posortowanie każdego po partii dostawcy zmienia to, które warstwy z rysunku mają zastosowanie, i to jest różnica na fakturze. Liczby są ilustracją; mechanizm nie.

Decyzje i kto je podejmuje

Układ to zestaw decyzji z właścicielami, a nie ustawienie.

Partycjonowanie — po czym i jak grubo — wynika z tego, jak tabela jest odpytywana i ile danych pomieści każda partycja. Za drobne daje małe pliki; za grube daje pełne skany. To decyzja projektowa podejmowana z ludźmi, którzy są właścicielami pytań.

Klucze sortowania lub grupowania wewnątrz plików decydują, czy statystyki cokolwiek robią. Podążają za dominującymi filtrami, które zmieniają się razem z biznesem.

Rozmiar pliku i harmonogram kompaktowania decydują, ile stopek otwiera silnik. Format tabeli dostarcza operację; ktoś musi ją uruchamiać, płacić za nią i zauważyć, kiedy strumień ją wyprzedził.

Kodek i kodowanie decydują o kompromisie rozmiar–procesor; ZSTD zwykle wygrywa rozmiarem, Snappy szybkością, a właściwa odpowiedź zależy od tego, za którą stronę się płaci.

Retencja decyduje, ile historii zostaje w gorącej tabeli, a co przechodzi do tańszego składowania. To także miejsce, w którym pojawiają się obowiązki prawne, bo usunięcie danych osoby zgodnie z RODO oznacza przepisanie plików, które je zawierają.

Agenci w pętli inżynierii danych

Większość z tych decyzji się mierzy, a nie zgaduje, i właśnie pomiar jest miejscem, w którym agenci kodujący i operacyjni zarabiają na swoje miejsce. W sposobie, w jaki to budujemy, agent czyta historię zapytań silnika i statystyki plików tabeli i raportuje, po których kolumnach filtruje się najczęściej, ile plików otwiera typowe zapytanie, jak nierówne są rozmiary plików i ile bajtów skanowałoby się przy innym kluczu sortowania. Przygotowuje zadanie kompaktowania i kolejność sortowania, generuje porównanie przed i po na próbce i otwiera zgłoszenie zmiany z dołączonymi liczbami.

Czego nie robi, to zatwierdzanie zmiany. Nowe partycjonowanie przepisuje tabelę i zmienia każde zadanie niżej; zmiana retencji może usunąć coś, o co zapyta audytor; zmiana kodeka przenosi koszt ze składowania na obliczenia i pojawia się w budżecie innego zespołu. To przegląda inżynier, a tam, gdzie dotyczy retencji lub usuwania, właściciel danych. Wynik agenta jest dowodem; decyzja pozostaje zapisana pod nazwiskiem osoby, co pokaże też historia formatu tabeli.

Traktowany jako część AI SDLC, układ ma testy jak każdy inny kod: bajty skanowane na zapytanie referencyjne poniżej progu, liczba małych plików poniżej granicy, indeks stron i statystyki obecne w każdym zapisanym pliku. Potok, który po cichu zaczyna zapisywać nieposortowane pliki, oblewa test, a nie kwartalny przegląd budżetu.

Jak wygląda dobry wynik

Każda tabela w lakehouse ma określone partycjonowanie, kolejność sortowania i docelowy rozmiar pliku oraz zadanie, które utrzymuje je w mocy. Bajty skanowane na zapytanie referencyjne są mierzone i publikowane obok czasu zapytania. Harmonogramy kompaktowania i retencji mają właścicieli i budżety. Nowe kolumny ze źródeł półstrukturalnych przychodzą z typami, nie jako ciągi znaków. Gdy nowy pulpit podnosi rachunek, zespół w ciągu dnia potrafi powiedzieć, czy przyczyną jest pytanie, czy układ.

Nasza część

W inżynierii danych AI przeprowadzamy przez to jedną istotną tabelę: zmierzone decyzje o układzie, zadania kompaktowania i sortowania, testy utrzymujące niski poziom skanowanych bajtów oraz agentów, które pilnują plików, żeby inżynierowie mogli decydować zamiast szukać. Nie odsprzedajemy platform. Więcej o predictes na stronie głównej.