MLV + SCD2: Ist SCD2 in Bronze das richtige Muster vor Silver MLVs?

Dimensionen mit aktuellem Stand lügen in dem Moment, in dem sich ein Attribut ändert. Dashboards, die sagen "wie ist es jetzt", sind für Ansichten des aktuellen Stands in Ordnung. Fragen zur Historie ("wie war es, als der Fakt passiert ist?") brauchen eine Slowly Changing Dimension vom Typ 2, nicht die Hoffnung, dass jemand den Auszug von gestern aufbewahrt hat.

Für jede Dimensionstabelle, deren Attribute sich mit der Zeit ändern, lege ich die Historie in SCD2 Materialized Lake Views ab, bevor jemand Stichtagsseiten baut. Der Change Feed ist die Quelle der Wahrheit. Die MLV ist die zum Produkt gemachte Spezifikation der Historie.

Abbildung 1. SCD2 als Produktspezifikation. Wahrheit aus dem Change Feed, Historie in der MLV, gemeinsame Stichtagsgranularität, dann abgesicherte Berichte. Aktuelle Dimensionen beantworten das Heute. Historie braucht SCD2.

Kontext und Rahmenbedingung

Ein häufiger Fehler: Stichtagsberichte widersprechen Ansichten des aktuellen Stands, die nur die neueste Zeile kennen. Die Granularität sah richtig aus, bis jemand nach der Sicht des letzten Quartals fragte. Die aktuellen Dimensionen beantworteten das Heute. Die Nutzer fragten nach damals.

Zwei Historien erzählen nicht immer dieselbe Geschichte. Wenn die vorgelagerte Änderungstabelle für eine Attributgruppe unvollständig ist, trenne die SCDs, statt eine einzige breite Historie zu erzwingen, die Gewissheit erfindet. Flags für Ereignistypen gehören neben die Historie, damit die Klassifizierung nicht jeden Sprint in DAX neu erfunden wird.

Abbildung 2 zeigt die Einordnung der Gültigkeitsdatierung vom Typ 2 in Learn. Modelliere die Datierung, bevor du Dashboards bittest, Historie zu erfinden.

Abbildung 2. Der Zustand zu einem Zeitpunkt ist eine Produktfrage für SCD2. Modelliere die Gültigkeitsdatierung, bevor du Dashboards bittest, Historie zu erfinden. Quelle: Microsoft Learn: Dimensionstabellen in der dimensionalen Modellierung.

Abbildung 3 zeigt, warum MLVs ein gutes Zuhause sind, wenn der Change Feed echt ist. Die Lineage zeigt, welcher Feed die Stichtagsspezifikation speist.

Abbildung 3. MLVs machen Historientransformationen betreibbar. Die Lineage zeigt, welcher Change Feed die Stichtagsspezifikation speist. Quelle: Microsoft Learn: Erste Schritte mit Materialized Lake Views.

Design

1. Zugeben, dass Dimensionen mit aktuellem Stand keine Historie sind

Eine Dimension, die an Ort und Stelle aktualisiert wird, beantwortet das "Jetzt". An dem Tag, an dem sich ein Attribut einer Dimensionszeile ändert, erbt jeder vergangene Fakt, der nur über aktuelle Schlüssel verknüpft ist, die neuen Attribute, außer du hast eine Gültigkeitsdatierung modelliert. So zu tun, als sei eine Typ-1-Dimension "gut genug, bis wir Historie brauchen", führt dazu, dass du Gold unter Termindruck neu baust.

2. MLVs bevorzugen, wenn der Change Feed die Wahrheit ist

Materialized Lake Views funktionieren gut, wenn du SCD2-Logik deklarativ über einen Change- oder Snapshot-Feed ausdrücken und nach einem Zeitplan, den du steuerst, neu materialisieren kannst. Halte die Logik nah am Lakehouse, versioniert und reviewbar. Notebooks mit handgestrickten Merges sind für Prototypen in Ordnung. Sie werden zu Stammeswissen, wenn jeder Engineer einen anderen Randfall beim Gültigkeitsdatum hat. Abbildung 1 zeigt diese Aufteilung der Verantwortung als vier Aufgaben.

3. Eine Historie in zwei aufteilen, wenn die Quellen ungleich sind

Attributgruppe A kommt vielleicht sauber an, während Attributgruppe B verspätet oder in einer anderen Tabelle ankommt. Modelliere zwei Historien mit klarer Granularität statt einer dünn besetzten Mega-SCD voller leerer Gültigkeitszeiträume. Berichte, die nur Historie A brauchen, sollten nicht auf die Qualität von Historie B warten, und umgekehrt. Abbildung 4 zeigt die Aufteilung.

Abbildung 4. Ungleiche Historien trennen. Zwei klare Granularitäten schlagen eine dünn besetzte Mega-SCD, die Gewissheit erfindet. Mehr Objekte zu dokumentieren ist billiger als eines, dem niemand vertraut.

4. Flags für Ereignistyp und Klassifizierung mit der Historie mitführen

Wenn "geändert", "umklassifiziert" und "korrigiert" unterschiedliche Änderungsereignisse sind, speichere die Flags neben den SCD-Zeilen. Sonst erfindet jedes semantische Modell eigene CASE-Logik, die auseinanderdriftet. Historie ohne Ereignissemantik wird zu einer Zeitleiste, über die in Meetings gestritten wird.

5. Die Join-Spezifikation für den Stichtag in Gold und im Modell festlegen

Benenne die Schlüssel, die Stichtagsbedingung (Transaktionszeit oder Gültigkeitszeit, falls du sie unterscheidest) und wie Fakten angebunden werden. Die semantischen Beziehungen müssen zu dieser Granularität passen. Eine Brücken- oder Role-Playing-Beziehung, die Gültigkeitsdaten ignoriert, sieht verbunden aus und liefert trotzdem falsche Attribute.

6. Stichtagsberichte erst freigeben, wenn die SCD existiert

Liefere keine Berichtsseite aus, die Historie suggeriert, während das Modell nur aktuelle Dimensionen hat. Mach die MLV (oder eine gleichwertige SCD-Tabelle) zu einer Abhängigkeit in der Liefer-Checkliste. Zeig den aktuellen Stand auf aktuellen Dimensionen. Zeig Historie erst, wenn SCD2 live und getestet ist. Abbildung 5 zeigt das Gate.

Abbildung 5. Stichtagsberichte an die SCD koppeln. Das Fixture-Paket ist grün, bevor die Historienseite kommt. Eine Dimension nur mit aktuellem Stand im Stichtagskostüm fällt beim Release durch.

Fixtures, die das Stichtagsverhalten belegen

Halte einen kleinen Satz Fixtures bereit: eine Dimensionszeile, die sich einmal ändert, eine, die umklassifiziert wird, eine mit einem Korrekturereignis und eine, die sich nie ändert. Prüfe für jede die Attribute zu Zeitpunkten vor und nach der Änderung. Wenn deine SCD-Logik diese Fixtures nicht besteht, diskutiere nicht über Dashboard-Farben. Repariere zuerst die Historie. Fixture-Pakete dokumentieren außerdem für den nächsten Engineer die fachliche Bedeutung der Ereignistypen.

Häufige Fehler

Für immer Typ 1. Die Ansichten des aktuellen Stands sind zufrieden. Die historische Prüfung nicht.

Eine SCD für jede Attributänderung. Verrauschte Historie, unklare Granularität, unmögliche Backfills. Abbildung 4 benennt das Anti-Pattern.

DAX baut Gültigkeitsdaten nach. Langsam, inkonsistent und für Data Engineers unsichtbar.

Annahme, der Change Feed sei vollständig. Späte Korrekturen ohne eigenen Ereignistyp schreiben die Geschichte still um.

Stichtags-Joins auf der falschen Uhr. Gültigkeitszeit und Ladezeit der Pipeline werden vermischt, ohne es zu sagen.

Das Visual vor der Spezifikation ausliefern. Die Leser glauben der Seite. Nach dem Release stellst du fest, dass die Dimension nur den aktuellen Stand kannte. Abbildung 5 zeigt die Checkliste, die das verhindert.

So übernehmen oder anpassen

So übernehmen

• Die Attributhistorie einer Dimension ist SCD2, bevor Stichtagsberichte ausgeliefert werden.
• MLVs (oder ein benanntes Gegenstück) verantworten die SCD-Transformation über den Change Feed.
• Zwei Historien dürfen getrennt sein, wenn die Reife der Quellen unterschiedlich ist.
• Flags für Ereignistypen reisen mit den Historienzeilen. DAX erfindet sie nicht neu.
• Granularität in Gold und Stichtagsbeziehungen im semantischen Modell werden als eine Spezifikation dokumentiert.
• Abnahmetests für Stichtage enthalten Fixtures mit bekannten Änderungen und Korrekturen.

Vor dem Einsatz anpassen

Speicherplatz und Neumaterialisierung für SCD2 kosten mehr als Typ 1. Das bezahlst du, um ehrliche Fragen zur Historie zu beantworten. MLVs bringen Plattformgrenzen und eine Refresh-Semantik mit, die du lernen musst. Dafür gibt es weniger maßgeschneiderten Merge-Code. SCDs zu trennen heißt, mehr Objekte zu dokumentieren. Die Alternative ist ein verwirrendes Objekt, dem niemand vertraut. Stichtagssemantik zwingt Product Owner außerdem festzulegen, welche Uhr zählt. Dieses Gespräch ist unbequem und nötig.

Wichtigste Quellen: Übersicht über Materialized Lake Views, Erste Schritte mit Materialized Lake Views und Dimensionstabellen in der dimensionalen Modellierung.

Bau SCD2 als Produktentscheidung. Leg es in MLVs, wenn der Change Feed echt ist. Trenne ungleiche Historien. Dann, und erst dann, bau die Stichtagsberichte, nach denen alle immer wieder fragen.