Delta Lake: als het bedrijf op Microsoft draait

Een financieel controller van opzij gezien aan een sta-bureau in een open kantoor, een breed scherm met een abstract blauw-grijs grootboek met een kolom versienummers, een tweede scherm met een agenda, grijze wanden en een dunne blauwe ledstrip onder het bureau

Een bedrijf draait al vijftien jaar op Microsoft. Mail, documenten en vergaderingen in Microsoft 365, rapporten in Power BI, en sinds kort een Fabric-werkruimte waar het datateam extracten uit het ERP neerzet. Wanneer zo’n bedrijf een besturingssysteem voor de hele organisatie overweegt, is de eerste vraag van IT redelijk: komt het register terecht op een plek waar onze tools het nog kunnen lezen?

Voor een bedrijf in die positie loopt het antwoord via Delta Lake. OneLake, de opslag onder Fabric, bewaart zijn tabellen als Delta Parquet volgens de documentatie van Microsoft, dus een register in Delta is een register dat Fabric zonder kopie kan lezen. De integratie van Hurukan met Microsoft 365 Copilot is gepland, niet live, en de laag Data is in aanbouw; deze tekst gaat over wat Delta Lake het register in die situatie geeft, en wat het bedrijf zelf moet beslissen. Waarom het register überhaupt bestaat, staat in de actuele toestand en het register.

Wat het log doet

Delta Lake voegt één ding toe aan een map met Parquet-bestanden: een transactielog. _delta_log/ bevat één JSON-bestand per commit, genummerd naar versie, met telkens welke bestanden zijn toegevoegd of verwijderd en wat het schema en het protocol zijn. Periodieke checkpoints in Parquet vatten het log samen, zodat een lezer het niet vanaf het begin hoeft af te spelen. Het protocoldocument definieert dit; release 4.4.0 is de actuele (gecontroleerd op 21 oktober 2026).

Uit dat ene mechanisme volgt alles wat het register nodig heeft. Een schrijfactie is atomair omdat het commitbestand bestaat of niet bestaat. Lezers zien een hele versie omdat ze een genummerde commit lezen, geen maplijst. Twee schrijvers beschadigen elkaar niet omdat optimistische concurrency het conflict bij de commit opmerkt. En “de tabel zoals hij was toen de agent dit voorstelde” is een versienummer, en dat maakt de auditvraag beantwoordbaar.

De features die voor een register tellen

De table features van Delta worden per tabel ingeschakeld en in het protocol vastgelegd, zodat een lezer weet of hij kan lezen waar hij naar kijkt. De versiepagina noemt ze met de lezer- en schrijverversies die ze vereisen (gecontroleerd op 21 oktober 2026). Vier ervan bepalen de vorm van een bedrijfsregister.

Deletion vectors markeren rijen als verwijderd zonder het bestand te herschrijven, zodat een verwijderverzoek voor één persoon niet een jaar aan facturen herschrijft. De verwijdering wordt definitief wanneer de oude bestanden worden opgeruimd (vacuum), en dat is een bewaarinstelling, geen automatisch gevolg.

Change Data Feed laat zien wat er tussen twee versies is veranderd, en zo horen volgende tabellen en agents van een wijziging zonder alles opnieuw te lezen.

Liquid clustering vervangt vaste partities door clustersleutels die later kunnen veranderen, zodat de indeling kan volgen hoe het register werkelijk wordt bevraagd.

UniForm schrijft Iceberg-metadata naast het Delta-log, zodat engines die Iceberg lezen dezelfde tabel zien. Het vereist column mapping, is vanaf de Iceberg-kant alleen-lezen, en heeft gedocumenteerde beperkingen rond deletion vectors en wijzigingsgegevens, beschreven onder Delta UniForm. De tekst in deze reeks over XTable en UniForm gaat in op wat dat oplevert.

Wat Fabric beheert, en wat niet

Een beheerd platform neemt het bedrijf echt werk uit handen: opslag, rekenkracht, de engines, de koppeling met Power BI, en steeds vaker de onderhoudstaken. Het is een verstandige plek voor een register als het bedrijf al heeft besloten op Microsoft te staan. Vier dingen blijven van het bedrijf, of het dat nu opmerkt of niet.

De catalogus. OneLake bepaalt hoe een tabel heet, wie hem mag lezen en waar de actuele versie wordt vastgelegd. De bestanden zijn open; de map met bestanden is van het platform. Een exitplan dat zegt “we hebben Parquet in een lake” heeft geen rekening gehouden met die map.

Bewaring en verwijdering. Logbewaring en vacuumdrempels zijn tabelinstellingen. Ze bepalen hoe ver time travel terugreikt en wanneer een verwijderde persoon werkelijk weg is. Niemand bij het platform stelt ze voor u in, en een agent in Hurukan mag ze voorstellen maar keurt ze niet goed.

Het inschakelen van features. Een nieuwere feature aanzetten verhoogt de protocolversie en kan een oudere lezer elders in het bedrijf buitensluiten. De winst is echt; de lezer die stopt met werken ook. Een mens beslist, per tabel, met de lijst van lezers voor zich.

Het schrijfpad. Delta kan door veel engines worden geschreven, maar welke engine een bepaalde tabel schrijft, is een ontwerpbeslissing, omdat daar het eigenaarschap van de data ligt. In Hurukan schrijven de modules via het eigen pad van het register en leest het platform; het omgekeerde is een andere architectuur.

Welke van deze dingen het bedrijf bezit, is precies de vraag onder beveiliging en soevereiniteit: infrastructuur die het bedrijf kiest, data en modellen die van het bedrijf blijven, een exit die in de praktijk mogelijk is.

Waar agents helpen, en waar ze stoppen

Het onderhoud van een Delta-register is mechanisch en doorlopend: compactie, vacuum, statistieken, clustering. Agents stellen deze taken goed op, en ze verklaren een trage query beter dan een dashboard dat doet. In Hurukan is elke zo’n taak een voorstel in de goedkeuringsinbox met de redenering erbij, goedgekeurd door een mens en vastgelegd zoals elke andere wijziging.

Wat agents niet doen, is bewaring bepalen, een protocolupgrade goedkeuren of het schrijfpad kiezen. Die drie beslissingen bepalen wat het register later kan bewijzen, en een bedrijf moet kunnen zeggen wie ze heeft genomen.

Een test die u vandaag kunt doen

Open één tabel die uw Fabric-werkruimte al bevat en zoek drie instellingen op: de logbewaring, de vacuumdrempel en de protocolversie die hij van een lezer vraagt. Als alle drie staan waar het platform ze heeft gelaten, heeft nog niemand besloten hoe ver uw register terugreikt of welke van uw tools het volgend jaar nog kunnen lezen. Dat is de eerste beslissing die een bedrijfsregister nodig heeft, en het kost niets om haar te nemen.