Ga naar de inhoud

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.

Lees de case

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.

Plan een gesprek
Man staat voor een whiteboard met een getekend stroomschema en schetsen, met papieren onder zijn arm.

Je krijgt één opslaglaag voor rapportage en machine learning, ingedeeld in brons, zilver en goud

Bespreek je lakehouse

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

  1. Platform en lagen kiezen

    We kiezen het platform bij je cloud en team, en leggen catalogi of workspaces en een eigenaar per laag vast.

  2. 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.

  3. 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?

Toets het in een gesprek

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.

Plan een kennismaking

Welke bron als eerste naar brons gaat, bepalen we samen in het eerste gesprek

Stef Stoelwinder

Stef Stoelwinder

Business Development

Stef is je eerste aanspreekpunt. In het eerste gesprek bespreken we je bronnen, je huidige platform en de eerste vraag voor het lakehouse.

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.

Vul een geldig e-mailadres in.

Laat ons weten waar we je mee kunnen helpen.

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.