Data ophalen in Microsoft Fabric: alle ingestie-opties uitgelegd (met keuzehulp)

Optie	Type	Beste voor	Latency
Data Factory pipelines	Orkestratie + copy	Batch, workflow, dependencies	Minuten tot uren
Dataflows Gen2	Low-code ETL	Business-friendly transformaties	Minuten tot uren
OneLake Shortcuts	Zero-copy toegang	Virtualiseren, data mesh, hergebruik	Direct (lees-pad)
Mirroring	Replicatie	Near real-time database synch	Laag, doorlopend
Eventstream	Streaming	Events/telemetrie/real-time	Seconden tot minuten
Notebooks	Code-first	Complexe logica, API’s, ML	Variabel

Waarom “ingestie” in Fabric vaak meer is dan data kopiëren

Data ophalen in Microsoft Fabric begint meestal met één simpele vraag: wil je data echt verplaatsen, of wil je hem vooral snel en beheersbaar beschikbaar maken. Dat verschil bepaalt direct je kostenprofiel, je performance en hoeveel operationeel gedoe je later krijgt. In Fabric kun je namelijk zowel fysieke loads doen als data “virtueel” ontsluiten via OneLake. Daarom is het handig om ingestie te bekijken als drie lagen: transport, transformatie en beschikbaarheid voor consumerende workloads. In sommige situaties wil je vooral transport en orkestratie, bijvoorbeeld bij dagelijkse batchloads en afhankelijkheden. In andere situaties wil je juist minimale data movement, omdat de bron al in een open bestandsformaat staat en je vooral centrale toegang en governance zoekt. In de praktijk bouw je vaak combinaties, zoals een pipeline die een notebook draait en daarna een semantisch model laat refreshen. Het overzicht hieronder helpt je om per optie de juiste “eerste keuze” te maken en daarna pas te optimaliseren. Als je dit strak neerzet, win je tijd in development én vertrouwen bij je stakeholders.

Data Factory pipelines in Fabric

Data Factory pipelines zijn de workflowmotor voor batch ingestie en orkestratie in Fabric. Je gebruikt ze wanneer je meerdere stappen wilt koppelen, zoals kopiëren, wachten op afhankelijkheden, conditionele paden en monitoring van runs. Dit is vaak de snelste route als je van bron naar Lakehouse of Warehouse wilt zonder dat je eerst een hele codebase optuigt. Technisch gezien heb je vooral connectors, permissies en in sommige scenario’s een gateway nodig. Voor on-prem bronnen werk je met de on-premises data gateway en moet je rekening houden met netwerk- en gatewayvoorwaarden. Ook is het relevant dat copy-scenario’s met on-prem koppelingen beperkingen hebben, zoals het gebruik van één gateway binnen één Copy activity. De beperking van pipelines zit meestal niet in “kan het?”, maar in “hoeveel logica stop je erin?”. Zodra je zware datakwaliteit, complexe JSON, speciale authenticatie of ingewikkelde incremental patronen nodig hebt, schuif je vaak richting notebooks. Zie pipelines daarom als orkestratie en betrouwbare bulkverplaatsing, niet als de plek waar je alle businesslogica onderhoudt.

Dataflows Gen2

Dataflows Gen2 zijn de low-code ETL-optie in Fabric, gebouwd op Power Query Online. Je zet ze in als je snel en herhaalbaar wilt transformeren en je team graag werkt met een visuele editor in plaats van code. Dit is bijzonder handig wanneer business analisten en BI-consultants mee moeten kunnen bouwen of wanneer je transformatielogica herbruikbaar wilt maken buiten één rapport of model. De belangrijkste technische vereiste is dat je een Fabric capacity, trial capacity of Power BI Premium capacity nodig hebt om Dataflows Gen2 te gebruiken. Daarnaast kom je in echte omgevingen vaak uit bij een gateway voor on-prem bronnen en moet je letten op ondersteunde datatypen en bestemmingen. Als je dat negeert, krijg je verrassingen bij publiceren of bij het wegschrijven naar Lakehouse of Warehouse. De beperkingen zijn vooral operationeel: refresh-limieten, throttling en het feit dat performance per bron en query folding sterk kan verschillen. Dataflows Gen2 zijn geweldig voor veel standaard ETL, maar ze zijn niet automatisch de beste keuze voor grote volumes of extreem frequente runs. Mijn vuistregel is simpel: als je het gesprek voert over kosten per run en incremental strategieën, check je vroeg of een pipeline of notebook beter past.

OneLake Shortcuts

OneLake Shortcuts zijn geen klassieke ingestie, maar ze horen wel in elk ingestie-overzicht. Je gebruikt Shortcuts wanneer je data in open bestandsformaten al ergens hebt staan en je die data in Fabric wilt gebruiken zonder kopiëren. Dit is ideaal voor data mesh-achtige scenario’s, hergebruik van domeindata en situaties waarin je data movement minimaal wilt houden. Technisch gezien heb je vooral een ondersteunde shortcut-bron nodig en heldere afspraken over security. In veel scenario’s draait het om OneLake-to-OneLake of externe storage zoals ADLS Gen2 en S3, afhankelijk van wat in jouw tenant en governance is toegestaan. Security is belangrijk omdat je met shortcuts vaak een “doorverwijzing” maakt en daarmee ook het autorisatiemodel en lineage-effecten beïnvloedt. De beperkingen zitten in schaal en gedrag: er zijn limieten op aantallen en op shortcut-structuren, en lineage is niet overal beschikbaar. Daarnaast blijft het een lees-pad naar data die elders staat, dus je performance en beschikbaarheid hangen deels af van de bron en de verbinding. Als je team shortcuts inzet alsof het “gratis ingestie” is, kom je later in discussies over governance, ownership en wie er verantwoordelijk is bij incidenten.

Mirroring

Mirroring is de optie als je near real-time data uit databases in OneLake wilt hebben, zonder dat je zelf CDC-pipelines bouwt. Je gebruikt mirroring vooral wanneer analytics dichtbij de bron moet zitten, maar je toch een kopie in Fabric wilt om te kunnen combineren met andere domeinen en workloads. Het is ook een sterk antwoord op het klassieke probleem van “we willen rapporteren op operationele databases zonder ze te slopen”. Technisch vraagt mirroring om een ondersteunde bron en specifieke voorwaarden per databaseplatform. Bij Azure SQL zijn er bijvoorbeeld tier- en modelvoorwaarden en er zijn situaties waarin mirroring niet kan, zoals bepaalde configuraties of wanneer de database al elders gemirrord wordt. Bij Cosmos DB gelden weer eigen eisen, zoals configuratievoorwaarden rond continuous backup, en elk platform heeft zijn eigen set aan randvoorwaarden. De beperkingen zijn belangrijker dan veel teams denken, omdat ze direct impact hebben op scope. Denk aan caps op aantallen tabellen die gerepliceerd kunnen worden en gedragsregels rond replication en (her)seeding. Daarnaast geldt bij sommige mirrored varianten dat je niet zomaar terugschrijft naar de bron vanuit Fabric, waardoor mirroring een analytics-kopie blijft. Als je dit vooraf goed afbakent, voorkom je dat je pilot strandt op “we dachten dat alles mee kon”.

Eventstream

Eventstream is je keuze wanneer je data echt als stream binnenkomt en je binnen seconden tot minuten wilt reageren. Denk aan IoT, clickstreams, applicatie-events of realtime operationele signalen die direct naar Fabric moeten voor analyse of acties. In Fabric is Eventstream gekoppeld aan Azure Event Hubs-concepten, waardoor het in de praktijk goed aansluit op bestaande event-architecturen. Technisch draait Eventstream om bronnen, operators en bestemmingen, plus de juiste workspace en security-inrichting. Je moet rekening houden met service-limieten zoals maximale berichtgrootte en retentie, en ook met het feit dat delivery “at least once” is. Dat betekent dat je downstream rekening houdt met mogelijke duplicaten en idempotente verwerking. De beperkingen zijn vaak niet functioneel, maar architecturaal: streaming is geen batch, dus je datamodel, monitoring en foutafhandeling moeten anders. Ook is het belangrijk om vooraf te kiezen waar je stream “landt”, omdat je kosten en query-ervaring meebewegen met je destination-keuze. Als je Eventstream inzet zonder duidelijke use case voor realtime, bouw je vooral complexiteit waar batch prima genoeg was.

Notebooks

Notebooks zijn de code-first route voor data ophalen in Microsoft Fabric, met maximale vrijheid in Python, Spark en dataverwerking. Je gebruikt notebooks als je complexe transformaties hebt, grote volumes efficiënt wilt verwerken of wanneer je integraties doet die in low-code lastig worden. Vooral API’s met complexe JSON, speciale authenticatie en custom libraries zijn typische notebook-gevallen. Technisch heb je een Lakehouse-context, de juiste runtime en toegang tot je bronnen nodig. Fabric ondersteunt het lezen en schrijven richting lakehouse via Spark en Pandas API’s, waardoor je zowel “raw landing” als curated delta tables kunt bouwen. In teams is het slim om afspraken te maken over repo-structuur, parameterisatie en herhaalbaarheid, zodat notebooks niet verworden tot losse experimenten in productie. De beperking van notebooks is zelden de techniek, maar vaker governance en beheersbaarheid. Zonder standaarden voor logging, dependency management en deployment kan het snel rommelig worden, zeker als meerdere engineers eraan werken. Als je notebooks professioneel inzet, zijn ze vaak de meest toekomstvaste keuze omdat je elk ingestiepatroon kunt modelleren, inclusief incremental loads en datakwaliteit. “Notebooks zijn geen last resort, ze zijn je gereedschap voor volwassen data engineering.”

Hoe kies je snel de juiste ingestie-optie

Een goede keuze begint bij één heldere vraag: wil je batch, near real-time replicatie, of echte streaming. Batch hoort meestal bij pipelines en dataflows, replicatie bij mirroring en streaming bij eventstream, met notebooks als flexibele “escape hatch” voor alles wat niet netjes in een wizard past. Door dit eerst scherp te zetten, voorkom je dat je een streaming-oplossing bouwt voor een daily refresh probleem. Daarna kijk je naar data movement en ownership: als je data niet wilt kopiëren en hij staat al in een open formaat, dan zijn shortcuts vaak de kortste route. Als je juist een analytics-kopie wilt met lage latency vanuit een databasebron, dan kom je uit bij mirroring. En als je te maken hebt met on-prem bronnen, netwerkrestricties of lastige authenticatie, dan is de technische haalbaarheid vaak leidend en wint code-first sneller dan je denkt. Tot slot bepaal je wie het gaat onderhouden: een business-gedreven team is vaak sneller met Dataflows Gen2, terwijl engineeringteams vaak standaardiseren op pipelines plus notebooks. Het echte succes zit in consistentie: kies een voorkeursroute per scenario en documenteer die als teamstandaard. Zo bouw je niet alleen een werkende ingestie, maar ook een platform dat schaalbaar blijft.