Problemet med Traditionelle Datatabeller

1. Manglende Atomicitet (Delvise Skrivninger)

Forestil dig, at din klynge er halvvejs gennem at skrive 50.000 nye diamantposter til en fil, når strømmen går eller netværket fejler.

Resultatet: Du ender med en "korrupt" fil. Halvdelen af dataene er der, halvdelen mangler, og din analyse er nu permanent forkert. Traditionelle filer har ikke en "alt eller intet"-regel.

2. Ingen Schema Enforcement

I en traditionel opsætning er der intet, der forhindrer en bruger i ved et uheld at uploade en diamantpost, hvor "Price" er et stykke tekst (som "Expensive") i stedet for et tal.

Resultatet: Næste gang du forsøger at køre en sum eller gennemsnit, crasher hele din pipeline, fordi "matematikken" ikke kan håndtere teksten. Rå filer er "stille fejl" — de accepterer dårlige data uden at klage.

3. "To kokke"-problemet (Samtidighed)

Hvad sker der, hvis to forskellige dataingeniører forsøger at opdatere Diamonds-tabellen på præcis samme sekund?

Resultatet: Den ene persons ændringer vil sandsynligvis overskrive den andens, eller filen vil blive låst og ubrugelig. Traditionelle filsystemer er ikke designet til, at flere personer læser og skriver til de samme data samtidigt.

4. Ingen "Fortryd"-knap

Hvis du ved et uheld kører en kommando, der sletter alle "Premium" cut diamanter fra dit datasæt, er disse data væk. I et standard filsystem er der ingen indbygget "historik" eller "fortryd"-knap, der viser, hvordan tabellen så ud for fem minutter siden.

Udviklingen: Hvorfor vi har brug for Delta Lake

Disse problemer er grunden til, at virksomheder bevæger sig væk fra Data Lakes (bare mapper med filer) og over mod Lakehouse.

For at løse disse udfordringer har Databricks skabt Delta Lake. Det tilføjer en "transaktionslog" til dine filer — fungerer som en sofistikeret revisor, der:

• Sporer alle ændringer;
• Sikrer, at ingen dårlige data kommer ind;
• Gør det muligt at "rejse tilbage i tiden" til tidligere versioner, hvis der sker en fejl.