Lakehouse of warehouse in Microsoft Fabric: welke kies je, en wanneer allebei?

Je bedrijf bekijkt Microsoft Fabric, of je bent er net mee gestart. Je klikt op "Nieuw item" en krijgt meteen een keuze voorgeschoteld: maak je een lakehouse of een warehouse? Twee termen die sterk op elkaar lijken, allebei bedoeld om data in op te slaan, en het scherm zelf legt niet uit wanneer je wat nodig hebt.

Die keuze is minder definitief dan ze lijkt, maar je maakt ze beter bewust. Hieronder lees je wat een data warehouse en een lakehouse zijn, hoe Microsoft ze in Fabric heeft ingevuld, waar het verschil precies zit en met welke vragen je beslist. Voorkennis is niet nodig.

Eerst de begrippen

Wat is een data warehouse?

Je ERP, je boekhoudpakket en je webshop hebben elk hun eigen database. Die databases zijn gebouwd om bestellingen en boekingen snel weg te schrijven, niet om vlot te antwoorden op vragen als "wat was onze marge per klant in de voorbije drie jaar". Zulke vragen, zeker over meerdere systemen heen, beantwoord je beter vanuit één aparte database die daarvoor gemaakt is. Die aparte database heet een data warehouse.

In een warehouse staat alles in nette tabellen: rijen en kolommen, zoals in een Excel-blad, maar met vaste afspraken over wat elke kolom bevat. Elke nacht of elk uur kopieer je de nieuwste cijfers uit je systemen naar die tabellen. Vragen stellen doe je met SQL, de standaardtaal om databases te bevragen. Je rapporteringstool, bijvoorbeeld Power BI, leest er rechtstreeks uit.

Wat is een data lake?

Een data lake vertrekt van het omgekeerde idee. Geen vaste tabellen, wel één grote opslagplaats waar je alles bewaart in de vorm waarin het binnenkomt: exports uit je ERP, CSV-bestanden van een leverancier, logbestanden van machines, PDF-facturen. Je beslist pas later wat je ermee doet. Dat maakt een lake goedkoop en flexibel voor grote hoeveelheden ruwe data. Het nadeel: een berg bestanden is nog geen databank. Rapporteren kan pas nadat iemand structuur aanbrengt.

En een lakehouse?

Een lakehouse combineert beide. Onderaan zit een data lake waar alle soorten bestanden in mogen. Daarbovenop ligt een laag die van een deel van die data nette tabellen maakt, zodat je ze kan bevragen zoals in een warehouse. Vandaar de naam: lake plus warehouse. Het begrip komt uit de bredere datawereld, Databricks maakte het populair, en Microsoft bouwde er zijn eigen versie van in Fabric.

Wat is Microsoft Fabric?

Microsoft Fabric is het platform waarin Microsoft sinds 2023 zijn datatools samenbrengt: data binnenhalen, opslaan, bewerken en rapporteren met Power BI, alles in één omgeving en één abonnement. Wie vandaag met Power BI werkt, komt vroeg of laat met Fabric in aanraking, want Power BI maakt er intussen deel van uit.

De fundering van Fabric heet OneLake. Vergelijk het met OneDrive, maar dan voor bedrijfsdata in plaats van Word-documenten: één centrale opslagplaats voor de hele organisatie, wat je er ook mee doet. Alle tabellen in OneLake gebruiken hetzelfde open bestandsformaat: Delta. Een Delta-tabel is een tabelformaat dat naast de data zelf ook alle wijzigingen bijhoudt, zodat verschillende tools veilig met dezelfde tabel kunnen werken.

Dat brengt ons bij het inzicht dat de keuze meteen eenvoudiger maakt: in Fabric bepaal je met de keuze tussen lakehouse en warehouse niet waar of hoe je data wordt opgeslagen. Beide bewaren hun tabellen als Delta-tabellen in OneLake. De opslag is identiek. Wat je wel kiest, is de manier van werken erbovenop.

Waarin verschillen ze dan?

Het warehouse: alles met SQL

Een warehouse in Fabric gedraagt zich als een klassieke SQL-database, vergelijkbaar met de SQL Server die veel bedrijven al in huis hebben. Je maakt tabellen aan, laadt data en wijzigt die data met T-SQL, de Microsoft-variant van SQL. Wie ooit een databank beheerde, voelt zich hier meteen thuis, en veel bestaande SQL-scripts blijven bruikbaar.

Het warehouse heeft één technische troef die het lakehouse niet heeft: transacties over meerdere tabellen. Dat betekent dat je meerdere tabellen in één beweging kan bijwerken, waarbij ofwel alles lukt, ofwel alles wordt teruggedraaid. Denk aan een correctie die tegelijk in je omzettabel en je voorraadtabel moet gebeuren: je wil niet dat de ene helft doorgaat terwijl de andere mislukt. Voor boekhoudkundige cijfers en officiële rapportering is dat een groot verschil.

Het lakehouse: code om te schrijven, SQL om te lezen

In een lakehouse werk je in de eerste plaats met Spark, een rekenmotor die grote datavolumes verwerkt en die je aanstuurt met code, meestal Python. Dat gebeurt in notebooks: documenten waarin code, uitleg en resultaten samen staan, handig om een bewerking stap voor stap op te bouwen. Naast tabellen heeft een lakehouse ook een bestandenzone, waar ruwe bestanden mogen staan die nog geen tabel zijn.

Bij elk lakehouse maakt Fabric automatisch een SQL analytics endpoint aan: een alleen-lezen toegang waarmee je de tabellen toch met SQL kan bevragen, views kan aanmaken en er Power BI-rapporten op kan bouwen. Lezen met SQL kan dus altijd. Data toevoegen of aanpassen via SQL kan niet, daarvoor gebruik je code of een van de laadtools van Fabric. Onder de motorkap draait dat endpoint trouwens op dezelfde SQL-motor als het warehouse.

Samengevat:

Warehouse: alles met SQL, lezen én schrijven, transacties over meerdere tabellen, enkel gestructureerde tabellen.
Lakehouse: schrijven met code (Spark), lezen met SQL via het endpoint, ook plaats voor ruwe bestanden van elk type.

Wanneer kies je het warehouse?

Kies het warehouse wanneer je data uit gestructureerde tabellen bestaat en de mensen die eraan werken vooral SQL kennen. Typische situaties bij KMO's:

Je wil verkoop-, marge- en voorraadrapportering bovenop je ERP, en de data komt netjes als tabellen binnen.
Er draait al een data warehouse op SQL Server en je wil die opzet meenemen naar de cloud zonder alles te herschrijven.
Je cijfers moeten kloppen tot op de cent, met correcties die over meerdere tabellen tegelijk lopen, zoals bij een maandafsluiting.
Je team of je partner schrijft vlot SQL, maar geen Python.

Wanneer kies je het lakehouse?

Kies het lakehouse wanneer je data gevarieerder is of je plannen breder zijn dan rapportering alleen:

Je bronnen zijn gemengd: naast ERP-tabellen ook CSV-exports, bestanden van leveranciers, machinedata of logbestanden.
Je wil naast rapportering ook analyses zoals vraagvoorspelling, waarvoor iemand met Python aan de slag gaat.
De volumes zijn groot of groeien snel, en je wil ruwe data goedkoop bijhouden zonder ze eerst in tabellen om te zetten.
Je weet nog niet goed waar je zal uitkomen. Microsoft zegt het zelf in zijn keuzegids: bij twijfel, start met een lakehouse.

Dat laatste is geen dooddoener. Een lakehouse kan alles bewaren, en dankzij het SQL analytics endpoint kan je er toch al mee rapporteren. Je sluit weinig uit door ermee te beginnen.

Moet je kiezen, of neem je beide?

In de praktijk komen ze vaak samen voor. Een gangbaar patroon deelt de data op in drie lagen, elk met een eigen doel:

Brons: een ruwe kopie van alles wat uit je bronsystemen komt, ongewijzigd bewaard.
Zilver: dezelfde data, maar opgekuist: dubbele records eruit, kolommen op orde, alles als nette tabellen.
Goud: rapporteringsklare tabellen, bijvoorbeeld omzet per klant per maand, waar Power BI op leest.

Microsoft noemt dit de medallion-architectuur. Een veel toegepaste invulling: brons en zilver in een lakehouse, en de goudlaag in een warehouse, zodat de rapporteringslaag volledig met SQL beheerd wordt. Even goed kan je alle lagen in lakehouses bouwen. Beide varianten staan in de officiële richtlijnen van Microsoft.

Combineren is bewust eenvoudig gehouden. Met een shortcut, een verwijzing naar data die ergens anders staat, maak je lakehouse-tabellen zichtbaar in je warehouse zonder ze te kopiëren. In één SQL-query kan je tabellen uit een warehouse en een lakehouse samen gebruiken. Je betaalt ook niet dubbel: lakehouse en warehouse zijn geen aparte licenties. Ze draaien op dezelfde Fabric-capaciteit, de rekenkracht die je in Fabric huurt. Wat je verbruikt hangt af van hoeveel je verwerkt en bevraagt, niet van het type item dat je aanmaakt.

Wat betekent dit voor je Power BI-rapporten?

Voor je rapporten maakt de keuze weinig uit. Power BI kan met Direct Lake rechtstreeks uit de Delta-tabellen in OneLake lezen, of die nu in een lakehouse of een warehouse staan. Rechtstreeks wil zeggen: zonder eerst een kopie van de data in het rapport te importeren en die kopie apart te moeten verversen. Nieuwe cijfers in de tabel zijn kort nadien zichtbaar in het rapport.

Wat als je verkeerd kiest?

Stel: je start met een lakehouse en zes maanden later blijkt dat je team liever volledig in SQL werkt, met transacties en al. Dan maak je een warehouse aan naast het lakehouse en verwijs je met shortcuts naar de bestaande tabellen, of je laadt de goudlaag voortaan daar. Omdat alles al als Delta-tabellen in OneLake staat, is dat een aanpassing van je werkwijze, geen migratieproject. Microsoft heeft het platform bewust zo opgezet dat je op elk moment het andere type kan toevoegen.

De keuze op dag één bepaalt dus hoe je team werkt, niet waar je data vastzit.

Wat je volgende week al kan doen

Lijst je databronnen op. Welke systemen bevatten data waarover je wil rapporteren, en zit daar iets tussen dat geen nette tabel is, zoals bestanden of logs?
Breng de skills in kaart. Wie gaat ermee werken, en kennen die mensen SQL, Python of geen van beide? Dit weegt het zwaarst in de keuze.
Activeer een gratis Fabric-proefperiode. Maak een lakehouse aan, laad er een export uit je ERP of webshop in en open het SQL analytics endpoint om te zien hoe bevragen werkt.
Noteer waar wijzigingen over meerdere tabellen tegelijk moeten gebeuren. Denk aan een maandafsluiting of correcties op omzet en voorraad samen. Vind je zo'n geval, plan dan een warehouse voor die laag.
Beslis daarna pas over je definitieve opzet. Een uur klikken in een proefomgeving zegt meer dan tien vergelijkende artikels.