Apache Parquet: jak ułożony jest zapis, żeby superinteligencja czytała całą firmę

O siódmej rano agent planowania dostaje pytanie, które otwarte zamówienia są zagrożone, bo ich pozycje mają wstrzymanie jakościowe. Odpowiedź wymaga trzech pól z rekordu zamówienia, dwóch z rekordu kontroli i jednego z kartoteki pozycji, we wszystkim, co w firmie jest otwarte. Potrzebuje ich, zanim planista usiądzie, i potrzebuje ich znów o dziewiątej, gdy plan się zmieni. Nikt nie zauważa tego pytania, gdy jest tanie. Wszyscy zauważają, gdy agenci, którzy je zadają, są powodem rozbudowy serwerów.

Superinteligencja czyta zapis znacznie częściej niż ludzie, a w systemie suwerennym robi to na sprzęcie, za który płaci firma. Układ plików przechowujących zapis decyduje więc o czymś, co wygląda na szczegół wydajności, a w istocie jest kosztem prowadzenia firmy. W warstwie Data Hurukana, która jest w budowie, zapis ma być przechowywany w Apache Parquet. Ten tekst jest o tym, co ten wybór daje i czego wymaga.

Co jest w środku pliku Parquet

Parquet przechowuje tabelę kolumna po kolumnie. Plik zawiera pewną liczbę grup wierszy; każda grupa zawiera po jednym kawałku na kolumnę; każdy kawałek to ciąg stron. Metadane, w tym schemat i położenie każdego kawałka, są zapisane na końcu, więc pisarz tworzy plik w jednym przebiegu, a czytelnik otwiera najpierw stopkę i idzie prosto do bajtów, których potrzebuje. Specyfikacja ma wersję 2.14.0 (blog projektu, sprawdzono 21.10.2026).

Dla kosztu liczy się kolejność rzeczy, które czytelnik może pominąć:

Kolumny, o które nie pytał. Agent planowania chce sześciu pól; plik może mieć sześćdziesiąt. Pozostałe pięćdziesiąt cztery nie są w ogóle czytane.

Grupy wierszy, które nie mogą zawierać odpowiedzi. Każdy kawałek kolumny niesie statystyki: wartość minimalną i maksymalną oraz liczbę wartości pustych. Jeśli pytanie dotyczy jednej rodziny pozycji, a plik jest posortowany po pozycji, większość grup wierszy odpada już na podstawie stopki.

Strony wewnątrz kawałka. Indeks stron zapisuje minimum i maksimum na stronę oraz początek każdej strony, więc nawet w wybranej grupie wierszy czytelnik skacze do stron, które pasują.

Wartości, których nie ma. Filtr Blooma na kawałek kolumny odpowiada „czy ten numer zamówienia w ogóle tu jest” bez czytania kawałka, a tego potrzebuje odczyt punktowy po polu o wielu wartościach.

To, co zostaje, jest czytane, a to, co jest czytane, jest małe, bo kolumny dobrze się kompresują: powtarzające się wartości stają się wpisami słownika, serie stają się licznikami, a ogólny kodek kończy robotę. Kodowania i kodeki są wyspecyfikowane, wśród kodeków Snappy, GZIP, ZSTD i Brotli, a nowszy LZ4_RAW zastępuje starszą ramkę LZ4.

Dlaczego układ jest pytaniem o suwerenność

Platforma zarządzana ukrywa koszt źle ułożonego zapisu za miesięczną fakturą. Na własnej infrastrukturze firmy, a tam żyje suwerenny system operacyjny, koszt jest widoczny jako procesory, dyski i czas, przez który agent czeka. To samo pytanie zadane zapisowi posortowanemu po polu, po którym filtruje, z grupami wierszy rozsądnej wielkości i kodowaniem słownikowym tam, gdzie wartości się powtarzają, dotyka ułamka bajtów, których dotknęłoby inaczej. Decyzja o układzie jest decyzją o tym, na ile pytań swoich agentów firmę stać. Szerszy projekt, w tym dlaczego zapis jest oddzielony od stanu bieżącego modułów, opisuje tekst stan bieżący i zapis.

Parquet jest też formatem, który czyta każdy silnik. Spark, Trino, DuckDB, Snowflake, BigQuery, Microsoft Fabric i biblioteki analityczne otwierają go natywnie. Zapis przechowywany w Parquet to zapis, który jutro przeczyta inny silnik, a to połowa wyjścia; druga połowa, metadane tabeli nad plikami, jest tematem tekstu ślad audytu to tabela.

Typy, których zapis będzie potrzebował

Specyfikacja rozrosła się w stronę kształtów, jakie zapis firmy naprawdę ma. Wersja 2.11 dodała typ VARIANT dla wartości półstrukturalnych, czyli luźnych atrybutów, które nie mieszczą się w stałej kolumnie, oraz GEOMETRY i GEOGRAPHY dla lokalizacji; 2.12 doprecyzowała, jak wartości VARIANT można rozszczepiać na typowane kolumny dla szybszego czytania; 2.14 dodała typ FILE (noty wydań na blogu projektu, definicje typów w LogicalTypes, sprawdzono 21.10.2026). Dla zapisu, który ma trzymać w jednym wierszu adres dostawy, elastyczny zestaw atrybutów kontroli i odwołanie do zeskanowanego dokumentu, to nie są egzotyczne rzeczy. Co z nich czyta dany silnik, trzeba sprawdzić per silnik, a projekt zakłada, że ta kontrola odbywa się przed użyciem typu, nie po.

Co proponują agenci, o czym decydują ludzie

Agent, który obserwuje pytania zadawane zapisowi, jest w dobrym miejscu, żeby poprawiać jego układ: widzi, że większość filtrów dotyczy rodziny pozycji, że pliki tabeli zrobiły się małe i liczne, odkąd konektor pisze co minutę, albo że słownik jednej kolumny już się nie mieści. W projekcie Hurukana te obserwacje stają się propozycjami, porządkiem sortowania, planem kompaktowania, zmianą kodeka, z dołączonymi dowodami, a propozycja jest zapisywana niezależnie od tego, czy zostanie przyjęta.

Agent nie decyduje o tym, jak długo zapis przechowuje każdy rodzaj wiersza, które wiersze opuszczają go, gdy ktoś prosi o usunięcie swoich danych, ani czy przepisanie roku plików, a tym jest zarówno kompaktowanie, jak i ponowne sortowanie, jest warte czasu procesora w tym tygodniu. To decyzje o zobowiązaniach i koszcie, podejmowane przez człowieka i zapisywane w zapisie jak każda inna.

Test, który możesz zrobić dziś

Weź ten jeden raport albo model w Twojej firmie, który czyta najwięcej historii. Ustal dwie rzeczy: w jakim formacie przechowywane są jego pliki źródłowe i czy ktokolwiek kiedykolwiek posortował je po czymkolwiek. Jeśli odpowiedź to CSV albo eksport z bazy, każde pytanie czyta każdy bajt. Jeśli pliki są kolumnowe, ale nieposortowane i nigdy niekompaktowane, pierwsze usprawnienie jest tanie i nikt za nie nie odpowiada. Strona warstwy Data opisuje, gdzie w Hurukanie leży zapis; przegląd pokazuje, co go czyta.