Forklart Lakehouse-arkitektur

For å virkelig forstå hvorfor Lakehouse er et gjennombrudd, må man se på den "gamle måten" å gjøre ting på – et system mange selskaper fortsatt strever med i dag. I flere tiår var data-verdenen delt i to isolerte øyer som rett og slett ikke snakket samme språk.

På den første øya fantes Data Warehouse. Tenk på dette som et svært organisert, eksklusivt bibliotek. Alt er på sin plass, katalogisert i ryddige tabeller og optimalisert for SQL-brukere som skal kjøre rapporter. Dette biblioteket er imidlertid svært kostbart å vedlikeholde. Det er også ganske rigid; det aksepterer bare bøker av en viss størrelse og form. Hvis du prøvde å ta med rå videofiler, rotete sosiale medier-feeder eller enorme logger fra et nettsted, kunne ikke Warehouse håndtere dem.

På den andre øya bygde selskaper Data Lakes. Hvis Warehouse er et bibliotek, er Lake et gigantisk digitalt "loft" eller et enormt lagergulv hvor du kan lagre alle typer rådata billig – bilder, sensordata, lyd, alt mulig. Selv om de var gode for lagring, ble de raskt det vi kaller "Data Swamps". Fordi det ikke var noen organisering eller kvalitetskontroll, var det som å lete etter en nål i en høystakk å finne spesifikk informasjon. I tillegg var de svært vanskelige å søke i med standard SQL, noe som gjorde dem nesten utilgjengelige for tradisjonelle forretningsanalytikere.

Det "rotete" mellomleddet

Det største problemet var imidlertid ikke bare de to øyene – det var broen mellom dem. For å få data fra "Lake" inn i "Warehouse" for rapportering, måtte ingeniører bygge komplekse, skjøre datarørledninger kjent som ETL (Extract, Transform, Load). Dette førte til tre store "datahodepiner":

• Utdaterte data: når dataene var flyttet, renset og formatert fra lake til warehouse, var de ofte timer, dager eller til og med uker gamle. I en moderne virksomhet er gårsdagens data ofte for sent;
• Inkonsistens: man endte ofte opp med et "versjon av sannheten"-problem. En Python-utvikler som jobbet med råfiler i Lake kunne beregne fortjenestemargin annerledes enn en SQL-analytiker som så på de bearbeidede tabellene i Warehouse;
• Høye kostnader: man betalte i praksis for å lagre de samme dataene to ganger. Enda verre, man betalte høyt kvalifiserte ingeniører bare for å holde "broen" oppe hver gang et dataformat endret seg.

Innføring i Lakehouse

Databricks introduserer Lakehouse-arkitekturen for å samle disse to øyene til ett samlet kontinent. Den ligger direkte på din rimelige skylagring, men legger til et viktig forvaltningslag – kalt Delta Lake. Dette laget gir "reglene" til et bibliotek på "skalaen" til et lager.

Med en Lakehouse får du endelig:

• Én sannhetskilde: alle, fra SQL-analytikeren som bygger dashbord til dataforskeren som trener en AI-modell, jobber med de samme dataene samtidig;
• Lager-ytelse til innsjø-pris: du får lynrask hastighet og pålitelighet som en database, uten den høye prisen til et tradisjonelt lager;
• Støtte for alle datatyper: enten det er en strukturert salgstabell som ligner et Excel-ark eller en ustrukturert videofil, lever alt i ett administrert og sikkert miljø.

Hvorfor dette er fremtiden

Ved å fjerne behovet for å flytte data frem og tilbake, lar Databricks team fokusere på innsikt i stedet for infrastruktur. Du trenger ikke lenger velge mellom "fleksibiliteten" til en innsjø og "strukturen" til et lager. Du får begge deler. For deg som lærer betyr dette at når du mestrer Databricks-miljøet, mestrer du i praksis hele den moderne datalivssyklusen – fra øyeblikket data blir til, til det blir en forretningsbeslutning.