Kernpunten
- Een datawarehouse brengt data uit meerdere bronnen samen, met vaste definities en historie, speciaal voor rapportage en analyse.
- Met ETL transformeer je data vóór het laden; met ELT laad je eerst en transformeer je in het warehouse zelf.
- Een data lake slaat ruwe data in elk formaat op; een data lakehouse voegt daar tabelstructuur en beheer aan toe.
- Voor AI op cijfers is een datawarehouse niet verplicht, maar het maakt de antwoorden wel betrouwbaarder en veiliger.
Wat een datawarehouse doet
Bronsystemen zoals een ERP, CRM of kassasysteem zijn gebouwd om transacties snel en correct vast te leggen. Ze zijn niet gemaakt voor vragen die over systemen en jaren heen gaan. Elk systeem heeft bovendien eigen codes en definities: een klant in het CRM is niet automatisch dezelfde klant in de boekhouding.
Een datawarehouse lost dat op. Het haalt data periodiek uit de bronnen, legt verbanden, hanteert één set definities en bewaart historie, ook als een bronsysteem gegevens overschrijft. Zo ontstaat een single source of truth: één plek waar omzet, marge en voorraad voor iedereen hetzelfde betekenen.
Een voorbeeld: Acme Groothandel wil de marge per klantsegment per maand zien. De orders staan in het ERP, de segmenten in het CRM en de inkoopprijzen in een apart prijsbestand. In een datawarehouse komen die drie samen in één model waarop dashboards en analyses draaien.
ETL en ELT: zo komt data in het datawarehouse
Data komt via een pijplijn in het warehouse. Bij ETL (extract, transform, load) haal je data op, bewerk je die in een aparte tool en laad je het resultaat. Bij ELT (extract, load, transform) laad je de ruwe data eerst in het warehouse en transformeer je die daarna met SQL in het warehouse zelf. In cloudomgevingen is ELT gangbaar geworden, omdat opslag en rekenkracht daar flexibel zijn.
Voor het ophalen bestaan veel tools, zoals Airbyte, Azure Data Factory en de pijplijnen in Microsoft Fabric. Voor het transformeren in het warehouse wordt vaak dbt gebruikt. Welke tool je kiest, is minder belangrijk dan dat de laadprocessen bewaakt worden en dat iemand eigenaar is van de definities.
| ETL | ELT | |
|---|---|---|
| Volgorde | Extract, transform, load | Extract, load, transform |
| Waar je transformeert | In een aparte tool of server, vóór het laden | In het datawarehouse zelf, meestal met SQL |
| Ruwe data bewaard | Vaak niet | Ja, in een aparte laag |
| Past bij | Vaste structuren, of gevoelige data die je vooraf wilt filteren | Cloudwarehouses, wisselende vragen, achteraf opnieuw berekenen |
Datawarehouse, data lake of data lakehouse
Naast het klassieke datawarehouse kom je twee andere begrippen tegen. Een data lake is een opslagplaats voor ruwe data in elk formaat: tabellen, bestanden, logs of afbeeldingen. De structuur bepaal je pas bij het lezen. Een data lakehouse combineert beide: de opslag van een data lake met open tabelformaten zoals Delta Lake of Apache Iceberg, zodat je er ook met SQL en BI-tools op kunt werken.
Een data lake platform of lakehouse is vooral interessant bij grote volumes, veel soorten data of data science. Microsoft Fabric is bijvoorbeeld opgebouwd rond OneLake, één centraal data lake voor de hele organisatie. Voor veel mkb-organisaties met vooral ERP-, CRM- en financiële data is een relationeel datawarehouse genoeg, en eenvoudiger te beheren.
| Datawarehouse | Data lake | Data lakehouse | |
|---|---|---|---|
| Soort data | Gestructureerd (tabellen) | Alles: tabellen, bestanden, logs, afbeeldingen | Alles, met een tabellaag erbovenop |
| Structuur | Vooraf bepaald (schema-on-write) | Bij het lezen bepaald (schema-on-read) | Open tabelformaten met een schema |
| Typische techniek | Relationele database, zoals PostgreSQL of SQL Server | Objectopslag, zoals Azure Data Lake Storage of Amazon S3 | Objectopslag met Delta Lake of Iceberg, zoals OneLake of Databricks |
| Sterk in | Rapportage, BI, consistente KPI's | Grote volumes, ruwe data, data science | Beide combineren op één platform |
| Aandachtspunt | Minder geschikt voor ongestructureerde data | Zonder beheer wordt het een onoverzichtelijke "data swamp" | Meer componenten en specialistische kennis nodig |
Lagen en datamodel in een datawarehouse
Een goed datawarehouse werkt met lagen. In de eerste laag landt de ruwe data zoals die uit de bron komt. In de tweede laag wordt die opgeschoond en samengevoegd: dubbele klanten eruit, codes vertaald, datums gelijkgetrokken. De laatste laag is ingericht voor gebruikers en tools. In lakehouse-omgevingen heten die lagen vaak brons, zilver en goud.
Voor die laatste laag is het sterschema de standaard. In het midden staat een feitentabel met gebeurtenissen en bedragen, zoals orderregels; daaromheen staan dimensietabellen met beschrijvingen, zoals klant, product en datum. Power BI werkt het best met zo'n model, en ook AI die SQL schrijft heeft er baat bij: begrijpelijke namen en duidelijke relaties vergroten de kans op een juiste query.
Heb je een datawarehouse nodig voor AI?
Niet strikt, maar voor AI op cijfers maakt het een groot verschil. Een AI-model dat SQL schrijft op de ruwe tabellen van een ERP-systeem, krijgt te maken met cryptische namen, technische codes en ontbrekende relaties. Op een datawarehouse met begrijpelijke namen, vastgelegde definities en een datadictionary zijn de antwoorden een stuk betrouwbaarder.
Er is ook een veiligheidsargument. Queries draaien dan niet op je productiesysteem, je bepaalt precies welke tabellen beschikbaar zijn en je kunt alleen-lezen toegang afdwingen. Voor AI op documenten (RAG) heb je geen datawarehouse nodig, maar een goede documentenindex.
ENABLE werkt met een PostgreSQL-datawarehouse per klant. Bronnen zoals Microsoft Dynamics 365 Business Central worden buiten het portaal ingeladen, bijvoorbeeld met Airbyte, en daarna in ENABLE gebruikt voor dashboards, de SQL Explorer met AI en de Data-API.
Wanneer een datawarehouse de moeite waard is
Heb je één bronsysteem met goede ingebouwde rapportages en weinig behoefte aan combinaties, dan kun je vaak nog zonder. Begin in elk geval bij de vragen die je wilt beantwoorden en niet bij de technologie: een warehouse waarin alles één op één wordt gekopieerd, zonder model en definities, lost weinig op.
Een datawarehouse is een investering in tijd en beheer. Het loont meestal als je een of meer van deze signalen herkent:
- Je combineert data uit meerdere systemen, nu nog handmatig in Excel.
- In overleggen circuleren verschillende cijfers voor hetzelfde begrip.
- Rapporten op je ERP-systeem zijn traag of belasten de dagelijkse operatie.
- Je verliest historie, omdat bronsystemen oude waarden overschrijven.
- Je wilt AI of externe systemen toegang geven tot data, zonder ze in je bronsystemen toe te laten.