Misvattingen van een data lake

We verwerken meer data dan ooit tevoren. In Azure en andere cloud platformen heb je zo goed als onbeperkte opslagcapaciteit tegen een lage prijs. Vandaag de dag doe je niet mee als je niet datagedreven en digitaal getransformeerd bent. Voor iedere data engineer is het vanzelfsprekend dat je daar een data lake voor nodig hebt.

Maar wat is een data lake precies? Volgens Wikipedia is het opslag van data in zijn oorspronkelijk formaat. Je kan deze data in drie soorten onderscheiden:

• Gestructureerd: Relationele database systemen. Bijvoorbeeld Azure SQL Database
• Semi-gestructureerd: Log bestanden of no-sql databases. Bijvoorbeeld Azure Cosmos DB
• Ongestructureerd: Alles dat overblijft. Bijvoorbeeld plaatjes, video’s of emails

De belofte

Met de komst van gedistribueerde bestandssystemen zoals Apache Hadoop werd het makkelijker om grote hoeveelheden data efficiënt op te slaan en te benaderen. Dit gecombineerd met de opkomst van Big Data, Machine Learning en het idee dat dit de oplossing is voor alle problemen is een data lake niet meer weg te denken in nieuwe architecturen.

Het einde van het data warehouse

In het begin was er verwarring. Gaat data lake het data warehouse vervangen? Want het data warehouse was wel aan vervanging toe. Vaak zien we ontevreden gebruikers omdat het model rigide is, wijzigingen lang duren en de data vaak maar één maal per dag ververst wordt. De cloud belooft ons meer efficientie en data lake werd vaak, ten onrechte gezien als oplossing voor deze problemen. Een goed ontworpen data lake is complementair aan een data warehouse of andere data oplossingen. Ze moeten elkaar versterken maar zeker niet vervangen.

data lake is niet de oplossing

Data Lake is technologie. Net als een relationeel database systeem of een file server. En ieder systeem heeft sterke en zwakke punten. Het succes van de oplossing hangt af van de gebruiker. Welke oplossing je ook kiest; het moet het werk van de gebruiker makkelijker maken of ondersteunen. Het zal de meeste gebruikers niet uitmaken welke onderliggende technologie gebruikt wordt.

Het implementeren van een data lake maakt een organisatie niet ineens data gedreven. Het helpt ook niet met het doorbreken van zogenaamde data silo’s; afdelingen binnen de organisatie die data angstvallig bij zich houden. Het gaat erom dat dat je als organisatie kunt reageren op veranderingen in de markt. Als de technologie daar ondersteunend en in zekere mate ook bepalend in is dan kan een implementatie succesvol zijn.

Uitdagingen voor het data lake

Een aantal traditionele databasesystemen komen uit de vorige eeuw. SQL Server bijvoorbeeld is ruim 30 jaar oud. Dat maakt het bewezen technologie en in veel gevallen de voor de hand liggende keuze. Voor transactionele applicaties is dit ook juist. Relationele systemen zijn, mits goed gemodelleerd een veilige en optimale keuze. Maar wanneer het gaat om analytische vragen waar grote sets verwerkt moeten worden, dan wordt het een stuk lastiger. Deze systemen komen uit een tijd dat disken langzaam en klein waren. De hoeveelheid data neemt alleen maar toe en de traditionele databases piepen en kraken onder dat geweld. Dit is waar een data lake uitkomst kan bieden.

Bij de meeste klanten zie ik hetzelfde patroon. Er wordt zo snel mogelijk data op het data lake geplaatst. Het hoe en waarom is niet direct relevant en ook de toegevoegde waarde is niet altijd bekend. Voor de meeste data lake implementaties is dat niet het grote probleem. Met oplossingen zoals Data Factory kun je eenvoudig grote datasets binnenhalen en in een zo ideaal mogelijk formaat opslaan. Maar hoe creëer je businessvalue uit data? Dat is niet door simpelweg je data lake vol te gooien met data. Dit zijn juist de scenario’s waar je eindigt met een data swamp (een overwoekert en onoverzichelijk geheel) of een data desert (weinig data en even zo weinig gebruikers).

Tot slot is zo’n enorme hoeveelheid data een nachtmerrie voor security engineers. Hoe beveilig je zo’n berg data? En hoe ga je om met de AVG? Wie is de eigenaar? Anders gezegd, een data lake implementatie is onmogelijk zonder governance.

Een succesvol data lake. Het kan!

Zoals eerder gezegd is data lake op zichzelf niet de oplossing. Maar het kan wel een belangrijk deel van de oplossing zijn. Bij veel bedrijven is de IT-afdeling de grote drijfveer achter het data lake. Dat zou de business moeten zijn. De eerste stap is kijken hoe de business waarde wil leveren. Welke vragen kunnen nu niet beantwoord worden? Welke vragen kunnen wel beantwoord worden maar duren te lang? En hoe vindt je kansen binnen de dataset? Hoe kunnen afdelingen elkaar versterken door efficienter data te delen? Dit zijn allemaal vragen die de business kan beantwoorden en waar de business dus ook bij betrokken moet worden.

IT faciliteert en ontwerpt

Wanneer het aankomt op implementatie is het aan de IT afdeling. Door een architectuur op te zetten waar data lake een integraal onderdeel is en alle aspecten meegenomen worden. Onderstaande afbeelding is een veel voorkomend patroon.

{: .center}

1. Het begin van de datareis begint met het binnenhalen data uit verschillende interne en externe bronnen.
2. De ruwe data wordt verder bewerkt zodat deze door verschillende interne systemen verwerkt kan worden. Denk hierbij aan het omzetten van losse Json bestanden naar bijvoorbeeld parquet bestanden.
3. Nadat data scientists en andere processen de data geschoond, bewerkt en verrijkt hebben kan de data geconsumeerd worden. Dit kan in allerlei vormen en formaten.

Van ontwerp naar lagen

Waar de vorige afbeelding meer naar de technologie kijkt is onderstaande afbeelding meer een conceptueel model. Dit is het model dat binnen het data lake gebruikt wordt om de verschillende stadia van data aan te kunnen duiden.

{: .center}

• Landing Zone: Dit is waar de data binnenkomt uit de bron systemen. De map structuur is vaak afgeleid van het bron systeem en de datum wanneer de data binnengehaald is. Bijvoorbeeld: /twitter/2021/03/10/06. Of op basis van een specifiek twitter account: /twitter/rhartskeerl/2021/03/10.
• Staging Zone: Data in de landing zone is vaak niet optimaal voor verder verwerking. Mogelijk zijn het losse bestanden of een incourant formaat. In de Staging Zone transformeer je data uit de Landing Zone zonder grote transformaties naar grotere sets in een uniform formaat. Bijvoorbeeld .parquet. De map structuur is veelal gelijk aan die van de Landing Zone.
• Curated Zone: Hier zijn business rules toegepast en is data geschoond. Dit is de data die geconsumeerd wordt. Dit is immers data die voldoet aan het bedrijfs beleid. De data en de map structuur is geoptimaliseerd voor lezen. Bijvoorbeeld sales/jaar/maand/regio/filiaal/dag-sales.parquet of sales/regio/filiaal/jaar/maand/dag-sales.parquet. Opslag is goedkoop en de juiste partitie structuur versnelt het uitvragen van grote datasets.
• Sandbox Zone: Hier werken data scientists en business analisten. Hier wordt gezocht naar patronen in de data. De map structuur is project gebaseerd en tijdelijk.

Vergeet compliancy, security en beschikbaarheid niet

Meer data betekent meer problemen. Data kan gestolen worden, corrupt raken of onbeschikbaar zijn. Als een storage account met een paar terrabyte aan data per ongeluk verwijderd wordt kan dat nogal desastreuze gevolgen hebben. Het is belangrijk om daarom in een vroeg stadium goed na te denken over security en welke (on)mogelijkheden het platform biedt. Zo is bijvoorbeeld Row Level Security of Data Masking beschikbaar in Azure SQL Database. Maar in een storage account werk je met bestanden en rechten op die bestanden. Daarmee zijn de mogelijkheden wat meer beperkt.

Wanneer je gebruik maakt van verschillende lagen en transformaties is het ook belangrijk om inzichtelijk te maken hoe de data tot stand is gekomen. Waar komt de data vandaan, hoe oud is de data, welke transformaties heeft het ondergaan en wie is de eigenaar van de data.

Waar een traditioneel databasesysteem zoals SQL Server gebruik maakt van clustering, replicatie, backup en andere vormen van logging om data beschikbaar en betrouwbaar te maken zie je dit minder bij storage oplossingen. Replicatie is vaak wel beschikbaar maar bescherming tegen het verwijderen of overschrijven van data is op dit moment nog maar beperkt beschikbaar.

Waar ligt de focus?

Een data lake is niet per definitie een ramp. Het is, mits juist toegepast een essentieel van het totale data landschap. Dit zijn een paar succesfactoren:

1. Data verplaatsingen zijn gecontroleerd.
2. Data verplaatsingen zijn geautomatiseerd en herhaalbaar.
3. Data kan op meerdere manieren en veilig geconsumeerd worden door bedrijfs applicaties.

Controle van data verplaatsingen

Het is belangrijk te weten waar data vandaan komt om te bepalen of de informatie betrouwbaar is. Hiervoor moet je als organisatie investeren in data mangement. Data gaat om data kwaliteit, master data management en een data catalogus. Daarnaast helpt data lineage om inzichtelijk te maken hoe een dataset tot stand is gekomen.

Automatisering en orchestratie

Data verplaatsingen moeten voorspelbaar en betrouwbaar zijn. Door deze te automatiseren kan de data verplaatsing regelmatig en gecontroleerd plaatsvinden.

Veilig benaderen van data

Het ophalen van data moet net zo veilig en betrouwbaar zijn als in iedere andere data applicatie. Het kan nodig zijn om hier een aparte laag, bijvoorbeel API’s voor in te richten.

Samenvattend

Een succesvol data lake is onderdeel van een data strategie. Een data strategie die draait om het creëeren van waarde in samenwerking met de gebruikers. De IT afdeling is op de hoogte van de technische mogelijkheden. De business is op de hoogte van de betekenis en waarde van de data. Die twee moeten samenkomen in een totale data oplossing.