Apache Parquet: hur registret är upplagt så att superintelligensen kan läsa hela företaget

En planeringsagent får klockan sju på morgonen frågan vilka öppna order som är i riskzonen för att deras artiklar har en kvalitetsspärr. Svaret kräver tre fält från orderposten, två från inspektionsposten och ett från artikelregistret, över allt som är öppet i företaget. Den behöver dem innan planeraren sätter sig, och den behöver dem igen klockan nio när planen ändras. Ingen lägger märke till frågan när den är billig. Alla lägger märke till när agenterna som ställer den är skälet till att servrarna uppgraderades.

Superintelligensen läser registret långt oftare än människor gör, och i ett suveränt system gör den det på hårdvara som företaget betalar för. Layouten på filerna som rymmer registret avgör därför något som ser ut som en prestandadetalj och i själva verket är en kostnad för att driva företaget. I Hurukans datalager, som är under uppbyggnad, är registret utformat för att lagras i Apache Parquet. Den här texten handlar om vad det valet ger och vad det kräver.

Vad som finns i en Parquet-fil

Parquet lagrar en tabell kolumn för kolumn. En fil rymmer ett antal radgrupper; varje radgrupp rymmer en bit för varje kolumn; varje bit är en följd av sidor. Metadatan, inklusive schemat och positionen för varje bit, skrivs i slutet, så att en skrivare producerar filen i ett svep och en läsare öppnar sidfoten först och sedan går rakt till de byte den behöver. Specifikationen är i version 2.14.0 (projektets blogg, kontrollerat den 21 oktober 2026).

Ordningen på det en läsare kan hoppa över är det som spelar roll för kostnaden:

Kolumner den inte bad om. Planeringsagenten vill ha sex fält; filen kan rymma sextio. De andra femtiofyra läses aldrig.

Radgrupper som inte kan innehålla svaret. Varje kolumnbit bär statistik, minimi- och maximivärdet och antalet nullvärden. Om frågan gäller en artikelfamilj och filen är sorterad efter artikel utesluts de flesta radgrupper redan utifrån sidfoten.

Sidor inuti en bit. Sidindexet registrerar minimum och maximum per sida och var varje sida börjar, så att läsaren även inuti en vald radgrupp hoppar till de sidor som matchar.

Värden som inte finns. Ett Bloom-filter per kolumnbit svarar på “finns det här ordernumret här över huvud taget” utan att läsa biten, vilket är vad en punktuppslagning på ett fält med hög kardinalitet behöver.

Det som blir kvar läses, och det som läses är litet, eftersom kolumner komprimeras väl: upprepade värden blir ordboksposter, löpningar blir antal, och en allmän kodek avslutar jobbet. Kodningarna och kodekarna är specificerade, med Snappy, GZIP, ZSTD och Brotli bland kodekarna och det nyare LZ4_RAW som ersätter den äldre LZ4-inramningen.

Varför layouten är en suveränitetsfråga

En hanterad plattform döljer kostnaden för ett dåligt upplagt register bakom en månadsfaktura. På företagets egen infrastruktur, som är där ett suveränt operativsystem bor, syns kostnaden som processorer, diskar och den tid en agent väntar. Samma fråga ställd mot ett register sorterat efter det fält den filtrerar på, med radgrupper av rimlig storlek och ordbokskodning där värden upprepas, rör en bråkdel av de byte den annars skulle röra. Beslutet om layout är ett beslut om hur många frågor företaget har råd att låta sina agenter ställa. Den större designen, inklusive varför registret är skilt från modulernas levande tillstånd, finns i det levande tillståndet och registret.

Parquet är också det format varje motor läser. Spark, Trino, DuckDB, Snowflake, BigQuery, Microsoft Fabric och analysbiblioteken öppnar alla det inbyggt. Ett register lagrat i Parquet är ett register en annan motor kan läsa i morgon, vilket är ena halvan av en utväg; den andra halvan, tabellmetadatan ovanför filerna, är ämnet för revisionsspåret är en tabell.

Typer registret kommer att behöva

Specifikationen har vuxit mot de former ett företagsregister faktiskt har. Version 2.11 lade till typen VARIANT för halvstrukturerade värden, de halvfärdiga attribut som inte passar i en fast kolumn, och GEOMETRY och GEOGRAPHY för platser; 2.12 fastställde hur VARIANT-värden kan delas upp i typade kolumner för snabbare läsning; 2.14 lade till en FILE-typ (utgåvenoteringar på projektets blogg, typdefinitioner i LogicalTypes, kontrollerat den 21 oktober 2026). För ett register som ska rymma en leveransadress, en flexibel uppsättning inspektionsattribut och en referens till ett skannat dokument på samma rad är de inte exotiska. Vad en given motor läser av dem måste kontrolleras per motor, och designen förutsätter att den kontrollen görs innan en typ används, inte efter.

Vad agenter föreslår, vad människor beslutar

En agent som iakttar de frågor som ställs till registret är väl placerad för att förbättra dess layout: den kan se att de flesta filter gäller artikelfamilj, att en tabells filer har blivit små och många sedan en koppling började skriva varje minut, eller att en kolumn har en ordbok som inte längre får plats. I Hurukans design blir de iakttagelserna förslag, en sorteringsordning, en komprimeringsplan, ett kodekbyte, med beläggen bifogade, och förslaget registreras oavsett om det antas eller inte.

Vad en agent inte beslutar är hur länge registret behåller varje slags rad, vilka rader som lämnar det när en person ber att få sina uppgifter borttagna, och om en omskrivning av ett års filer, vilket både komprimering och omsortering är, är värd processortiden den här veckan. Det är beslut om skyldighet och kostnad, fattade av en människa och inskrivna i registret som vilka andra som helst.

Ett test du kan göra i dag

Ta den rapport eller modell i ditt företag som läser mest historik. Ta reda på två saker: i vilket format dess källfiler lagras, och om någon någonsin har sorterat dem efter något. Om svaret är CSV eller en databasexport läser varje fråga varje byte. Om filerna är kolumnära men osorterade och aldrig komprimerade är den första förbättringen billig och ingen äger den. Sidan om datalagret beskriver var registret sitter i Hurukan; översikten visar vad som läser det.