Typisierung in Bronze: Ist es eine gute Idee, alles als Strings zu laden?

Dieselbe physische Spalte in jeder Medallion-Schicht erneut zu CASTen, fühlt sich sorgfältig an. Meistens vervielfacht sich genau so die Drift. Bronze castet nach decimal. Silver castet noch einmal, "sicherheitshalber". Gold castet ein drittes Mal und erfindet ein unknown-Literal mit wieder einem anderen Typ. Die Konsumenten erben ein Ratespiel.

Typisiere jede veröffentlichte Spalte einmal, so früh du dich traust (meist in Bronze, manchmal in der ersten stabilen bereinigten View). Silver und Gold behalten nur Aliasse, fachliche Berechnungen und typisierte Literale für Unknown-Zeilen. Casts zur Angleichung bei UNION sind die Ausnahme, nicht der Lebensstil. Den Rest prüfst du per Lint.

Abbildung 1. Jede Spalte einmal typisieren, so früh du dich traust. Nachgelagerte Schichten erben den Vertrag. Sie erfinden CAST für dieselbe physische Spalte nicht neu.

Kontext und Rahmenbedingung

Ein häufiges Muster ist SQL in Silver, das mehr Zeilen darauf verwendet, Typen neu zu deklarieren, als Geschäftsregeln auszudrücken. Das Lakehouse sah diszipliniert aus. Die Typen passten trotzdem nicht zum semantischen Modell, weil Gold seine eigene CAST-Folklore hatte. Als nach einer Typänderung die halbe Lineage neu materialisiert werden musste, wurden die Kosten offensichtlich.

Rituelles CAST in Silver und Gold erzeugt parallele Wahrheiten: hier float, dort decimal, in einem dritten Notebook Datumswerte als strings. Unknown-Member brauchen in Gold ausdrückliche typisierte Literale, keine zufälligen Nullwerte, die Beziehungen brechen. Wenn sich der Vertrag ändert, materialisiere die abhängige Lineage bewusst neu. Ein halber Refresh ist der Weg, auf dem die Typen von gestern die Measures von morgen heimsuchen.

Abbildung 2 zeigt die Oberfläche aus Learn, auf der Zuordnung und Typisierung in einer Pipeline auftauchen. Das Produkt lässt dich casten. Die Plattform braucht trotzdem eine Regel, wo der Vertrag lebt.

Abbildung 2. Entscheidungen zu Zuordnung und Typen tauchen früh im Ingest-Pfad auf. Leg den dauerhaften Vertrag an die früheste stabile Veröffentlichungsgrenze, nicht in jedes nachgelagerte SELECT. Quelle: Microsoft Learn: Copy-Data-Aktivität.

Design

1. Die früheste stabile Typisierungsgrenze wählen

Bevorzuge Bronze (oder die schlanke bereinigte View auf vertrauenswürdigen Shortcuts), sobald der Quellvertrag verstanden ist. In der rohen Landezone zu typisieren, bevor sich die Quelle stabilisiert, friert nur die Unruhe ein. Nur in Gold zu typisieren, schiebt die Mehrdeutigkeit durch jeden vorgelagerten Konsumenten. Wähle die Schicht, in der die Spalte zur Wiederverwendung veröffentlicht wird, und deklariere die Typen dort. Abbildung 1 zeigt diese Grenze als drei Aufgaben.

2. Rituelles CAST in Silver und Gold verbieten

Silver verändert Granularität und wendet Geschäftsregeln an. Gold formt Fakten und Dimensionen für die Nutzung. Keine der beiden sollte CAST(x AS DECIMAL(18,2)) wiederholen, weil jemand nervös war. Nervosität gehört in Tests gegen den Vertrag in Bronze. Wenn Silver CASTen muss, dann weil es eine neue abgeleitete Spalte erzeugt, nicht weil es Bronze misstraut. Abbildung 3 stellt den Fehler mit der Kuscheldecke neben den bevorzugten Weg.

Abbildung 3. Rituelles CAST vervielfacht die Drift. Typisiere einmal in Bronze. Berechne nachgelagert. Lass Casts zur Angleichung bei UNION neben dem UNION stehen und prüf den Rest per Lint.

3. Casts zur Angleichung bei UNION als benannte Ausnahmen erlauben

Zweige von UNION und UNION ALL brauchen angeglichene Typen. Diese Casts sind echtes Engineering. Benenne sie in Kommentaren oder Hilfsfunktionen, lass sie neben dem UNION stehen und kopiere sie nicht "der Einheitlichkeit halber" in jede Select-Liste. Einheitlichkeit ohne UNION ist Rauschen.

4. Gold verantwortet typisierte Unknown-Zeilen, nicht das Neuverhandeln von Typen

Unknown- und Not-applicable-Member brauchen Schlüssel und Literale, die zu den Typen der Beziehungen passen. Das ist Arbeit für Gold. Wer ein string 'unknown' neben einen int64-Schlüssel setzt, bekommt später leere Visuals. Halte die Typisierung der Unknown-Zeilen im selben Vertrag wie die Granularität der Faktentabelle. Abbildung 4 zeigt das beziehungssichere Unknown im Vergleich zum stillen Bruch.

Abbildung 4. Bei Unknown-Membern zeigt sich die Disziplin beim Typisieren. Lass die Schlüsseltypen übereinstimmen. Dokumentiere die Konvention neben der Granularität. Materialisiere neu, wenn sich der Vertrag bewegt.

5. CAST-Rauschen per Lint prüfen

SQLFluff oder vergleichbare Regeln sollten bei verrauschten CAST-Mustern in Silver und Gold fehlschlagen, außer in Dateien auf der Allowlist (UNION-Hilfsfunktionen). Lint schlägt Folklore im Code-Review. Wenn das Team erklären kann, warum ein CAST nötig ist, setz ihn mit Begründung auf die Allowlist. Wenn nicht, lösch ihn.

6. Nach Änderungen am Typvertrag neu materialisieren

Wer Typen in Bronze ändert, ohne die abhängigen Objekte neu aufzubauen, hinterlässt gemischte Generationen im Lake. Plane die Neumaterialisierung als Teil der Typänderung, nicht als überraschenden Incident. Dokumentiere, welche MLVs und Tabellen in welcher Reihenfolge neu aufgebaut werden müssen. Abbildung 4 enthält diese Klausel mit Absicht: Ein halber Refresh ist ein Typfehler mit Verzögerung.

Wie du das Verbot ohne Glaubenskrieg einführst

Fang mit einem Bericht über die CAST-Dichte pro Schicht an. Nimm dir die lautesten Objekte in Gold vor und lösche überflüssige Casts, während du die Gleichheit der Ergebnisse belegst. Führe Lint zuerst im Warnmodus ein und dann im Fehlermodus für neue Änderungen. Schreib nicht jedes Modell in einem PR um. Das Ziel ist eine Ratsche: Neues rituelles CAST kommt nicht mehr dazu, altes rituelles CAST stirbt bei normalen Änderungen. Ergänze die Ratsche um ein kurzes ADR, damit Reviewer etwas anderes zitieren können als Geschmack.

Bei Unknown-Membern zeigt sich die Disziplin

Teams, die rituelles CAST verbieten, stolpern trotzdem über Unknown-Zeilen: Eine Faktentabelle macht einen Left Outer Join auf eine Dimension, jemand ersetzt per Coalesce einen fehlenden Schlüssel durch den string "UNK", und die Beziehung stirbt. Entscheide die Typen von Unknown-Schlüsseln mit demselben Ernst wie numerische Typen. Leg das Unknown-Member mit einem typisierten Schlüssel in die Dimension. Verweise aus den Fakten auf diesen Schlüssel. Dokumentiere die Regel neben der Aussage zur Granularität, damit ein späteres Notebook keine zweite Unknown-Konvention für dieselbe Entität erfindet.

Häufige Fehler

CAST als Kuscheldecke. Jede Schicht "repariert" Typen, keine verantwortet sie. Abbildung 3 zeigt diesen Fehler.

Schlüssel als strings in einer Schicht. Beziehungen und Joins funktionieren nur noch saisonal.

Unknown-Literale mit zufälligen Typen. Semantische Modelle scheitern still. Abbildung 4 zeigt Bruch und Lösung.

Halber Refresh nach Typänderungen. Alte Parquet-Dateien behalten in der Praxis die alten Typen.

Lint optional. Reviewer werden müde, das CAST-Ritual kehrt zurück.

Typisieren in instabilen Rohdaten. Du zementierst das Chaos des Quell-Dumps als Plattformwahrheit.

So übernehmen oder anpassen

So übernehmen

• Veröffentlichte Spalten bekommen ihre endgültigen Typen in Bronze (oder in der dokumentierten frühesten stabilen Schicht).
• Rituelles CAST auf unveränderten physischen Spalten in Silver/Gold ist verboten.
• Casts zur Angleichung bei UNION sind erlaubt und bleiben lokal.
• Literale für Unknown-Zeilen in Gold müssen zu den Typen der Beziehungen passen.
• Lint in CI schlägt bei CAST-Rauschen außerhalb der Allowlists fehl.
• Änderungen am Typvertrag enthalten einen ausdrücklichen Plan zur Neumaterialisierung.

Vor dem Einsatz anpassen

Frühes Typisieren bindet dich früher an das Verständnis der Quelle. Spätes Typisieren bindet jeden Konsumenten länger an Mehrdeutigkeit. Falsch-positive Lint-Treffer brauchen einen Prozess für die Allowlist, sonst umgehen die Leute CI. Neumaterialisierung kostet Kapazität. Wer sie auslässt, bezahlt mit Incidents. Abgeleitete Spalten werden weiterhin CASTen. Die Regel betrifft das rituelle erneute Typisieren desselben physischen Felds, nicht ein Verbot von SQL.

Wichtigste Quellen: die Doku zu Datentypen in Spark SQL und die Hinweise zur Medallion-Architektur im Fabric Lakehouse auf Microsoft Learn. Kombiniere sie mit einem Regelwerk für Lint im Repo, damit der Vertrag durchsetzbar ist.

Fazit

Wenn jede Schicht dieselbe Spalte neu typisiert, hast du kein Typsystem. Du hast eine Gewohnheit.

Einmal früh typisieren. Nachgelagert berechnen. Das Ritual per Lint abschaffen. Neu materialisieren, wenn sich der Vertrag bewegt. Die Plattform wird ruhiger, und die leeren Visuals werden seltener.

Verwandte Notizen

• CI-Gates: Was sicherst du in Azure DevSecOps Pipelines wirklich ab? (Lint-Regeln den Build in CI scheitern lassen)