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" , is er niet één eenduidige visie over hoe een "Data Lake" geïmplementeerd moet 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 kunnen 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, bestaat uit zo genoemde Data Scientists. Toepassingen van het Data Lake zijn veelzijdig: geavanceerde (predictive) analyses, machine learning, data discovery, management rapportages, operationele rapportage, en nog veel meer.
Verschillende visies
Net als bij het Data Warehouse is er niet één geaccepteerde visie over hoe een Data Lake er concreet uitziet. Wel is er een aantal zaken wat vaak genoemd worden, en die zullen in deze paragraaf beschreven worden. Ook bestaat er een aantal termen welke op het Data Lake geïnspireerd zijn, hiermee samenhangen of hier conceptueel sterk op lijken, zoals bijvoorbeeld: Data Hub, Data Lakehouse, Delta Lake. Ook hierover volgt later in dit artikel meer.
Zoals gezegd, volgt hier een aantal veel genoemde kenmerken van het Data Lake:
1. 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.
2. Low Cost Storage
Het data lake is van oorsprong gebaseerd op Hadoop HDFS storage. Deze was destijds goedkoper omdat deze 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 staan, 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 kijken daarom vaak sceptisch naar de Data Lake hype. Data Lakes die uiteindelijk veranderen in een grote puinbak worden ook wel Data Swamps of Data Cesspools genoemd.
Hoe houd je een Data Lake beheersbaar?
Zoals gezegd: het bouwen en beheren van een Data Lake is geen sinecure. Hieronder volgt een aantal aandachtspunten en best-practices.
1. Zones
Om te voorkomen dat het data lake een rommeltje wordt, is het gebruikelijk om het Data Lake op te delen in verschillende zones. Voorbeelden van zones die hierbij genoemd worden zijn:
2. Storage types
Hoewel eerder is gezegd dat data wordt 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 wordt 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 kan 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, dient 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 zal dus zelf moeten zorgdragen dat deze gegevens op de één of andere manier verwijderd worden. Dit kan heel veel ontwikkeltijd en dus geld kosten.
4. Catalogiseren van data
Data zonder context heeft weinig waarde. Het artikel "Hoe data Informatie wordt" gaat hier dieper op in. Een goede data catalogus met uitgebreide zoek mogelijkheden is daarom een must-have voor Data Lake omgevingen. Deze moet informatie bevatten over de herkomst van data (data lineage), het eigenaarschap, toegepaste business rules, verversings informatie, toepassing van de data, etc.
4. 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 is daarom een zeer belangrijk onderdeel van de Governance structuur van het Data Lake.
Ontwikkelingen met betrekking tot het Data Lake
Technologie verandert continue. Met name in de Cloud worden constant nieuwe toepassingen ontwikkeld, welke zeer snel beschikbaar zijn voor gebruikt door klanten. Ook met betrekking tot hetgeen hierboven is beschreven, zijn allerlei ontwikkelingen aan de gang. Zo worden databases voorzien van mogelijkheden om ongestructureerde data te lezen en combineren met de aanwezige gestructureerde data. Je zou kunnen zeggen dat databases worden voorzien van schema on read mogelijkheden. Daarnaast dat Spark services voorzien worden van ACID mogelijkheden. Deltalake is hier een goed voorbeeld van. Kortom, het is lastig te voorspellen of de huidige technische beperkingen of technische voordelen ook in de toekomst geldig zullen blijven. Veel bedrijven maken op dit moment gebruik van een z.g. Data Warehouse architectuur. Mogelijk denkt men er aan om een dergelijke omgeving om te bouwen naar een Data Lake architectuur. Dit zal een grote investering vragen. Een dergelijke keuze zal daarvoor in ieder geval op langere termijn voordeel op moeten leveren. Een puur op technologie gebaseerde beslissing kan binnen korte tijd alweer achterhaald zijn. De keuze zou daarom op andere zaken gebaseerd moeten zijn dan puur technologie. Ook zou de keuze rekening moeten houden met toekomstige ambities op het gebied van data en informatie. Op deze site zullen komende tijd veel nieuwe artikelen geplaatst worden, welke dieper ingaan op de huidige ontwikkelingen op het gebied van analytics, Business Intelligence, Data Warehousing, Data Engineering en Artificial Intelligence.