2025-08-09
Use Fabric Notebooks for Data Transformation and ML

TL;DR
-
Replace fragile, click-heavy steps with code-first notebooks (Python/R) that run next to your data in the Lakehouse with Spark scale.
-
Follow a simple Bronze → Silver → Gold pattern; publish to Power BI or kick off ML directly.
-
The overlooked switch: make notebooks the single source of truth—Git-connected, parameterized, and auditable—so every change is traceable.
-
Build guardrails: env configs, data snapshots, canary queries, idempotent writes, and RBAC.
Why notebooks (and why now)
-
End the “Power Query + Excel + scripts” shuffle; put all transformations in one place with readable, testable code.
-
Transparency & lineage: every filter/join/feature is visible in code and versioned.
-
Scale on demand: Spark handles 10M+ rows without moving data off the Lakehouse.
End-to-end pattern (what good looks like)
-
Bronze (raw landings)
-
Ingest files/streams to
/Tables/bronze/*. -
Enforce schemas; quarantine bad rows.
-
-
Silver (clean & conformed)
-
Standardize types/time zones/encodings.
-
De-dup, SCD handling, business keys.
-
-
Gold (analytics/ML ready)
-
Feature engineering (lags, cohorts, RFM, seasonality).
-
Write Delta tables with partitioning and Z-order.
-
Expose as Power BI semantic model or feed ML.
-
Minimal notebook workflow (concept)
-
Read:
spark.read.format("delta").load("/Tables/bronze/sales") -
Clean/Join: PySpark/pandas ops; unify dims/facts; validate row counts.
-
Feature: rolling windows, categorical encodings, outlier rules.
-
Write:
df.write.format("delta").mode("overwrite").save("/Tables/gold/sales_features") -
Publish: create/refresh Power BI model; or trigger training job.
Governance & collaboration (the guardrails)
-
Git integration: dev → test → main branches; pull requests required.
-
Parameters: environment URLs, table paths, feature flags (no hard-coding).
-
RBAC: restrict read/write at Lakehouse & notebook levels; avoid broad contributor roles.
-
Audit & lineage: enable workspace activity logs; tag runs with correlation IDs.
Data reliability checks (fast & effective)
-
Schema drift: assert expected columns/types before writes.
-
Canary queries: verify key metrics (row counts, null thresholds) post-write.
-
Idempotency: partitioned upserts/merge; no double counting on reruns.
-
Snapshots: Delta time travel or pre-release copy for quick rollbacks.
Power BI handoff (smooth, not brittle)
-
Build a semantic model over Gold tables; avoid loading from ad-hoc exports.
-
Parameterize workspace/dataset IDs; schedule refresh after Gold writes complete.
-
Add data quality tiles (e.g., freshness, row-count) to the report.
Security essentials
-
No secrets in notebooks: use Key Vault–backed connections.
-
Separate sensitive dims (PII) with row/column-level security; mask in non-prod.
-
Least-privilege service principals for scheduled runs; no shared personals.
Performance tips
-
Prefer PySpark for big joins; use pandas for small, in-memory fixes.
-
Partition by date (or high-cardinality natural keys) + optimize/Z-order on query columns.
-
Cache hot dims; broadcast small lookup tables.
Quick wins (this week)
-
Move one noisy Power Query pipeline into a single Fabric Notebook.
-
Add canary checks + Delta snapshot before publishing Gold.
-
Connect the notebook to Git; create dev/test/main branches.
-
Parameterize Lakehouse paths and workspace IDs; remove hard-coded values.
Anti-patterns to avoid
-
Mixing notebook code with manual Excel fixes.
-
Writing CSVs back and importing into Power BI (lose lineage & scale).
-
Hard-coding secrets/paths; skipping PRs on “quick edits.”
-
One giant “do-everything” notebook—modularize by layer.
FAQ
Do I need to abandon Power Query?
No—use it where it shines. Move complex/fragile steps into notebooks for scale, tests, and reuse.
Python or R?
Either works. For large transformations, PySpark typically wins on ecosystem/scale.
How do I roll back a bad run?
Use Delta time travel or restore from a pre-run snapshot; revert notebook commit in Git.
Host: Mirko Peters