OneLake Shortcuts: Sollten Shortcuts nur in Bronze bleiben?

Medallion-Diagramme verleiten Teams immer noch dazu, eine physische Bronze-Kopie von allem aus der Quelle zu laden. Wenn die Quelldomäne bereits kuratiertes Delta in OneLake veröffentlicht, ist diese Kopie keine Vorsicht. Sie ist ein zweites Warehouse mit einem freundlicheren Namen.

Bronze kann ein Vertrag aus Shortcuts und schlanken Clean-Views sein. Die Verantwortung bleibt beim Herausgeber. Die Aktualität folgt der Quelle. Deine CI/CD-Liste wird zur Menge der Shortcuts, nicht zu einem Schattenkatalog geklonter Tabellen.

Abbildung 1. Bronze als Shortcut-Vertrag. Verweise auf kuratiertes Delta. Erfinde kein zweites Warehouse aus Klonen.

Kontext und Rahmenbedingung

Ein typischer Fehler: Bronze sieht beschäftigt aus und lügt trotzdem über die Verantwortung. Pipelines kopieren über Nacht Silver und Gold aus benachbarten Domänen. Die Rufbereitschaft verantwortet die Kopie. Niemand verantwortet die Abweichung, wenn der Herausgeber einen Key ändert.

Physisches Laden zählt weiterhin für Rohdateien, CDC-Dumps und Systeme außerhalb von OneLake. Es zählt nicht für "dieser Delta-Tabelle nebenan vertrauen wir schon". Shortcuts plus schlanke Clean-Views schlagen Kopieren und dann Bereinigen bei Kosten, Aktualität und der Klarheit darüber, wer eine kaputte Granularität repariert. Verwaiste Clean-Views ohne Shortcut dahinter sind Fiktion. Lösche sie oder gib ihnen eine Quelle.

Abbildung 2 zeigt die Oberfläche aus Learn, mit der du einen Shortcut zu einem anderen Speicherort anlegst. Die Plattform hat die Bytes bereits. Ein Zeiger ist besser als ein nächtlicher Klon.

Abbildung 2. Bronze kann eine Schicht aus Zeigern sein. Nimm lieber OneLake Shortcuts, statt Bytes zu kopieren, die die Plattform bereits hat. Quelle: Microsoft Learn: OneLake Shortcuts.

Design

1. Externe Rohdaten von internen kuratierten Daten trennen

In einem Wort stecken zwei Bronze-Geschichten. Externe Rohdaten müssen geladen und registriert werden: Dateien, Extrakte, API-Dumps. Interne kuratierte Daten sind das veröffentlichte Delta einer anderen Domäne. Behandle die beiden in Doku und Pipelines unterschiedlich. Die zweite Geschichte besteht aus Shortcuts, nicht aus Spark-Schreibvorgängen, die das Silver von jemand anderem nachspielen.

Abbildung 3 zeigt die Gabelung, die Teams davon abhält, jede Tabelle aus der Quelle wie einen Extrakt zu behandeln, der noch einmal geladen werden muss.

Abbildung 3. Zwei Bronze-Geschichten. Physisches Laden für externe Quellen und Quellen außerhalb von OneLake. Shortcuts für kuratiertes Delta nebenan, dem du schon vertraust.

2. Die Menge der Shortcuts ist der Bronze-Vertrag

Liste jeden Shortcut-Pfad, den Ziel-Workspace oder das Ziel-Lakehouse und die erwartete Granularität im Repo auf, so wie du API-Verträge auflistest. Bei Beförderung und Review sollte die Frage lauten, ob sich die Menge der Shortcuts geändert hat, nicht ob ein Kopierjob grün gelaufen ist. Wenn ein Herausgeber eine Tabelle umbenennt, bricht der Vertrag an einer Stelle, die du finden kannst.

3. Schlanke Clean-Views, keine zweite Transformationsschicht

Clean-Views auf Shortcuts übernehmen Umbenennungen, kleine Typanpassungen und die Auswahl von Spalten für Silver weiter unten. Sie sollten kein paralleles Medallion werden. Wenn die View aufwendige Geschäftslogik braucht, schmuggelst du Silver in Bronze. Bring diese Diskussion zur Quelle oder verantworte eine echte Silver-Transformation mit Begründung.

4. Verwaiste Clean-Views abschaffen

Eine "bereinigte" oder "transformierte" View ohne Shortcut (oder ohne registrierte Rohdaten) ist eine Tabelle, die jemand erfunden hat, weil gerade ein Notebook offen war. Hänge sie an eine echte Quelle oder lösche sie. Verwaiste Views verwirren Join-Keys, Doku und neue Kolleginnen und Kollegen, die annehmen, dass hinter jedem Bronze-Objekt eine Quelle steht.

Abbildung 4 zeigt die Schranke im Review: Schlankes bleibt, Verkleidetes zieht um, Verwaistes verschwindet.

Abbildung 4. Schlanke Clean-Views bleiben in Bronze, wenn eine Quelle dahintersteht. Verkleidete Clean-Views ziehen in ein benanntes Silver um. Verwaiste werden angebunden oder gelöscht.

5. Join-Keys langweilig halten

Sobald Bronze keine parallelen physischen Tabellen mehr erfindet, bleiben die Keys die Keys des Herausgebers. Dein Silver joint auf dokumentierten Business Keys statt auf "dem Surrogate unserer Kopie, der letzten Dienstag abgedriftet ist". Die Benennung bleibt einfach, wenn du keine Alias-Tabellen für dieselbe Entität pflegst.

6. CI/CD rund um die Shortcut-Karte dokumentieren

Deployment-Notizen sollten Schritte zum Neuanlegen oder Prüfen der Shortcuts enthalten. Ein Lakehouse, das ohne Shortcuts befördert wird, ist ein leeres Versprechen. Verbinde die Karte mit der Verantwortung: Welches Team verantwortet das Ziel-Delta, welches Team die Views der Verbraucher?

Was "schlank" im Review bedeutet

Eine Clean-View, die Spalten umbenennt, Typen castet, die schon in der Quelle entschieden wurden, und die Spalten auswählt, die Silver braucht, ist schlank. Eine Clean-View, die einen Geschäftsstatus neu berechnet, Surrogate Keys erfindet oder ohne dokumentierten Grund auf eine bevorzugte Teilmenge filtert, ist Silver im Kostüm. Reviewer sollten verkleidete Clean-Views ablehnen oder verlangen, dass sie in eine benannte Silver-Transformation mit Tests umziehen. Bronze nur mit Shortcuts scheitert, wenn jedes Team Logik in die Clean-Schicht schmuggelt, weil "sie gerade da war".

Häufige Fehler

Kopieren für das gute Gefühl. Aus "vielleicht brauchen wir das offline" wird eine dauerhafte doppelte Pflege. Du zahlst für immer Speicher und Abgleich.

Clean-Views, die die Granularität umschreiben. Aus schlank wird dick. Plötzlich verantwortet Bronze Geschäftsregeln, die der Herausgeber nie unterschrieben hat.

Stilles Neuveröffentlichen von Gold aus der Quelle als lokales Bronze. Verbraucher halten deinen Workspace für das System of Record. Support-Tickets springen ewig hin und her.

Wildwuchs bei Shortcuts ohne Liste. Zwanzig Shortcuts, keine Vertragsdatei, ein kaputter Pfad in Produktion. Dasselbe Fehlerbild wie bei undokumentierten APIs.

Aktualität mit Pipeline-Erfolg verwechseln. Dein Kopierjob kann auf dem Stand von gestern erfolgreich sein, während der Herausgeber heute schon etwas korrigiert hat. Shortcuts erben die Wahrheit, Kopien erfinden Verzögerung.

So übernehmen oder anpassen

So übernehmen

• Bronze besteht aus Shortcuts plus schlanken Clean-Views für Delta, das bereits in OneLake veröffentlicht ist. Physisch geladen wird nur für externe Quellen oder Quellen außerhalb von OneLake.
• Ein versioniertes Inventar der Shortcuts ist der Bronze-Vertrag in Git.
• Kein bereinigtes oder transformiertes Bronze-Objekt ohne registrierte Quelle dahinter.
• Aufwendige Logik gehört nach Silver oder in die Quelle, niemals als stilles Umschreiben in Bronze.
• CI prüft Shortcuts und die Schemas kritischer Views bei jeder Beförderung.
• Neben jedem Eintrag im Shortcut-Inventar steht, wem das Ziel-Delta gehört.

Vor dem Einsatz anpassen

Shortcuts machen dich abhängig von der Verfügbarkeit und den Berechtigungen des Herausgebers. Genau darum geht es. Wenn du für einen regulierten Extrakt einen abgeschotteten Snapshot brauchst, sag das und lade bewusst eine Kopie mit Aufbewahrungsregeln. Tu nicht so, als bräuchte jede Tabelle diese Haltung.

Shortcuts über Workspaces hinweg brauchen saubere Identitäten und Freigaben. Teams, die kein Delta teilen können, sollten auch keine Integration mit nächtlichen Klonen vortäuschen. Repariere das Freigabemodell oder akzeptiere eine formale Schnittstellentabelle, die der Herausgeber verantwortet.

Auch schlanke Views brauchen Tests, wenn sich Typen in der Quelle ändern. Du tauschst die Verzögerung der Kopie gegen die Überwachung des Vertrags. Setze Schema-Prüfungen auf die Shortcut-Ziele, die dir wichtig sind.

Wichtigste Quellen: OneLake Shortcuts, Übersicht über Lakehouse und Lakehouse-Schemas.

Wenn dein Bronze-Ordner ein Museum aus Klonen ist, schrumpfe ihn auf einen Shortcut-Vertrag und schlanke Views. Kosten, Aktualität und Verantwortung werden im selben Zug ehrlich.

Verwandte Notizen

• Fabric PII: Was würdest du beim Laden sensibler Daten tun? (die andere Grenze: was das Lakehouse verlassen darf)