Revisionsspåret är en tabell: Delta Lake, Iceberg eller Hudi

En revisor ställer en enkel fråga om en betalning som godkändes i mars: vad såg personen som godkände den på skärmen, och vad hade agenten som utarbetade den läst innan den föreslog den? I de flesta företag är svaret en rekonstruktion. Någon hämtar en säkerhetskopia, någon annan söker i en inkorg, och resultatet är en kvalificerad gissning om ett tillstånd som inte längre finns.

I Hurukan är varje agentförslag och varje mänskligt beslut en händelse i företagets register, och registret är utformat så att den frågan har ett rakt svar: en version av tabellerna som de stod i det ögonblicket. Den egenskapen kommer inte från filerna. Den kommer från tabellformatet ovanpå dem. Den här texten handlar om vad de tre öppna tabellformaten gör med frågan, och hur man väljer mellan dem. Datalagret är under uppbyggnad; det som följer är hur det utformas. Skälet till att alls ha ett register finns i det levande tillståndet och registret.

Vad ett revisionsspår kräver av en tabell

Filer i registret redigeras aldrig. En ändring skriver nya filer och en ny version av tabellens metadata som säger vilka filer som nu räknas. Tre saker följer för revisionen.

Varje version är adresserbar. “Tabellen som den var 14:02 den 12 mars” måste vara en giltig fråga, inte ett återställningsjobb. I formaten nedan är det tidsresa (time travel), och det är mekanismen bakom “vad såg agenten”.

Varje version har en upphovsman. Metadatan för en ändring måste bära vem eller vad som gjorde den: en person, en agent som handlar på en persons godkännande, eller en systemuppgift som komprimering. Hurukan registrerar aktören i sin egen beslutslogg, men tabellversionen är beviset för att loggen stämmer med datan.

Gamla versioner går ut med avsikt, inte av misstag. Att behålla varje version för alltid är en kostnad; att ta bort dem är ett beslut om bevarande och, för personuppgifter, om radering. Det beslutet tillhör en människa, och tabellformatet måste göra det uttryckligt.

Tre sätt att hålla ritningen

Varje format håller en ritning över vilka filer som utgör tabellen. Ritningen är där revisionen bor.

Delta Lake håller en logg: en katalog _delta_log/ med en JSON-fil per commit, namngiven med ett tjugosiffrigt versionsnummer, var och en med åtgärder som add, remove, metaData och protocol, med periodiska Parquet-kontrollpunkter så att en läsare inte spelar upp hela historiken. Protokollet definierar det; aktuell version är 4.4.0 (kontrollerat den 21 oktober 2026). Loggbevarandet är som standard 30 dagar och VACUUM 7 dagar, vilket betyder att tidsresan bara når så långt tillbaka som de två inställningarna tillåter.

Apache Iceberg håller ett träd: en tabellmetadatafil pekar på en ögonblicksbild, ögonblicksbilden på en manifestlista, manifesten på data- och raderingsfiler med deras statistik. En commit är ett atomärt byte av pekaren till metadatafilen, och bytet sker i katalogen. Specifikationen är i version 3, med raderingsvektorer, radhärkomst och typen VARIANT; aktuell version är 1.12.0 (kontrollerat den 21 oktober 2026).

Apache Hudi håller en tidslinje: varje åtgärd på tabellen — commit, komprimering, rensning, återställning — är ett ögonblick med ett tillstånd, och tidslinjens historik arkiveras i en LSM-struktur. Poster har nycklar och ett index, så en ändring av en kund rör en filgrupp snarare än en partition. Tabeller är Copy-on-Write eller Merge-on-Read, och version 1.2.1 lade till tabellversion 9 (kontrollerat den 21 oktober 2026). Dokumentationen om tidslinjen beskriver tillstånden.

Alla tre svarar revisorn. Skillnaden är var svaret förvaras och vem mer som kan läsa det.

Välj efter katalog, inte efter funktionslista

Funktionslistorna har närmat sig varandra: transaktioner, tidsresa, schemautveckling, radering på radnivå och strömmande skrivningar finns i alla. Det som inte har närmat sig är platsen där den aktuella versionen av en tabell deklareras, och den platsen är där suveräniteten avgörs.

För Delta Lake är det loggkatalogen själv, så varje motor som kan läsa lagringen kan hitta den aktuella versionen. I praktiken är katalogen runt den Unity Catalog eller, i Microsoft Fabric, OneLake, som lagrar sina tabeller som Delta Parquet enligt Microsofts dokumentation.

För Iceberg är det katalogpekaren, och katalogen talar en öppen REST-specifikation. Apache Polaris, ett toppnivåprojekt sedan februari 2026 med version 1.8.0, implementerar den; Snowflake, AWS S3 Tables, Googles lakehouse-katalog och Databricks läser och skriver alla Iceberg-tabeller genom den (kontrollerat den 21 oktober 2026).

För Hudi är det tidslinjen på lagringen, läst inbyggt av Spark, Flink, Trino och Presto; andra plattformar når i allmänhet en Hudi-tabell genom metadataöversättning.

Så frågan för ett företag är inte “vilket format har bäst revision”. Den är: på vems infrastruktur körs katalogen, vilka motorer måste läsa registret, och kan registret tas med om leverantören byts? Hurukans svar är att katalogen och filerna körs på infrastruktur som företaget väljer, som beskrivs under säkerhet och suveränitet, och att formatet följer av de motorer företaget redan har snarare än tvärtom.

Vad som stannar hos människor

Agenter är bra på den mekaniska delen av datalagret: att utarbeta komprimeringsschemat, skriva jobbet som låter gamla ögonblicksbilder gå ut, föreslå en partitionsändring när frågor blir långsamma. Vart och ett av dessa är ett förslag i godkännandekorgen, med resonemanget bifogat, och vart och ett registreras när det godkänns. Tre beslut delegeras aldrig.

Bevarande och radering. Hur långt tillbaka tidsresan når är samma inställning som hur länge personuppgifter överlever en begäran om radering. En människa sätter det per tabell och skriver under.

Protokolluppgraderingar. Att aktivera en nyare tabellfunktion kan stänga ute en äldre motor som fortfarande läser registret. Vinsten är verklig; det är läsaren som slocknar också. En människa väger det.

Formatet självt. Att byta det senare är möjligt, som nästa text i serien om XTable och UniForm förklarar, men det är ett projekt, inte en inställning.

Ett test du kan göra i dag

Ta ett beslut från förra kvartalet som en revisor rimligen skulle kunna fråga om: en höjd kreditgräns, en godkänd leverantör, en beviljad rabatt. Skriv ner, enbart från dina system, vad beslutsfattaren såg i det ögonblicket. Räkna de system du var tvungen att öppna och de ställen där du var tvungen att gissa. Den räkningen är avståndet mellan ditt nuvarande register och ett vars revisionsspår är en tabell.