Dataflows Gen1 vs Gen2 in Microsoft Fabric: de juiste staging- en computearchitectuur kiezen

By Mirko Peters · 2026-10-28

Vergelijk Dataflows Gen1 en Gen2 in Microsoft Fabric. Lees hoe opslag, staging en capaciteit invloed hebben op je cloud-ETL-strategie.

Automatically translated with AI from the original post. Read the English original

Bij de migratie van ETL-workloads naar Microsoft Fabric bepaalt de keuze van de juiste staging- en computearchitectuur tussen Dataflows Gen1 en Gen2 rechtstreeks je pipelineprestaties, resourcekosten en de betrouwbaarheid van je data. Inzicht in de onderliggende verschillen in computetoewijzing en opslagafhandeling voorkomt kostbare architectuurknelpunten voordat je team de rapportage opschaalt.

Belangrijkste punten

• Dataflows Gen2 brengt native integratie met OneLake, waardoor de manier waarop data wordt gestaged en opgeslagen fundamenteel verandert ten opzichte van Gen1.
• Een verkeerde computekeuze tijdens het ontwerpen kan leiden tot onverwachte capaciteitsbeperking en prestatieverlies in je Fabric-werkruimte.
• Gen1 vertrouwde sterk op externe opslagmechanismen, terwijl Gen2 standaard rechtstreeks naar Fabric Lakehouse-tabellen schrijft als bestemming.
• Een correcte stagingconfiguratie voorkomt dubbele transformaties en optimaliseert de refreshes van je Power BI-semantische modellen.
• Door je ETL-strategie af te stemmen op Fabric-capaciteitseenheden voorkom je dat je organisatie onbeheersbare computekosten maakt.

De architectuurverschuiving in Fabric begrijpen

De overstap van klassieke Power BI-dataflows naar Microsoft Fabric-dataflows is geen simpele herbranding; het is een volledige herziening van de architectuur van hoe clouddata wordt ingelezen, getransformeerd en opgeslagen. In de oude wereld van Gen1 waren dataflows vooral bedoeld om Power BI-semantische modellen te voeden. Ze werkten binnen een nogal geïsoleerd ecosysteem: datatransformaties gebeurden in Power Query Online en de output werd opgeslagen in interne opslag die volledig door de Power BI-service werd beheerd.

Met de introductie van Microsoft Fabric zijn Dataflows Gen2 vanaf de grond af opgebouwd om OneLake als centrale datarepository te gebruiken. Dat betekent dat elke transformatie die je toepast via Power Query Online niet langer vastzit in een propriëtair modelcontainer. In plaats daarvan overbrugt Gen2 de kloof tussen traditionele self-service datavoorbereiding en enterprise data engineering door rechtstreeks te schrijven naar Delta Parquet-tabellen in een open formaat binnen een Fabric Lakehouse. Deze fundamentele verandering beïnvloedt hoe cloudarchitecten omgaan met datastaging, computegebruik en het vertrouwen in downstream-rapportage.

De verschuiving in opslag

In oudere opzetten kon een business analyst die een Excel-export moest opschonen, lege rijen moest verwijderen en datums moest opmaken, die data alleen binnen de opslaggrens van de dataflow gebruiken. Als een andere afdeling diezelfde opgeschoonde dataset wilde gebruiken, moest ze die vaak uit het rapport halen of de query opnieuw maken. Dataflows Gen2 lost dit op door het Lakehouse als eerste-klas bestemming te behandelen. Zodra je dataflow wordt uitgevoerd, is de opgeschoonde data meteen beschikbaar als Delta-tabellen, klaar voor Spark-notebooks, SQL-analyse-endpoints en rechtstreekse DirectLake-rapportage, zonder extra datatransport.

De beslissing over compute en staging die de meeste teams missen

Een van de belangrijkste architectuurbeslissingen bij het bouwen van Dataflows Gen2 is het beheren van de compute- en stagingfasen. Anders dan bij Gen1, waar het computebeheer grotendeels was geabstraheerd en soms ondoorzichtig, draait Gen2 op de onderliggende Fabric Capacity Units (CU's). Als je organisatie niet zorgvuldig bijhoudt hoe en wanneer data wordt gestaged tijdens de queryevaluatiefase, loop je het risico dat je capaciteit sneller opraakt dan verwacht.

Wanneer je complexe transformaties toepast, bepaalt Power Query of stappen kunnen worden teruggevouwen naar de brondata of lokaal in de dataflow-engine moeten worden uitgevoerd. In Gen2 fungeert het staginggebied als tussenliggende landingszone. Bij een verkeerde configuratie kunnen grote datasets herhaaldelijk in het geheugen worden geladen, verwerkt en weggeschreven, wat onnodige computebelasting oplevert. Architecten moeten hun brontsystemen, netwerklatentie en transformatiecomplexiteit beoordelen om te bepalen of de verwerking naar de brondatabase moet worden gepusht of dat Fabric het zware werk moet doen.

Capacity Units optimaliseren voor ETL-workloads

Fabric-capaciteit is een gedeelde pool binnen je organisatie. Wanneer een slecht geoptimaliseerde Dataflow Gen2 geplande vernieuwingen draait tijdens piekuren, kan die capaciteit opeisen en daardoor de weergave van Power BI-rapporten voor managers beperken. Om dat te voorkomen, kunnen teams zware ETL-taken isoleren in aparte werkruimten met passende capaciteitsreserveringen, of ze plannen buiten de piekuren. Begrijpen hoe achtergrondcomputetaken samenwerken met interactieve workloads is essentieel voor een stabiele Fabric-omgeving.

Vertrouwen opbouwen met een consistente architectuur

Het uiteindelijke doel van het upgraden van je datapijplijnen is het wegnemen van de handmatige Excel-correcties die de bedrijfsrapportage teisteren. Wanneer rapporten falen, ligt dat zelden aan een gebrek aan data; bijna altijd ligt het aan een gebrek aan vertrouwen. Wanneer gebruikers tegenstrijdige cijfers zien omdat het ene rapport een ruwe CSV gebruikt en het andere een verouderde dataflow, keldert de adoptie.

Door te standaardiseren op Dataflows Gen2 en de Lakehouse-architectuur te gebruiken, creëren organisaties één enkele bron van waarheid. Opgeschoonde datums, gestandaardiseerde kolomnamen en gevalideerde bedrijfslogica worden één keer vastgelegd in de dataflow en automatisch doorgegeven aan downstream-items. Dit vermindert menselijke fouten, haalt de afhankelijkheid van individuele desktops weg en zorgt ervoor dat de onderliggende cijfers betrouwbaar en controleerbaar zijn wanneer het management een dashboard opent.

Conclusie

Migreren naar en bouwen met Dataflows Gen2 vraagt om een andere kijk op cloudopslag, computebudgetten en datagovernance. Begin met één terugkerend, rommelig spreadsheetproces, breng dat correct in kaart in een Fabric Lakehouse, en je team bouwt schaalbare pijplijnen die de tijd doorstaan. Wil je de achterliggende concepten van deze evolutie verkennen en expertinzichten horen over moderne Microsoft-cloudstrategieën? Luister dan zeker naar de volledige aflevering van de M365 FM Podcast: Listen to the full episode.

Veelgestelde vragen

Wat is het belangrijkste verschil tussen Dataflows Gen1 en Gen2 als het gaat om opslag?

Dataflows Gen1 slaan getransformeerde data op binnen de interne opslaggrenzen van Power BI, terwijl Dataflows Gen2 native wegschrijven naar open Delta Parquet-tabellen in een Microsoft Fabric Lakehouse via OneLake.

Hoe beïnvloeden Dataflows Gen2 de Fabric Capacity Units?

Gen2-dataflows gebruiken onderliggende Fabric-capaciteit tijdens hun compute- en stagingfasen. Slecht geoptimaliseerde transformaties of zware vernieuwingen tijdens piekuren kunnen je capaciteit uitputten en andere workloads beperken.

Kan Dataflows Gen2 traditionele Azure Data Factory-pijplijnen vervangen?

Voor self-service datavoorbereiding, lichtgewicht ETL en low-code datatransformatie zijn Dataflows Gen2 een uitstekend alternatief. Voor complexe orkestratie op enterprise-niveau, vertakkingslogica en geavanceerde data engineering blijven Azure Data Factory of Fabric Pipelines echter de voorkeurstools.

Waarom is de stagingfase belangrijk in Dataflows Gen2?

De stagingfase fungeert als tussenliggend landingsgebied voor datatransformaties. Door staging correct te configureren voorkom je onnodige dubbele verwerking, optimaliseer je query folding en zorg je voor efficiënte writes naar je doel-Lakehouse.

Hoe verbeteren Dataflows Gen2 de datavertrouwen in rapportages?

Doordat Gen2 het opschonen van rommelige handmatige exports automatiseert en transformaties centraliseert in herbruikbare Lakehouse-tabellen, schaft het handmatige Excel-omwegen af en zorgt het voor consistente, betrouwbare data in alle downstream-rapporten.