Het Data Lake

Wat is een Data Lake?

Met de komst van Big Data is er een nieuw architectuur concept of paradigma ontstaan binnen de wereld van data en analyse, het zo genoemde Data Lake. De term is geïntroduceerd door James Dixon in 2010, en is daarna snel populair geworden.

Net zoals bij het begrip Data Warehouse , was er niet één eenduidige visie over hoe een Data Lake geïmplementeerd moest worden. Het oorspronkelijke idee achter een “Data Lake” (of in het Nederlands: “Datameer”) is een grote verzameling rauwe data, afkomstig uit verschillende bronnen, die is opgeslagen op een centrale locatie welke geïmplementeerd is op goedkope en snelle opslag (HDFS). Verschillende gebruikersgroepen konden gebruik maken van deze data, ofwel: vissen in het meer, ieder op zijn eigen wijze. Een belangrijke gebruikersgroep van het Data Lake, ofwel de “vissersvloot” van het Datameer, bestond uit zo genoemde Data Scientists. Toepassingen van het Data Lake waren veelzijdig: geavanceerde (predictive) analyses, machine learning, data discovery, management rapportages, operationele rapportage, en nog veel meer.

Verschillende visies

Net als bij het Data Warehouse was er niet één geaccepteerde visie over hoe een Data Lake er concreet uitziet. Wel was er een aantal zaken wat vaak genoemd werd, en die zullen in deze paragraaf beschreven worden. Het oorspronkelijke data lake is op dit moment niet echt actueel meer. Op dit moment bestaat er wel architecturen welke op het Data Lake geïnspireerd zijn, of hier uit voortgekomen zijn. De bekendste hiervan is de zo genoemde Data Lakehouse Architectuur, welke aspecten van het Data Warehouse en Data Lake combineert. Op deze architectuur zijn bekende data platforms als Databricks, Snowflake en Data Fabric gebaseerd.

Zoals gezegd, volgt hier een aantal veel genoemde kenmerken van de oorspronkelijke versie van het Data Lake:

Schema on Read

Het principe “schema on read” is van oorsprong van toepassing op Data Lakes. “Schema on read” is de tegenhanger van “schema on write”. De laatste vorm wordt toegepast binnen traditionele relationele databases (dus ook in het Data Warehouse, wat zich in een relationele database bevindt ). Bij “schema on write” wordt data vastgelegd binnen een vaste structuur , bestaande uit tabellen, waarin kolommen vaste data typen en formaten hebben, welke door de database worden gevalideerd voordat de data wordt vastgelegd. Bij “schema on read” wordt de data vastgelegd zoals deze is ontvangen. Er vind bij het schrijven geen enkele controle plaats. Pas tijdens het lezen wordt de structuur van de data bepaald. Big data processing tools, zoals Spark, zijn in staat om data tijdens het lezen naar de juiste structuur te vormen vanuit diverse bestandsformaten (zoals csv, json, flat file formaten). Dit komt overeen met de wenst om allerlei soorten data op te kunnen slaan (niet alleen gestructureerde data) en ook om alle rauwe data op te slaan inclusief alle wijzigingen over de tijd, ongeacht de kwaliteit hiervan. Een voordeel van deze aanpak is ook dat de data niet eerst uitgebreid geanalyseerd moet worden om de juiste opslag structuur te kunnen bepalen. Het Data Lake past bij een data strategie waarbij zoveel mogelijk data centraal wordt opgeslagen, en een eventuele toepassing later bepaald wordt.

Low Cost Storage
Het data lake is van oorsprong gebaseerd op Hadoop HDFS storage. Deze was destijds goedkoper omdat het gebruik maakte van reguliere goedkope hardware, waarbij grote aantallen computers parallel werden ingezet ten behoeve van de snelheid. Op dit moment biedt de Cloud allerlei relatief goedkope opslag varianten, welke een HDFS interface hebben en als zodanig voor Data Lakes ingezet kunnen worden. Deze Data Lake Storage is goedkoper dan de storage die wordt gebruikt in reguliere databases. Hierbij dient wel een kanttekening geplaatst worden, dat storage duurder wordt naarmate je er meer eisen aan stelt qua snelheid, betrouwbaarheid, veiligheid. Dit geldt ook voor deze opslagvariant.

Uit het bovenstaande zou je kunnen afleiden dat een Data Lake eigenlijk niet meer is, dan een HDFS file locatie waarin allerlei bestanden worden opgeslagen. Wie thuis of op het werk een PC heeft, weet hoe lastig het kan zijn om je harde schijf netjes te houden, zodat je alle bestanden later makkelijk terug kan vinden. Iedere datawarehouse ontwikkelaar weet hoeveel problemen Excel en csv-bestanden kunnen geven tijdens het inlezen. Bestandformaten wijzigen constant, bewust of onbewust, wat allerlei problemen oplevert voor de verwerkende ETL systemen. Mensen met ervaring in business intelligence, data warehousing en ETL keken daarom vaak sceptisch naar de Data Lake hype. Data Lakes die uiteindelijk veranderden in een grote puinbak werden ook wel Data Swamps of Data Cesspools genoemd.

De Beheersbaarheid van het Data Lake

Zoals gezegd: het bouwen en beheren van een Data Lake was geen sinecure. Hieronder volgt een aantal aandachtspunten en best-practices die destijds gehanteerd werden om het een en ander beheersbaar te houden.

1. Zones
   Om te voorkomen dat het data lake een rommeltje wordt, was het gebruikelijk om het Data Lake op te delen in verschillende zones. Voorbeelden van zones die hierbij genoemd werden zijn:
   • Landing zone / Transient zone : Dit betreft een tijdelijke opslag van brondata, totdat deze is doorverwerkt naar volgende lagen
   • Raw data zone : Dit betreft een centrale (historische) opslag van onbewerkte brondata in zijn originele vorm.
   • Curated / Trusted data zone : Centrale opslag van getransformeerde data. Bedrijfsspecifieke business rules zijn toegepast in deze zone, zoals opschonen, conformeren, berekenen, etc.
   • Refined data zone : Data in deze zone was nog verder bewerkt voor een speciale toepassing, afdeling of gebruikersgroep.
   • Analytics Sandbox / Discovery zone : In deze zone kunnen Data Scientist eigen data opslaan, zoals brondata en resultaten van hun experimenten.
   • Cold storage zone : Een andere toepassing van het Data Lake was archivering van historische data uit bronsystemen
2. Storage types
   Hoewel eerder is gezegd dat data wordt opgeslagen zoals deze ontvangen is, geldt ook dat niet alle opslagvormen even geschikt zijn voor massale parallele verwerking. Daar komt het eerder genoemde probleem bij dat dataformaten kunnen wijzingen over de tijd, wat een schema on read aanpak lastig maakt. Vaak werd er daarom voor gekozen om in het Data Lake toch een “schema on write” aanpak te hanteren, door bestandsformaten te kiezen die een schema bevatten en geoptimalizeerd zijn voor parallele verwerking. Voorbeelden hiervan zijn: Avro, OCR en Parquet.
3. Robuustheid van verwerkingsprocessen
   Het is belangrijk dat ETL processen robuust zijn, zodat gebruikers erop kunnen vertrouwen dat data volledig en betrouwbaar is. Dit geldt zowel voor standaard Data Warehouse omgevingen, als Data Lake omgevingen. Alleen kon dit binnen een Data Lake een extra grote uitdaging opleveren. Waar databases standaard beschikken over een zo genoemd ACID (atomicity, consistency, isolation, durability) transactie mechanisme, diende de ontwikkelaar binnen een Data Lake omgeving veelal zelf zorg voor te dragen voor een correcte afhandeling van transacties. In het geval van een onverwachte crash zal een database de openstaande transacties automatisch terugdraaien. Bij het schrijven naar files, zoals dit in een Data Lake plaats kan vinden, staat er in dat geval een half geschreven bestand. Het ETL process moest dus zelf zorgdragen dat deze gegevens op de één of andere manier verwijderd werden. Dit kon heel veel ontwikkeltijd en dus geld kosten.
4. Catalogiseren van data
   Data zonder context heeft weinig waarde. Een goede data catalogus met uitgebreide zoek mogelijkheden was daarom een must-have voor Data Lake omgevingen. Deze moest informatie bevatten over de herkomst van data (data lineage), het eigenaarschap, toegepaste business rules, verversings informatie, toepassing van de data, etc.
5. Security en Privacy
   Het opslaan van allerlei data zonder deze eerst uitgebreid te analyseren kan risico’s opleveren met betrekking tot security en privacy regels. Mogelijk bevat de data – zonder dat iemand zich er bewust van is – gevoelige informatie, welke middels het Data Lake aan het hele bedrijf ter beschikking wordt gesteld. Beveiliging was daarom een zeer belangrijk onderdeel van de Governance structuur van het Data Lake.