Ongelma Perinteisissä Tietotauluissa

1. Atomisuuden puute (osittaiset kirjoitukset)

Kuvittele, että klusterisi on puolivälissä kirjoittamassa 50 000 uutta timanttitietuetta tiedostoon, kun virta katkeaa tai verkko epäonnistuu.

Tulos: Saat "vioittuneen" tiedoston. Osa tiedoista on tallessa, osa puuttuu, ja analyysisi on nyt pysyvästi virheellinen. Perinteisissä tiedostoissa ei ole "kaikki tai ei mitään" -sääntöä.

2. Skeeman valvonnan puute

Perinteisessä ympäristössä mikään ei estä käyttäjää vahingossa lataamasta timanttitietuetta, jossa "Price"-kenttä on tekstiä (esim. "Expensive") numeron sijaan.

Tulos: Seuraavalla kerralla, kun yrität laskea summan tai keskiarvon, koko putkesi kaatuu, koska "laskenta" ei pysty käsittelemään tekstiä. Raakatiedostot ovat "hiljaisia virheitä" — ne hyväksyvät virheellisen datan ilman varoitusta.

3. "Kaksi kokkia" -ongelma (Rinnakkaisuus)

Mitä tapahtuu, jos kaksi eri data-insinööriä yrittää päivittää Diamonds-taulua täsmälleen samalla sekunnilla?

Tulos: Toinen muutoksista todennäköisesti ylikirjoittaa toisen, tai tiedosto lukittuu ja muuttuu käyttökelvottomaksi. Perinteiset tiedostojärjestelmät eivät ole suunniteltu siihen, että useat henkilöt lukevat ja kirjoittavat samaan dataan samanaikaisesti.

4. "Ei peruuta" -painiketta

Jos suoritat vahingossa komennon, joka poistaa kaikki "Premium"-luokan timantit tietoaineistostasi, nämä tiedot ovat poissa. Tavallisessa tiedostojärjestelmässä ei ole sisäänrakennettua "historia"- tai "peruuta"-painiketta, jolla näkisit, miltä taulu näytti viisi minuuttia sitten.

Kehitys: Miksi tarvitsemme Delta Laken

Nämä ongelmat ovat syy siihen, miksi yritykset siirtyvät pois Data Lakeista (pelkät kansiotiedostot) kohti Lakehousea.

Näiden haasteiden ratkaisemiseksi Databricks kehitti Delta Laken. Se lisää tiedostoihin "transaktiolokin" — toimien kuin kehittynyt kirjanpitäjä, joka:

• Seuraa jokaista muutosta;
• Varmistaa, ettei virheellistä dataa pääse sisään;
• Mahdollistaa "aikamatkailun" aiempiin versioihin, jos virhe tapahtuu.