De senere år er der er sket store fremskridt i, hvordan vi bygger dataplatforme, og nye begreber og strategier skyller ind over os hele tiden. Ikke nok med at de store cloud-udbydere Microsoft, AWS og Google foretager store investeringer, virksomheder som f.eks. Data Bricks markedsfører sin Delta Lake med stor succes lige nu, og Snowflake er fortsat hot på markedet.
Jeg har arbejdet som udvikler og arkitekt i snart 15 år inden for Business Intelligence, og jeg tænkte, at jeg ville forsøge at finde ud af, hvad det egentlig handler om. Er der tale om et paradigmeskifte eller er det bare dygtige marketingfolk, der har været i gang? Generelt har markedet de seneste år været domineret af to hovedstrategier, hvor Data Lakehouse er det perfekte kompromis, hvor de to bliver til én.
Formålet med et Data Warehouse er overvejende at sammenstille data fra forskellige steder på en måde, der gør det nemt og hurtigt at lave analyser og rapporter og har eksisteret i over 30 år i forskellige former. En database hvor vi har fælles definitioner og beregninger af vores vigtigste nøgletal, og hvordan de forholder sig til hinanden – en stræben efter “a Single version of the Truth” for en organisation, hvor det er nemt at konsumere information af høj kvalitet, så der kan træffes mange bedre beslutninger.
Når man opbygger et Data Warehouse er det per definition et forsøg på at skabe orden, så flere kan arbejde mere datadrevet på en enklere og hurtigere måde uden at skulle bekymre sig for meget om kvaliteten af dataene, og om tallene faktisk er rigtige.
For godt 10 år siden kom Big Data med bulder og brag ind på scenen og gav helt nye muligheder for at gemme og behandle filer af forskellige typer i store mængder. Med tiden kunne vi se, at der blev dannet et parallelt spor med dataplatforme baseret på forskellige varianter af Hadoop-løsninger, som vi for nylig er begyndt at samle under konceptet Data Lakes. Ofte drevet af evnen til at håndtere særligt store, hurtige eller komplekse data, andre med et ønske om at fokusere mere på analyser frem for rapportering.
I en moderne dataplatform i skyen er det dog ofte ikke så sort/hvidt, som det nogle gange fremstilles, vi har længe gjort brug af Data Lakens fordele sammen med databasens styrker i den samlede platform. Med moderne DevOps og mulighed for at skalere ydeevnen er startomkostningerne ved at implementere et Data Warehouse også faldet markant. De, der har investeret i en Data Lake-strategi, har ofte bygget flere lag oven på deres struktur for bedre at kunne genbruge beregninger og få bedre struktur på deres data. Så hvilke hovedudfordringer løser et Data Warehouse egentlig?
Når man afgrænser en informationsmængde med et Schema skaber det klarhed for brugerne og øger graden af genbrugelighed og datakvalitet. Det giver en overskuelig grænseflade, hvor information præsenteres på en enklere måde end blot med en bunke filer, som det ofte er tilfældet i en Data Lake. Det kræver stor viden for at lave et korrekt udtræk, og det er noget som Data Warehouses altid har været meget omhyggelige med.
Et problem, der opstår ved behandling af lidt større datamængder i et Data Warehouse, er dog, at data skal flyttes gennem forskellige lag i en database (schema-on-write), ofte i overensstemmelse med en standardiseret ETL-proces. Noget der ofte tager tid, computerkraft og øger risikoen for at en del ikke virker. Hvis du derudover på et senere tidspunkt finder ud af, at du vil at behandle dataene på en anden måde, kan det betyde lange og komplicerede genindlæsninger. Her ligger et stort potentiale i at adskille beregningslogikken fra lageret, så længe vi kan få tilstrækkelig god ydeevne i udlæsningen.
Data Lakehouse løser dette problem med Schema-on-Read, dvs. at det ikke er nødvendigt fysisk at skrive dataene til disken, men mere som visninger af en mængde filer.
En simpel ting som at have god orden på sine dimensioner, som f.eks. kunder, produkter og afdelinger er en udfordring, hvis du har bygget en løsning baseret på filer i en Data Lake. I et Data Warehouse er dette sjældent et problem. Enten opdaterer man en kunderække med de seneste oplysninger eller også har man en form for historikstyring. Dette er ikke helt trivielt at løse, hvis kundeoplysningerne er spredt i mange filer, og du kan blive tvunget til at læse tusindvis af filer igennem for at finde ud af, hvilken adresse en kunde havde for et år siden.
Her er der et stort potentiale for at fremskynde processen, især for dem, der arbejder med friere analyser, og også for at øge kvaliteten af analyserne. I et Data Lakehouse burde dette fungere lige så smidigt som i en database, men det er forskelligt afhængig af leverandør og implementering.
En platform til at understøtte behovene for både Data Science og traditionel BI gør os i stand til i højere grad at bruge og produktionssætte avancerede analyser i rapporter, dashboards og i driftsprocesser. Oftest vil den store værdi af avancerede analyser vise sig, når brugen udbredes, og de mange små beslutninger kan optimeres. Hvis teamene samtidig kan arbejde mere sammen, mindskes risikoen for dobbeltarbejde, og vi kan få endnu mere værdi i forretningsdriften.
Jeg synes, at det er vigtigt hele tiden at udfordre måden, vi arbejder på, for at se, om det er muligt at gøre det bedre og mere effektivt. Der er meget at vinde ved ikke at være fanget i eksempelvis at skulle have en database for at bygge et Data Warehouse, og vi har set utallige eksempler på mislykkede forsøg på at bygge f.eks. økonomisk rapportering oven på en Data Lake, hvor det ofte endte med at der alligevel blev bygget en database oven på Data Laken. Uden hård og streng kontrol stagnerer datakvaliteten i en Data Lake altid med tiden.
Så vidt jeg kan vurdere, er et Data Lakehouse blot en naturlig udvikling af et Data Warehouse, men uden brug af en database. Vi kommer helt sikkert til at se en udvikling i den retning fremadrettet, og vejen dertil er nok en form for hybridvariant. Så tænk over de forhold og behov, der er i din organisation, men det vigtigste er faktisk at komme i gang med at bygge. Med en god struktur i dine lag og god styring af metadata er det nemt at justere på et senere tidspunkt.