Lakehouse-Architektur meistern: Bronze, Silver und Gold in Microsoft Fabric

Von Mirko Peters · 2026-08-28

Willkommen zurück beim Podcast-Begleitblog! In unserer neuesten Folge haben wir die praktischen Realitäten des Machine-Learning-Engineerings innerhalb von Micro… ausführlich beleuchtet.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück beim Begleitblog zu unserem Podcast! In unserer neuesten Folge haben wir uns eingehend mit den praktischen Anforderungen des Machine-Learning-Engineerings im Microsoft-Ökosystem beschäftigt. Falls Sie sie noch nicht gehört haben, sehen Sie sich unbedingt Build Machine Learning Models in Microsoft Fabric an. Heute vertiefen wir diese Konzepte und zeigen, wie die Strukturierung Ihrer Daten nach einer Medallion-Architektur innerhalb eines Microsoft Fabric Lakehouse das absolute Fundament für einen erfolgreichen, skalierbaren Machine-Learning-Betrieb bildet.

Produktionsreife Machine-Learning-Modelle entstehen nicht allein durch die Wahl des richtigen Algorithmus oder das Feintuning von Hyperparametern. Meist hängt der Erfolg Ihrer Vorhersagemodelle von Datenhygiene, reproduzierbaren Pipelines und einer robusten Governance ab. Schauen wir uns an, wie Sie Ihre Lakehouse-Architektur mit Microsoft Fabric beherrschen.

Die Architektur auf einen Blick

Beim Entwurf einer durchgängigen Daten- und Machine-Learning-Plattform in Microsoft Fabric ist es entscheidend, den Datenfluss zu verstehen. Alles beginnt in OneLake, das als einheitliche Speicherschicht dient. Von dort werden die Daten in ein Lakehouse geleitet, wo sie als Delta-Tabellen die Stufen Bronze, Silver und Gold durchlaufen.

Für die Rechenleistung stellen Fabric Notebooks Data Scientists einen vorinstallierten Data-Science-Stack bereit, der auf Spark, Python und R basiert. Das Experiment-Tracking erfolgt nahtlos über integrierte MLflow-Läufe, die Metriken, Parameter und Artefakte erfassen, ohne externe Tracking-Server zu benötigen. Sobald Modelle trainiert sind, wandern sie in die einheitliche Registry, inklusive Versionierung, Genehmigungen und vollständiger Datenherkunft (Data Lineage). Schließlich werden Modelle über verwaltete Batchaufträge oder Echtzeit-HTTP-Endpunkte bereitgestellt und speisen Verbraucher wie Power BI, Power Apps und benutzerdefinierte API-Clients.

Lakehouse: Eingaben bändigen, Kontrolle behalten

Die Grundidee eines Lakehouse ist, die Flexibilität eines Data Lake mit der Verlässlichkeit eines Data Warehouse zu verbinden. Damit das funktioniert, müssen Sie Ihre Daten in klar getrennte Schichten strukturieren.

Tabellen in Schichten ordnen

• Bronze: Dies ist Ihre Schicht für die Rohdatenaufnahme. Daten landen hier nach dem Prinzip Schema-on-Read und bleiben unveränderlich, damit Prüfungen und Neuverarbeitungen möglich sind.
• Silver: In dieser Schicht werden Daten bereinigt, typisiert und zusammengeführt. Personenbezogene Daten (PII) werden minimiert, und erste Qualitätsprüfungen werden durchgesetzt.
• Gold: Die Gold-Schicht enthält aufbereitete Feature-Aggregate, die auf klaren, dokumentierten Datenverträgen beruhen und Ihre Machine-Learning-Modelle direkt nutzen können.

Zugriff nach Zweck steuern

Kombinieren Sie die rollenbasierte Zugriffssteuerung auf Arbeitsbereichsebene mit Zugriffssteuerungslisten auf Tabellenebene. Geben Sie Data Scientists Lesezugriff auf Silver- und Gold-Tabellen und beschränken Sie den Schreibzugriff gezielt auf Feature-Tabellen und Experimentierverzeichnisse.

Leitplanken für die Datenqualität

Definieren Sie strikte Erwartungen an Not-Null-Bedingungen, Wertebereiche und referenzielle Integrität. Schlagen Zeilen diese Prüfungen fehl, leiten Sie sie direkt an eine _quarantine-Tabelle weiter, damit nachgelagerte Pipelines nicht stillschweigend scheitern oder beschädigte Daten übernehmen.

Ein schlanker Feature Store

Behandeln Sie wiederverwendbare Features wie Gold-Tabellen, zum Beispiel feat_customer_rolling_90d, und ergänzen Sie sie um ein YAML-Datenwörterbuch, damit Ihr Team versteht, was jedes Feature repräsentiert.

Notebooks ohne Reibungsverluste

Gemeinsames Programmieren kann schnell im Chaos enden, wenn Entwickler mit unterschiedlichen Umgebungen arbeiten. Fabric stellt vorinstallierte Kernel bereit, darunter pandas, PySpark, scikit-learn und PyTorch, sodass alle von exakt derselben Ausgangsbasis aus arbeiten.

Setzen Sie auf ein strukturiertes Projektlayout, das explorative Notebooks, Skripte zur Feature-Entwicklung, Routinen für das Modelltraining und Konfigurationsdateien voneinander trennt. Verankern Sie die Reproduzierbarkeit im Code statt in manuellen Klicks in der Benutzeroberfläche. Lesen Sie über Spark SQL aus Ihrem Lakehouse, schreiben Sie die finalen Features als Delta-Tabellen und legen Sie stets kleinere Entwicklungs-Beispieltabellen an, damit Ihr Team schnell iterieren kann, ohne auf Abfragen über den gesamten Datensatz warten zu müssen.

Alles mit MLflow verfolgen (integriert)

Manuell nachverfolgte Modellexperimente führen zu Ergebnissen, die sich nicht reproduzieren lassen. Mit der integrierten MLflow-Integration in Fabric stellen Sie die Vergleichbarkeit zwischen einzelnen Läufen sicher, erreichen eine lückenlose Nachvollziehbarkeit und können ein Modell problemlos zurücksetzen, wenn ein neu bereitgestelltes Modell schlechter abschneidet.

Protokollieren Sie alle Hyperparameter, Bewertungsmetriken und trainierten Modellartefakte direkt in Ihren Trainingsskripten. Versehen Sie Ihre Läufe mit kontextbezogenen Metadaten wie Datenzeitraum, Versionen der Feature-Sets und Commit-Hashes des Codes. Außerdem sollten Sie Ihre Trainingstabellen auf bestimmte Delta-Snapshot-Versionen festlegen.

Registry, Freigaben und Lineage

Der Übergang eines Modells von der Experimentierphase in den Produktivbetrieb sollte niemals dem Zufall überlassen werden. Befördern Sie Ihre leistungsstärksten Läufe zu einem registrierten Modell und vergeben Sie dabei semantische Versionsnummern wie 1.0.0. Richten Sie einen zweistufigen Freigabeprozess ein, der die Zustimmung sowohl des Data-Science-Verantwortlichen als auch des Fachverantwortlichen erfordert. Erfassen Sie schließlich umfassende Metadaten einer Modellkarte, die Zweck des Modells, Datenumfang, Hinweise zur Fairness sowie Service-Level-Ziele für das Monitoring beschreiben.

Bereitstellungsoptionen (je nach Workload wählen)

Batch-Scoring (günstig und zuverlässig)

Für Workloads, die keine sofortigen Antwortzeiten im Subsekundenbereich benötigen, ist Batch-Scoring die beste Wahl. Verwenden Sie zeitgesteuerte Fabric-Aufträge oder Notebooks, um produktive Modelle aus der Registry zu laden, sie auf Batch-Datensätze anzuwenden und die Vorhersagen zurück in das Lakehouse zu schreiben.

Echtzeit-Endpunkt (interaktive Apps)

Wenn Ihre Benutzer sofortiges Feedback benötigen, etwa bei der Formularvalidierung oder einer Risikobewertung per Klick, stellen Sie Ihr registriertes Modell direkt über die Fabric-Benutzeroberfläche als verwalteten Echtzeit-Endpunkt bereit. Definieren Sie einen klar vorhersehbaren JSON-Vertrag und binden Sie ihn sicher an Power Apps oder externe Anwendungen an.

Monitoring und Neutraining

Die Bereitstellung eines Modells ist erst die halbe Miete. Sie müssen Datendrift kontinuierlich überwachen, indem Sie die aktuellen Feature-Verteilungen mit Ihrer Trainingsbasis vergleichen, etwa anhand der Kullback-Leibler-Divergenz oder von Schwellenwerten des Population Stability Index. Erfassen Sie außerdem Metriken zum Betriebszustand, darunter Endpunkt-Latenz, Fehlerraten und Kosten pro tausend Bewertungen. Automatisieren Sie Ihre Neutrainings-Pipelines über eine Kombination aus zeitbasierten Auslösern und ereignisbasierten Drift-Warnungen, damit Ihre Modelle langfristig genau bleiben.

Sicherheit und Compliance

Beim Umgang mit Unternehmensdaten hat Sicherheit höchste Priorität. Setzen Sie das Prinzip der minimalen Berechtigungen durch, indem Sie Data Scientists Lesezugriff auf die Silver- und Gold-Ebene gewähren und Schreibberechtigungen auf die vorgesehenen Verzeichnisse für Features und Experimente beschränken. Verwenden Sie für sämtliche Anmeldedaten verwaltete Identitäten und Azure Key Vault, damit keine Geheimnisse jemals fest in Ihren Notebooks codiert werden. Minimieren Sie die Offenlegung personenbezogener Daten, indem Sie sensible Informationen früh in der Silver-Ebene hashen oder tokenisieren, sodass sie niemals in Ihre Feature-Stores gelangen.

Was Sie messen sollten (Nutzen schnell belegen)

Um den Nutzen Ihrer Machine-Learning-Initiativen schnell zu belegen, sollten Sie sich auf die richtigen Kennzahlen konzentrieren. Messen Sie die Modellleistung anhand von AUC und Precision-at-k für Rankings, verfolgen Sie den geschäftlichen Effekt über zusätzlichen Umsatz oder reduzierte Kündigungsraten, überwachen Sie die Geschwindigkeit von der Datenbereitschaft bis zur Produktivsetzung und bewerten Sie die Zuverlässigkeit der Infrastruktur sowie die Kosteneffizienz pro tausend Vorhersagen.

14-Tage-Rollout-Plan

Wenn Sie zügig von null auf eine produktionsreife Fabric-Bereitstellung kommen möchten, folgen Sie diesem strukturierten Zwei-Wochen-Plan:

• Tag 1–2: Lakehouse-Hygiene, Struktur aus Bronze, Silver und Gold, ACLs sowie Qualitätsprüfungen.
• Tag 3: Notebook-Grundgerüst, Datenhilfsfunktionen und Beispieltabellen für die Entwicklung.
• Tag 4–5: Feature-Set v1, Training des Basismodells und MLflow-Protokollierung.
• Tag 6: Evaluierungssuite, Erstellung der Modellkarte und Registrierung des Modells (v0.1).
• Tag 7: Erstellung des Batch-Scoring-Auftrags und Integration des Power-BI-Dashboards.
• Tag 8: Minimales Monitoring (MVP), Drift-Prüfungen und Betriebsprotokollierung.
• Tag 9: Implementierung des Freigabe-Workflows und Beförderung in die Produktion.
• Tag 10: Einrichtung des Echtzeit-Endpunkts, Drosselung und Protokollierung der Anfragen (falls zutreffend).
• Tag 11–12: A/B-Tests, Backtesting und Definition der geschäftlichen KPIs.
• Tag 13: Kostensteuerung, Leitplanken für die automatische Skalierung und Plan für Canary-Deployments.
• Tag 14: Runbook-Dokumentation, Übergabe an das Team und Backlog-Planung.

Häufige Fehler (und schnelle Lösungen)

Auch erfahrene Teams stoßen auf Hindernisse. Vermeiden Sie das Notebook-Roulette, indem Sie Ihre Umgebungen an die Standard-Kernel von Fabric binden. Testen Sie nicht ausschließlich mit winzigen Stichproben, die beim Skalieren auf vollständige Datensätze brechen. Verhindern Sie Geistermodelle in der Produktion, indem Sie Registry-Promotion-Workflows konsequent durchsetzen. Behalten Sie Ihre Cloud-Kosten im Griff, indem Sie wo immer möglich Batchverarbeitung als Standard nutzen und abgeleitete Features zwischenspeichern.

Praktische Codebeispiele

Um Ihr nächstes Projekt zu starten, finden Sie hier einen kurzen Codeausschnitt, der zeigt, wie Sie eine bestimmte Version einer Delta-Tabelle lesen:

sales_v = spark.read.option("versionAsOf", 123).table("lakehouse.gold.sales_txn")

Wenn Sie die Feature-Wichtigkeit mit scikit-learn extrahieren und direkt in MLflow protokollieren möchten, verwenden Sie diesen Ansatz:

import pandas as pd
fi = pd.Series(clf.feature_importances_, index=feature_cols).sort_values(ascending=False)
mlflow.log_artifact(fi.head(30).to_frame("importance").to_csv("fi.csv", index=True))

Und so berechnen Sie den Population Stability Index (PSI) zur Drift-Erkennung:

import numpy as np
def psi(expected, actual, bins=10):
    e, b = np.histogram(expected, bins=bins, range=(np.min(expected), np.max(expected)))
    a, _ = np.histogram(actual,   bins=b,     range=(np.min(expected), np.max(expected)))
    e = np.clip(e / e.sum(), 1e-6, None); a = np.clip(a / a.sum(), 1e-6, None)
    return np.sum((a - e) * np.log(a / e))

Wenn Sie möchten, nennen Sie in den Kommentaren Ihre aktuellen Lakehouse-Tabellennamen und einen Zielanwendungsfall, etwa Kundenabwanderung, Lead-Scoring oder Nachfrageprognose, oder wenden Sie sich direkt an mich. Ich erstelle Ihnen dann einen minimalen Feature-Satz, eine Empfehlung für das Basismodell und die genaue Anbindung für Batch- oder Echtzeitverarbeitung, damit Sie Ihre erste Microsoft-Fabric-Bereitstellung schnell live bringen können!