Bronze, Silver, Gold: Nicht jede Medaille braucht drei Schichten.

Microsoft empfiehlt Medallion als Designansatz für Fabric. Das ist vernünftig. Aus der Empfehlung folgt aber nicht, dass jedes Projekt drei Workspaces, drei Lakehouses und dieselbe Zahl Tabellenkopien braucht.

Eine Schicht verdient ihren Platz erst, wenn sie eine klare Grenze zieht: zwischen Quelle und Plattform, zwischen technisch gültig und fachlich vertrauenswürdig oder zwischen wiederverwendbaren Daten und einem konkreten Berichtsmodell.

Die drei Rollen, nicht nur drei Farben

Bronze muss reproduzierbar sein, nicht hübsch

In Bronze zählt Herkunft vor Eleganz. Behalte Quelldatei, Ladezeit, Quellsystem und nach Möglichkeit einen stabilen Batch- oder Ereignisschlüssel. Ändere Daten nur so weit, wie sie für eine zuverlässige Ablage nötig sind. Eine still korrigierte Postleitzahl gehört nicht hierhin.

Bronze muss nicht zwangsläufig eine physische Kopie sein. Microsoft empfiehlt für Daten, die bereits in OneLake, ADLS Gen2, Amazon S3 oder Google liegen, einen OneLake Shortcut als Alternative zum erneuten Kopieren. Das spart Bewegung, ändert aber den Betriebsvertrag: Verfügbarkeit und Berechtigungen der Quelle bleiben Teil deines Pfads.

Bronze ist gelungen, wenn …

• ein fehlgeschlagener Silver-Lauf denselben Eingabestand erneut verarbeiten kann,
• du einen Datensatz auf Quelle, Datei und Ladezeit zurückführen kannst,
• Schemaänderungen auffallen, statt still Spalten zu verschlucken,
• Aufbewahrung und Datenschutz bewusst festgelegt sind.

Silver ist die wichtigste und am häufigsten verwässerte Schicht

Silver ist nicht „Bronze, aber als Delta“. Hier entsteht ein belastbarer fachlicher Datenbestand. Technische Bereinigung allein reicht nicht. Ein Datum kann syntaktisch gültig und fachlich unmöglich sein. Eine Kundennummer kann gefüllt und trotzdem unbekannt sein.

Quarantäne statt stiller Datenkosmetik

Fehlerhafte Datensätze brauchen einen sichtbaren Pfad. Speichere Regel, Grund, Batch und Zeitpunkt. Entscheide bewusst, ob gute Datensätze weiterlaufen dürfen oder der gesamte Batch blockiert. Eine pauschale Regel für alle Quellen ist selten sinnvoll.

Gold ist ein Produkt, kein Siegel

Gold heißt nicht „fehlerfrei“. Es heißt: für einen benannten Verbrauch geformt. Das kann ein Star Schema für Power BI, eine aggregierte Tabelle für operative Analysen oder eine kuratierte Schnittstelle für ein anderes Team sein.

Eine Gold-Tabelle braucht einen Besitzer, beschriebene Kennzahlen und ein vereinbartes Aktualitätsziel. Ohne diese Angaben ist „curated“ nur ein freundliches Etikett.

Direct Lake ändert die Verantwortung, nicht die Schichten

Direct Lake kann Gold-Delta-Tabellen ohne klassische vollständige Importkopie für ein semantisches Modell nutzen. Das macht Dateigrößen, Datentypen und Tabellenpflege noch sichtbarer. Medallion ersetzt kein Modellierungs- oder Capacity-Konzept.

Wann zwei Schichten reichen

Auch innerhalb eines Projekts dürfen Datenpfade unterschiedlich viele Stufen haben. Eine große Faktentabelle kann Bronze, Silver und Gold benötigen, während eine kleine Referenztabelle direkt aus einer geprüften Quelle in Gold landet. Einheitlichkeit ist kein Selbstzweck.

Lakehouse, Schema oder Workspace?

Microsoft empfiehlt, die Layer in getrennten Lakehouses oder Warehouses zu halten und nennt separate Workspaces als Governance-Empfehlung. Das verbessert Zugriffsgrenzen und Verantwortlichkeit. Es erhöht aber auch Deployment-, Berechtigungs- und Betriebsaufwand.

• Ein Lakehouse mit Schemas passt für kleine Teams, einfache Berechtigungen und kurze Wege.
• Getrennte Lakehouses in einem Workspace trennen Speicher und Lebenszyklen, ohne sofort die gesamte Workspace-Verwaltung zu vervielfachen.
• Getrennte Workspaces passen, wenn Layer eigene Berechtigungen, Teams, Deployment-Zyklen oder Governance-Grenzen brauchen.

Der Betrieb entscheidet, ob das Muster trägt

Idempotenz und Wasserstände

Jeder Übergang braucht einen wiederholbaren Schreibmodus. Append, Merge oder vollständiger Neuaufbau sind bewusste Entscheidungen. Ein „letzter erfolgreicher Zeitstempel“ reicht nicht, wenn verspätete Änderungen oder Löschungen auftreten können.

Schemaänderungen

Neue optionale Spalten sind etwas anderes als geänderte Datentypen oder verschwundene Schlüssel. Pro Übergang muss feststehen, was automatisch übernommen wird, was quarantänisiert und was den Lauf stoppt.

Backfill ist nicht Wiederaufbau

Ein Backfill verarbeitet ein fehlendes oder korrigiertes Zeitfenster. Ein Wiederaufbau erzeugt einen ganzen Datenbestand mit einer neuen Regel- oder Codeversion erneut. Beides braucht explizite Parameter wie Eingabebereich, Lademodus, Quellstand und Regelversion. Das manuelle Zurücksetzen eines Watermarks ist kein Betriebskonzept.

Fabric stellt bei intervallbasierten Pipeline-Zeitplänen Start und Ende des Fensters als Parameter bereit. Die eingebaute Time-Slice-Überwachung und Backfill-Funktion ist laut Microsoft derzeit jedoch noch nicht verfügbar. Plane deshalb selbst, wie Bereiche protokolliert, erneut verarbeitet und erst nach vollständiger Prüfung veröffentlicht werden. Bei einem Wiederaufbau muss zusätzlich klar sein, ob Bronze und historische Referenzdaten vollständig vorliegen und wie ein halbfertiger Stand vor Konsumenten verborgen bleibt.

Dateigrößen und Tabellenwartung

Viele kleine Delta-Dateien kosten Leseleistung. OPTIMIZE kompaktiert Dateien; VACUUM entfernt nicht mehr referenzierte Dateien nach der Aufbewahrungsfrist und ist kein Performance-Ersatz. Microsoft unterscheidet inzwischen klarer nach Arbeitslast: In Bronze steht schnelles Schreiben im Vordergrund, in Gold häufiger schnelles Lesen.

V-Order ist in neu erstellten Fabric-Workspaces standardmäßig deaktiviert. Aktiviere es gezielt für leseintensive Tabellen und nicht reflexartig für jede Ingestion. Miss mit realen Daten und Verbrauchswegen.

Jede physische Schicht verbraucht Capacity

Eine zusätzliche Kopie kostet nicht nur Speicher. Sie erzeugt weitere Schreib- und Lesevorgänge, Pipeline- oder Notebook-Läufe, Qualitätsprüfungen, Wartung, Monitoring und Arbeit bei Backfills. Spark-Arbeiten nutzen standardmäßig die dem Workspace zugeordnete Fabric Capacity, die sich mehrere Workspaces und Jobs teilen können. Bursting und Smoothing gleichen kurze Spitzen aus, verhindern aber keine Überlastung bei dauerhaft zu hoher Nutzung.

Eine dritte Schicht sollte diesen Betriebsaufwand deshalb durch einen messbaren Nutzen rechtfertigen: einen unabhängigen Vertrag, bessere Wiederverwendung, eine Sicherheitsgrenze, eine eigene Veröffentlichung oder nachweisbar bessere Abfragen. „Storage ist günstig“ greift zu kurz – teuer wird meist die dauerhaft zusätzlich betriebene Verarbeitung.

Welche Fabric-Werkzeuge passen?

• Data Pipelines orchestrieren Kopien, Notebooks, Dataflows und Wartungsaktivitäten.
• Notebooks mit Spark passen für komplexe Transformationen, große Datenmengen und nicht rein SQL-basierte Logik.
• Dataflows Gen2 passen für Power-Query-nahe Transformationen und Teams mit entsprechendem Know-how.
• Materialized Lake Views können mehrstufige SQL-Transformationen deklarativ abbilden, Abhängigkeiten planen und Datenqualitätsregeln anwenden. Sie sind nicht die richtige Wahl für jede Python-, ML- oder Streaming-Logik.
• Warehouse und SQL passen dort, wo relationale Modellierung und T-SQL der natürliche Arbeitsmodus sind.

Sechs typische Fehlentscheidungen

Die acht Fragen vor dem dritten Layer

1. Welches konkrete Qualitäts- oder Betriebsproblem löst die zusätzliche Schicht?
2. Wer besitzt ihren Vertrag und reagiert auf Fehler?
3. Kann der Eingabestand reproduziert werden?
4. Welche Regeln blockieren den Lauf, welche führen in Quarantäne?
5. Ist der Schreibprozess idempotent und restartfähig?
6. Welche Verbraucher teilen den Bestand tatsächlich?
7. Welche Berechtigungsgrenze braucht ein eigenes Lakehouse oder einen Workspace?
8. Ist die zusätzliche Materialisierung messbar günstiger als eine View, ein Shortcut oder eine direkte Transformation?

Transparenz: Produktaussagen sind mit den verlinkten Microsoft-Quellen belegt. Empfehlungen zu Schichtanzahl, Verträgen und Betriebsmodell sind redaktionelle Einordnung.