Een tijdje terug maakte ik een blog en vlog over het verschil tussen datalakes en datawarehouses. Een van ons meest gelezen en bekeken blogs. Tijd voor een update. Mede ook door de snelle groei van varianten zoals ‘data lakehouses’.
Door Harmen, CTO & senior data scientist bij Datalab
Hoe zat het ook alweer….?
Datawarehouse, datalake, datalakehouse… hoe zat het ook alweer? Datawarehouses bestaan feitelijk al tientallen jaren. Sinds de jaren 2010 zijn dit soort data-opslagplekken echt gemeengoed geworden. Erg functioneel, echter wel pas als de randvoorwaarden goed zijn. Een van de belangrijkste voorwaarde is de structuur van opslag. Er zijn verschillende stijlen van hoe je informatie structureert: als feiten-en-dimensietabellen (een zogenaamd Kimball-schema, vernoemd naar bedenker ervan) of dicht in de buurt van de oorspronkelijke dataset (veelal een genormaliseerd model). Dit laatste model geeft de meeste flexibiliteit, de reden waarom wij fan hiervan zijn. Je maakt eenvoudigweg afgeleide datasets -zogenaamde views- waarin je de data precies vormt voor jouw dashboard of analyse. Wil je in de toekomst een ander perspectief op je data centraal stellen (bijvoorbeeld van marketing naar inkooplogistiek), dan hoef je alleen maar een nieuwe view aan te maken. Het maken van views is een koud kunstje: met onze uitgekiende training leren we onze klanten in een paar uurtjes views maken. De tijdsinvestering zit ‘m dan ook in het goed gestructureerd opslaan van data.
De ‘z’-schijf
Data lakes bestaan waarschijnlijk veel langer dan datawarehouses, zij het niet onder deze noemer. De precieze definitie van een data lake is vaag, maar in elk geval sla je informatie op zonder al te veel structuur in een goed toegankelijke locatie. 
Vroeger hadden organisaties daar de ‘z’-schijf voor (of welke letter dan ook; in elk geval een gedeelde netwerkschijf). Dat bleek toch wat te chaotisch en toegangsbeheer is lastig te regelen. Met de opkomst van de cloud werd het data lake geboren. Gevolg: een netwerkschijf in de cloud met veelal onvindbare informatie, onduidelijkheid over wie eigenaar is, welke structuur gehanteerd is, welke (delen van) de data geüpdatet zijn, enzovoorts. Tegelijk is het goedkoop en een snel in te richten plek waar data samenkomt. Met de enorme vlucht die ‘big data analytics’ rond 2015 heeft genomen, een handige manier voor veel organisaties om ermee te starten. De techniek heeft de tand des tijds helaas niet goed doorstaan, want veel organisaties kiezen voor een migratie naar een datawarehouse. Juist omdat informatie zo lastig te vinden is. Data lakes worden nu vooral gebruikt voor opslag van grote datasets die inherent ongestructureerd zijn zoals foto’s, video’s, back-ups. Ook dient het regelmatig als tijdelijke ‘parkeerplek’ voor datasets die later verwerkt worden in een datawarehouse.
Enter: data lakehouses, het ideale compromis tussen warehouse en lake?
Een data lakehouse is een combinatie van een data warehouse (gestructureerd) én data lakes (ongestructureerd). De truc is dat data uit beide soorten bronnen makkelijk combineerbaar zijn. In het lakehouse zelf houd je metadata bij waarin je beschrijft wat er in de losse files in je data lake staat (en wie er voor verantwoordelijk is, wie er bij mag, enzovoorts). Dat lijkt ideaal: minder moeite doen om data te structureren, toch toegankelijk en koppelbaar én goede metadata.
Voor sommige organisaties zal een data lakehouse inderdaad prima werken. Bijvoorbeeld organisaties die met vaak wisselende databronnen werken en beschikken over een eigen data science-afdeling. De grotere jongens dus. Waarom juist voor hen? Omdat data scientists niet hoeven te wachten op datawarehouse-experts om data te integreren. Zo kunnen de analisten sneller aan de slag.
“Ne sutor ultra crepidam”
Uiteraard… er zit een keerzijde aan het data lakehouse. Samengevat valt dat het best te omschrijven met een goed Nederlands gezegde: Ne sutor ultra crepidam, oftwel: ‘schoenmaker, blijf bij je leest’. De meeste data scientists en dashboardbouwers zijn handig met data, zoals een technisch geschoold iemand handig is met auto’s. Zelfs als snap je hoe een auto werkt en kun je zelf de bougies, oliefilters en de olie vervangen, dat maakt je nog geen automechanicus. Het zou dus best kunnen zijn dat je de verkeerde pluggen of olie gebruikt, of andere onhandige dingen doet die op langere termijn meer schade aanbrengen dan goeds opleveren.
Praktischer voor de data-analist: er komt nogal wat kijken bij het goed structureren van data. Niet voor niets schrijft gerenommeerd onderzoeksbureau Gartner dat de rol van de data engineer een onmisbare is in veel teams.
Goed met data omgaan kost hoe dan ook tijd…
Bij een data warehouse besteed je vooraf tijd aan het structureren van je data. Bij een data lake wordt er te vaak helemaal geen tijd aan het structureren van data besteed en bij een data lakehouse besteed je iedere keer als je een nieuwe analyse wilt maken tijd aan het structureren van je data.
Daarom: een data lakehouse kan een nuttige oplossing zijn, vooral voor grotere teams waarbij hergebruik van de data minder aan de orde is en er vaak wisselende databronnen zijn. Ook nu geldt dat bestaande technieken met een reden al zo lang bestaan: omdat ze goed werken. Dat geldt zeker voor een datawarehouse. Of een data lakehouse ook op de lange termijn een goede oplossing is, zal nog maar zeer de vraag zijn. Hoe dan ook, het is belangrijk de ontwikkelingen goed te volgen. Iets dat we bij Datalab graag doen.
Wil je weten welke techniek het beste bij je past? Stuur me gerust vrijblijvend een email of plan een gesprek in. Ook ben ik erg benieuwd naar jouw ervaringen met data warehouses, lakes en lakehouses. Deel ze gerust!