Problemet med Tradisjonelle Datatabeller

1. Manglende atomisitet (delvise skrivinger)

Tenk deg at klyngen din er halvveis i å skrive 50 000 nye diamantposter til en fil når strømmen går eller nettverket svikter.

Resultatet: Du ender opp med en «korrupt» fil. Halvparten av dataene er der, halvparten mangler, og analysen din er nå permanent feil. Tradisjonelle filer har ikke en «alt eller ingenting»-regel.

2. Ingen skjema-håndhevelse

I en tradisjonell løsning er det ingenting som hindrer en bruker i å ved et uhell laste opp en diamantpost der "Price" er et tekstfelt (som "Expensive") i stedet for et tall.

Resultatet: Neste gang du prøver å kjøre en sum eller et gjennomsnitt, krasjer hele datastrømmen fordi «matematikken» ikke kan håndtere tekst. Råfiler gir «stille feil» — de aksepterer ugyldige data uten å varsle.

3. "To kokker"-problemet (Samtidighet)

Hva skjer hvis to forskjellige dataingeniører prøver å oppdatere Diamonds-tabellen på nøyaktig samme sekund?

Resultatet: Endringene til én person vil sannsynligvis overskrive den andres, eller filen blir låst og ubrukelig. Tradisjonelle filsystemer er ikke laget for at flere personer skal lese og skrive til samme data samtidig.

4. Ingen "Angre"-knapp

Hvis du ved et uhell kjører en kommando som sletter alle "Premium"-slipte diamanter fra datasettet ditt, er disse dataene borte. I et standard filsystem finnes det ingen innebygd "historikk" eller "angre"-knapp for å se hvordan tabellen så ut for fem minutter siden.

Utviklingen: Hvorfor vi trenger Delta Lake

Disse problemene er grunnen til at selskaper går bort fra Data Lakes (bare mapper med filer) og over til Lakehouse.

For å løse disse utfordringene har Databricks laget Delta Lake. Det legger til en "transaksjonslogg" til filene dine — som fungerer som en sofistikert regnskapsfører som:

• Sporer hver eneste endring;
• Sikrer at ingen dårlige data kommer inn;
• Lar deg "reise tilbake i tid" til tidligere versjoner hvis det skjer en feil.