Apache Parquet: hoe het register is ingedeeld zodat superintelligentie het hele bedrijf kan lezen

Een planningsagent krijgt om zeven uur ‘s ochtends de vraag welke open orders gevaar lopen omdat hun artikelen een kwaliteitsblokkade hebben. Het antwoord heeft drie velden uit het orderrecord nodig, twee uit het inspectierecord en één uit de artikelstam, over alles wat in het bedrijf openstaat. Het moet er zijn voordat de planner gaat zitten, en om negen uur opnieuw, wanneer het plan verandert. Niemand merkt de vraag op zolang hij goedkoop is. Iedereen merkt hem op wanneer de agents die hem stellen de reden zijn dat de servers werden uitgebreid.

Superintelligentie leest het register veel vaker dan mensen, en in een soeverein systeem doet ze dat op hardware waarvoor het bedrijf betaalt. De indeling van de bestanden die het register bevatten bepaalt daarom iets wat op een prestatiedetail lijkt maar in feite een kostenpost van het runnen van het bedrijf is. In de laag Data van Hurukan, die in aanbouw is, is het register ontworpen om in Apache Parquet te worden opgeslagen. Deze tekst gaat over wat die keuze oplevert en wat ze vraagt.

Wat er in een Parquet-bestand zit

Parquet slaat een tabel kolom voor kolom op. Een bestand bevat een aantal row groups; elke row group bevat één chunk per kolom; elke chunk is een reeks pagina’s. De metadata, inclusief het schema en de positie van elke chunk, wordt aan het eind geschreven, zodat een schrijver het bestand in één keer produceert en een lezer eerst de footer opent en dan direct naar de bytes gaat die hij nodig heeft. De specificatie staat op versie 2.14.0 (projectblog, gecontroleerd op 21 oktober 2026).

Voor de kosten telt de volgorde van wat een lezer kan overslaan:

Kolommen waar niet om gevraagd is. De planningsagent wil zes velden; het bestand kan er zestig bevatten. De andere vierenvijftig worden nooit gelezen.

Row groups die het antwoord niet kunnen bevatten. Elke kolomchunk draagt statistieken, de minimale en maximale waarde en het aantal nulls. Als de vraag over één artikelfamilie gaat en het bestand op artikel gesorteerd is, vallen de meeste row groups al op basis van de footer af.

Pagina’s binnen een chunk. De page index legt minimum en maximum per pagina vast en waar elke pagina begint, zodat de lezer ook binnen een gekozen row group direct naar de passende pagina’s springt.

Waarden die niet bestaan. Een Bloom-filter per kolomchunk beantwoordt “staat dit ordernummer hier überhaupt in” zonder de chunk te lezen, en dat is wat een opzoeking op een veld met veel unieke waarden nodig heeft.

Wat overblijft wordt gelezen, en wat gelezen wordt is klein, omdat kolommen goed comprimeren: herhaalde waarden worden woordenboekitems, reeksen worden tellingen, en een algemene codec maakt het af. De encoderingen en codecs zijn gespecificeerd, met Snappy, GZIP, ZSTD en Brotli onder de codecs en het nieuwere LZ4_RAW als vervanging van de oudere LZ4-framing.

Waarom de indeling een soevereiniteitsvraag is

Een beheerd platform verbergt de kosten van een slecht ingedeeld register achter een maandfactuur. Op de eigen infrastructuur van het bedrijf, waar een soeverein besturingssysteem draait, zijn de kosten zichtbaar als processors, schijven en de tijd dat een agent wacht. Dezelfde vraag, gesteld aan een register dat gesorteerd is op het veld waarop gefilterd wordt, met row groups van een redelijke omvang en woordenboekencodering waar waarden zich herhalen, raakt een fractie van de bytes die ze anders zou raken. De beslissing over de indeling is een beslissing over hoeveel vragen het bedrijf zijn agents kan laten stellen. Het bredere ontwerp, inclusief waarom het register los staat van de actuele toestand van de modules, staat in de actuele toestand en het register.

Parquet is ook het formaat dat elke engine leest. Spark, Trino, DuckDB, Snowflake, BigQuery, Microsoft Fabric en de analysebibliotheken openen het allemaal native. Een register in Parquet is een register dat morgen door een andere engine gelezen kan worden, en dat is de ene helft van een exit; de andere helft, de tabelmetadata boven de bestanden, is het onderwerp van het auditspoor is een tabel.

Typen die het register nodig zal hebben

De specificatie is gegroeid naar de vormen die een bedrijfsregister werkelijk heeft. Versie 2.11 voegde het type VARIANT toe voor semigestructureerde waarden, de half gevormde kenmerken die niet in een vaste kolom passen, en GEOMETRY en GEOGRAPHY voor locaties; 2.12 legde vast hoe VARIANT-waarden in getypeerde kolommen kunnen worden opgesplitst (shredding) voor sneller lezen; 2.14 voegde een type FILE toe (releasenotes op het projectblog, typedefinities in LogicalTypes, gecontroleerd op 21 oktober 2026). Voor een register dat een afleveradres, een flexibele set inspectiekenmerken en een verwijzing naar een gescand document op dezelfde rij moet bevatten, zijn dat geen exotische zaken. Wat een bepaalde engine daarvan leest, moet per engine worden gecontroleerd, en het ontwerp gaat ervan uit dat die controle gebeurt voordat een type wordt gebruikt, niet erna.

Wat agents voorstellen, wat mensen beslissen

Een agent die de vragen aan het register volgt, is goed geplaatst om de indeling te verbeteren: hij ziet dat de meeste filters op artikelfamilie zijn, dat de bestanden van een tabel klein en talrijk zijn geworden sinds een connector elke minuut begon te schrijven, of dat een kolom een woordenboek heeft dat niet meer past. In het ontwerp van Hurukan worden die waarnemingen voorstellen, een sorteervolgorde, een compactieplan, een codecwijziging, met het bewijs erbij, en het voorstel wordt vastgelegd, of het nu wordt geaccepteerd of niet.

Wat een agent niet beslist, is hoe lang het register elk soort rij bewaart, welke rijen eruit gaan wanneer iemand vraagt om verwijdering van zijn gegevens, en of het herschrijven van een jaar aan bestanden, wat compactie en hersortering allebei zijn, deze week de processortijd waard is. Dat zijn beslissingen over verplichtingen en kosten, genomen door een mens en vastgelegd in het register zoals alle andere.

Een test die u vandaag kunt doen

Neem het ene rapport of model in uw bedrijf dat de meeste historie leest. Zoek twee dingen uit: in welk formaat de bronbestanden zijn opgeslagen, en of iemand ze ooit ergens op heeft gesorteerd. Als het antwoord CSV of een database-export is, leest elke vraag elke byte. Als de bestanden kolomgewijs zijn maar ongesorteerd en nooit gecompacteerd, is de eerste verbetering goedkoop en is niemand er eigenaar van. De pagina laag Data beschrijft waar het register in Hurukan zit; het overzicht laat zien wat het leest.