Waarom datawarehouse-automatisering bovenop Azure Data Factory?
Azure Data Factory is de uitvoeringslaag. Het kopieert data, het orkestreert en het draait op een schema, en dat doet het goed. Wat ADF niet doet is bepalen welke tabellen er vandaag geladen moeten worden, hoe je een wijziging herkent, waar de historie blijft en wat er gebeurt als een bronsysteem een kolom hernoemt. Dat bouw je zelf, of je laat het genereren. Yres doet het tweede: het schrijft de ADF-pipelines, de tabellen en de laadlogica uit metadata, in de Data Factory van de klant zelf.
Laatst bijgewerkt:
Wat doet Azure Data Factory zelf?
ADF levert de connectoren, de copy-activiteit, de orkestratie en de triggers. Je wijst een bron en een doel aan, en het verplaatst de data. Het houdt per run bij of een pipeline geslaagd is.
Daarmee heb je een motor, geen datawarehouse. ADF weet niet wat een klantrecord is, of dat vestiging drie anders boekt sinds de fusie, of dat een adreswijziging van vorige maand bewaard moet blijven. Die kennis stop je erin, en dat is het werk.
Wat bouw je er zelf bovenop?
Bij één bron valt het mee. Bij dertig bronnen en een paar honderd tabellen wordt het een tweede product dat je onderhoudt naast je datawarehouse.
Microsoft documenteert zelf een metadata-driven patroon voor ADF: een controletabel met de objecten en laadparameters, en geparameteriseerde pipelines die daar hun werk uit halen. Dat is precies de goede richting. Het is alleen het begin van de lijst, niet het einde.
| Onderdeel | Levert ADF dit? | Wat het in de praktijk betekent |
|---|---|---|
| Bron aansluiten | Ja, connector aanwezig | Authenticatie, paginering en foutafhandeling configureer je per bron |
| Metadata van de bron ophalen | Nee | Je bouwt zelf het ophalen en bijhouden van kolommen en types |
| Staging | Nee | Eigen laag, eigen naamgeving, eigen opruiming |
| Incrementeel laden | Deels | Watermerk of CDC per bron zelf bedenken en bijhouden |
| Wijzigingsdetectie | Nee | Hashes of vergelijkingen zelf schrijven |
| Historie (SCD2) | Nee | De merge-logica is het lastigste stuk dat je zelf bouwt |
| Verdwenen records | Nee | Een record dat weg is uit de bron verdwijnt stilzwijgend |
| Schemawijzigingen | Nee | Een hernoemde kolom ziet een datawarehouse als een verdwenen plus een nieuwe kolom |
| Naar acceptatie en productie | Deels | ADF kent git en publiceren; welke wijziging bij elkaar hoort niet |
| Controles op de inhoud | Nee | Pipeline groen zegt niets over of de cijfers kloppen |
| Retentie van logging | Nee | Logtabellen groeien door tot iemand ingrijpt |
Wat genereert Yres daarvan?
Alles in die tabel, uit één metadatamodel. Je configureert een bron en de tabellen die je wilt, en Yres schrijft de ADF-pipelines en de linked services weg in je eigen Data Factory, met git-integratie naar je eigen Azure DevOps. De tabellen en de laadprocedures komen in je eigen Azure SQL.
Zeven laadtypes dekken de manieren waarop een bron zich gedraagt, van een volledige kopie tot een wijzigingsfeed. Zes ervan bouwen de historie op bij binnenkomst, omdat de meeste SaaS-API's alleen de huidige stand teruggeven en de historie daar dus niet vandaan kan komen.
Een nieuwe tabel aansluiten is daarna configuratie, geen ontwikkeling. Dat is het hele punt: het verschil tussen bron één en bron honderd moet zo klein mogelijk zijn.
- ADF-pipelines en linked services, in je eigen Data Factory
- Staging- en historietabellen, met SCD2 zonder dat je de merge schrijft
- Incrementeel laden met het watermerk dat bij de bron past
- Een wijzigingsproces over DTAP: wat bij elkaar hoort gaat samen naar de volgende omgeving
- Monitoring per load en per stap, plus controles op de inhoud in plaats van alleen op de run
Wat Yres bewust niet doet
Het datamodel. Kimball, Data Vault of een eigen variant: die keuze hangt af van je organisatie en je mensen, niet van je gereedschap. Yres levert de laag waar elke methodiek op kan staan en laat de modellering aan het team.
Dat is een architectuurkeuze en geen omissie, maar het is er wel een die je moet willen. Zoek je een product dat automatisch een dimensioneel model genereert, dan ben je bij andere leveranciers beter af en zeggen we dat ook.
Wanneer je ADF beter zelf houdt
Er zijn situaties waarin een automatiseringslaag erbij meer kost dan oplevert.
Het omslagpunt zit niet bij een bepaald aantal bronnen maar bij de vraag hoeveel een nieuwe bron kost nadat de eerste werkt. Blijft dat een middag, dan is er niets aan de hand. Kost bron eenentwintig net zoveel als bron één, dan betaal je je standaardisatie in uren in plaats van in licentie.
- Een handvol bronnen die zelden verandert
- Een sterk engineeringteam dat code-first wil werken en de standaardisatie zelf onderhoudt
- Een architectuur die om Databricks of Snowflake heen is gebouwd in plaats van om Azure SQL
- Streaming of near-realtime als kernvereiste; Yres laadt op een schema
Wat er van jou blijft
Alles staat in je eigen Azure-abonnement: de pipelines in je eigen Data Factory, de tabellen en historie in je eigen Azure SQL, je secrets in je eigen Key Vault, de git-historie in je eigen Azure DevOps.
De pipelines die Yres genereert, beheert Yres ook: handmatige wijzigingen daarin worden bij de volgende generatie overschreven. Wat jij in de custom-map zet blijft altijd staan, ook na een upgrade. Standaardwerk besteed je uit, uitzonderingen houd je zelf.
Veelgestelde vragen
Vervangt Yres Azure Data Factory?
Nee. Yres gebruikt ADF als uitvoeringslaag en genereert de pipelines die erin draaien. Je blijft dus op Azure Data Factory werken, alleen bouw je de pipelines niet meer met de hand.
Kan ik mijn bestaande ADF-pipelines houden?
Ja. Wat in de custom-map van je Data Factory staat, laat Yres met rust, ook bij hergeneratie en na een upgrade. Je eigen pipelines draaien gewoon naast de gegenereerde.
Genereert Yres een datamodel?
Nee, bewust niet. Yres levert de ingestion- en historielaag; het dimensionele of Data Vault-model bouw je zelf met je eigen views en procedures. Wil je dat een tool dat model voor je maakt, dan passen andere producten beter.
Wat gebeurt er met de ADF-pipelines als ik stop met Yres?
Die blijven staan. Ze draaien in je eigen Data Factory, in je eigen abonnement, met git-historie in je eigen Azure DevOps. Wij leggen bij vertrek geen beperkingen op.
Wat is het verschil met de metadata-driven copy van Microsoft zelf?
Dat patroon lost het kopieerdeel op: een controletabel stuurt geparameteriseerde pipelines aan. Yres doet dat ook, en daarnaast de historie, de wijzigingsdetectie, het uitrollen over DTAP, de controles op de inhoud en het onderhoud. Het verschil zit in alles na het kopiëren.
