Delta Lake: när företaget står på Microsoft

Ett företag har kört på Microsoft i femton år. E-post, dokument och möten i Microsoft 365, rapporter i Power BI, och på senare tid en Fabric-arbetsyta där datateamet landar uttag från ERP-systemet. När ett sådant företag överväger ett operativsystem för hela verksamheten är den första frågan från IT rimlig: hamnar registret någonstans där våra verktyg fortfarande kan läsa det?

För ett företag i den positionen går svaret genom Delta Lake. OneLake, lagringen under Fabric, håller sina tabeller som Delta Parquet enligt Microsofts dokumentation, så ett register i Delta är ett register Fabric kan läsa utan kopia. Hurukans integration med Microsoft 365 Copilot är planerad, inte i drift, och datalagret är under uppbyggnad; den här texten handlar om vad Delta Lake ger registret i den miljön, och vad som förblir företagets att besluta. Varför registret alls finns står i det levande tillståndet och registret.

Vad loggen gör

Delta Lake lägger till en sak till en katalog med Parquet-filer: en transaktionslogg. _delta_log/ rymmer en JSON-fil per commit, namngiven efter version, var och en med vilka filer som lades till eller togs bort och vad schemat och protokollet är. Periodiska Parquet-kontrollpunkter sammanfattar loggen så att en läsare inte spelar upp den från början. Protokolldokumentet definierar det; version 4.4.0 är aktuell (kontrollerat den 21 oktober 2026).

Ur den ena mekanismen följer allt registret behöver. En skrivning är atomär eftersom commit-filen antingen finns eller inte finns. Läsare ser en hel version eftersom de läser en numrerad commit, inte en kataloglistning. Två skrivare förstör inte för varandra eftersom optimistisk samtidighet upptäcker konflikten vid commit. Och “tabellen som den var när agenten föreslog det här” är ett versionsnummer, vilket är det som gör revisionsfrågan besvarbar.

Funktionerna som spelar roll för ett register

Deltas tabellfunktioner aktiveras per tabell och bärs i protokollet, så att en läsare vet om den kan läsa det den tittar på. Versionssidan listar dem med de läsar- och skrivarversioner de kräver (kontrollerat den 21 oktober 2026). Fyra av dem formar ett företagsregister.

Raderingsvektorer markerar rader som borttagna utan att skriva om filen, så att en begäran om radering för en person inte skriver om ett års fakturor. Borttagningen blir slutgiltig när de gamla filerna rensas med vacuum, vilket är en bevarandeinställning, inte en automatisk effekt.

Change Data Feed exponerar vad som ändrades mellan två versioner, vilket är hur tabeller nedströms och agenter får veta om en ändring utan att läsa om allt.

Liquid clustering ersätter fasta partitioner med klusternycklar som kan ändras senare, så att layouten kan följa hur registret faktiskt frågas.

UniForm skriver Iceberg-metadata bredvid Delta-loggen, så att motorer som läser Iceberg ser samma tabell. Det kräver kolumnmappning, är skrivskyddat från Iceberg-sidan och har dokumenterade gränser kring raderingsvektorer och ändringsdata, beskrivna under Delta UniForm. Serietexten om XTable och UniForm går in på vad det ger.

Vad Fabric hanterar, och vad det inte gör

En hanterad plattform tar verkligt arbete från företaget: lagring, beräkning, motorerna, Power BI-kopplingen och alltmer underhållsjobben. Det är en vettig plats för ett register om företaget redan har bestämt sig för att stå på Microsoft. Fyra saker förblir företagets vare sig det märker det eller inte.

Katalogen. OneLake avgör vad en tabell heter, vem som får läsa den och var den aktuella versionen deklareras. Filerna är öppna; förteckningen över filer är plattformens. En utträdesplan som säger “vi har Parquet i en sjö” har inte räknat med den förteckningen.

Bevarande och radering. Loggbevarande och vacuum-trösklar är tabellinställningar. De avgör hur långt tidsresan når och när en raderad person faktiskt är borta. Ingen på plattformen sätter dem åt dig, och en agent i Hurukan kan föreslå dem men godkänner dem inte.

Aktivering av funktioner. Att slå på en nyare funktion höjer protokollversionen och kan stänga ute en äldre läsare någon annanstans i företaget. Vinsten är verklig; det är läsaren som slutar fungera också. En människa beslutar, per tabell, med listan över läsare framför sig.

Skrivvägen. Delta kan skrivas av många motorer, men vilken motor som skriver en given tabell är ett designbeslut, eftersom det är där ägandet av datan sitter. I Hurukan skriver modulerna genom registrets egen väg och plattformen läser; det omvända är en annan arkitektur.

Vilka av dessa företaget äger är precis frågan under säkerhet och suveränitet: infrastruktur som företaget väljer, data och modeller som förblir företagets, ett utträde som är möjligt i praktiken.

Var agenter hjälper, och var de stannar

Underhållet av ett Delta-register är mekaniskt och kontinuerligt: komprimering, vacuum, statistik, klustring. Agenter utarbetar de jobben väl, och de förklarar en långsam fråga bättre än en instrumentpanel gör. I Hurukan är varje sådant jobb ett förslag i godkännandekorgen med sitt resonemang bifogat, godkänt av en människa och registrerat som vilken annan ändring som helst.

Vad agenter inte gör är att besluta om bevarande, godkänna en protokolluppgradering eller välja skrivvägen. De tre besluten avgör vad registret kan bevisa senare, och ett företag måste kunna säga vem som fattade dem.

Ett test du kan göra i dag

Öppna en tabell som din Fabric-arbetsyta redan rymmer och hitta tre inställningar: dess loggbevarande, dess vacuum-tröskel och den protokollversion den kräver av en läsare. Om de tre står där plattformen lämnade dem har ingen ännu beslutat hur långt tillbaka ditt register når eller vilka av dina verktyg som kommer att kunna läsa det nästa år. Det är det första beslut ett företagsregister behöver, och det kostar ingenting att fatta.