“Wij hebben net een data warehouse gebouwd… en nu starten we met een data lake.”
Waarom eigenlijk?
Een data warehouse en een data lake dienen gelijkaardige doelen maar doen dat op een andere manier.
In deze blog duiken we in de verschillen en de technologie achter beide oplossingen.
Het concept van een data warehouse ontstond al in de jaren ’80. Begin jaren ‘90 beschreven Bill Inmon en Ralph Kimball hoe transactionele systemen vooral gebouwd zijn om dagelijkse processen te ondersteunen, terwijl bedrijven data willen gebruiken voor rapportering, analyse en inzichten.
Rond 2011 kwam Big Data op en won het concept van een data lake aan populariteit. Later evolueerde dit verder naar het data lakehouse: een technische architectuur die de flexibiliteit van een data lake combineert met de structuur en performantie van een data warehouse.
Een transactioneel systeem is bijvoorbeeld je CRM systeem: het helpt je in de transactie van het beheren van klantgegevens. Je ERP systeem is ook een transactioneel systeem: het helpt je in het beheren van resources. Je website ook, je boekhoudsysteem ook. Alle systemen die dienen om data te capteren zijn transactionele systemen.
Typisch hebben transactionele systemen veel logica en een mooie gebruikersinterface, en de database is een relationele database. Een relationele database wordt ook wel een OLTP - online transaction processing database - genoemd.
Een data warehouse is een centrale plaats om gestructureerde data op te slaan en te analyseren. Met gestructureerde data bedoelen we data in tabelvorm, zoals databases, CSV-bestanden of Excel-files, en dus alle data uit meerdere transactionele systemen.
Een data warehouse werkt met een strikt schema: een afgesproken structuur die bepaalt hoe de data gevormd is. Typisch bevat een datawarehouse de logica om van ruwe data naar inzicht te gaan, en wordt het gevisualiseerd in business intelligence tools. De onderliggende database is een OLAP database. Een datawarehouse wordt ook wel een OLAP - online analytical processing database - genoemd.
Maar een data warehouse is veel meer dan een klassieke database. Het is specifiek ontworpen om snel en accuraat antwoorden te geven op data analyse vragen, zowel terugkerende rapporteringen als ad-hocvragen, zonder de operationele bronsystemen zwaar te belasten.
Daarnaast dient het om de informatie in een organisatie te verankeren en verbinden in een business-vriendelijk datamodel waar je een 360-graden zicht over heel je organisatie creëert. Zie het als een centraal element om digitale informatie gemakkelijk te kunnen interpreteren.
Waar transactionele systemen vooral dienen om dagelijkse processen uit te ondersteunen, is een data warehouse gebouwd voor analyse en inzicht.
De belangrijkste rol van een data warehouse is dan ook om data uit verschillende systemen samen te brengen in één centrale omgeving. Daardoor kan je analyses uitvoeren over je volledige organisatie heen. Het heeft ook de rol om historische cijfers bij te houden. Denk aan vragen zoals: “Wat zijn onze salescijfers sinds 2022 per maand voor product A?” of “Welk proces binnen onze organisatie werkt het minst efficiënt?” Zonder data warehouse zit die informatie vaak verspreid over verschillende applicaties, waardoor analyses traag, foutgevoelig of zelfs onmogelijk worden.
Naarmate je organisatie groeit zijn er sowieso meerdere transactionele systemen nodig. Er is niet zo iets als een silver bullet, het addagio van “maar mijn software moet alles kunnen” werkt dus niet als je groeit.
Voor een KMO is een centrale locatie voor je data, KPI en definities de basis van datagedreven werken.
*Note ter volledigheid: in grotere organisaties wordt dit soms uitgesplitst (zie ook data mesh).
Tot een tiental jaar geleden draaiden de meeste data warehouses op één krachtige server. Maar zo’n systeem moet permanent actief blijven, zelfs wanneer niemand analyses uitvoert. Daarnaast zijn opslag en rekenkracht sterk met elkaar verbonden. Heb je meer data of zwaardere analyses? Dan moet je investeren in meer rekenkracht. Ook als die extra kracht maar af en toe nodig is.
In dezelfde periode kwam de “migratie naar de cloud” ook voor. Organisaties wilden geen grote servers meer aankopen, want dat was niet efficiënt.
In 2011 viel voor het eerst de term “Big Data". Bedrijven begonnen enorme hoeveelheden data te verzamelen: terabytes en zelfs petabytes aan gestructureerde data, logs, sensordata, clickstreams, afbeeldingen en andere databronnen. Die volumes werden gewoon te groot om nog efficiënt te verwerken op één systeem.
Dat zorgde voor een fundamentele verandering in technologische architectuur. Dit was de drijfveer om opslag en rekenkracht van elkaar los te koppelen. Data kon goedkoop opgeslagen worden in grote, schaalbare opslagomgevingen, terwijl rekenkracht enkel werd ingeschakeld wanneer nodig. In plaats van één zware server gebruikte men clusters van computers die samen berekeningen uitvoeren op enorme datasets. Dus naast het horizontaal schaalbaar maken van opslag, werd rekenkracht ook horizontaal schaalbaar (note: horizontaal schaalbaar = meer computers doen samen werk ipv 1 grote computer die alles doet)
Uit die evolutie ontstond het data lake: een flexibele opslaglaag waarin grote hoeveelheden ruwe data centraal worden verzameld, terwijl rekenkracht afzonderlijk en naar behoefte kan worden ingezet. Je gebruikt dus alleen de rekenkracht die je nodig hebt, op het moment dat je die nodig hebt.
Een data lake is een centrale opslagplaats voor grote hoeveelheden data in allerlei formaten. In correcte technologische termen is een data lake een “object store” met “buckets”. Vergelijk het met een emmer of een grote vergaarbak van informatie.
Waar een data warehouse vooral werkt met gestructureerde data in tabellen, kan een data lake vrijwel elk type bestand opslaan: van CSV's, Excel-bestanden en databasedumps tot PDF's, afbeeldingen, video's, logbestanden en zelfs ruwe binaire data. Je kan het vergelijken met een enorme netwerkschijf waarin alle data centraal wordt bewaard, terwijl toegang en beveiliging geregeld worden via API's.
Net zoals een data warehouse heeft een data lake als doel om data centraal beschikbaar te maken voor analyse en inzichten. Het grote verschil zit in de architectuur: opslag en rekenkracht zijn volledig van elkaar gescheiden.
De opkomst van het data lake gaf iedereen de mogelijkheid om goedkoop alles op te slagen. Het effect was dat iedereen dat ook deed. Maar zoals we weten uit de Spiderman strips: “With great power comes great responsibility”. Die vrijheid had dus ook een keerzijde: heel veel data, met heel weinig structuur. Veel bedrijven gingen hier te onvoorzichtig mee om en creëerden een “data swamp”, een ongestructureerde hoop ruwe data.
Daarnaast kwamen ook operationele uitdagingen boven: hoe gaan we om met nieuwe data? hoe met historische data? hoe bepalen we eigenaarschap en security? Dit zijn allemaal dingen die in een data warehouse of database “de basis” zijn, maar door de splitsing niet meer bestaan. Dit is een actief ontwikkeldomein voor data lake softwareproviders.
Een data lake is dus vooral interessant wanneer je flexibel wilt omgaan met grote hoeveelheden uiteenlopende data, schaalbaar wilt werken en analyses wil uitvoeren op volumes die vroeger onhaalbaar waren. Zonder goede structuur en data governance kan die flexibiliteit echter snel omslaan in chaos.
Voorbeelden van data lakes:
Rond 2019 ontstond een nieuwe evolutie: het data lakehouse. Grote technologiebedrijven achter data lakes merkten dat organisaties nood hadden aan meer structuur en betrouwbaarheid bovenop hun flexibele data lakes.
Een data lakehouse combineert daarom het beste van twee werelden:
Concreet betekent dit dat je data nog steeds goedkoop en schaalbaar kan opslaan in een data lake, maar tegelijk extra lagen toevoegt die structuur afdwingen. Denk aan vaste schema’s, kwaliteitscontroles, versiebeheer en parallelle query’s voor rapportering en analyse.
Voorbeelden van een data lakehouse:
De discussie “data warehouse versus data lake” gaat eigenlijk niet over welke technologie beter is. Het gaat over welke architectuur het best past bij jouw organisatie, jouw data en jouw noden.
Data lakes ontstonden omdat klassieke data warehouses het moeilijk kregen met de opkomst van big data: grote volumes, hoge verwerkingssnelheden en een grotere variëteit aan databronnen. Door opslag en rekenkracht van elkaar los te koppelen, werd dataopslag veel goedkoper en flexibeler. Die flexibiliteit had echter een nadeel: zonder voldoende structuur ontstonden vaak onoverzichtelijke data lakes. Daarom is een puur data lake vandaag zelden de beste keuze.
Het data lakehouse combineert de schaalbaarheid en flexibiliteit van een data lake met de structuur, betrouwbaarheid en analysemogelijkheden van een data warehouse. Veel moderne data-platformen en data-infrastructuren evolueren dan ook meer en meer richting een lakehouse-architectuur.
Een data warehouse blijft een sterke keuze voor organisaties die voornamelijk met gestructureerde data werken en die snel en betrouwbaar analyses willen doen. Het biedt structuur, performantie en eenvoud. Voor veel KMO’s is dat vandaag nog altijd meer dan voldoende.
Bovendien zijn moderne data warehouses veel flexibeler geworden dan vroeger. Ze kunnen data lezen uit en wegschrijven naar data lakes en passen daardoor perfect binnen hedendaagse data-architecturen. De grens tussen een data warehouse en een data lakehouse vervaagt steeds meer. Sterker nog: veel moderne data warehouses beschikken vandaag al over lakehouse-functionaliteiten zonder dat gebruikers zich daar bewust van zijn.
Maar wat heb je nodig?
Niet elk bedrijf heeft petabytes aan data, AI-modellen of complexe videobestanden. Voor veel organisaties is een goed opgebouwd data warehouse of lakehouse nog steeds de beste oplossing. Het biedt de structuur, eenvoud en betrouwbaarheid die nodig zijn om snel waarde uit data te halen. Groeit de hoeveelheid data, het aantal databronnen en de analytische ambities dan wordt de schaalbaarheid en flexibiliteit van een lakehouse-architectuur belangrijker. Voor grotere organisaties kan dat een doorslaggevend voordeel zijn.
De beste keuze is dus niet automatisch de nieuwste technologie, maar de oplossing die past bij de maturiteit, schaal en ambities van je organisatie.
Met MAKOkiezen we bewust voor een moderne open data warehouse/lakehouse-aanpak met ClickHouse. Waarom? Omdat het snel is, perfect werkt voor gestructureerde data en aansluit bij de realiteit van de meeste kmo’s. We kunnen eenvoudig schalen naar een volledige lakehouse architectuur. Daar bovenop ontsluiten we een sterk data security model in dezelfde software, waardoor je iedereen in de organisatie de kans geeft om datagedreven te werken.
En verandert je organisatie of noden later? Geen probleem. MAKO en Understanding Data is ontworpen om flexibel mee te evolueren met nieuwe technologieën en toekomstige data-architecturen, inclusief data lake- en lakehousemodellen.
Wil je meer weten over hoe MAKO hét datafundament is voor de KMO?
