Apache Parquet: sådan er registret indrettet, så superintelligensen kan læse hele virksomheden

En planlægningsagent bliver klokken syv om morgenen spurgt, hvilke åbne ordrer der er i fare, fordi deres varer har en kvalitetsspærring. Svaret kræver tre felter fra ordreregistret, to fra inspektionsregistret og ét fra varestamdata, på tværs af alt åbent i virksomheden. Det skal foreligge, før planlæggeren sætter sig, og igen klokken ni, når planen ændres. Ingen lægger mærke til spørgsmålet, når det er billigt. Alle lægger mærke til det, når de agenter, der stiller det, er grunden til, at serverne blev opgraderet.

Superintelligensen læser registret langt oftere end mennesker, og i et suverænt system gør den det på hardware, som virksomheden betaler for. Layoutet af de filer, der rummer registret, afgør derfor noget, der ligner en ydelsesdetalje, men i virkeligheden er en omkostning ved at drive virksomheden. I Hurukans datalag, som er under opbygning, er registret designet til at blive lagret i Apache Parquet. Denne tekst handler om, hvad det valg køber, og hvad det kræver.

Hvad der er inde i en Parquet-fil

Parquet lagrer en tabel kolonne for kolonne. En fil rummer et antal rækkegrupper (row groups); hver rækkegruppe rummer én del (chunk) for hver kolonne; hver del er en sekvens af sider (pages). Metadata, herunder skemaet og placeringen af hver del, skrives til sidst, så en skribent producerer filen i ét gennemløb, og en læser åbner foden først og går derefter direkte til de bytes, den har brug for. Specifikationen er i version 2.14.0 (projektets blog, kontrolleret den 21. oktober 2026).

Rækkefølgen af det, en læser kan springe over, er det, der betyder noget for omkostningen:

Kolonner, den ikke spurgte efter. Planlægningsagenten vil have seks felter; filen kan rumme tres. De øvrige fireoghalvtreds læses aldrig.

Rækkegrupper, der ikke kan indeholde svaret. Hver kolonnedel bærer statistik, mindste og største værdi og antallet af tomme værdier. Handler spørgsmålet om én varefamilie, og er filen sorteret efter vare, udelukkes de fleste rækkegrupper alene ud fra foden.

Sider inde i en del. Sideindekset registrerer mindste og største værdi pr. side og hvor hver side starter, så læseren selv inde i en valgt rækkegruppe springer direkte til de sider, der passer.

Værdier, der ikke findes. Et Bloom-filter pr. kolonnedel svarer på “er dette ordrenummer overhovedet her” uden at læse delen, og det er, hvad et opslag på et felt med mange forskellige værdier har brug for.

Det, der er tilbage, læses, og det, der læses, er småt, fordi kolonner komprimeres godt: gentagne værdier bliver ordbogsindgange, sekvenser bliver optællinger, og en generel codec gør resten. Kodningerne og codecs er specificeret, med Snappy, GZIP, ZSTD og Brotli blandt codecs og det nyere LZ4_RAW i stedet for den ældre LZ4-indramning.

Hvorfor layoutet er et spørgsmål om suverænitet

En administreret platform skjuler omkostningen ved et dårligt indrettet register bag en månedlig faktura. På virksomhedens egen infrastruktur, hvor et suverænt operativsystem lever, er omkostningen synlig som processorer, diske og den tid, en agent venter. Det samme spørgsmål stillet til et register, der er sorteret efter det felt, det filtrerer på, med rækkegrupper i en fornuftig størrelse og ordbogskodning, hvor værdier gentages, rører en brøkdel af de bytes, det ellers ville røre. Beslutningen om layout er en beslutning om, hvor mange spørgsmål virksomheden har råd til at lade sine agenter stille. Det bredere design, herunder hvorfor registret er adskilt fra modulernes levende tilstand, står i den levende tilstand og registret.

Parquet er også det format, alle motorer læser. Spark, Trino, DuckDB, Snowflake, BigQuery, Microsoft Fabric og analysebibliotekerne åbner det alle direkte. Et register lagret i Parquet er et register, en anden motor kan læse i morgen, og det er den ene halvdel af en udgang; den anden halvdel, tabelmetadata over filerne, er emnet for revisionssporet er en tabel.

Typer, registret får brug for

Specifikationen er vokset mod de former, et virksomhedsregister faktisk har. Version 2.11 tilføjede typen VARIANT til semistrukturerede værdier, de halvt formede attributter, der ikke passer i en fast kolonne, samt GEOMETRY og GEOGRAPHY til placeringer; 2.12 færdiggjorde, hvordan VARIANT-værdier kan opdeles (shredding) i typede kolonner for hurtigere læsning; 2.14 tilføjede en FILE-type (udgivelsesnoter på projektets blog, typedefinitioner i LogicalTypes, kontrolleret den 21. oktober 2026). For et register, der på samme række skal rumme en leveringsadresse, et fleksibelt sæt inspektionsattributter og en henvisning til et scannet dokument, er de ikke eksotiske. Hvad en given motor læser af dem, skal kontrolleres motor for motor, og designet forudsætter, at den kontrol udføres, før en type tages i brug, ikke bagefter.

Hvad agenter foreslår, hvad mennesker beslutter

En agent, der holder øje med de spørgsmål, der stilles til registret, er godt placeret til at forbedre dets layout: den kan se, at de fleste filtre er på varefamilie, at en tabels filer er blevet små og mange, siden en konnektor begyndte at skrive hvert minut, eller at en kolonne har en ordbog, der ikke længere passer. I Hurukans design bliver de observationer til forslag, en sorteringsrækkefølge, en kompakteringsplan, et skift af codec, med dokumentationen vedlagt, og forslaget registreres, uanset om det accepteres eller ej.

Hvad en agent ikke beslutter, er, hvor længe registret beholder hver slags række, hvilke rækker der forlader det, når en person beder om at få sine data slettet, og om en omskrivning af et års filer, hvilket både kompaktering og omsortering er, er processortiden værd denne uge. Det er beslutninger om forpligtelse og omkostning, truffet af et menneske og skrevet ind i registret som alt andet.

En test, du kan lave i dag

Tag den ene rapport eller model i din virksomhed, der læser mest historik. Find ud af to ting: i hvilket format dens kildefiler er lagret, og om nogen nogensinde har sorteret dem efter noget. Er svaret CSV eller et databaseudtræk, læser hvert spørgsmål hver eneste byte. Er filerne kolonnebaserede, men usorterede og aldrig kompakterede, er den første forbedring billig, og ingen ejer den. Siden om datalaget beskriver, hvor registret sidder i Hurukan; oversigten viser, hvad der læser det.