Microsoft Fabric in zes lessen

Van OneLake tot capaciteitsbeheer. Shortcuts, de keuze tussen Lakehouse en Warehouse, pipelines met incrementeel laden, Direct Lake en het inrichten van rechten.

6
Lessen
Beginner tot gevorderd
Niveau
6
Praktijkoefeningen
100%
Gratis

Les 1: Wat is Microsoft Fabric?

60 minuten Beginner Inclusief Demo

Microsoft Fabric: Eén Platform voor Alle Analytics

Microsoft Fabric is een unified analytics platform dat alle data services integreert in één product. Het combineert data engineering, data warehousing, data science, real-time analytics en business intelligence.

Key Insight

Voor Fabric moesten organisaties verschillende Microsoft services (Azure Data Factory, Synapse, Power BI) apart configureren en beheren. Fabric biedt dit nu geïntegreerd aan met gedeelde governance, security en OneLake als centrale dataopslag.

Microsoft Fabric Architecture

Data Engineering

Spark, notebooks, data pipelines

Data Science

ML modellen, experimenten, R/Python

Data Warehousing

SQL, T-SQL, data marts

Real-time Analytics

KQL, streaming, observability

Power BI

Dashboards, rapporten, AI visuals

Data Factory

ETL/ELT, data movement, orchestration

Alle workloads delen OneLake als centrale dataopslag met Delta Lake formaat

Microsoft Fabric vs Traditionele Architectuur

Aspect Microsoft Fabric Traditionele Azure Stack On-premise Stack
Integratie ✅ Volledig geïntegreerd ❌ Losse services (ADF, Synapse, Power BI) ❌ Silo's van tools
Data Opslag OneLake (centraal, Delta Lake) Verschillende storage accounts Fileservers, databases
Governance ✅ Unified governance (Purview) ❌ Per service beheren ❌ Handmatige processen
Kosten Model Capacity Units (CU's) - één prijs Per service betalen CapEx + onderhoud
Development ✅ Low-code + pro-code in één ❌ Verschillende tools/interfaces ❌ Complexe integratie
Time to Value Dagen Weken tot maanden Maanden tot jaren

Pro Tip: Wanneer Microsoft Fabric Kiezen?

Kies Fabric wanneer je: (1) Al in Microsoft ecosystem zit (Office 365, Azure), (2) Low-code en pro-code wil combineren, (3) Unified governance nodig hebt, (4) Power BI al gebruikt, (5) Snelle integratie tussen data engineering en BI wil.

OneLake: Het Hart van Microsoft Fabric

PowerShell - fabric_setup.ps1

# Microsoft Fabric PowerShell Module installeren
Install-Module -Name MicrosoftPowerBIMgmt -Force
Install-Module -Name MicrosoftPowerBIMgmt.Admin -Force
Install-Module -Name MicrosoftPowerBIMgmt.Workspaces -Force

# Aanmelden bij Power BI (Fabric)
Connect-PowerBIServiceAccount

# Fabric Workspace aanmaken
New-PowerBIWorkspace -Name "Fabric Analytics Platform" `
    -Description "Productie workspace voor enterprise analytics" `
    -Type "Premium" `
    -CapacityId "your-capacity-id"

# OneLake bestanden beheren via OneLake file explorer
# OneLake werkt als een normale filesystem maar dan in de cloud
# Voorbeeld: abfss://onelake@fabric.dfs.core.windows.net/

# Fabric Items maken met REST API
$headers = @{
    "Authorization" = "Bearer $accessToken"
    "Content-Type" = "application/json"
}

# Data Warehouse aanmaken
$body = @{
    displayName = "Enterprise Data Warehouse"
    description = "Centraal data warehouse voor alle business units"
    type = "Warehouse"
} | ConvertTo-Json

Invoke-RestMethod -Method Post `
    -Uri "https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/items" `
    -Headers $headers `
    -Body $body

# Data Pipeline aanmaken
$pipelineBody = @{
    displayName = "Daily Sales ETL"
    description = "Dagelijkse ETL voor sales data van SAP en CRM"
    type = "Pipeline"
    properties = @{
        activities = @(
            @{
                name = "Copy SAP Data"
                type = "Copy"
                inputs = @(@{referenceName = "SAPSource"})
                outputs = @(@{referenceName = "RawSales"})
            },
            @{
                name = "Transform Data"
                type = "Spark"
                inputs = @(@{referenceName = "RawSales"})
                outputs = @(@{referenceName = "CleanedSales"})
            }
        )
    }
} | ConvertTo-Json -Depth 5

# Capaciteit (CU's) monitoren
Get-PowerBICapacity -Scope Organization |
    Where-Object {$_.State -eq "Active"} |
    Select-Object DisplayName, Sku, State, Admins, Users |
    Format-Table -AutoSize

# Fabric licentie rapport genereren
$report = Get-PowerBICapacity -Scope Organization |
    ForEach-Object {
        [PSCustomObject]@{
            Workspace = $_.DisplayName
            SKU = $_.Sku
            Status = $_.State
            AssignedTo = $_.Admins -join ", "
            MonthlyCost = if($_.Sku -eq "P1") {"€4,995"} 
                         elseif($_.Sku -eq "F64") {"€5,002.88"}
                         else {"Onbekend"}
        }
    }

$report | Export-Csv -Path "fabric_capacity_report.csv" -NoTypeInformation
Write-Host "✅ Fabric capaciteit rapport gegenereerd" -ForegroundColor Green
        

Python Voorbeeld: Werken met Fabric Spark & OneLake

Python - fabric_spark_demo.py

# Microsoft Fabric Notebook (Python)
# OneLake is standaard geconfigureerd als Spark default storage

from pyspark.sql import SparkSession
from pyspark.sql.functions import *
from delta.tables import *
import pandas as pd
import json

# Spark sessie in Fabric (geen configuratie nodig)
spark = SparkSession.builder.getOrCreate()
print(f"Spark versie: {spark.version}")
print(f"Fabric Workspace: {spark.conf.get('spark.fabric.workspace.name')}")

def demonstrate_fabric_features():
    """Demonstreer Fabric-specifieke features"""
    
    # 1. Data lezen van OneLake (Delta format)
    print("1. Data lezen van OneLake...")
    
    # OneLake path: abfss://workspace@onelake.dfs.fabric.microsoft.com/
    sales_df = spark.read.format("delta").load(
        "Files/Sales/Transactions"
    )
    
    print(f"   Sales data: {sales_df.count():,} rijen")
    
    # 2. Data transformeren met Spark
    print("2. Data transformeren...")
    
    daily_metrics = sales_df \
        .groupBy("TransactionDate", "StoreId", "ProductCategory") \
        .agg(
            sum("Amount").alias("TotalSales"),
            avg("Quantity").alias("AvgQuantity"),
            count("*").alias("TransactionCount")
        ) \
        .withColumn("Year", year(col("TransactionDate"))) \
        .withColumn("Month", month(col("TransactionDate")))
    
    # 3. Opslaan naar OneLake (Delta Lake)
    print("3. Opslaan naar OneLake als Delta table...")
    
    daily_metrics.write \
        .format("delta") \
        .mode("overwrite") \
        .partitionBy("Year", "Month") \
        .save("Tables/DailySalesMetrics")
    
    # 4. Direct Query met SQL Endpoint
    print("4. Direct SQL query op Warehouse...")
    
    # Maak een SQL Endpoint view
    daily_metrics.createOrReplaceTempView("daily_sales_metrics_view")
    
    # SQL query uitvoeren
    sql_result = spark.sql("""
        SELECT 
            Year,
            Month,
            ProductCategory,
            SUM(TotalSales) as MonthlySales,
            AVG(AvgQuantity) as AvgDailyQuantity
        FROM daily_sales_metrics_view
        WHERE Year = 2024
        GROUP BY Year, Month, ProductCategory
        ORDER BY MonthlySales DESC
        LIMIT 10
    """)
    
    print("   Top 10 product categorieën 2024:")
    sql_result.show(truncate=False)
    
    # 5. Shortcuts gebruiken - virtuele links naar externe data
    print("5. Shortcuts maken naar externe data...")
    
    # Maak een shortcut naar Azure Data Lake Storage
    spark.sql("""
        CREATE SHORTCUT IF NOT EXISTS ExternalCustomerData
        ON 'abfss://customer-data@externaladls.dfs.core.windows.net/raw/'
        WITH (
            TYPE = 'ADLS',
            ACCOUNT_NAME = 'externalstorage'
        )
    """)
    
    # Lees data via shortcut
    external_data = spark.read.parquet(
        "ExternalCustomerData/customers/*.parquet"
    )
    
    print(f"   Externe customer data: {external_data.count():,} rijen")
    
    return daily_metrics, sql_result

def fabric_data_science_example():
    """Data Science met Fabric ML"""
    
    print("\n6. Machine Learning met Fabric ML...")
    
    from synapse.ml import *
    from synapse.ml.lightgbm import *
    
    # Laad data voor ML
    ml_data = spark.read.format("delta").load(
        "Tables/MLReadyData"
    )
    
    # Feature engineering
    feature_cols = [c for c in ml_data.columns if c not in ["Label", "CustomerId"]]
    
    # Train LightGBM model
    lgbm = LightGBMClassifier(
        featuresCol="features",
        labelCol="Label",
        predictionCol="prediction",
        objective="binary",
        numLeaves=31,
        maxDepth=5,
        numIterations=100
    )
    
    # Data splitsen
    train_data, test_data = ml_data.randomSplit([0.8, 0.2])
    
    # Model trainen
    model = lgbm.fit(train_data)
    
    # Voorspellingen maken
    predictions = model.transform(test_data)
    
    # Model opslaan in MLflow (geïntegreerd in Fabric)
    import mlflow
    
    with mlflow.start_run():
        mlflow.log_param("num_leaves", 31)
        mlflow.log_param("max_depth", 5)
        mlflow.spark.log_model(model, "churn_prediction_model")
        
        # Metrics loggen
        from sklearn.metrics import accuracy_score, f1_score
        
        pdf = predictions.select("Label", "prediction").toPandas()
        accuracy = accuracy_score(pdf["Label"], pdf["prediction"])
        f1 = f1_score(pdf["Label"], pdf["prediction"])
        
        mlflow.log_metric("accuracy", accuracy)
        mlflow.log_metric("f1_score", f1)
    
    print(f"   Model accuracy: {accuracy:.2%}")
    print(f"   F1 score: {f1:.2%}")
    
    return model, predictions

def power_bi_integration():
    """Power BI Direct Lake mode demo"""
    
    print("\n7. Power BI Direct Lake integration...")
    
    # Maak een dataset klaar voor Direct Lake
    # Direct Lake laadt data direct van OneLake zonder import
    
    # 1. Maak een semantic model
    semantic_model_sql = """
    CREATE TABLE SalesSemanticModel (
        SalesAmount decimal(18,2),
        Quantity int,
        ProductName varchar(100),
        Category varchar(50),
        TransactionDate date,
        StoreLocation varchar(200)
    )
    """
    
    # 2. Vul het semantic model
    spark.sql("""
        INSERT INTO SalesSemanticModel
        SELECT 
            Amount as SalesAmount,
            Quantity,
            p.ProductName,
            p.Category,
            t.TransactionDate,
            s.StoreLocation
        FROM Files/Sales/Transactions t
        JOIN Tables/Products p ON t.ProductId = p.ProductId
        JOIN Tables/Stores s ON t.StoreId = s.StoreId
        WHERE t.TransactionDate >= '2024-01-01'
    """)
    
    print("   Semantic model gemaakt voor Power BI Direct Lake")
    print("   Power BI kan nu direct queryen op OneLake zonder data kopiëren!")
    
    # 3. Power BI dataset URL genereren
    workspace_name = spark.conf.get("spark.fabric.workspace.name")
    dataset_id = "sales_semantic_model"
    
    pbix_url = f"https://app.powerbi.com/groups/me/datasets/{dataset_id}"
    print(f"   Power BI dataset URL: {pbix_url}")

if __name__ == "__main__":
    print("=" * 70)
    print("MICROSOFT FABRIC DEMO")
    print("=" * 70)
    
    # Demo basis features
    metrics, sql_result = demonstrate_fabric_features()
    
    # Demo Data Science
    try:
        model, predictions = fabric_data_science_example()
    except Exception as e:
        print(f"   ML demo skipped: {e}")
    
    # Demo Power BI integration
    power_bi_integration()
    
    print("\n" + "=" * 70)
    print("DEMO VOLTOOID")
    print("=" * 70)
    print("\nVolgende stappen:")
    print("1. Open Power BI voor Direct Lake dashboards")
    print("2. Bekijk data lineage in Purview")
    print("3. Configureer data governance policies")
    print("4. Maak data pipelines in Data Factory")
        

Oefening: Fabric Enterprise Architectuur

Scenario: Een Nederlandse bank wil overstappen naar Microsoft Fabric. Ze hebben:

  • 100+ SQL Server databases on-premise
  • 500 Power BI rapporten (Pro licentie)
  • Azure Data Factory pipelines voor ETL
  • Strikte compliance vereisten (AFM/DNB)
  • 300 gebruikers (analisten, data scientists, managers)

Opdracht: Ontwerp een Microsoft Fabric migratie strategie:

  1. Hoe migreer je on-premise data naar OneLake?
  2. Welke Fabric Capaciteit (F SKU) heb je nodig?
  3. Hoe organiseer je workspaces voor verschillende teams?
  4. Welke governance features gebruik je voor compliance?
  5. Hoe integreer je bestaande Power BI rapporten?
  6. Hoe beheer je kosten met Capacity Units?

Real-World Case: ABN AMRO Bank

Uitdaging: ABN AMRO had gefragmenteerde data platformen met hoge integratiekosten en complexe governance.

Oplossing met Microsoft Fabric:

  • OneLake als centrale dataopslag voor alle divisies
  • Direct Lake mode voor real-time Power BI dashboards
  • Fabric Data Warehouses voor divisie-specifieke data marts
  • Microsoft Purview voor unified data governance
  • Fabric Capacities (F64, F128) voor voorspelbare kosten

Resultaat: 40% kostenreductie in data platform, 70% snellere time-to-insight, centrale governance voor 500+ datasets, en compliance met Nederlandse bank regelgeving.

Quick Knowledge Check

Vraag 1: Wat is het belangrijkste voordeel van Microsoft Fabric?

A. Unified platform met geïntegreerde services en OneLake
B. Het is goedkoper dan alle andere cloud platforms
C. Het werkt alleen on-premise
D. Het heeft geen SQL support

Vraag 2: Wat is OneLake in Microsoft Fabric?

A. Een nieuwe programmeertaal voor data science
B. Gecentraliseerde dataopslag die alle Fabric workloads deelt
C. Een tool voor data visualisatie
D. Een alternatief voor Power BI

Vraag 3: Wat is Direct Lake mode in Fabric Power BI?

A. Direct queryen op OneLake zonder data te kopiëren
B. Een nieuwe programmeertaal voor rapporten
C. Een tool voor data governance
D. Een alternatief voor Excel

Les 2: OneLake en opslag

50 minuten Beginner Met voorbeelden

Eén meer voor je hele organisatie

OneLake is de opslaglaag onder alle Fabric-onderdelen. Je krijgt er precies één per tenant, en dat is met opzet: waar een klassieke opzet al snel vijf losse storage accounts kent, is er hier één plek waar alles staat.

Alles wordt opgeslagen in Delta Parquet. Dat betekent dat een tabel die je met een Spark-notebook wegschrijft, meteen bevraagbaar is met T-SQL vanuit het Warehouse en direct zichtbaar is in Power BI — zonder dat er ook maar iets gekopieerd wordt.

Onthoud dit

In OneLake bepaalt het formaat de samenwerking. Omdat alles Delta is, hoef je geen data te verplaatsen tussen tools. Dat is het hele idee achter Fabric, en het verklaart waarom shortcuts hieronder zo belangrijk zijn.

Workspaces, lakehouses en de mappenstructuur

Een workspace is je eenheid van samenwerking en rechten. Daarbinnen maak je items aan: een Lakehouse, een Warehouse, een notebook, een rapport. Elk Lakehouse heeft twee mappen die je uit elkaar moet houden:

Shortcuts: verwijzen in plaats van kopiëren

Een shortcut is een verwijzing naar data die ergens anders staat: in een andere workspace, in Azure Data Lake Storage, in Amazon S3 of in Google Cloud Storage. De data blijft staan waar hij staat; Fabric leest hem alsof hij lokaal is.

Dit is het antwoord op het probleem dat je anders krijgt: dezelfde dataset in drie afdelingen, drie keer gekopieerd, drie keer net anders.

Wanneer een shortcut en wanneer niet

Gebruik een shortcut voor data die elders al goed beheerd wordt en waarvan jij alleen de leeskant nodig hebt. Kopieer wel als je de data gaat verrijken of als de bron traag of onbetrouwbaar is: een shortcut is zo snel als de bron erachter, en die latency merk je terug in elk rapport.

Python - shortcut_lezen.py

# Een shortcut gedraagt zich als een gewone map in je Lakehouse
df = spark.read.format("delta").load("Files/verkoop_extern/orders")

# Wegschrijven als beheerde tabel, zodat het SQL-eindpunt hem ziet
(df.write
   .format("delta")
   .mode("overwrite")
   .option("overwriteSchema", "true")
   .saveAsTable("bronze_orders"))

# Het volledige OneLake-pad werkt ook, handig tussen workspaces
pad = "abfss://Verkoop@onelake.dfs.fabric.microsoft.com/Sales.Lakehouse/Tables/orders"
spark.read.format("delta").load(pad).createOrReplaceTempView("orders_extern")
        

Capaciteit: wat je werkelijk afrekent

Fabric rekent niet per query maar per capaciteit, uitgedrukt in Capacity Units. Je koopt een SKU — F2, F8, F64 — en alle werk in alle workspaces die aan die capaciteit hangen deelt dezelfde pot.

Twee dingen moet je daarvan weten. Ten eerste smoothing: een piek wordt over een langere periode uitgesmeerd, zodat een zware query je niet meteen stillegt. Ten tweede throttling: verbruik je structureel meer dan je SKU aankan, dan worden je verzoeken vertraagd of geweigerd.

De grens bij F64

Vanaf F64 mogen eindgebruikers rapporten bekijken zonder eigen Power BI Pro-licentie. Daaronder heeft iedere lezer wél een licentie nodig. Dat maakt de sprong naar F64 vaak goedkoper dan hij op papier lijkt zodra je veel rapportlezers hebt — reken het door voordat je een kleinere SKU kiest.

Oefening: opslag inrichten

Situatie: een productiebedrijf met drie databronnen:

  • ERP-data die al in een Azure Data Lake staat, beheerd door een ander team
  • Machinedata die als CSV binnenkomt en nog opgeschoond moet worden
  • Een verkoopdataset die het salesteam in een eigen workspace onderhoudt

Opdracht:

  1. Welke bronnen koppel je met een shortcut en welke kopieer je?
  2. In welke map van het Lakehouse landt de machinedata, en waarom niet meteen in Tables?
  3. Je team klaagt dat rapporten traag zijn sinds de ERP-koppeling erbij kwam. Wat onderzoek je als eerste?
  4. Welke SKU overweeg je als er veertig mensen rapporten gaan bekijken?

Richting: ERP en verkoop zijn shortcuts — die worden elders beheerd en jij hebt alleen de leeskant nodig. Machinedata kopieer je, want je gaat hem bewerken; die landt eerst in Files en pas na opschoning als Delta-tabel in Tables. Trage rapporten na een shortcut wijzen meestal op de latency van de bron, niet op Fabric zelf: meet hoe lang de onderliggende storage erover doet. En bij veertig lezers reken je F64 door tegen de kosten van veertig Pro-licenties.

Les 3: Lakehouse of Warehouse?

45 minuten Gemiddeld Met voorbeelden

Twee deuren naar dezelfde data

Fabric biedt twee manieren om met tabellen te werken, en de keuze daartussen is de vraag die het vaakst verkeerd beantwoord wordt. Allebei schrijven ze naar OneLake in Delta-formaat; het verschil zit in wie er schrijft en met welke taal.

LakehouseWarehouse
Je schrijft metSpark (PySpark, Scala, Spark SQL)T-SQL
SQL-eindpuntAlleen lezenLezen én schrijven
Transacties over meerdere tabellenNeeJa
Geschikt voorRuwe data, bestanden, machine learningGemodelleerde lagen, klassieke BI
Past bij een team vanData engineersSQL-ontwikkelaars en BI-bouwers

De val waar veel teams in stappen

Het SQL-eindpunt van een Lakehouse ziet er precies zo uit als een Warehouse, maar je kunt er niet in schrijven. Teams bouwen er een half model in en lopen dan vast op de eerste UPDATE. Wil je in SQL schrijven, kies dan vanaf het begin een Warehouse.

Een opzet die in de praktijk werkt

Gebruik een Lakehouse voor de bronze- en silverlaag, waar je bestanden binnenhaalt en opschoont met Spark. Gebruik een Warehouse voor de goldlaag, waar je BI-team met T-SQL de modellen bouwt. Omdat allebei in OneLake staan, kun je vanuit het Warehouse rechtstreeks de Lakehouse-tabellen bevragen — ook over workspaces heen.

SQL - over_items_heen.sql

-- Vanuit het Warehouse een Lakehouse-tabel bevragen via drieledige naamgeving
SELECT
    k.klant_id,
    k.naam,
    SUM(o.bedrag) AS omzet
FROM SalesLakehouse.dbo.orders        AS o
JOIN dim_klant                        AS k ON k.klant_id = o.klant_id
WHERE o.besteldatum >= '2026-01-01'
GROUP BY k.klant_id, k.naam;

-- In het Warehouse mag je wel schrijven
CREATE TABLE fact_omzet AS
SELECT besteldatum, klant_id, SUM(bedrag) AS omzet
FROM SalesLakehouse.dbo.orders
GROUP BY besteldatum, klant_id;

-- COPY INTO laadt rechtstreeks vanuit opslag
COPY INTO dim_product
FROM 'https://account.blob.core.windows.net/data/producten.parquet'
WITH (FILE_TYPE = 'PARQUET');
        

Medallion in Fabric

De gelaagde opzet die je uit andere platformen kent, werkt hier net zo goed: bronze voor ruwe data zoals hij binnenkwam, silver voor opgeschoonde en ontdubbelde data, gold voor de modellen waar rapporten op draaien.

Python - silver_laag.py

from pyspark.sql import functions as F
from pyspark.sql.window import Window

bronze = spark.read.table("bronze_orders")

venster = Window.partitionBy("order_id").orderBy(F.col("geladen_op").desc())

silver = (bronze
    .withColumn("rang", F.row_number().over(venster))
    .filter(F.col("rang") == 1)                    # alleen de laatste versie
    .drop("rang")
    .filter(F.col("order_id").isNotNull())
    .withColumn("bedrag", F.col("bedrag").cast("decimal(12,2)"))
    .withColumn("besteldatum", F.to_date("besteldatum", "dd-MM-yyyy")))

(silver.write
    .format("delta")
    .mode("overwrite")
    .option("overwriteSchema", "true")
    .saveAsTable("silver_orders"))
        

Oefening: de juiste deur kiezen

Situatie: je team bestaat uit twee data engineers die Python schrijven en drie BI-ontwikkelaars die alleen SQL kennen. Er komt dagelijks 30 GB aan logbestanden binnen die opgeschoond moeten worden, en daarnaast moet er een stermodel komen voor de financiële rapportage.

Opdracht:

  1. Welk item gebruik je voor de logverwerking, en welk voor het stermodel?
  2. De BI-ontwikkelaars willen een kolom toevoegen aan een tabel uit de logverwerking. Kan dat via het SQL-eindpunt?
  3. Hoe zorg je dat het stermodel bij de opgeschoonde logdata kan zonder die te kopiëren?
  4. Wanneer zou je toch alles in één Warehouse doen?

Richting: een Lakehouse voor de logverwerking, want 30 GB per dag opschonen is Spark-werk, en een Warehouse voor het stermodel zodat de BI-ontwikkelaars in hun eigen taal kunnen bouwen. Een kolom toevoegen via het SQL-eindpunt kan níet — dat is alleen-lezen, dus die wijziging hoort in het Spark-notebook of in een gold-tabel in het Warehouse. Het stermodel bereikt de logdata met drieledige naamgeving, zonder kopie. Eén Warehouse is verdedigbaar als je geen Python-werk hebt en je bronnen netjes gestructureerd binnenkomen.

Les 4: Data Factory en pipelines

50 minuten Gemiddeld Met voorbeelden

Drie manieren om data te verplaatsen

Fabric geeft je drie gereedschappen die elkaar overlappen. Weten wanneer je wat pakt, scheelt veel herbouw.

Pipelines regelen de volgorde: haal dit op, draai dan dat notebook, stuur bij een fout een mail. Ze bevatten zelf geen transformatielogica.

Dataflows Gen2 gebruiken Power Query. Prettig voor wie die taal al kent uit Power BI, en goed voor overzichtelijke transformaties op beperkte volumes.

Notebooks geven je de volle kracht van Spark. Voor grote volumes en alles wat complexer is dan een paar kolomtransformaties.

Een bruikbare vuistregel

Pipeline voor de orkestratie, notebook voor het echte rekenwerk, dataflow alleen als je team Power Query al beheerst en het volume bescheiden is. Dataflows worden traag en lastig te onderhouden zodra ze groeien.

Incrementeel laden met een watermerk

Elke nacht alles opnieuw ophalen werkt tot je bron groeit. Daarna wil je alleen wat veranderd is. Je bewaart dan het hoogste tijdstempel van de vorige run en haalt alleen wat daarna kwam.

Python - incrementeel_laden.py

from pyspark.sql import functions as F
from delta.tables import DeltaTable

# Het watermerk van de vorige run ophalen
try:
    watermerk = (spark.read.table("silver_orders")
                      .agg(F.max("gewijzigd_op")).collect()[0][0])
except Exception:
    watermerk = "1900-01-01"

nieuw = (spark.read.table("bronze_orders")
              .filter(F.col("gewijzigd_op") > F.lit(watermerk)))

print(f"{nieuw.count()} gewijzigde rijen sinds {watermerk}")

# MERGE: bestaande rijen bijwerken, nieuwe toevoegen
doel = DeltaTable.forName(spark, "silver_orders")
(doel.alias("d")
     .merge(nieuw.alias("n"), "d.order_id = n.order_id")
     .whenMatchedUpdateAll()
     .whenNotMatchedInsertAll()
     .execute())
        

Let op de grens van je watermerk

Gebruik > en niet >=, anders haal je elke run de laatste rijen opnieuw op. Komt je brondata met vertraging binnen, neem dan bewust een marge van bijvoorbeeld een uur terug en vertrouw op de MERGE om dubbelingen af te vangen.

Fouten zichtbaar maken

Een pipeline die stilletjes faalt is gevaarlijker dan een die hard stukloopt. Zorg dat elke run zijn uitkomst wegschrijft, zodat je de volgende ochtend kunt zien of het goed ging zonder in logs te hoeven duiken.

Python - run_loggen.py

import datetime

def log_run(stap, status, rijen=0, melding=""):
    regel = [(stap, status, rijen, melding, datetime.datetime.now())]
    kolommen = ["stap", "status", "rijen", "melding", "tijdstip"]
    (spark.createDataFrame(regel, kolommen)
          .write.format("delta").mode("append").saveAsTable("pipeline_log"))

try:
    aantal = verwerk_orders()          # je eigen functie
    log_run("silver_orders", "gelukt", aantal)
except Exception as fout:
    log_run("silver_orders", "mislukt", 0, str(fout)[:500])
    raise                               # opnieuw opgooien, anders denkt de pipeline dat het goed ging
        

Oefening: een nachtelijk proces ontwerpen

Situatie: elke nacht moeten drie bronnen binnengehaald worden: een SQL Server-database met 12 miljoen orderregels, een REST-API met wisselkoersen, en een map met Excel-bestanden van filialen. Daarna draait een transformatie en wordt een semantisch model ververst.

Opdracht:

  1. Welk gereedschap kies je per bron?
  2. Hoe voorkom je dat je elke nacht alle 12 miljoen orderregels opnieuw ophaalt?
  3. De Excel-bestanden komen soms te laat. Hoe zorg je dat de rest wel doorgaat?
  4. Hoe weet je de volgende ochtend binnen tien seconden of alles goed ging?

Richting: een pipeline als regisseur, met een notebook voor de orders (volume vraagt om Spark, met een watermerk op gewijzigd_op), een eenvoudige kopieeractiviteit voor de API, en een notebook dat de Excel-map inleest. Zet de Excel-tak als aparte vertakking die mag falen zonder de rest te blokkeren, en laat het semantische model pas verversen als de verplichte takken geslaagd zijn. Schrijf elke stap naar een logtabel en bouw daar een klein rapport op — dat is je ochtendblik.

Les 5: Semantische modellen en Direct Lake

45 minuten Gemiddeld Power BI

De derde manier om data te bevragen

Power BI kende tot nu toe twee modi. Import kopieert data in het model: snel, maar je rapport is zo vers als de laatste verversing. DirectQuery bevraagt de bron live: altijd actueel, maar traag.

Direct Lake is de derde weg en bestaat alleen in Fabric. Power BI leest de Delta-bestanden in OneLake rechtstreeks in het geheugen, zonder kopie en zonder query naar een database. Je krijgt de snelheid van Import met de actualiteit van DirectQuery.

Waar het misgaat

Direct Lake valt terug op DirectQuery zodra je iets doet wat niet ondersteund wordt — een berekende tabel, bepaalde DAX-constructies, of een model dat niet in het geheugen van je SKU past. Je rapport werkt dan nog wel, maar wordt opeens veel trager. Controleer dus of je werkelijk in Direct Lake draait en niet ongemerkt bent teruggevallen.

Een model dat presteert

De regels voor een goed semantisch model zijn niet anders dan in gewone Power BI, maar wegen in Direct Lake zwaarder omdat alles in het geheugen moet passen.

DAX - maatstaven.dax

-- Expliciete maatstaven, geen kolommen die je in een visual sleept
Omzet = SUM(fact_omzet[bedrag])

Omzet vorig jaar =
CALCULATE([Omzet], SAMEPERIODLASTYEAR(dim_datum[datum]))

Groei % =
VAR Huidig = [Omzet]
VAR Vorig  = [Omzet vorig jaar]
RETURN DIVIDE(Huidig - Vorig, Vorig)      -- DIVIDE vangt deling door nul af

-- Lopend totaal binnen het jaar
Omzet YTD =
TOTALYTD([Omzet], dim_datum[datum])
        

Markeer je datumtabel

Zonder een als datumtabel gemarkeerde dimensie werken tijdsintelligentiefuncties als SAMEPERIODLASTYEAR onbetrouwbaar. Zorg dat die tabel aaneengesloten datums bevat, zonder gaten, over de hele periode waarin je feiten hebt.

Oefening: een traag rapport doorgronden

Situatie: een rapport op Direct Lake reageerde eerst binnen een seconde, maar duurt sinds vorige week acht seconden per klik. Er is in die week een berekende tabel toegevoegd en het model is gegroeid naar 9 GB. Jullie draaien op F16.

Opdracht:

  1. Wat is de meest waarschijnlijke oorzaak, gezien wat er veranderd is?
  2. Hoe controleer je of het rapport nog echt in Direct Lake draait?
  3. Noem twee manieren om het model kleiner te maken zonder functionaliteit te verliezen.
  4. Wanneer is opschalen naar een grotere SKU het juiste antwoord, en wanneer een pleister?

Richting: de berekende tabel is de verdachte: die wordt in Direct Lake niet ondersteund en veroorzaakt een terugval naar DirectQuery. Controleer dat in de modelinstellingen of met Performance Analyzer. Kleiner maken doe je door ongebruikte kolommen te verwijderen en tijdstempels te splitsen in datum en tijd — dat levert vaak tientallen procenten op. Opschalen is pas het juiste antwoord als het model ná opschoning nog steeds niet past; doe je het ervoor, dan betaal je structureel voor een probleem dat je in een uur had kunnen oplossen.

Les 6: Beheer, rechten en kosten

45 minuten Gemiddeld Governance

Rechten zitten op drie niveaus

Wie wat mag zien in Fabric wordt op drie plekken bepaald, en ze stapelen. Begrijp je die stapeling niet, dan krijg je of te ruime toegang of eindeloze klachten dat mensen niets zien.

Viewer is zelden genoeg

Een Viewer kan rapporten bekijken maar bereikt de onderliggende tabellen niet. Wil je dat een analist zelf query's schrijft op het SQL-eindpunt, dan heeft die naast de workspace-rol ook expliciet leesrechten op dat item nodig. Dit is de meest voorkomende verwarring bij een nieuwe inrichting.

SQL - rij_en_kolomniveau.sql

-- Rijniveau: iedere accountmanager ziet alleen zijn eigen regio
CREATE SCHEMA beveiliging;
GO

CREATE FUNCTION beveiliging.regio_filter(@regio AS VARCHAR(50))
RETURNS TABLE WITH SCHEMABINDING
AS
RETURN SELECT 1 AS toegestaan
       WHERE @regio = USER_NAME()
          OR USER_NAME() = 'datateam@bedrijf.nl';
GO

CREATE SECURITY POLICY beveiliging.regio_beleid
ADD FILTER PREDICATE beveiliging.regio_filter(regio) ON dbo.fact_omzet
WITH (STATE = ON);
GO

-- Kolomniveau: niet iedereen hoeft salarissen te zien
GRANT SELECT ON dbo.dim_medewerker(medewerker_id, naam, afdeling) TO analist_rol;
        

Capaciteit bewaken

Omdat alles uit één pot komt, is het verbruik per workspace niet vanzelf zichtbaar. De Fabric Capacity Metrics-app is daarom geen luxe maar noodzaak: die laat per item zien wat er verbruikt wordt en wanneer je tegen je grens aan loopt.

Waar je op let

Kijk naar pieken die smoothing niet meer kan opvangen, naar notebooks die langer draaien dan nodig, en naar semantische modellen die bij elke verversing volledig opnieuw worden opgebouwd. Een enkel zwaar notebook dat per ongeluk elk kwartier draait, kan een hele capaciteit opeten.

Oefening: inrichting voor drie afdelingen

Situatie: finance, sales en operations gaan alle drie met Fabric werken op één F64-capaciteit. Finance werkt met gevoelige gegevens, sales wil zelf rapporten bouwen, en operations heeft alleen kijkrechten nodig. Er is één gedeelde klantdimensie.

Opdracht:

  1. Hoeveel workspaces maak je aan, en waarom niet één per capaciteit?
  2. Welke rol geef je elk team, en waar wijk je op itemniveau af?
  3. Hoe deel je de klantdimensie zonder hem drie keer te kopiëren?
  4. Hoe voorkom je dat een zware run van finance de dashboards van operations traag maakt?
  5. Welk mechanisme gebruik je zodat sales geen loongegevens ziet in de gedeelde dimensie?

Richting: een workspace per afdeling plus één gedeelde voor gemeenschappelijke dimensies. Sales krijgt Contributor in de eigen workspace en Viewer op de gedeelde; operations alleen Viewer; finance een eigen afgeschermde workspace. De klantdimensie deel je met een shortcut vanuit de gedeelde workspace. Dat laatste punt is de lastigste: binnen één capaciteit concurreren alle workspaces om dezelfde CU's, dus plan zware runs buiten kantooruren of overweeg een aparte capaciteit voor finance. Loongegevens scherm je af op kolomniveau, niet met een aparte kopie van de tabel.

Microsoft Fabric Carrière Kansen in Nederland

De vraag naar Microsoft Fabric experts explodeert sinds de launch in 2023. Gemiddelde salarissen (2024):

€55K - €70K
Junior Fabric Consultant
€70K - €95K
Fabric Data Engineer
€85K - €115K+
Senior Fabric Architect
€95K - €135K+
Lead Analytics Engineer

Tip: Microsoft Certified: Fabric Analytics Engineer Associate certificering verhoogt je salaris met 25-35%. Veel Nederlandse organisaties migreren nu naar Fabric.

Microsoft Fabric Certificering Pad

Na het voltooien van deze cursus ben je klaar voor:

DP-600: Fabric Analytics Engineer

Implement data solutions with Microsoft Fabric

PL-300: Power BI Data Analyst

Prepare, model, visualize and analyze data

DP-500: Analytics Engineer

Advanced analytics with Azure and Fabric

DP-100: Data Scientist

Design and implement data science solutions

Microsoft Fabric Pricing Calculator

Microsoft Fabric gebruikt Capacity Units (CU's). Bereken jouw maandelijkse kosten:

50 gebruikers
10 TB

Geschatte maandelijkse kosten:

€5,002.88

Inclusief: OneLake storage, Data Engineering, Data Warehousing, Real-time Analytics, Data Science, Power BI Premium

Microsoft Fabric Learning Resources

Fabric als dataplatform

Wat Fabric samenbrengt: OneLake, Lakehouse, Warehouse, Data Factory en Power BI in één omgeving.

Lees de platformpagina

Wat is Microsoft Fabric?

De onderdelen uitgelegd, inclusief capaciteiten, licenties en hoe het zich verhoudt tot Synapse.

Lees het artikel

Medallion-architectuur in Fabric

Bronze, Silver en Gold inrichten in een Fabric Lakehouse, met de keuzes die je onderweg maakt.

Lees het artikel

Pipeline Generator

Beschrijf je bron en doel, en krijg een opzet voor een Fabric-pipeline terug.

Open de tool

Jouw Fabric Learning Journey

Na deze essentials cursus kun je door naar:

Actuele Microsoft Fabric Vacatures

Bekijk onze Microsoft Fabric vacatures voor de nieuwste kansen bij Nederlandse organisaties zoals overheden, banken, verzekeraars en grote enterprises.

Microsoft Fabric vs Andere Platforms

Platform Sterke Punten Zwakke Punten Best Voor Prijzen (Nederland)
Microsoft Fabric End-to-end integratie, Power BI, Microsoft ecosystem Nog relatief nieuw (2023), Microsoft lock-in Microsoft shops, Unified analytics €263 - €40k/maand (Capacity Units)
Snowflake Data sharing, Multi-cloud, Zero-copy cloning Kostbaar, minder geïntegreerd BI Data sharing, Multi-cloud €2-€4 per credit
Databricks Machine Learning, Delta Lake, Spark Complexer voor pure SQL, minder geïntegreerd BI Data Science, ML, Engineering €0.40-€0.70 per DBU
Google BigQuery Serverless, BigQuery ML, Google Cloud Vendor lock-in, minder Microsoft integratie Google Cloud ecosystem €4.80 per TB (on-demand)

Microsoft Fabric is bijzonder sterk voor organisaties die al in Microsoft ecosystem zitten (Office 365, Azure, Power BI).