Apache Parquet: näin rekisteri on järjestetty, jotta superäly voi lukea koko yrityksen

Suunnitteluagentilta kysytään aamuseitsemältä, mitkä avoimet tilaukset ovat vaarassa, koska niiden nimikkeillä on laatupidätys. Vastaus tarvitsee kolme kenttää tilaustietueesta, kaksi tarkastustietueesta ja yhden nimikerekisteristä, kaikesta yrityksessä avoinna olevasta. Se tarvitsee ne ennen kuin suunnittelija istuutuu, ja se tarvitsee ne uudelleen yhdeksältä, kun suunnitelma muuttuu. Kukaan ei huomaa kysymystä, kun se on halpa. Kaikki huomaavat sen, kun sitä esittävät agentit ovat syy siihen, että palvelimet päivitettiin.

Superäly lukee rekisteriä paljon useammin kuin ihmiset, ja suvereenissa järjestelmässä se tekee sen laitteistolla, josta yritys maksaa. Rekisteriä säilyttävien tiedostojen asettelu ratkaisee siis jotain, joka näyttää suorituskykyyksityiskohdalta ja on todellisuudessa yrityksen pyörittämisen kustannus. Hurukanin rakenteilla olevassa datakerroksessa rekisteri on suunniteltu tallennettavaksi Apache Parquet -muodossa. Tämä teksti kertoo, mitä tuo valinta antaa ja mitä se vaatii.

Mitä Parquet-tiedoston sisällä on

Parquet tallentaa taulun sarake sarakkeelta. Tiedosto sisältää joukon riviryhmiä; jokainen riviryhmä sisältää yhden lohkon kutakin saraketta kohden; jokainen lohko on sivujen jono. Metadata, mukaan lukien skeema ja jokaisen lohkon sijainti, kirjoitetaan loppuun, joten kirjoittaja tuottaa tiedoston yhdellä kierroksella ja lukija avaa ensin alatunnisteen ja menee sitten suoraan tarvitsemiinsa tavuihin. Spesifikaatio on versiossa 2.14.0 (projektin blogi, tarkistettu 21. lokakuuta 2026).

Kustannuksen kannalta ratkaisevaa on järjestys, jossa lukija voi ohittaa asioita:

Sarakkeet, joita se ei pyytänyt. Suunnitteluagentti haluaa kuusi kenttää; tiedostossa voi olla kuusikymmentä. Muita viittäkymmentäneljää ei koskaan lueta.

Riviryhmät, jotka eivät voi sisältää vastausta. Jokainen sarakelohko kantaa tilastot: minimi- ja maksimiarvon sekä null-arvojen määrän. Jos kysymys koskee yhtä nimikeperhettä ja tiedosto on lajiteltu nimikkeen mukaan, useimmat riviryhmät suljetaan pois pelkän alatunnisteen perusteella.

Sivut lohkon sisällä. Sivuindeksi tallentaa minimin ja maksimin sivua kohden sekä kunkin sivun alkukohdan, joten valitunkin riviryhmän sisällä lukija hyppää täsmääviin sivuihin.

Arvot, joita ei ole. Bloom-suodatin sarakelohkoa kohden vastaa kysymykseen «onko tämä tilausnumero täällä lainkaan» lukematta lohkoa, mitä pistehaku korkean kardinaliteetin kentästä tarvitsee.

Jäljelle jäävä luetaan, ja luettava on pientä, koska sarakkeet pakkautuvat hyvin: toistuvat arvot muuttuvat sanakirjamerkinnöiksi, sarjat lukumääriksi, ja yleinen koodekki viimeistelee työn. Koodaukset ja koodekit on määritelty; koodekkien joukossa ovat Snappy, GZIP, ZSTD ja Brotli, ja uudempi LZ4_RAW korvaa vanhemman LZ4-kehystyksen.

Miksi asettelu on suvereniteettikysymys

Hallinnoitu alusta piilottaa huonosti järjestetyn rekisterin kustannuksen kuukausilaskun taakse. Yrityksen omassa infrastruktuurissa, jossa suvereeni käyttöjärjestelmä asuu, kustannus näkyy prosessoreina, levyinä ja aikana, jonka agentti odottaa. Sama kysymys esitettynä rekisterille, joka on lajiteltu suodatuskentän mukaan, jossa riviryhmät ovat järkevän kokoisia ja sanakirjakoodaus käytössä toistuville arvoille, koskettaa murto-osaa tavuista, joita se muuten koskettaisi. Päätös asettelusta on päätös siitä, kuinka moneen kysymykseen yrityksellä on varaa antaa agenttiensa vastata. Laajempi suunnitelma, mukaan lukien se, miksi rekisteri on erillään moduulien nykytilasta, on tekstissä nykytila ja rekisteri.

Parquet on myös muoto, jota jokainen moottori lukee. Spark, Trino, DuckDB, Snowflake, BigQuery, Microsoft Fabric ja analyysikirjastot avaavat sen kaikki natiivisti. Parquetiin tallennettu rekisteri on rekisteri, jonka toinen moottori voi lukea huomenna, mikä on toinen puoli poistumisesta; toinen puoli, tiedostojen yläpuolella oleva taulumetadata, on aiheena tekstissä tarkastusjälki on taulu.

Tyypit, joita rekisteri tulee tarvitsemaan

Spesifikaatio on kasvanut kohti muotoja, joita yrityksen rekisterillä todella on. Versio 2.11 lisäsi VARIANT-tyypin puolirakenteisille arvoille, puolivalmiille attribuuteille, jotka eivät sovi kiinteään sarakkeeseen, sekä GEOMETRY- ja GEOGRAPHY-tyypit sijainneille; 2.12 viimeisteli sen, miten VARIANT-arvot voidaan pilkkoa tyypitettyihin sarakkeisiin nopeampaa lukemista varten; 2.14 lisäsi FILE-tyypin (julkaisutiedot projektin blogissa, tyyppimääritykset LogicalTypes-tiedostossa, tarkistettu 21. lokakuuta 2026). Rekisterille, jonka on pidettävä samalla rivillä toimitusosoite, joustava joukko tarkastusattribuutteja ja viittaus skannattuun dokumenttiin, nämä eivät ole eksoottisia. Se, mitä tietty moottori niistä lukee, on tarkistettava moottorikohtaisesti, ja suunnitelma olettaa, että tarkistus tehdään ennen tyypin käyttöönottoa, ei sen jälkeen.

Mitä agentit ehdottavat, mitä ihmiset päättävät

Agentti, joka seuraa rekisterille esitettyjä kysymyksiä, on hyvässä asemassa parantamaan sen asettelua: se näkee, että useimmat suodattimet kohdistuvat nimikeperheeseen, että taulun tiedostot ovat muuttuneet pieniksi ja lukuisiksi sen jälkeen, kun liitin alkoi kirjoittaa joka minuutti, tai että yhden sarakkeen sanakirja ei enää mahdu. Hurukanin suunnitelmassa näistä havainnoista tulee ehdotuksia — lajittelujärjestys, tiivistyssuunnitelma, koodekin vaihto — todisteineen, ja ehdotus kirjataan riippumatta siitä, hyväksytäänkö se.

Agentti ei päätä, kuinka kauan rekisteri säilyttää kunkin rivityypin, mitkä rivit poistuvat siitä, kun henkilö pyytää tietojensa poistamista, ja onko vuoden tiedostojen uudelleenkirjoitus — jota sekä tiivistys että uudelleenlajittelu ovat — prosessoriajan arvoinen tällä viikolla. Ne ovat päätöksiä velvoitteesta ja kustannuksesta, jotka ihminen tekee ja jotka kirjoitetaan rekisteriin kuten mikä tahansa muu.

Testi, jonka voit tehdä tänään

Ota yrityksesi se raportti tai malli, joka lukee eniten historiaa. Selvitä kaksi asiaa: missä muodossa sen lähdetiedostot on tallennettu, ja onko kukaan koskaan lajitellut niitä minkään mukaan. Jos vastaus on CSV tai tietokantavienti, jokainen kysymys lukee jokaisen tavun. Jos tiedostot ovat sarakemuotoisia mutta lajittelemattomia eikä niitä ole koskaan tiivistetty, ensimmäinen parannus on halpa eikä kukaan omista sitä. Datakerroksen sivu kuvaa, missä rekisteri sijaitsee Hurukanissa; yleiskatsaus näyttää, mikä sitä lukee.