--- title: "Revisjonssporet er en tabell: Delta Lake, Iceberg eller Hudi" url: "https://hurukan.com/no/blog/revisjonssporet-er-en-tabell" description: "Hvem endret hva, og hva så agenten da den foreslo det? Delta Lake, Iceberg og Hudi svarer ulikt. Velg etter katalog og infrastruktur." --- # Revisjonssporet er en tabell: Delta Lake, Iceberg eller Hudi 26\. september 2026·4 min lesing·Redaksjonen En revisor sett bakfra ved et langt bord i et møterom av glass, tre innbundne hovedbøker åpne side om side, en bærbar som viser en abstrakt blågrå versjonsliste, en tynn blå lysstripe langs bordkanten En revisor stiller et enkelt spørsmål om en betaling godkjent i mars: hva så personen som godkjente den på skjermen, og hva hadde agenten som utarbeidet den, lest før den foreslo den? I de fleste virksomheter er svaret en rekonstruksjon. Noen henter en sikkerhetskopi, noen andre søker i en innboks, og resultatet er en kvalifisert gjetning om en tilstand som ikke lenger finnes. I Hurukan er hvert agentforslag og hver menneskelig beslutning en hendelse i virksomhetens register, og registeret er utformet slik at dette spørsmålet har et enkelt svar: en versjon av tabellene slik de sto i det øyeblikket. Den egenskapen kommer ikke fra filene. Den kommer fra tabellformatet oppå dem. Denne teksten handler om hva de tre åpne tabellformatene gjør med spørsmålet, og hvordan man velger mellom dem. Datalaget er under bygging; det som følger, er hvordan det utformes. Begrunnelsen for å ha et register i det hele tatt finnes i [nåtilstand og register](https://hurukan.com/no/blog/naatilstand-og-registeret-to-minner). ## Hva et revisjonsspor trenger fra en tabell Filer i registeret redigeres aldri. En endring skriver nye filer og en ny versjon av tabellens metadata som sier hvilke filer som nå teller. Tre ting følger for revisjonen. **Hver versjon kan adresseres.** «Tabellen slik den var klokken 14:02 den 12. mars» må være en gyldig spørring, ikke en gjenopprettingsjobb. I formatene nedenfor er dette tidsreise (time travel), og det er mekanismen bak «hva så agenten». **Hver versjon har en opphavsperson.** Metadataene til en endring må bære hvem eller hva som gjorde den: en person, en agent som handler på en persons godkjenning, eller en systemoppgave som komprimering. Hurukan registrerer aktøren i sin egen beslutningslogg, men tabellversjonen er beviset på at loggen stemmer med dataene. **Gamle versjoner utløper med vilje, ikke ved et uhell.** Å beholde hver versjon for alltid er en kostnad; å fjerne dem er en beslutning om oppbevaring og, for personopplysninger, om sletting. Den beslutningen tilhører en person, og tabellformatet må gjøre den eksplisitt. ## Tre måter å holde planen på Hvert format holder en plan over hvilke filer som utgjør tabellen. Planen er der revisjonen bor. **Delta Lake** holder en logg: en katalog `_delta_log/` med én JSON-fil per commit, navngitt med et tjuesifret versjonsnummer, der hver lister handlinger som `add`, `remove`, `metaData` og `protocol`, med periodiske Parquet-kontrollpunkter slik at en leser ikke spiller av hele historikken. [Protokollen](https://github.com/delta-io/delta/blob/master/PROTOCOL.md) definerer den; gjeldende utgivelse er [4.4.0](https://github.com/delta-io/delta/releases) (kontrollert 21. oktober 2026). Loggoppbevaring er som standard 30 dager og `VACUUM` 7 dager, som betyr at tidsreise bare rekker så langt tilbake som de to innstillingene tillater. **Apache Iceberg** holder et tre: en tabellmetadatafil peker til et øyeblikksbilde, øyeblikksbildet til en manifestliste, manifestene til data- og slettefiler med statistikken deres. En commit er et atomisk bytte av pekeren til metadatafilen, og byttet skjer i katalogen. [Spesifikasjonen](https://iceberg.apache.org/spec/) er på versjon 3, med slettevektorer, radopphav og VARIANT-typen; gjeldende utgivelse er [1.12.0](https://github.com/apache/iceberg/releases) (kontrollert 21. oktober 2026). **Apache Hudi** holder en tidslinje: hver handling på tabellen — commit, komprimering, opprydding, tilbakerulling, gjenoppretting — er et øyeblikk med en tilstand, og tidslinjens historikk arkiveres i en LSM-struktur. Poster har nøkler og en indeks, så en endring på én kunde berører én filgruppe heller enn en partisjon. Tabeller er Copy-on-Write eller Merge-on-Read, og utgivelse [1.2.1](https://hudi.apache.org/releases/release-1.2) la til tabellversjon 9 (kontrollert 21. oktober 2026). Dokumentasjonen for [tidslinjen](https://hudi.apache.org/docs/timeline) beskriver tilstandene. Alle tre svarer revisoren. Forskjellen er hvor svaret oppbevares og hvem andre som kan lese det. ## Velg etter katalog, ikke etter funksjonsliste Funksjonslistene har nærmet seg hverandre: transaksjoner, tidsreise, skjemaevolusjon, sletting på radnivå og strømmende skriving finnes i alle. Det som ikke har nærmet seg, er stedet der gjeldende versjon av en tabell erklæres, og det stedet er der suverenitet avgjøres. **For Delta Lake er det selve loggkatalogen**, så enhver motor som kan lese lagringen, kan finne gjeldende versjon. I praksis er katalogen rundt den Unity Catalog eller, i Microsoft Fabric, OneLake, som lagrer tabellene sine som Delta Parquet ifølge [Microsofts dokumentasjon](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview). **For Iceberg er det katalogpekeren**, og katalogen snakker en åpen [REST-spesifikasjon](https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml). Apache Polaris, et toppnivåprosjekt siden februar 2026 med utgivelse 1.8.0, implementerer den; Snowflake, AWS S3 Tables, Googles lakehouse-katalog og Databricks leser og skriver alle Iceberg-tabeller gjennom den (kontrollert 21. oktober 2026). **For Hudi er det tidslinjen på lagringen**, lest direkte av Spark, Flink, Trino og Presto; andre plattformer når som regel en Hudi-tabell gjennom metadataoversettelse. Så spørsmålet for en virksomhet er ikke «hvilket format har best revisjon». Det er: på hvem sin infrastruktur kjører katalogen, hvilke motorer må lese registeret, og kan registeret tas med hvis leverandøren byttes? Hurukans svar er at katalogen og filene kjører på infrastruktur virksomheten velger, som beskrevet under [sikkerhet og suverenitet](https://hurukan.com/no/system/sikkerhet-og-suverenitet), og at formatet følger av motorene virksomheten allerede har, ikke omvendt. ## Hva som blir hos mennesker Agenter er gode på den mekaniske delen av datalaget: å utarbeide komprimeringsplanen, skrive jobben som lar gamle øyeblikksbilder utløpe, foreslå en partisjonsendring når spørringer blir trege. Hvert av dem er et forslag i godkjenningsinnboksen, med begrunnelsen vedlagt, og hvert registreres når det godkjennes. Tre beslutninger delegeres aldri. **Oppbevaring og sletting.** Hvor langt tilbake tidsreisen rekker, er samme innstilling som hvor lenge personopplysninger overlever en sletteforespørsel. En person setter den per tabell og signerer. **Protokolloppgraderinger.** Å slå på en nyere tabellfunksjon kan stenge ute en eldre motor som fortsatt leser registeret. Gevinsten er reell; det er også leseren som blir mørk. En person veier det. **Selve formatet.** Å endre det senere er mulig, slik neste tekst i denne serien om [XTable og UniForm](https://hurukan.com/no/blog/ett-register-lesbart-for-verktoyene-du-har) forklarer, men det er et prosjekt, ikke en innstilling. ## En test du kan gjøre i dag Ta én beslutning fra forrige kvartal som en revisor rimeligvis kunne spørre om: en kredittgrense som ble hevet, en leverandør som ble godkjent, en rabatt som ble gitt. Skriv ned, ut fra systemene dine alene, hva beslutningstakeren så i det øyeblikket. Tell systemene du måtte åpne og stedene du måtte gjette. Det tallet er avstanden mellom registeret ditt i dag og ett der revisjonssporet er en tabell. - tabellformater - Delta Lake - Apache Iceberg - Apache Hudi - revisjonsspor ## Les videre - [Én identitet for mennesker og agenter: hvem får gjøre hva](https://hurukan.com/no/blog/en-identitet-for-mennesker-og-agenter) - [Nåtilstand og register: to minner i et operativsystem for virksomheten](https://hurukan.com/no/blog/naatilstand-og-registeret-to-minner)