Microsoft Fabric

Introductie

Modern Data Platform Architecture plaatste Fabric al naast Snowflake en Databricks: de sterkste keuze bij diepe Microsoft-ecosysteemintegratie. Dit hoofdstuk gaat voorbij die vergelijking en behandelt wat Fabric architectonisch fundamenteel anders maakt dan de andere twee platformen: één gedeelde opslaglaag (OneLake) onder meerdere gespecialiseerde workloads, in plaats van één enkele compute-engine met één opslagvorm.

OneLake: "OneDrive voor Data"

Waar Snowflake en Databricks elk hun eigen opslagabstractie hanteren (Snowflake's interne storage, Databricks' Delta-tabellen op cloud storage), heeft Fabric daar één laag onder getrokken: OneLake, één enkele, tenant-brede opslaglaag waar letterlijk elk Fabric-workload — Lakehouse, Data Warehouse, KQL Database, Power BI-semantische modellen — zijn data in dezelfde onderliggende Delta Parquet-bestanden opslaat. Microsoft noemt dit zelf "OneDrive voor data": één account, één opslagplek, ongeacht welke tool je gebruikt om ernaar te kijken.

De praktische consequentie is groot: data die je in een Lakehouse landt, hoeft niet gekopieerd of geëxporteerd te worden om in een Data Warehouse of vanuit Power BI bevraagd te worden — hetzelfde fysieke Delta-bestand wordt door meerdere engines gelezen, elk met hun eigen sterkte (SQL-analytics in Warehouse, Spark-notebooks in Lakehouse, tijdreeksanalyse in KQL Database). Dit is een wezenlijk andere architectuur dan "één platform, één engine" — Fabric is bewust één opslaglaag, meerdere gespecialiseerde engines.

Shortcuts: Data Verbinden Zonder te Kopiëren

Shortcuts zijn Fabric's mechanisme om data die buiten OneLake staat — in Azure Data Lake Storage, Amazon S3, of een ander Fabric-item — te ontsluiten alsof die zich lokaal in je Lakehouse bevindt, zonder de data daadwerkelijk te verplaatsen of te dupliceren:

Lakehouse "Sales"
├── Tables/
│   └── orders                    (echte, lokale Delta-tabel)
└── Shortcuts/
    └── external_weather_data     → wijst naar ADLS Gen2, elders in de organisatie

Een shortcut is een verwijzing, geen kopie — een query tegen external_weather_data leest live uit de brondata, wat betekent dat wijzigingen aan de bron direct zichtbaar zijn zonder een aparte syncpijplijn. Dit is vergelijkbaar in geest met Snowflake's Secure Data Sharing uit Snowflake (data ontsluiten zonder kopiëren), maar dan bewust breder toepasbaar: ook tussen verschillende Fabric-workspaces onderling, en ook naar cloudopslag buiten Microsoft's eigen ecosysteem. Voor organisaties met data verspreid over meerdere teams of zelfs meerdere clouds, vermijdt dit een hele categorie ETL-pijplijnen wiens enige doel is "kopieer data van A naar B zodat B het kan bevragen".

Het Workload-Portfolio: Eén Opslag, Meerdere Motoren

Fabric's onderscheidende architectuurkeuze wordt het duidelijkst in hoe de verschillende workloads zich tot elkaar verhouden, allemaal bovenop dezelfde OneLake-data:

Lakehouse — de Spark-/notebook-gedreven werkomgeving, vergelijkbaar met een Databricks-lakehouse: ideaal voor de bronze/silver-transformatiestappen uit Medallion Architecture, met Python/PySpark-notebooks als primair gereedschap.

Data Warehouse — een volledig T-SQL-gebaseerde, warehouse-achtige ervaring bovenop diezelfde OneLake-data, voor teams die liever in SQL werken dan in notebooks — functioneel dichter bij Snowflake's ervaring, maar wijzend naar exact dezelfde onderliggende Delta-bestanden als het Lakehouse.

KQL Database — geoptimaliseerd voor tijdreeks- en logdata (Kusto Query Language, oorspronkelijk uit Azure Data Explorer), relevant voor observability-data en telemetrie op een schaal en snelheid waarvoor standaard SQL minder geschikt is — zie de raakvlakken met Monitoring & Observability.

Power BI — niet langer een los rapportagetool die data importeert, maar een workload die rechtstreeks tegen OneLake kan lezen (zie Direct Lake hieronder).

Het punt is niet dat elk team alle vier de workloads gebruikt — de meeste platforms gebruiken er twee of drie — maar dat de keuze tussen bijvoorbeeld Lakehouse en Data Warehouse een ontwikkelervaring-keuze is (notebooks versus SQL), niet een datakopie-keuze, omdat beide dezelfde OneLake-data delen.

Direct Lake: Power BI Zonder Import of Refresh

Traditionele Power BI-modellen werken op een van twee manieren: Import (data wordt gekopieerd in een gecomprimeerd, in-memory model, snel te bevragen maar vereist periodieke refreshes die zelf tijd en compute kosten) of DirectQuery (elke visual stuurt een live query naar de bron, altijd actueel maar merkbaar trager per interactie). Direct Lake is Fabric's derde optie, en het genereert het meeste enthousiasme van de drie: Power BI leest de Delta-tabellen in OneLake rechtstreeks in het eigen geheugengeoptimaliseerde formaat, zonder de data eerst te hoeven importeren én zonder de latency-nadelen van DirectQuery.

De praktische consequentie: zodra een silver- of gold-tabel in OneLake wordt bijgewerkt (bijvoorbeeld door een nachtelijke Spark-transformatie), ziet een Direct Lake-rapport die wijziging vrijwel onmiddellijk, zonder dat er een aparte Power BI-refresh-taak hoeft te draaien of ingepland te worden — de traditionele "wanneer ververst het dashboard" vraag uit eerdere hoofdstukken vervalt voor dit specifieke pad grotendeels, omdat er geen aparte kopie meer bestaat die kan verouderen.

Capacity-Based Billing: een Fundamenteel Ander Kostenmodel

Waar Snowflake credits per warehouse verbruikt en Databricks DBU's per cluster, koopt Fabric capaciteit (F-SKUs, bijvoorbeeld F64, F128) die wordt gedeeld over alle workloads binnen een tenant — Lakehouse-Spark-jobs, Warehouse-queries, Power BI-refreshes en Dataflows putten allemaal uit dezelfde capaciteitspool, in plaats van elk hun eigen, apart afgerekende compute te hebben.

Dit heeft een directe consequentie voor kostenbeheer die afwijkt van de per-warehouse-scheiding uit Modern Data Platform Architecture: in plaats van workloads te scheiden over aparte, individueel beheerde compute-eenheden, beheer je op Fabric vooral de totale capaciteitsgrootte en houd je in de gaten welke workload binnen die gedeelde pool het meeste verbruikt via de Capacity Metrics-app. Fabric biedt hier wel smoothing (piekgebruik uitgesmeerd over een venster in plaats van directe doorbelasting) en bursting (tijdelijk boven de capaciteitsgrens draaien, gecompenseerd door latere rustigere periodes) — mechanismen zonder directe tegenhanger bij de andere twee platformen, specifiek ontworpen voor een gedeeld-capaciteitsmodel.

Mirroring: Zero-ETL Replicatie van Externe Databases

Een functie die direct voortbouwt op het shortcut-principe, maar dan voor operationele databases in plaats van bestandsopslag: Mirroring repliceert continu en vrijwel real-time de inhoud van een externe database — Azure SQL Database, Azure Cosmos DB, en zelfs Snowflake zelf — naar OneLake, in Delta-formaat, zonder dat je zelf een ingestion-pipeline hoeft te bouwen of te onderhouden. In de kern is dit een ingebouwde, beheerde change-data-capture-koppeling die de handmatige extractiestap uit Introduction to Data Engineering grotendeels overbodig maakt voor specifiek ondersteunde bronnen.

De praktische waarde zit in de combinatie met shortcuts en Direct Lake: een gemirrorde tabel verschijnt automatisch als bevraagbare Delta-tabel in OneLake, direct beschikbaar voor Spark-notebooks, SQL-warehousequeries én Direct Lake Power BI-rapporten — zonder ETL, zonder handmatige planning, zonder een aparte Fivetran- of Airbyte-koppeling. De beperking is dat Mirroring alleen werkt voor de specifiek ondersteunde bronsystemen; voor alles daarbuiten blijft een reguliere ingestion-pipeline (Data Factory, of een externe tool) nodig.

Dataflows Gen2: Low-Code Transformatie

Naast notebook- en SQL-gebaseerde transformatie biedt Fabric Dataflows Gen2, gebouwd op dezelfde Power Query-engine die achter Excel's "Data ophalen en transformeren" en Power BI's query-editor zit — een visuele, low-code interface voor transformaties, met de mogelijkheid om ook aangepaste M-code (Power Query's eigen taal) te schrijven voor complexere logica. Dit is functioneel het dichtst bij de klassieke ETL-tools uit ETL vs ELT, maar dan native in Fabric en schrijvend naar OneLake in plaats van naar een apart doelsysteem. Voor teams met sterke Power Query/Excel-vaardigheden maar minder SQL- of Python-ervaring is dit een toegankelijke ingang tot transformatie — met als afweging dat complexe, testbare transformatielogica zich doorgaans beter in versiebeheerde dbt-modellen of notebooks laat uitdrukken dan in een visuele canvas, om dezelfde reden als bij traditionele ETL-tools besproken in Introduction to Data Engineering.

Codevoorbeeld: Shortcut en Notebook Samen

Een concreet voorbeeld van hoe de bouwstenen hierboven samenkomen: een shortcut ontsluit externe brondata, een notebook transformeert die naar silver, en de resulterende tabel is direct bruikbaar door elke andere workload op OneLake.

# Fabric-notebook (PySpark) — leest via een shortcut, schrijft naar silver
df_bronze = spark.read.format("delta").load("Tables/external_orders")  # shortcut-tabel

df_silver = (
    df_bronze
    .dropDuplicates(["order_id"])
    .withColumn("order_date", F.to_date("order_date"))
)

df_silver.write.format("delta").mode("overwrite").save("Tables/silver_orders")
# Vanaf hier: bevraagbaar via SQL Warehouse, Power BI (Direct Lake) en andere notebooks,
# zonder enige aparte kopieerstap.

// Data Factory-pipeline in Fabric: triggert het notebook op een schema
{
  "name": "silver_orders_pipeline",
  "activities": [
    { "name": "Run_Silver_Notebook", "type": "TridentNotebook",
      "notebook": { "referenceName": "transform_silver_orders" } }
  ],
  "triggers": [{ "type": "ScheduleTrigger", "recurrence": { "frequency": "Hour", "interval": 1 } }]
}

Git-integratie op Workspace-niveau

Fabric ondersteunt het koppelen van een volledige workspace aan een Git-repository (Azure DevOps of GitHub), waarna items — notebooks, pipelines, Lakehouse-definities, rapporten — als broncode worden gesynchroniseerd in plaats van alleen binnen de Fabric-portal te bestaan. Dit is vergelijkbaar met Databricks Repos uit Databricks, maar dan toegepast op de bredere set Fabric-item-types, en het is de basis waarop een fatsoenlijke CI/CD-flow (zie CI/CD for Data Engineering) voor Fabric-items wordt gebouwd — zonder deze koppeling blijven wijzigingen beperkt tot handmatige export/import tussen workspaces.

Best Practices

• Gebruik shortcuts in plaats van kopieerpijplijnen wanneer data al ergens anders in Delta/Parquet-vorm beschikbaar is — dit bespaart zowel opslag als synchronisatiecomplexiteit.
• Kies de workload (Lakehouse/Warehouse) op basis van teamvaardigheden, niet uit een aanname dat data gedupliceerd moet worden om beide te kunnen gebruiken — ze delen dezelfde OneLake-data toch al.
• Zet Power BI-rapporten op Direct Lake waar mogelijk, zeker voor dashboards op gold-tabellen die al periodiek door een pipeline worden ververst — een aparte Import-refresh is dan overbodige complexiteit.
• Monitor capaciteitsverbruik via de Capacity Metrics-app, niet per workload afzonderlijk, omdat het gedeelde model juist vraagt om zicht op de totale pool in plaats van geïsoleerde metingen.
• Koppel elke productieworkspace aan Git vanaf het begin, niet pas nadat de eerste ongewenste, onomkeerbare wijziging in de portal is gemaakt.
• Overweeg Mirroring vóór een custom ingestion-pipeline wanneer de bron een ondersteund systeem is (Azure SQL, Cosmos DB, Snowflake) — het bespaart bouw- en onderhoudswerk dat anders in een eigen CDC-koppeling zou gaan zitten.

Veelgemaakte Fouten

• Data onnodig kopiëren tussen Lakehouse en Warehouse uit gewoonte van andere platformen, terwijl een shortcut of de gedeelde OneLake-laag dat overbodig maakt.
• Alle workloads even zwaar laten draaien zonder capaciteitsplanning, waardoor een piek in Power BI-refreshes onverwacht Spark-jobs vertraagt omdat ze dezelfde gedeelde capaciteitspool delen.
• Complexe, kritieke transformatielogica in Dataflows Gen2 bouwen puur omdat het laagdrempelig aanvoelt, zonder de testbaarheid en versiebeheerbaarheid van een dbt-model of notebook te overwegen.
• Direct Lake verwarren met DirectQuery — Direct Lake leest OneLake's eigen geoptimaliseerde formaat rechtstreeks in geheugen, met prestaties dichter bij Import dan bij traditionele DirectQuery, wat vaak wordt onderschat.
• Workspaces niet aan Git koppelen, waardoor wijzigingen in pipelines of notebooks alleen terug te vinden zijn via Fabric's eigen versiegeschiedenis, zonder de reviewbaarheid van een pull request.
• Een custom ingestion-pipeline bouwen voor een bron die Mirroring al ondersteunt, waardoor onnodig onderhoudswerk ontstaat voor iets dat native en beheerd beschikbaar was.

Performance Tips

• Gebruik shortcuts strategisch, niet overal — elke shortcut naar externe opslag introduceert een netwerkafhankelijkheid; voor zeer frequent bevraagde data kan een lokale kopie soms toch sneller zijn ondanks het synchronisatienadeel.
• Houd Direct Lake-tabellen binnen de door Microsoft gedocumenteerde grootte- en kolomlimieten — buiten die grenzen valt een rapport automatisch terug op DirectQuery-achtig gedrag, met de bijbehorende prestatie-impact.
• Plan zware Spark-notebook-runs buiten piekuren van Power BI-gebruik binnen dezelfde capaciteit, om te voorkomen dat gedeelde capaciteit een van beide workloads laat wachten.
• Gebruik V-Order (Fabric's Delta-tabeloptimalisatie) bewust voor tabellen die primair via Direct Lake of SQL worden bevraagd — het optimaliseert de fysieke bestandslayout specifiek voor leesprestaties op deze workloads.
• Beperk het aantal actieve shortcuts naar dezelfde externe bron waar mogelijk — elke shortcut voegt een eigen verbindings- en metadata-laag toe, en een enkele, gedeelde shortcut is doorgaans beter te onderhouden dan meerdere losse verwijzingen naar dezelfde data vanuit verschillende Lakehouses.

Interviewvragen

"Wat is OneLake, en waarom is het architectonisch anders dan hoe Snowflake of Databricks opslag regelen?" Let op: één gedeelde, tenant-brede opslaglaag onder alle Fabric-workloads, in plaats van een opslagvorm gekoppeld aan één specifieke engine — meerdere gespecialiseerde motoren op dezelfde data, niet één motor met eigen opslag.

"Wat is een shortcut in Fabric, en welk probleem lost het op?" Let op: een verwijzing naar externe of andere-workspace-data zonder te kopiëren, vergelijkbaar in geest met Snowflake's Secure Data Sharing maar breder toepasbaar — voorkomt onnodige synchronisatiepijplijnen.

"Leg uit wat Direct Lake is, en hoe het verschilt van Import en DirectQuery." Let op: rechtstreeks lezen van OneLake's geoptimaliseerde Delta-formaat in geheugen, zonder importstap (dus geen verouderde kopie) en zonder de latency van traditionele DirectQuery.

"Hoe verschilt Fabric's kostenmodel van Snowflake's warehouse-credits of Databricks' DBU's?" Let op: gedeelde capaciteit (F-SKU) over alle workloads binnen een tenant, met smoothing en bursting, in plaats van per-workload afgerekende, geïsoleerde compute.

"Wanneer zou je Dataflows Gen2 kiezen boven een notebook- of SQL-gebaseerde transformatie?" Let op: laagdrempelige, visuele transformatie voor teams met sterke Power Query-vaardigheden en minder complexe logica — met de kanttekening dat kritieke, testbare businesslogica zich vaak beter leent voor versiebeheerde code.

"Waarom zou je een Fabric-workspace aan Git koppelen?" Let op: items worden dan als broncode gesynchroniseerd met reviewbare pull requests, in plaats van alleen binnen de portal te bestaan met beperkte, minder transparante versiegeschiedenis.

"Wat is Mirroring, en waarom is het anders dan een reguliere ingestion-pipeline?" Let op: een beheerde, vrijwel real-time replicatie van specifiek ondersteunde externe databases (Azure SQL, Cosmos DB, Snowflake) rechtstreeks naar OneLake als Delta-tabellen, zonder zelf een CDC-pipeline te hoeven bouwen — met als beperking dat het alleen voor ondersteunde bronnen werkt.

Relevante Documentatie

• Microsoft Fabric: OneLake Overview — de officiële uitleg van de gedeelde opslaglaag.
• Microsoft Fabric: OneLake Shortcuts — configuratie en beperkingen in detail.
• Microsoft Fabric: Direct Lake Overview — grootte- en kolomlimieten, en fallback-gedrag.
• Microsoft Fabric: Capacity and Billing — F-SKU's, smoothing en bursting in detail.

Samenvatting

Microsoft Fabric onderscheidt zich niet primair door een sterkere individuele engine, maar door een architectuurkeuze: één gedeelde opslaglaag (OneLake) onder meerdere gespecialiseerde workloads — Lakehouse, Data Warehouse, KQL Database, Power BI — die dezelfde onderliggende Delta-data delen in plaats van kopiëren. Shortcuts verlengen dit principe naar externe opslag, Direct Lake elimineert de traditionele import/refresh-cyclus voor Power BI, en het capacity-based billingmodel met smoothing/bursting vervangt de per-warehouse-scheiding van andere platformen door gedeeld capaciteitsbeheer. Mirroring bouwt hierop voort door zelfs de ingestion-stap voor ondersteunde bronnen native te beheren, zonder een eigen CDC-pipeline te hoeven bouwen. Met alle drie de grote platformen nu behandeld — Snowflake, Databricks, Fabric — verschuift de aandacht in het volgende hoofdstuk naar een meer gespecialiseerd onderdeel van het Microsoft-ecosysteem: Azure Data Factory, dat ook buiten Fabric zelfstandig wordt ingezet.