Data lakehouse laten bouwen
We bouwen een data lakehouse in lagen van brons, zilver en goud, met één use case als start, zoals bij Fokker Services Group.
Voor Fokker Services Group bouwen we aan een dataplatform volgens de medaillonarchitectuur
Data uit veel bronnen wordt samengebracht, opgeschoond en gemodelleerd volgens de medaillonarchitectuur, op Databricks in Azure en met dbt. De datastromen zijn direct gekoppeld aan use cases zoals planning, voorraadbeheer en kosteninzicht.
Waarom rekent ons datateam op een andere kopie dan het dashboard?
De data scientist haalt ruwe bestanden uit het data lake, de controller rapporteert uit een apart datawarehouse en elke nacht kopieert een job tabellen van het een naar het ander. Een lakehouse zet beide op dezelfde tabellen, met één set rechten.
Je krijgt één opslaglaag voor rapportage en machine learning, ingedeeld in brons, zilver en goud
Ruwe data die bewaard blijft
Brons bewaart de bron zoals hij binnenkwam, zodat je opnieuw kunt verwerken. Bij Vivara komt dagelijks data uit onder meer SAP, Magento en SharePoint binnen.
Opgeschoond in zilver, klaar in goud
Zilver controleert en ontdubbelt, goud levert tabellen per vraag. Bij Fokker Services Group zitten de datakwaliteitscontroles in het platform zelf.
Open tabellen in je eigen opslag
De tabellen staan in het open Delta-formaat in je eigen cloudopslag of in OneLake. Power BI, SQL en Python lezen dezelfde tabellen.
Rechten en herkomst per tabel
Een catalogus regelt wie wat ziet en waar een tabel vandaan komt. Voor het Koninklijk Concertgebouworkest werken we met Delta Lake en Unity Catalog.
Eén vraag gaat eerst door alle lagen, daarna sluiten we de volgende bronnen aan
-
Platform en lagen kiezen
We kiezen het platform bij je cloud en team, en leggen catalogi of workspaces en een eigenaar per laag vast.
-
Eén use case door de lagen
Voor één concrete vraag laden we de bronnen in brons en bouwen we zilver en goud. Gebruikers toetsen de uitkomst.
-
Uitbreiden en beheren
Nieuwe bronnen hergebruiken dezelfde lagen en releases lopen via Git. Daarna beheert je team het platform, of wij.
Hebben wij een lakehouse nodig, of volstaat iets lichters?
Past als
Naast ERP- en CRM-tabellen komen er sensordata, logbestanden, documenten of JSON uit API's bij, en je wilt dezelfde data voor rapportage en machine learning gebruiken zonder twee kopieën bij te houden.
Past niet als
Je rapporteert uit een paar gestructureerde bronnen en je team werkt in SQL. Dan is een datawarehouse eenvoudiger. Gaat het om een handvol overzichten, dan volstaat vaak een Power BI-model op de bron.
Waar de omvang van afhangt
Het aantal bronnen en hoe vaak ze verversen, of er streaming bij komt, hoeveel historie je bewaart, of er al een omgeving staat die we kunnen hergebruiken en wie het beheer doet.
Zitten we daarna vast aan één leverancier?
De data staat in het open Delta-formaat in je eigen opslag, en pipelines en transformaties staan als code in je eigen Git. Overstappen kost werk, maar je data blijft van jou en leesbaar.
Bouwen we het lakehouse op Databricks, op Microsoft Fabric of op allebei?
Databricks
Kies dit als je team in Python en Spark werkt, je data op Azure, AWS of Google Cloud staat of modellen met versiebeheer in productie moeten. Zie Databricks implementatie.
Microsoft Fabric
Kies dit als Power BI al de standaard is en je weinig infrastructuur wilt beheren. Brons en zilver worden lakehouses, goud eventueel een warehouse. Zie Microsoft Fabric implementatie.
Allebei
Kies dit als engineering in Azure Databricks zit en de organisatie Power BI gebruikt. Fabric leest de catalogus dan zonder kopie. Ons advies: houd één plek waar tabellen worden geschreven.
Als partner van Databricks en Microsoft adviseren we het platform dat bij je organisatie past
Data Science Lab werkt sinds 2016 met data en AI, vanuit Amsterdam. Op Databricks werken we aan dataplatforms voor onder meer Fokker Services Group, Vivara en het Koninklijk Concertgebouworkest.

Welke bron als eerste naar brons gaat, bepalen we samen in het eerste gesprek
Stef Stoelwinder
Business DevelopmentStef is je eerste aanspreekpunt. In het eerste gesprek bespreken we je bronnen, je huidige platform en de eerste vraag voor het lakehouse.
E-mail info@datasciencelab.nl
Telefoon +31 (0)20 3636 724
Welke bronnen moeten straks samen in ons lakehouse?
Vertel welke bronnen en welk platform je nu gebruikt. Je krijgt antwoord per mail, of we plannen een eerste gesprek.
Bericht verstuurd
Bedankt voor je bericht. We nemen zo snel mogelijk contact met je op.
Veelgestelde vragen
Een data lakehouse combineert de goedkope, open opslag van een data lake met de betrouwbaarheid van een datawarehouse. De data staat als bestanden in een open formaat, maar met een laag erboven die transacties, schemacontrole en rechten regelt.
Zo werken rapportage, analyse en machine learning op dezelfde gevalideerde tabellen, in plaats van op elk een eigen kopie. Het lakehouse is een onderdeel van ons data fundament.
Een datawarehouse levert schone, gestructureerde tabellen voor BI en wordt meestal in SQL ontwikkeld. Een lakehouse kan daarnaast ongestructureerde en semigestructureerde data bewaren, zoals logbestanden en JSON, en is gebouwd voor Spark en Python naast SQL.
De grens vervaagt: in Microsoft Fabric slaan lakehouse en warehouse allebei Delta-tabellen op in OneLake. Volgens Microsoft past een warehouse als je T-SQL en transacties over meerdere tabellen nodig hebt. Werk je vooral met gestructureerde data uit ERP en CRM, lees dan over een datawarehouse laten bouwen.
De medallion architectuur, of medaillonarchitectuur, deelt een lakehouse in drie lagen in. Brons bevat ruwe, ongevalideerde data zoals hij uit de bron kwam. Zilver is gevalideerd, opgeschoond en ontdubbeld. Goud bevat tabellen per bedrijfsvraag, voor dashboards en modellen.
Databricks noemt het een aanbevolen werkwijze, geen verplichting, en raadt af om vanuit de inname direct naar zilver te schrijven: een schemawijziging in de bron breekt dan je pipeline. Microsoft adviseert in Fabric elke laag in een eigen workspace te zetten, voor meer grip per laag.
Delta Lake slaat data op als Parquet-bestanden met een transactielog erbij. Dat geeft ACID-transacties, schemacontrole bij het schrijven en een versie per wijziging, zodat je met time travel een eerdere stand kunt opvragen. Het is het standaardformaat in zowel Databricks als Microsoft Fabric.
Omdat het protocol open is, kunnen ook andere tools de tabellen lezen. Met UniForm maakt Databricks er Iceberg-metadata bij, zodat Iceberg-lezers dezelfde bestanden kunnen lezen zonder kopie.
Op Databricks met Unity Catalog: tabellen, volumes en modellen krijgen een naam als catalog.schema.tabel, rechten gaan via groepen en lineage laat zien welke bron in welk dashboard terechtkomt. Voor het Koninklijk Concertgebouworkest werken we met Delta Lake en Unity Catalog.
In Fabric doen workspacerollen, OneLake-beveiliging tot op rij- en kolomniveau en gevoeligheidslabels uit Microsoft Purview dat werk. De afspraken over eigenaarschap en definities horen bij data governance.
Vraagt iemand op grond van de AVG om zijn gegevens te wissen, dan is een DELETE niet genoeg. Delta Lake bewaart oude tabelversies voor time travel, dus de gegevens staan nog in de bestanden tot VACUUM die opruimt. Bij tabellen met deletion vectors is daarvoor eerst nog een REORG-stap nodig.
Databricks adviseert te beginnen in de bronslaag en de verwijdering daarna door te voeren in zilver en goud. Leg dat proces vast voordat het eerste verzoek binnenkomt. Over de juridische kant beslist je jurist of privacyfunctionaris.
Zelden op de techniek. Meestal ontbreekt een eigenaar per tabel, schrijft elk team in zijn eigen map en weet niemand meer welke notebook een goudtabel vult. Dan wordt het lakehouse alsnog een moeras van bestanden.
Ook onderhoud wordt vergeten. Veel kleine bestanden vertragen queries, en zonder VACUUM groeit de opslag door oude versies. Op Databricks regelt predictive optimization dat voor beheerde tabellen. Wie het platform na livegang onderhoudt, spreek je vooraf af; dat kan je eigen team zijn of beheer en doorontwikkeling bij ons.
Als je uit een paar gestructureerde bronnen rapporteert, je team in SQL werkt en er geen machine learning of ongestructureerde data aankomt. Dan is een datawarehouse eenvoudiger te bouwen en te beheren. Gaat het om een handvol overzichten uit één systeem, dan volstaat vaak een Power BI-model op de bron.
Een rommelige bron los je met een lakehouse ook niet op; daar begin je bij afspraken over de invoer. Past een lichtere oplossing, dan zeggen we dat. Wil je eerst aanbieders vergelijken, bekijk dan ons overzicht van dataplatformbureaus.
Op welk platform komt jouw lakehouse te staan?
- Data fundamentHoe we een betrouwbare dataomgeving bouwen als basis voor rapportage en AI.
- Databricks implementatieEen lakehouse op Delta Lake met Unity Catalog, Lakeflow en MLflow, in je eigen cloud.
- Microsoft Fabric implementatieOneLake, lakehouses en Power BI in één beheerde omgeving binnen je Microsoft-tenant.