Apache Parquet: slik er registeret lagt opp for at superintelligensen kan lese hele virksomheten

En planleggingsagent blir spurt, klokken sju om morgenen, hvilke åpne ordrer som er i fare fordi varene deres har en kvalitetssperre. Svaret trenger tre felt fra ordreposten, to fra inspeksjonsposten og ett fra vareregisteret, på tvers av alt som er åpent i virksomheten. Den trenger dem før planleggeren setter seg, og den trenger dem igjen klokken ni når planen endres. Ingen legger merke til spørsmålet når det er billig. Alle legger merke til det når agentene som stiller det, er grunnen til at serverne ble oppgradert.

Superintelligens leser registeret langt oftere enn mennesker gjør, og i et suverent system gjør den det på maskinvare virksomheten betaler for. Oppsettet av filene som holder registeret, avgjør derfor noe som ser ut som en ytelsesdetalj og i virkeligheten er en kostnad ved å drive virksomheten. I Hurukans datalag, som er under bygging, er registeret utformet for å lagres i Apache Parquet. Denne teksten handler om hva det valget gir og hva det krever.

Hva som er inne i en Parquet-fil

Parquet lagrer en tabell kolonne for kolonne. En fil holder et antall radgrupper; hver radgruppe holder én del for hver kolonne; hver del er en rekke sider. Metadataene, inkludert skjemaet og posisjonen til hver del, skrives til slutt, slik at en skriver produserer filen i én omgang og en leser åpner bunnteksten først og går deretter rett til bytene den trenger. Spesifikasjonen er på versjon 2.14.0 (prosjektbloggen, kontrollert 21. oktober 2026).

Rekkefølgen av spørsmålene en leser kan hoppe over, er det som betyr noe for kostnaden:

Kolonner den ikke ba om. Planleggingsagenten vil ha seks felt; filen kan holde seksti. De andre femtifire leses aldri.

Radgrupper som ikke kan inneholde svaret. Hver kolonnedel bærer statistikk, minimums- og maksimumsverdien og antall nullverdier. Hvis spørsmålet gjelder én varefamilie og filen er sortert etter vare, utelukkes de fleste radgruppene ut fra bunnteksten alene.

Sider inne i en del. Sideindeksen registrerer minimum og maksimum per side og hvor hver side begynner, slik at leseren selv inne i en valgt radgruppe hopper til sidene som passer.

Verdier som ikke finnes. Et Bloom-filter per kolonnedel svarer på «finnes dette ordrenummeret her i det hele tatt» uten å lese delen, som er det et punktoppslag på et felt med høy kardinalitet trenger.

Det som er igjen, leses, og det som leses, er lite, fordi kolonner komprimerer godt: gjentatte verdier blir ordbokoppføringer, serier blir tellinger, og en generell kodek fullfører jobben. Kodingene og kodekene er spesifisert, med Snappy, GZIP, ZSTD og Brotli blant kodekene og den nyere LZ4_RAW som erstatter den eldre LZ4-innrammingen.

Hvorfor oppsettet er et suverenitetsspørsmål

En administrert plattform skjuler kostnaden ved et dårlig lagt opp register bak en månedlig faktura. På virksomhetens egen infrastruktur, som er der et suverent operativsystem bor, er kostnaden synlig som prosessorer, disker og tiden en agent venter. Det samme spørsmålet stilt mot et register sortert etter feltet det filtrerer på, med radgrupper av fornuftig størrelse og ordbokkoding der verdier gjentas, berører en brøkdel av bytene det ellers ville berørt. Beslutningen om oppsett er en beslutning om hvor mange spørsmål virksomheten har råd til å la agentene sine stille. Det bredere designet, inkludert hvorfor registeret er atskilt fra modulenes nåtilstand, finnes i nåtilstand og register.

Parquet er også formatet hver motor leser. Spark, Trino, DuckDB, Snowflake, BigQuery, Microsoft Fabric og analysebibliotekene åpner det alle direkte. Et register lagret i Parquet er et register en annen motor kan lese i morgen, som er den ene halvdelen av en utgang; den andre halvdelen, tabellmetadataene over filene, er temaet i revisjonssporet er en tabell.

Typer registeret vil trenge

Spesifikasjonen har vokst mot formene et virksomhetsregister faktisk har. Versjon 2.11 la til typen VARIANT for halvstrukturerte verdier, de halvformede attributtene som ikke passer i en fast kolonne, og GEOMETRY og GEOGRAPHY for steder; 2.12 ferdigstilte hvordan VARIANT-verdier kan splittes i typede kolonner for raskere lesing; 2.14 la til en FILE-type (utgivelsesnotater på prosjektbloggen, typedefinisjoner i LogicalTypes, kontrollert 21. oktober 2026). For et register som må holde en leveringsadresse, et fleksibelt sett inspeksjonsattributter og en referanse til et skannet dokument på samme rad, er det ikke eksotisk. Hva en gitt motor leser av dem, må sjekkes per motor, og designet forutsetter at den sjekken gjøres før en type tas i bruk, ikke etter.

Hva agenter foreslår, hva mennesker beslutter

En agent som følger med på spørsmålene som stilles til registeret, er godt plassert for å forbedre oppsettet: den kan se at de fleste filtre er på varefamilie, at en tabells filer har blitt små og mange siden en kobling begynte å skrive hvert minutt, eller at én kolonne har en ordbok som ikke lenger får plass. I Hurukans design blir de observasjonene forslag, en sorteringsrekkefølge, en komprimeringsplan, et kodekbytte, med bevisene vedlagt, og forslaget registreres enten det godtas eller ikke.

Det en agent ikke avgjør, er hvor lenge registeret beholder hver type rad, hvilke rader som forlater det når en person ber om å få dataene sine fjernet, og om en omskriving av et år med filer, som både komprimering og resortering er, er verdt prosessortiden denne uken. Det er beslutninger om forpliktelse og kostnad, tatt av en person og skrevet inn i registeret som enhver annen.

En test du kan gjøre i dag

Ta den ene rapporten eller modellen i virksomheten din som leser mest historikk. Finn ut to ting: i hvilket format kildefilene dens er lagret, og om noen noensinne har sortert dem etter noe som helst. Hvis svaret er CSV eller en databaseeksport, leser hvert spørsmål hver byte. Hvis filene er kolonnebaserte, men usorterte og aldri komprimert, er den første forbedringen billig, og ingen eier den. Siden om datalaget beskriver hvor registeret sitter i Hurukan; oversikten viser hva som leser det.