Große Fakten: Warum driftet ein grüner Refresh trotzdem?

Große Faktentabellen können bei jedem Lauf "erfolgreich" sein und trotzdem lügen. Die Zeilenzahlen sehen gut aus. Die Pipelines sind grün. Die Measures driften, weil Löschungen, Nachzügler und Korrekturen nie Teil des inkrementellen Vertrags waren. Analysten entdecken es jede Woche. Engineers nennen es wackelig. Meistens fehlt schlicht eine Vereinbarung.

Große Faktentabellen sind der klassische Patient. Die Krankheit heißt: Notebooks, Watermarks und semantische Konsumenten passen nicht zusammen. Schnelle Materialisierung ohne Drift-Tests scheitert nur schneller.

Abbildung 1. Vertrag vor Grün. Schreib die inkrementelle Bedeutung auf, richte die Watermarks an den Korrekturen aus, sichere Drift in der Pipeline ab und veröffentliche dann ein Refresh-SLA mit Verantwortlichem. Exit-Code null ist keine Ehrlichkeit.

Kontext und Rahmenbedingung

Ein häufiger Fehler: Bei großen Faktentabellen sehen die täglichen Ladeläufe gesund aus, während die Measures wandern. Die Pipeline ist nicht zufällig. Die Watermark erzählt eine engere Geschichte, als das Fachgebiet glaubt. Sobald der Vertrag geschrieben ist und Drift in der Pipeline getestet wird, wird "wackelig" zu einer geschlossenen Ticketklasse.

Erfolg bei den Zeilenzahlen kann Löschungen verbergen, die nie angekommen sind, Nachzügler außerhalb der Watermark und Korrekturen, die vorgelagert angewendet, nachgelagert aber ignoriert wurden. Semantische Konsumenten setzen eine Granularität und eine Geschichte zur Frische voraus. Wenn die Notebooks davon abweichen, ist Drift das Symptom. Es wackelig zu nennen, verzögert die Lösung.

Abbildung 2 ist die Erinnerung aus Learn, dass der geplante Refresh eine Betriebsoberfläche ist. Auch grüne Zeitpläne brauchen einen inkrementellen Vertrag, der Nachzügler und Korrekturen abdeckt.

Abbildung 2. Ein Refresh kann geplant sein und trotzdem über die Historie lügen. Der Zeitplan ist nicht der Vertrag. Quelle: Microsoft Learn: Datenaktualisierung in Power BI.

Design

1. Den inkrementellen Vertrag auf einer Seite schreiben

Nenne Granularität, Bedeutung der Watermark-Spalte, wie Löschungen auftauchen, wie Nachzügler behandelt werden und wie Korrekturen die Historie wieder öffnen. Wenn zwei Engineers nach dem Lesen unterschiedlicher Meinung sind, ist die Seite nicht fertig. Verträge schlagen Stammeswissen in Notebook-Kommentaren.

2. Watermarks an fachlichen Korrekturregeln ausrichten

Wenn das Fachgebiet erwartet, dass Korrekturen am selben Tag durchlaufen, lässt eine strikte Nur-anhängen-Watermark die Measures driften. Wenn das Fachgebiet unveränderliche Tages-Snapshots erwartet, brauchen weiche Korrekturen einen anderen Weg. Entscheide bewusst und teste den Normalpfad und den Korrekturpfad. Abbildung 3 zeigt die Gabelung.

Abbildung 3. Nur anhängen ist einfacher. Korrekturfreundlich ist schwieriger und manchmal nötig. Die fachliche Regel bestimmt die Geschichte der Watermark, nicht die Gewohnheit im Notebook.

3. Drift-Checks in die Pipeline einbauen

Vergleiche wichtige Measures oder Hash-Aggregate mit einer früheren vertrauenswürdigen Marke oder einer Abgleichsquelle innerhalb einer Toleranz. Lass den Lauf fehlschlagen oder stell den Ausschnitt unter Quarantäne, wenn die Drift die Regel überschreitet. Die wöchentliche Überraschung bei den Analysten ist keine Kontrolle. Abbildung 4 zeigt das Gate.

Abbildung 4. Ein Ladelauf kann grün und trotzdem unehrlich sein. Das Drift-Gate entscheidet zwischen Veröffentlichen und Quarantäne, bevor die Konsumenten den Ausschnitt sehen.

4. Ein Refresh-SLA pro Fakten-Granularität veröffentlichen

Sag, wie frisch die Faktentabelle sein soll, für wen und was "gut" über grüne Checks hinaus bedeutet. SLAs ohne Drift-Tests sind Verfügbarkeitstheater. SLAs mit Verantwortlichen schaffen Eskalationswege.

5. Tempo von Ehrlichkeit trennen

Materialisiere schnell, sobald der Vertrag testbar ist. Schnellere falsche Fakten verbreiten falsche Entscheidungen nur früher. Performance-Arbeit folgt den Korrektheits-Gates, nicht umgekehrt.

6. Annahmen in Notebook, Watermark und semantischem Modell nachverfolgen

Inventarisiere, wo jede Annahme steckt. Wenn das semantische Modell ein SCD-Verhalten erwartet, das das Notebook nicht liefert, dokumentiere die Abweichung als Defekt. Drift sitzt oft in den Nahtstellen zwischen Teams.

Wie ein Drift-Test aussehen kann, ohne den Ozean zum Kochen zu bringen

Du brauchst am ersten Tag keine perfekte Automatisierung für den Abgleich. Fang mit stabilen Schlüsseln an: Anzahl eindeutiger Zeilen in einem abgeschlossenen Fenster, Summe eines wichtigen Measures für einen gesperrten Zeitraum oder Null-Quoten bei kritischen Fremdschlüsseln. Vergleiche mit der vorherigen erfolgreichen Marke und mit einem Quellauszug für einen Beispieltag. Toleranzen sollten ausdrücklich sein. Null Toleranz bei volatilen offenen Zeiträumen erzeugt falsche Fehlschläge. Unendliche Toleranz erzeugt falsche Ruhe.

Drift gegenüber Stakeholdern kommunizieren

Sag: Die Pipeline war mechanisch erfolgreich. Der inkrementelle Vertrag hat für diese Art von Korrektur versagt. Das ist die fachliche Regel, die wir codieren. Das ist der Test, der das Release blockiert, wenn es wieder auftritt. Vermeide "die Plattform war wackelig". Gib nicht den Analysten die Schuld, weil sie es bemerkt haben. Präzision schafft schneller Vertrauen als Beschwichtigung.

Neu aufbauen oder reparieren

Manche Drift erfordert einen begrenzten Neuaufbau eines Datumsbereichs. Manche nur eine Korrektur nach vorne. Halte im Runbook fest, welche Situationen einen Neuaufbau verlangen. Wer diese Entscheidung dem Urteil um 2 Uhr nachts überlässt, bekommt garantiert eine inkonsistente Historie. Verbinde die Playbooks für den Neuaufbau mit einem Blick auf die Kapazität, damit Ehrlichkeit nicht versehentlich zu einem Denial of Service auf der Kapazität wird.

Häufige Fehler

Grün heißt wahr. Exit-Codes ersetzen den Abgleich.

Undefinierte Löschungen. Zeilen, die verschwinden sollten, bleiben für immer.

Ignorierte Nachzügler. Das Fachgebiet glaubt, sie sind drin. Die Watermark sagt nein.

Analysten als Monitor. Drift wird in Meetings gefunden, nicht in Pipelines.

SLA als Marketing. Versprechen zur Frische ohne Tests.

Umbauten mit Tempo zuerst. Schnellere Materialisierung, dasselbe Loch im Vertrag.

So übernehmen oder anpassen

So übernehmen

• Große Faktentabellen veröffentlichen einen inkrementellen Vertrag, der Löschungen, Nachzügler und Korrekturen abdeckt.
• Die Semantik der Watermarks entspricht den dokumentierten fachlichen Erwartungen.
• Drift-Checks laufen in der Pipeline, mit ausdrücklichen Toleranzen und einer Regel für Fehlschläge.
• Jede Fakten-Granularität hat ein Refresh-SLA mit einem Verantwortlichen.
• Performance-Arbeit an der Materialisierung folgt den Ehrlichkeits-Gates.
• Regeln für Neuaufbau oder Korrektur nach vorne stehen in einem versionierten Runbook.

Vor dem Einsatz anpassen

Verträge und Drift-Tests kosten Designzeit und CI-Minuten. Undefiniertes inkrementelles Verhalten kostet stille Diskussionen darüber, welche Zahl stimmt. Engere Watermarks sind für manche Fälle einfacher und richtiger. Korrekturfreundliche Watermarks sind schwieriger und für andere Fälle nötig. Quarantänepfade machen die Anbindung der Konsumenten komplizierter. Das stille Veröffentlichen gedrifteter Ausschnitte macht das Vertrauen komplizierter. SLAs schaffen Verantwortlichkeit und machen Unterfinanzierung früh sichtbar.

Wichtigste Quellen: Datenaktualisierung in Power BI, die Hinweise zu Fabric-Pipelines und zum Refresh semantischer Modelle auf Microsoft Learn sowie deine Doku zur Verantwortung für Fakten-Granularitäten. Stell den SLA-Text neben die Namen der Drift-Tests, damit Betrieb und Analytics dasselbe Vokabular teilen.

Definiere die inkrementelle Bedeutung. Teste sie in der Pipeline. Veröffentliche das SLA. Richte die Watermarks an den Korrekturen aus. Bevorzuge ehrliches Tempo. Hör auf, Vertragsbrüche wackelig zu nennen.

Verwandte Notizen

• Warehouse Views: Solltest du schwere Views für Direct Lake materialisieren? (für Tempo materialisieren, sobald der Vertrag testbar ist)
• Spark Ingest: Wie lädst du große Tabellen ohne Driver OOM? (Ladeläufe in Batches, die vollständige Neuaufbauten endlich halten)
• Fabric Monitor: Refresh-Fehler systematisch überwachen (ein Runbook zur Diagnose von Refresh-Fehlern)