Delta Lake: når virksomheten står på Microsoft

En virksomhet har kjørt på Microsoft i femten år. E-post, dokumenter og møter i Microsoft 365, rapporter i Power BI, og i det siste et Fabric-arbeidsområde der datateamet lander uttrekk fra ERP-systemet. Når en slik virksomhet vurderer et operativsystem for hele virksomheten, er det første spørsmålet fra IT rimelig: havner registeret et sted verktøyene våre fortsatt kan lese?

For en virksomhet i den situasjonen går svaret gjennom Delta Lake. OneLake, lagringen under Fabric, holder tabellene sine som Delta Parquet ifølge Microsofts dokumentasjon, så et register i Delta er et register Fabric kan lese uten kopi. Hurukans integrasjon med Microsoft 365 Copilot er planlagt, ikke i drift, og datalaget er under bygging; denne teksten handler om hva Delta Lake gir registeret i den sammenhengen, og hva som forblir virksomhetens å avgjøre. Hvorfor registeret finnes i det hele tatt, står i nåtilstand og register.

Hva loggen gjør

Delta Lake legger én ting til en katalog med Parquet-filer: en transaksjonslogg. _delta_log/ holder én JSON-fil per commit, navngitt etter versjon, der hver lister hvilke filer som ble lagt til eller fjernet og hva skjemaet og protokollen er. Periodiske Parquet-kontrollpunkter oppsummerer loggen slik at en leser ikke spiller den av fra starten. Protokolldokumentet definerer dette; utgivelse 4.4.0 er gjeldende (kontrollert 21. oktober 2026).

Fra den ene mekanismen følger alt registeret trenger. En skriving er atomisk fordi commit-filen enten finnes eller ikke. Lesere ser en hel versjon fordi de leser en nummerert commit, ikke en katalogliste. To skrivere ødelegger ikke for hverandre fordi optimistisk samtidighet oppdager konflikten ved commit. Og «tabellen slik den var da agenten foreslo dette» er et versjonsnummer, som er det som gjør revisjonsspørsmålet mulig å besvare.

Funksjonene som betyr noe for et register

Deltas tabellfunksjoner slås på per tabell og bæres i protokollen, så en leser vet om den kan lese det den ser på. Versjoneringssiden lister dem med leser- og skriverversjonene de krever (kontrollert 21. oktober 2026). Fire av dem former et virksomhetsregister.

Slettevektorer merker rader som fjernet uten å skrive om filen, så en sletteforespørsel for én person skriver ikke om et år med fakturaer. Fjerningen blir endelig når de gamle filene ryddes med vacuum, som er en oppbevaringsinnstilling, ikke en automatisk effekt.

Change Data Feed eksponerer hva som endret seg mellom to versjoner, som er slik tabeller og agenter nedstrøms får vite om en endring uten å lese alt på nytt.

Liquid clustering erstatter faste partisjoner med klyngenøkler som kan endres senere, så oppsettet kan følge hvordan registeret faktisk spørres.

UniForm skriver Iceberg-metadata ved siden av Delta-loggen, så motorer som leser Iceberg, ser den samme tabellen. Det krever kolonnetilordning, er skrivebeskyttet fra Iceberg-siden og har dokumenterte grenser rundt slettevektorer og endringsdata, beskrevet under Delta UniForm. Serieteksten om XTable og UniForm går inn på hva det gir.

Hva Fabric forvalter, og hva det ikke gjør

En administrert plattform tar reelt arbeid av virksomhetens hender: lagring, regnekraft, motorene, Power BI-koblingen og i økende grad vedlikeholdsjobbene. Det er et fornuftig sted for et register hvis virksomheten allerede har bestemt seg for å stå på Microsoft. Fire ting forblir virksomhetens enten den merker det eller ikke.

Katalogen. OneLake avgjør hva en tabell heter, hvem som får lese den og hvor gjeldende versjon erklæres. Filene er åpne; katalogen over filene er plattformens. En utgangsplan som sier «vi har Parquet i en lake», har ikke tatt høyde for den katalogen.

Oppbevaring og sletting. Loggoppbevaring og vacuum-terskler er tabellinnstillinger. De avgjør hvor langt tidsreisen rekker og når en slettet person faktisk er borte. Ingen hos plattformen setter dem for deg, og en agent i Hurukan kan foreslå dem, men godkjenner dem ikke.

Aktivering av funksjoner. Å slå på en nyere funksjon hever protokollversjonen og kan stenge ute en eldre leser et annet sted i virksomheten. Gevinsten er reell; det er også leseren som slutter å virke. En person avgjør, per tabell, med listen over lesere foran seg.

Skriveveien. Delta kan skrives av mange motorer, men motoren som skriver en gitt tabell, er en designbeslutning, fordi det er der eierskapet til dataene sitter. I Hurukan skriver modulene gjennom registerets egen vei og plattformen leser; det motsatte er en annen arkitektur.

Hvilke av disse virksomheten eier, er nøyaktig spørsmålet under sikkerhet og suverenitet: infrastruktur virksomheten velger, data og modeller som forblir virksomhetens, en utgang som er mulig i praksis.

Hvor agenter hjelper, og hvor de stopper

Vedlikeholdet av et Delta-register er mekanisk og kontinuerlig: komprimering, vacuum, statistikk, klynging. Agenter utarbeider disse jobbene godt, og de forklarer en treg spørring bedre enn et dashbord gjør. I Hurukan er hver slik jobb et forslag i godkjenningsinnboksen med begrunnelsen vedlagt, godkjent av en person og registrert som enhver annen endring.

Det agenter ikke gjør, er å avgjøre oppbevaring, godkjenne en protokolloppgradering eller velge skriveveien. De tre beslutningene fastsetter hva registeret kan bevise senere, og en virksomhet må kunne si hvem som tok dem.

En test du kan gjøre i dag

Åpne én tabell Fabric-arbeidsområdet ditt allerede holder, og finn tre innstillinger: loggoppbevaringen, vacuum-terskelen og protokollversjonen den krever av en leser. Hvis de tre er der plattformen etterlot dem, har ingen ennå avgjort hvor langt tilbake registeret ditt rekker eller hvilke av verktøyene dine som vil kunne lese det neste år. Det er den første beslutningen et virksomhetsregister trenger, og den koster ingenting å ta.