Apache Iceberg: het register dat u kunt meenemen

Een groep neemt een bedrijf over. De koper draait zijn rapportage op Snowflake; het overgenomen bedrijf hield zijn data in een eigen datacenter en bevroeg die met Trino. In het integratieplan staat een regel “data migreren”, en iedereen weet wat die regel kost: een jaar kopiëren, intussen twee sets cijfers, en afhankelijkheid van het platform waar de kopie terechtkomt.

Het alternatief is dat het register in een formaat staat dat beide kanten al lezen, met een catalogus die de groep beheert. Apache Iceberg is op dit moment het formaat waarover de meeste concurrenten het eens zijn, en de reden is geen sentiment. Het is de vorm van de metadata. Het register van Hurukan is ontworpen om in precies deze zin draagbaar te zijn, en de laag Data die het bevat is in aanbouw.

Een tabel als boom, met één pointer

Iceberg beschrijft een tabel als een boom van bestanden die nooit worden bewerkt. Bovenaan staat een metadatabestand van de tabel; dat wijst naar een snapshot; de snapshot wijst naar een manifestlijst; elk manifest somt databestanden en verwijderbestanden op met hun statistieken. Een wijziging aan de tabel schrijft nieuwe bladeren en een nieuwe wortel, en doet dan één klein ding: ze verplaatst de pointer in de catalogus van de oude wortel naar de nieuwe. De specificatie maakt die verplaatsing atomair.

Daar volgen twee dingen uit. Elke wortel die heeft bestaan, is nog steeds een volledige, leesbare versie van de tabel; dat is tijdreizen (time travel), en in Hurukan is het het antwoord op “wat zag de agent toen hij dit voorstelde”. En meerdere engines kunnen veilig naar dezelfde tabel schrijven, omdat het enige waarom ze concurreren de pointer is.

De actuele release is Iceberg 1.12.0 van september 2026 (gecontroleerd op 21 oktober 2026). Versie 3 van de specificatie is aangenomen: deletion vectors opgeslagen in Puffin-bestanden, row lineage, een type VARIANT, geometrietypen, tijdstempels in nanoseconden en standaardwaarden voor kolommen. Versie 4 is in ontwikkeling en niet aangenomen.

Verborgen partitionering, en waarom een analist er nooit naar vraagt

Iceberg leidt partitiewaarden af uit kolomtransformaties — de dag van een tijdstempel, een bucket van een identificator — en legt de transformatie vast in de metadata. Een query die op de tijdstempel filtert, wordt teruggebracht tot de juiste partities zonder dat de persoon die hem schrijft weet dat er partities bestaan. Wanneer het volume verandert, kan de partitiespecificatie evolueren zonder de data te herschrijven; oude bestanden houden de oude indeling, nieuwe bestanden krijgen de nieuwe, en beide worden correct gelezen.

Voor een register dat bedoeld is om door superintelligentie gelezen te worden in plaats van door mensen die de opslagindeling kennen, weegt die eigenschap zwaarder dan het klinkt. De ontologie kan een tabel “betalingen” noemen en de indeling aan de laag Data overlaten.

De catalogus is waar soevereiniteit zit

Alles hierboven zijn bestanden. Bestanden kunnen op elke objectopslag staan, ook op een in het eigen gebouw van het bedrijf. Wat de bestanden niet kunnen, is een lezer vertellen welke wortel actueel is en of deze persoon hem mag lezen. Dat is de taak van de catalogus, en het is de plek waar een bedrijf zijn register bezit of huurt.

Iceberg publiceert een open REST-catalogusspecificatie: namespaces, tabellen, views, commits, scanplanning en het uitgeven van inloggegevens achter één HTTP-interface. Apache Polaris, een implementatie ervan, werd in februari 2026 een top-level Apache-project en bracht in september 2026 versie 1.8.0 uit (gecontroleerd op 21 oktober 2026). Er bestaan andere implementaties. Waar het om gaat: een catalogus kan draaien op infrastructuur die het bedrijf kiest, en een engine van welke leverancier ook kan ermee praten.

Zo behandelt de laag beveiliging en soevereiniteit het register: rechten afgedwongen bij de catalogus, op de eigen server van het bedrijf, voor mensen en agents gelijk. De engine van een leverancier die het register leest, doet dat met de inloggegevens die de catalogus hem geeft, en niet meer.

Wie het leest

De lijst, uit de eigen documentatie van de leveranciers op 21 oktober 2026: Snowflake leest en schrijft Iceberg-tabellen tot en met specificatie v3 en kan een externe REST-catalogus gebruiken; Amazon S3 Tables slaan Iceberg native op, inclusief v3; de lakehousecatalogus van Google biedt een Iceberg REST-endpoint; Databricks biedt beheerde Iceberg-tabellen in Unity Catalog met een REST-endpoint. Spark, Flink, Trino en DuckDB lezen het rechtstreeks.

Voor de overname uit de eerste alinea is die lijst het plan: één register, op de opslag van de groep, achter de catalogus van de groep, gelezen door Snowflake aan de ene kant en Trino aan de andere, zonder migratieregel in het budget.

Wat agents hier doen, en wat mensen houden

Een agent kan de taak opstellen die een partitiespecificatie laat evolueren wanneer het volume groeit, de compactie die kleine bestanden samenvoegt, het laten verlopen van oude snapshots zodra de bewaring die het bedrijf heeft ingesteld is bereikt. Elk daarvan is een voorstel met een testresultaat, goedgekeurd door een mens, vastgelegd zoals elke andere wijziging in Hurukan.

Mensen houden de beslissingen die niet af te leiden zijn: welke catalogus, en waar die draait; wie welke namespace mag lezen; hoe lang historie wordt bewaard en wanneer de gegevens van een persoon definitief worden verwijderd; en of een tabel naar een nieuwere specificatieversie gaat, want een lezer die v3 niet kent, leest een tabel die het gebruikt niet. De vraag welke data het gebouw überhaupt mag verlaten, is een aparte, behandeld in Welke data binnen de deur blijft.

Een test die u vandaag kunt doen

Vraag wie in uw bedrijf deze week een nieuwe engine op uw belangrijkste tabel zou kunnen richten en die correct laten lezen, zonder export. Als het antwoord een supportticket bij een leverancier bevat, is het register nog niet van u.