Lakehouse

Introductie

Volgens de Economist is data de nieuwe olie van de 21ste eeuw. Om meer met deze olie te kunnen doen, zijn veel bedrijven in het afgelopen decennium gemigreerd van een (on-premise) datawarehouse (DWH) naar nieuwere data platform architecturen, zoals een data Lakehouse in de cloud. Met dit nieuwe platform wordt in de kern nog steeds de ruwe olie geraffineerd, zodat we informatieproducten kunnen tanken.

Onder menig DWH ontwikkelaar, die al wat langer in het vak zit, leeft de mening dat hiermee een robuust en betrouwbaar proces om data te verwerken, wordt ingeruild voor een complexe situatie waar alles weer helemaal opnieuw moet worden uitgevonden. Soms wordt het eerder gezien als achteruitgang, waardoor in plaats van innovatie, het idee opkomen om uit protest op een snelweg te gaan zitten om de olie in de grond te laten zitten. Dit staat in contrast met de vaak jongere data engineers die warm lopen voor de grotere flexibiliteit, best practices uit software ontwikkeling en oneindige mogelijkheden tot innovatie die de cloud biedt. Voor deze jongere generatie kan er niet genoeg olie worden opgepompt.

In deze blog doe ik poging om onder woorden te brengen waar dit contrast uit voort komt en wat wij in de praktijk zien bij onze klanten.   

Het betrouwbare datawarehouse

Laten we, om beide kampen beter te begrijpen, beginnen met de voor- en nadelen van een DWH zoals deze vaak genoemd worden. Een DWH is in de olie-analogie de raffinaderij en het tankstation, waarbij de ruwe olie onder andere uit applicaties komt. Het eerste DWH kwam in de jaren 80 ter wereld, met Bill Inmon van IBM als vader. Sindsdien is het als ecosysteem met veel verschillende leveranciers en hulptools zijn kinderziektes ontgroeid en volwassen geworden. Na 40 jaar heeft vrijwel elk bedrijf zijn eigen implementatie.

Destijds was het vernieuwende dat je een kopie van de data uit meerdere productiedatabases en applicaties op één plek beschikbaar kon maken voor analyse-doeleinden. Niet langer hoefde je als gebruiker op meerdere plekken te zoeken. Het combineren van de datasets is gestructureerd en gedreven vanuit een datamodel. De kopie zorgt er ook voor dat als er weer eens iemand een query heeft gemaakt die beter niet uitgevoerd had kunnen worden het productieproces niet meteen omvalt. Tevens kan met deze kopieën historie worden bijgehouden, ook als de bronapplicatie dit zelf niet doet. Traditioneel kennen we drie fases in een DWH namelijk ETL :

• Extraheren van een selectie uit de bron naar een tijdelijke staging laag.
• Transformeren en controleren van de data zodat het qua structuur overeenkomt met een data model en de kwaliteit geborgd is.
• InLaden van de data, zodat het wordt toegevoegd aan de tabellen.

Volgens Bill Inmon heb je pas een betrouwbaar DWH als het voldoet aan de volgende punten:

• Allereerst moet de data bruikbaar zijn voor de business en kunnen worden gebruikt in besluitvorming.
• Er is metadata vastgelegd zodat gebruikers weten welke data er is en waar ze er bij kunnen.
• De datakwaliteit moet op orde zijn er is goede monitoring op de aantallen in de aanleveringen.
• Er wordt gewerkt met een data model voor structuur en begrip.
• Er is goede data lineage om te kunnen herleiden waar de data vandaan komt.
• De toegepaste transformaties moeten begrijpelijk zijn vastgelegd en inzichtelijk zijn, ook voor gebruikers.
• Last but not least moet er zo veel mogelijk geautomatiseerd zijn om consistentie en efficiëntie af te dwingen. Denk aan het ontsluiten van data of genereren van ETL om je data model te bouwen middels templates.

Een DWH is dus veel meer dan alleen data. Al met al staat met een modern DWH een degelijk proces waar structuur, kwaliteit en voorspelbaarheid voorop staan. Het DWH team heeft volledige controle over alles van begin tot eind. Althans, zo gaat het volgens de overleveringen.

Net als met olie tegenwoordig, wordt het DWH team vaak verdoemd. Niet door te veel vervuiling, maar te duur, te langzaam en te complex. Een gemiddeld DWH is vaak het resultaat van jaren aan ontwikkeling. Het kan nogal eens voorkomen dat de onderdelen en verschillende tools die in de decennia zijn toegevoegd niet goed aansluiten tot één geheel. Geregeld ligt kennis over hoe dit allemaal is gedaan, bij enkele personen. Verlaat iemand met die kennis het bedrijf dan is opeens de data catalogus en documentatie weg. Volg dan als nieuwkomer maar eens het spoor van stored procedures de diepte in om een probleem op te lossen. Of probeer er dan maar achter te komen dat je toch nog die ene filter had moeten toepassen, want dat moest door die ene migratie in 1991.

Daarnaast heerst bij de gebruikers van de data vaak het gevoel dat ze ver van de brondata af staan. Er is vaak geen inzicht in de transformatie logica die is toegepast, omdat dit vaak in aparte tooling zit waarvoor specifieke kennis nodig is. Data lineage is zelden in kaart gebracht, omdat dit vaak duur is en pas écht relevant is bij het migreren. Door dit alles is het voor analisten moeilijker om fouten in de getransformeerde data te ontdekken, met een grotere kans op foutieve interpretaties en incorrecte analyses ten gevolg.

Als DWH team moet je bovendien vooraf ook al goed weten welke analyses er gedaan zouden kunnen worden, want daarop moet het datamodel en de bijbehorende transformaties worden ontworpen. Flexibiliteit om deze transformaties (snel) aan te passen in het geval van een nieuwe analysevraag ontbreekt vaak. De doorlooptijd voordat een analist met de uiteindelijke data aan de slag kan, is dan ook relatief lang, omdat het DWH team verantwoordelijk is voor zowel het extraheren als transformeren. Zat er daarnaast een fout in de verwerkte data, dan moet in veel gevallen de data opnieuw geladen worden vanuit de bron (indien mogelijk). Zat er een fout in je historische laag, tja, wat dan.

Snel innoveren met nieuwe tooling is niet echt mogelijk. Een product upgrade doorvoeren was de tijd dat opeens iedereen op vakantie wilde. Daarnaast is er de afgelopen jaren een breed scala aan ongestructureerde datasets opgekomen waar het DWH zich niet goed voor leent, zoals tekst. En dan als laatste is er tegenwoordig ook nog zo iets als big data en streaming. Het blijft toch vervelend als je maar een paar maanden aan transacties van je website kunt opslaan omdat anders je database overstroomt.  

Een Lakehouse met een schone lei

Een migratie naar de cloud, nieuwe ronde nieuwe kansen, maar waar te beginnen? Volgens het nieuwste boek van de vader van het datawarehouse Bill Inmon uit 2021 is een data Lakehouse nu de beste mogelijkheid (nog steeds voorzien van plaatjes uit de jaren 80 voor de liefhebber). Dit is niet zo gek, omdat een Lakehouse in theorie een combinatie van de beste aspecten van zijn oude DWH met de beste aspecten van een data lake in de cloud zou moeten zijn. Door extra flexibiliteit te combineren met goede data governance zou je sneller méér kunnen met een Lakehouse dan in een DWH.

Een Lakehouse borduurt voort op de scheiding van rekenkracht en de relatief veel goedkopere opslag die met de opkomst van de cloud gebruikelijk zijn geworden. De rekenkracht hoeft alleen te worden ingekocht indien er iets berekend moet worden, zo kun je kosten besparen. Een andere belangrijke hoeksteen om nog meer kosten te besparen is het omarmen van opensource technologie. Hiermee wordt het bijvoorbeeld mogelijk om zonder licentiekosten je data efficiënt op te slaan in een data lake met Delta, in tegenstelling tot een ouder DWH waar dit altijd in een ‘dure’ database zit. Delta komt ook met extra voordelen zoals een transactielog, waar je makkelijk monitoring op aantallen mee kan realiseren en eventuele fouten mee kan terugdraaien.

In tegenstelling tot de gebruikelijke ETL schrijft een Lakehouse ELT voor. Het grote verschil is dat de data één-op-één wordt ingeladen vanuit de bron, wordt opgeslagen en dan pas wordt getransformeerd (en eventueel weer opgeslagen). Hiermee kun je sneller bronnen ontsluiten. Plat gezegd blijft de traditionele tijdelijke DWH staginglaag dus beschikbaar. Gooi je deze weg na het opschonen of transformeren dan doe je niet aan ELT. Een voordeel is dat hogere lagen nu relatief makkelijk kunnen worden her-berekend, zoals bij gewenste wijzigingen of ontdekte fouten.

Het grootste voordeel is wel dat analisten nu veel makkelijker kunnen bijdragen aan transformatie logica en  kunnen experimenteren op de ruwe data. Dit kan de capaciteit bij het transformeren en het begrip van de data aanzienlijk vergroten. Combineer dit met de opensource tool dbt en je hebt een groot deel van je automation (data vault of niet), metadata, documentatie, lineage en data kwaliteit monitoring te pakken. Wederom zonder licentiekosten.

Nog een voordeel is dat applicaties waarin de data gebruikt wordt eventueel ook kunnen inprikken op de ruwe data. Niet iedereen heeft een hele data vault nodig. Omdat al je data beschikbaar is op een data lake kan een gebruiker er vanuit bijna elke wensbare taal of applicatie op inprikken. Hiermee worden veel meer use-cases mogelijk. Niet in de laatste plaats omdat tekst of andere ongestructureerde data nu ook makkelijk in grote hoeveelheden kan worden opgeslagen. 

Het is natuurlijk niet alleen maar rozengeur en maneschijn. Waar aan het concept DWH al 40 jaar ontwikkeld wordt is het gebruik van data lakes pas sinds 2010 echt op gang gekomen. De uitwerking van een Lakehouse is pas iets van de laatste jaren. Hierdoor is er zeker nog ruimte voor verbetering. Daarnaast kunnen data kwaliteit problemen later ontdekt worden met de overgang naar ELT, omdat deze vaak bij het uitgestelde transformeren pas opvallen.

De meeste problemen lijken voort te komen uit het vergeten van de (dure) lessen die al geleerd zijn in het DWH. Bill Inmon beschrijft dat veel bedrijven nu focussen op het ontwikkelen van architecturen en tooling in plaats van te beginnen bij een sterke data strategie die focust op hoe de data uiteindelijk de business moet gaan ondersteunen. In de praktijk worden onder het mom van agile werken en minimal viable products bouwstenen zoals data lineage, metadata, documentatie, data modellen, goede monitoring en automation aan de kant gezet totdat ‘we daar tegen aan lopen’. Eigenlijk loop je op dun ijs als je deze basis niet gelijk meeneemt, zoals de peetvader ook voorschrijft. Van een duidelijke scope wordt het echt niet minder agile. Goedkoper is het vaak helemaal niet. Komt dit niet omdat we door het ijs zakken van de slechte basis (zo het data swamp in), dan wel omdat er minimaal gebruik wordt gemaakt van opensource, die toch voornamelijk nog als onbetrouwbaar wordt gezien in plaats van als kans. Ook komt het geregeld voor dat de nieuwe technologie verkeerd wordt gebruikt. Draait er in jouw Lakehouse bijvoorbeeld een Delta VACUUM proces om overbodige kopieën op te schonen of stop je toch al je data weer in een database die altijd aan staat? 

In de praktijk heeft een Lakehouse last van dezelfde vloek als het DWH (te duur, te complex, te langzaam). In de cloud is het makkelijker om te experimenteren, maar het doel moet wel duidelijk zijn. Daarnaast betekent het ook dat er daarna net zo goed tijd nodig is voor goede integratie. Technical debt opbouwen is misschien nog wel makkelijker dan het was. Hier ligt weinig focus op. Het grootste probleem is waarschijnlijk dat het opleiden van medewerkers wordt onderschat. Dit is geen nieuw probleem, maar in de cloud waar nieuwe innovaties met lichtsnelheid beschikbaar komen, waar de meeste tools relatief nieuw zijn en waar we in het data vakgebied veel meer als software ontwikkelaars (zouden moeten) werken is het wel een relatief groter probleem. Hier focus in aanbrengen is al een hele taak op zich.

Is er dan wel een contrast?

Eigenlijk zitten de DWH ontwikkelaar en data engineer dus in dezelfde olietanker. Het is niet zo dat alle kennis van het DWH overbodig is geworden en ook niet zo dat de kennis van nieuwe cloud tooling en software ontwikkel werkwijzen van data engineers alles op kunnen lossen. Zelfs Bill Inmon ziet dit nog in op 75 jarige leeftijd. Gelukkig kunnen we weer beginnen met een boek, net zoals in de jaren 80. Wel digitaal dit keer. Als we dat wat meer zouden lezen en als leidraad zouden gebruiken in plaats van alles zelf uitzoeken dan komen we wellicht wat dichter bij elkaar. Er ligt een duurzame toekomst voor de boeg.