Forklaring af Lakehouse-Arkitekturen

For virkelig at forstå, hvorfor Lakehouse er et gennembrud, skal man se på den "gamle måde" at gøre tingene på – et system, som mange virksomheder stadig kæmper med i dag. I årtier var dataområdet delt op i to isolerede øer, der simpelthen ikke talte samme sprog.

På den første ø var der Data Warehouse. Tænk på dette som et meget organiseret, eksklusivt bibliotek. Alt er på sin plads, katalogiseret i pæne tabeller og optimeret til SQL-brugere, der skal køre rapporter. Dette bibliotek er dog meget dyrt at vedligeholde. Det er også ret stift; det accepterer kun bøger af en bestemt størrelse og form. Hvis du prøvede at bringe rå videofiler, rodede sociale medie-feeds eller massive logfiler fra et website ind, kunne Warehouse simpelthen ikke håndtere dem.

På den anden ø byggede virksomheder Data Lakes. Hvis Warehouse er et bibliotek, er Lake et kæmpe digitalt "loft" eller et stort lagergulv, hvor du kan smide alle former for rå data billigt – billeder, sensordata, lyd, hvad som helst. Selvom de var gode til at lagre alt, blev de hurtigt til det, vi kalder "Data Swamps". Fordi der ikke var nogen organisering eller kvalitetskontrol, var det som at lede efter en nål i en høstak at finde specifik information. Derudover var de utroligt svære at forespørge med standard SQL, hvilket gjorde dem næsten utilgængelige for traditionelle forretningsanalytikere.

Det "Rodede" Mellemstadie

Det største problem var dog ikke kun de to øer – det var broen mellem dem. For at få data fra "Lake" ind i "Warehouse" til rapportering, måtte ingeniører bygge komplekse, skrøbelige pipelines kendt som ETL (Extract, Transform, Load). Dette førte til tre store "datahovedpiner":

• Forældede data: Når dataene var flyttet, renset og formateret fra lake til warehouse, var de ofte timer, dage eller endda uger gamle. I en moderne virksomhed er gårsdagens data ofte for sent;
• Inkonsistens: Man endte ofte med et "version of the truth"-problem. En Python-udvikler, der arbejder med rå filer i Lake, kunne beregne en profitmargin anderledes end en SQL-analytiker, der ser på de behandlede tabeller i Warehouse;
• Høje omkostninger: Man betalte reelt for at lagre de samme data to gange. Endnu værre, man betalte højt kvalificerede ingeniører blot for at holde "broen" kørende, hver gang et dataformat ændrede sig.

Introduktion til Lakehouse

Databricks introducerer Lakehouse-arkitekturen for at samle disse to øer til ét samlet kontinent. Den ligger direkte oven på din billige cloud-lagring, men tilføjer et vigtigt administrationslag - kaldet Delta Lake. Dette lag bringer "reglerne" fra et bibliotek til "skalaen" fra lagergulvet.

Med en Lakehouse får du endelig:

• Én enkelt sandhedskilde: alle, fra SQL-analytikeren der bygger et dashboard til Data Scientist'en der træner en AI-model, arbejder med de samme data på samme tid;
• Lagerpræstation på et Lake-budget: du får den lynhurtige hastighed og pålidelighed fra en database uden den store pris fra et traditionelt lager;
• Understøttelse af alle datatyper: uanset om det er en struktureret salgstabel, der ligner et Excel-ark, eller en ustruktureret videofil, lever det hele i ét administreret, sikkert miljø.

Hvorfor dette er fremtiden

Ved at fjerne behovet for at flytte data frem og tilbage, gør Databricks det muligt for teams at fokusere på indsigt frem for infrastruktur. Du behøver ikke længere vælge mellem "fleksibiliteten" fra en lake og "strukturen" fra et lager. Du får begge dele. For dig som lærende betyder det, at når du først mestrer Databricks-miljøet, mestrer du i bund og grund hele den moderne datalivscyklus – fra det øjeblik data opstår, til det bliver til en forretningsbeslutning.