--- title: "Delta Lake: når virksomheden står på Microsoft" url: "https://hurukan.com/da/blog/delta-lake-naar-virksomheden-staar-paa-microsoft" description: "OneLake gemmer tabeller som Delta Parquet. Hvad Delta-loggen giver virksomhedens register, hvad Microsoft Fabric styrer for dig, og hvad du selv skal beslutte." --- # Delta Lake: når virksomheden står på Microsoft 1\. oktober 2026·4 min. læsning·Redaktionen En økonomicontroller set fra siden ved et ståbord i et åbent kontor, en bred skærm viser en abstrakt blågrå hovedbog med en kolonne af versionsnumre, en anden skærm med en kalender, grå vægge og en tynd blå LED-liste under bordet En virksomhed har kørt på Microsoft i femten år. Mail, dokumenter og møder i Microsoft 365, rapporter i Power BI og på det seneste et Fabric-arbejdsområde, hvor datateamet lander udtræk fra ERP. Når sådan en virksomhed overvejer et operativsystem for hele forretningen, er IT’s første spørgsmål rimeligt: ender registret et sted, hvor vores værktøjer stadig kan læse det? For en virksomhed i den situation går svaret gennem Delta Lake. OneLake, lageret under Fabric, gemmer sine tabeller som Delta Parquet ifølge [Microsofts dokumentation](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview), så et register i Delta er et register, Fabric kan læse uden en kopi. Hurukans integration med Microsoft 365 Copilot er planlagt, ikke i drift, og datalaget er under opbygning; denne tekst handler om, hvad Delta Lake giver registret i den sammenhæng, og hvad virksomheden selv skal beslutte. Hvorfor registret overhovedet findes, står i [den levende tilstand og registret](https://hurukan.com/da/blog/den-levende-tilstand-og-registret-to-hukommelser). ## Hvad loggen gør Delta Lake tilføjer én ting til en mappe med Parquet-filer: en transaktionslog. `_delta_log/` rummer én JSON-fil pr. commit, navngivet efter version, som hver angiver, hvilke filer der blev tilføjet eller fjernet, og hvad skema og protokol er. Periodiske Parquet-kontrolpunkter (checkpoints) opsummerer loggen, så en læser ikke skal afspille den fra begyndelsen. [Protokoldokumentet](https://github.com/delta-io/delta/blob/master/PROTOCOL.md) definerer dette; udgivelse [4.4.0](https://github.com/delta-io/delta/releases) er den aktuelle (kontrolleret den 21. oktober 2026). Af den ene mekanisme følger alt, hvad registret har brug for. En skrivning er atomisk, fordi commit-filen enten findes eller ej. Læsere ser en hel version, fordi de læser et nummereret commit, ikke en mappeliste. To skribenter ødelægger ikke hinanden, fordi optimistisk samtidighed opdager konflikten ved commit. Og “tabellen, som den var, da agenten foreslog dette” er et versionsnummer, hvilket er det, der gør revisionsspørgsmålet besvarligt. ## De funktioner, der betyder noget for et register Deltas tabelfunktioner (table features) slås til pr. tabel og bæres i protokollen, så en læser ved, om den kan læse det, den kigger på. [Versionssiden](https://docs.delta.io/latest/versioning.html) oplister dem med de læser- og skriverversioner, de kræver (kontrolleret den 21. oktober 2026). Fire af dem former et virksomhedsregister. **Sletningsvektorer** (deletion vectors) markerer rækker som fjernet uden at omskrive filen, så en sletteanmodning for én person ikke omskriver et års fakturaer. Fjernelsen bliver endelig, når de gamle filer ryddes med vacuum, og det er en opbevaringsindstilling, ikke en automatisk virkning. **Change Data Feed** viser, hvad der ændrede sig mellem to versioner, og det er sådan, tabeller og agenter længere nede lærer om en ændring uden at genlæse alt. **Liquid clustering** erstatter faste partitioner med klyngenøgler, der kan ændres senere, så layoutet kan følge, hvordan registret faktisk forespørges. **UniForm** skriver Iceberg-metadata ved siden af Delta-loggen, så motorer, der læser Iceberg, ser den samme tabel. Det kræver kolonnemapping, er skrivebeskyttet fra Iceberg-siden og har dokumenterede begrænsninger omkring sletningsvektorer og ændringsdata, beskrevet under [Delta UniForm](https://docs.delta.io/latest/delta-uniform.html). Seriens tekst om [XTable og UniForm](https://hurukan.com/da/blog/et-register-laesbart-for-de-vaerktoejer-du-allerede-har-xtable-og-uniform) går i dybden med, hvad det køber. ## Hvad Fabric styrer, og hvad det ikke styrer En administreret platform tager reelt arbejde fra virksomheden: lager, beregning, motorerne, forbindelsen til Power BI og i stigende grad vedligeholdelsesjobbene. Det er et fornuftigt sted for et register, hvis virksomheden allerede har besluttet at stå på Microsoft. Fire ting forbliver virksomhedens, uanset om den bemærker det. **Kataloget.** OneLake bestemmer, hvad en tabel hedder, hvem der må læse den, og hvor den aktuelle version er erklæret. Filerne er åbne; fortegnelsen over filerne er platformens. En exitplan, der siger “vi har Parquet i en sø”, har ikke taget højde for den fortegnelse. **Opbevaring og sletning.** Logopbevaring og vacuum-tærskler er tabelindstillinger. De afgør, hvor langt tidsrejse (time travel) rækker, og hvornår en slettet person faktisk er væk. Ingen på platformen sætter dem for dig, og en agent i Hurukan kan foreslå dem, men godkender dem ikke. **Aktivering af funktioner.** At slå en nyere funktion til hæver protokolversionen og kan lukke en ældre læser andetsteds i virksomheden ude. Gevinsten er reel; det er den læser, der holder op med at virke, også. Et menneske beslutter, tabel for tabel, med listen over læsere foran sig. **Skrivevejen.** Delta kan skrives af mange motorer, men den motor, der skriver en given tabel, er en designbeslutning, fordi det er dér, ejerskabet til data ligger. I Hurukan skriver modulerne gennem registrets egen vej, og platformen læser; det omvendte er en anden arkitektur. Hvilke af disse virksomheden ejer, er netop spørgsmålet under [sikkerhed og suverænitet](https://hurukan.com/da/system/sikkerhed-og-suveraenitet): infrastruktur, som virksomheden vælger, data og modeller, der forbliver virksomhedens, en udgang, der er mulig i praksis. ## Hvor agenter hjælper, og hvor de stopper Vedligeholdelsen af et Delta-register er mekanisk og løbende: kompaktering, vacuum, statistik, klyngedannelse. Agenter udarbejder disse job godt, og de forklarer en langsom forespørgsel bedre, end et dashboard gør. I Hurukan er hvert sådant job et forslag i godkendelsesindbakken med begrundelsen vedlagt, godkendt af et menneske og registreret som enhver anden ændring. Hvad agenter ikke gør, er at beslutte opbevaring, godkende en protokolopgradering eller vælge skrivevejen. De tre beslutninger fastlægger, hvad registret senere kan bevise, og en virksomhed skal kunne sige, hvem der traf dem. ## En test, du kan lave i dag Åbn én tabel, som dit Fabric-arbejdsområde allerede rummer, og find tre indstillinger: dens logopbevaring, dens vacuum-tærskel og den protokolversion, den kræver af en læser. Står de tre, hvor platformen efterlod dem, har ingen endnu besluttet, hvor langt tilbage jeres register rækker, eller hvilke af jeres værktøjer der kan læse det næste år. Det er den første beslutning, et virksomhedsregister har brug for, og den koster intet at træffe. - Delta Lake - Microsoft Fabric - OneLake - transaktionslog - suverænitet ## Læs videre - [Én identitet for mennesker og agenter: hvem må hvad](https://hurukan.com/da/blog/en-identitet-for-mennesker-og-agenter) - [Den levende tilstand og registret: to hukommelser i et operativsystem for virksomheden](https://hurukan.com/da/blog/den-levende-tilstand-og-registret-to-hukommelser)