Apache Iceberg: rekisteri, jonka voi ottaa mukaan

Konserni ostaa yrityksen. Ostaja tekee raportointinsa Snowflakessa; ostettu yritys piti datansa omassa konesalissaan ja kysyi sitä Trinolla. Integraatiosuunnitelmassa on rivi “siirretään data”, ja kaikki tietävät, mitä se maksaa: vuoden kopiointia, kahdet luvut sillä välin ja riippuvuuden siitä alustasta, jolle kopio päätyy.

Vaihtoehto on, että rekisteri on muodossa, jota molemmat osapuolet jo lukevat, ja luettelossa, jota konserni hallitsee. Apache Iceberg on tällä hetkellä muoto, josta useimmat kilpailijat ovat yhtä mieltä, eikä syy ole tunteissa. Se on sen metatietojen rakenne. Hurukanin rekisteri on suunniteltu siirrettäväksi juuri tässä mielessä, ja sitä pitävä datakerros on rakenteilla.

Taulu puuna, jossa on yksi osoitin

Iceberg kuvaa taulun puuna tiedostoista, joita ei koskaan muokata. Ylimpänä on taulun metatietotiedosto; se osoittaa tilannekuvaan (snapshot); tilannekuva osoittaa manifestiluetteloon; jokainen manifesti luettelee datatiedostot ja poistotiedostot tilastoineen. Muutos tauluun kirjoittaa uudet lehdet ja uuden juuren ja tekee sitten yhden pienen asian: se vaihtaa luettelossa olevan osoittimen vanhasta juuresta uuteen. Määrittely tekee vaihdosta atomisen.

Tästä seuraa kaksi asiaa. Jokainen juuri, joka on ollut olemassa, on yhä täydellinen, luettava versio taulusta, mikä on aikamatka (time travel), ja Hurukanissa se on vastaus kysymykseen “mitä agentti näki, kun se ehdotti tätä”. Ja useampi moottori voi kirjoittaa samaan tauluun turvallisesti, koska ainoa asia, josta ne kilpailevat, on osoitin.

Ajantasainen julkaisu on Iceberg 1.12.0 syyskuulta 2026 (tarkistettu 21. lokakuuta 2026). Määrittelyn versio 3 on hyväksytty: Puffin-tiedostoihin tallennetut poistovektorit, rivien alkuperä (row lineage), VARIANT-tyyppi, geometriatyypit, nanosekuntien aikaleimat ja sarakkeiden oletusarvot. Versio 4 on kehitteillä eikä sitä ole hyväksytty.

Piilotettu osiointi ja miksi analyytikko ei koskaan kysy siitä

Iceberg johtaa osioarvot sarakemuunnoksista — aikaleiman päivä, tunnisteen lohko (bucket) — ja kirjaa muunnoksen metatietoihin. Aikaleimalla suodattava kysely karsitaan oikeisiin osioihin ilman, että sen kirjoittaja tietää osioiden olemassaolosta. Kun datamäärä muuttuu, osiomäärittely voi kehittyä ilman datan uudelleenkirjoittamista; vanhat tiedostot pitävät vanhan asettelun, uudet saavat uuden, ja molemmat luetaan oikein.

Rekisterille, jota on tarkoitus lukea superälyn eikä tallennusasettelun tuntevien ihmisten toimesta, tämä ominaisuus merkitsee enemmän kuin miltä kuulostaa. Ontologia voi nimetä taulun “maksut” ja jättää asettelun datakerrokselle.

Luettelossa on suvereniteetti

Kaikki edellä mainittu on tiedostoja. Tiedostot voivat olla missä tahansa objektivarastossa, myös yrityksen omassa rakennuksessa. Sitä tiedostot eivät voi tehdä, että kertoisivat lukijalle, mikä juuri on nykyinen ja saako tämä henkilö lukea sitä. Se on luettelon (catalogue) tehtävä, ja se on paikka, jossa yritys joko omistaa rekisterinsä tai vuokraa sen.

Iceberg julkaisee avoimen REST-luettelon määrittelyn: nimiavaruudet, taulut, näkymät, commitit, skannauksen suunnittelu ja tunnistetietojen jakelu yhden HTTP-rajapinnan takana. Sen toteutus Apache Polaris nousi Apachen päätason projektiksi helmikuussa 2026 ja julkaisi version 1.8.0 syyskuussa 2026 (tarkistettu 21. lokakuuta 2026). Muitakin toteutuksia on. Olennaista on, että luetteloa voi ajaa yrityksen valitsemalla infrastruktuurilla ja minkä tahansa toimittajan moottori voi keskustella sen kanssa.

Näin tietoturva- ja suvereniteettikerros kohtelee rekisteriä: käyttöoikeudet valvotaan luettelossa, yrityksen omalla palvelimella, ihmisille ja agenteille samalla tavalla. Toimittajan moottori, joka lukee rekisteriä, tekee sen niillä tunnistetiedoilla, jotka luettelo sille antaa, eikä millään muilla.

Kuka sitä lukee

Luettelo toimittajien omasta dokumentaatiosta 21. lokakuuta 2026: Snowflake lukee ja kirjoittaa Iceberg-tauluja määrittelyn versioon 3 asti ja voi käyttää ulkoista REST-luetteloa; Amazon S3 Tables tallentaa Icebergiä natiivisti, myös versiota 3; Googlen lakehouse-luettelo tarjoaa Iceberg REST -päätepisteen; Databricks tarjoaa hallinnoituja Iceberg-tauluja Unity Catalogissa REST-päätepisteellä. Spark, Flink, Trino ja DuckDB lukevat sitä suoraan.

Alun yrityskaupalle tämä luettelo on suunnitelma: yksi rekisteri, konsernin tallennuksessa, konsernin luettelon takana, jota Snowflake lukee toisella puolella ja Trino toisella, eikä budjetissa ole siirtoriviä.

Mitä agentit tekevät tässä ja mitä ihmiset pitävät itsellään

Agentti voi laatia tehtävän, joka kehittää osiomäärittelyä datamäärän kasvaessa, tiivistyksen, joka yhdistää pienet tiedostot, ja vanhojen tilannekuvien vanhentamisen, kun yrityksen asettama säilytysaika täyttyy. Jokainen on ehdotus testituloksineen; ihminen hyväksyy sen, ja se kirjataan Hurukanissa kuten mikä tahansa muu muutos.

Ihmiset pitävät päätökset, joita ei voi päätellä: mikä luettelo ja missä se toimii; kuka saa lukea mitäkin nimiavaruutta; kuinka kauan historiaa säilytetään ja milloin henkilön tiedot poistetaan lopullisesti; ja siirretäänkö taulu uudempaan määrittelyversioon, koska lukija, joka ei tunne versiota 3, ei lue sitä käyttävää taulua. Kysymys siitä, mikä data ylipäätään saa poistua talosta, on erillinen, ja sitä käsitellään tekstissä Mikä data ei saa koskaan poistua talosta.

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

Kysy, kuka yrityksessäsi voisi tällä viikolla osoittaa uuden moottorin tärkeimpään tauluunne ja saada sen lukemaan oikein ilman vientiä. Jos vastaukseen liittyy toimittajan tukipyyntö, rekisteri ei ole vielä teidän.