Azure Data Factory implementatie

Je richt de factory zo in dat pipelines betrouwbaar en herhaalbaar laden. Een pipeline is een reeks activiteiten, zoals kopiëren of een notebook starten. Een linked service beschrijft een bron of rekendienst, en de integration runtime is de rekenkracht ertussen. Een Azure Data Factory consultant ontwerpt het laadpatroon, de runtimes, de triggers en de route naar productie.

ADF is de laadlaag van een data- en AI-platform. Wil je het hele platform op Azure inrichten, met opslag, netwerk en rekenlaag, lees dan over een Azure dataplatform inrichten.

Als een bron in een privénetwerk staat zonder directe verbinding met de cloud, zoals een SQL Server op kantoor. De self-hosted runtime draait op een Windows-machine achter je firewall en maakt alleen uitgaande HTTP-verbindingen. Voor bronnen met een eigen driver, zoals SAP HANA en MySQL, is hij ook nodig; daarvoor moet Java op dezelfde machine staan.

Voor beschikbaarheid koppel je meerdere machines aan één runtime, die dan actief-actief werken. In CI/CD moet de runtime in elke omgeving dezelfde naam en hetzelfde type hebben.

Een schedule trigger start pipelines op vaste tijden en kan meerdere pipelines tegelijk starten. Hij meldt succes zodra een run begint, ook als die later faalt. Een tumbling window trigger werkt met aaneengesloten tijdvakken, wacht op de uitkomst van de run, kan met terugwerkende kracht laden en probeert mislukte runs opnieuw.

Voor incrementeel laden per uur of per dag is de tumbling window trigger daarom vaak de veiligste keuze. Voor nieuwe bestanden in een storage account gebruik je een storage event trigger.

Met parameters die je bij elke run meegeeft. Microsoft noemt het voorbeeld van één linked service voor verschillende databases op dezelfde SQL-server: je maakt de databasenaam een parameter, in plaats van per database een linked service te maken. Een pipeline leest dan uit een lijst welke tabellen hij laadt.

Wachtwoorden parametriseer je niet. Microsoft raadt aan geheimen in Azure Key Vault te zetten en alleen de naam van het geheim als parameter te gebruiken.

Ontwikkelaars werken in een ontwikkelfactory die aan Git is gekoppeld, elk in een eigen branch. Na een pull request gaat de wijziging via Azure Pipelines naar test en productie, met Resource Manager-templates en parameters per omgeving. Zo past niemand meer iets aan in de live factory.

Let op instellingen die niet in die templates zitten, zoals de kostenrapportage per pipeline. Die zet je per factory zelf aan.

Zet een alert op de metric voor mislukte pipeline-runs, zodat het team een melding krijgt bij elke fout. Data Factory bewaart rungegevens maar een beperkte tijd. Stuur de logs daarom via diagnostische instellingen naar Log Analytics; daar kun je ook meerdere factories samen bevragen.

Per pipeline-run zie je het verbruik per meter. Zet je de kostenrapportage per pipeline aan, dan zie je in Cost Management welke pipeline wat kost.

Microsoft noemt Data Factory in Fabric de volgende generatie van ADF. Er zijn drie routes: je bestaande factory als item in een Fabric-workspace zetten, pipelines upgraden met de ingebouwde upgrade, of ze opnieuw bouwen. De upgrade deelt elke pipeline in als Ready, Needs review, Coming soon of Not compatible.

Linked services worden verbindingen, datasets staan in de activiteit zelf en globale parameters worden een variabelenbibliotheek. Vergelijk ook met Azure Synapse als je pipelines daar draaien.

Als je een paar bronnen hebt die Power BI zelf kan verversen, of als je helemaal nieuw begint en Fabric al de standaard is. Dan is een losse ADF-omgeving extra beheer zonder winst.

Zit het probleem niet in het laden maar in wat er daarna met de data gebeurt, zoals modellen, tests en datakwaliteit, dan begin je bij data engineering.