Lakehouse-Design: Ein Lakehouse mit Schemas oder viele Lakehouses?

Die Medallion-Architektur fragt, wo Bronze, Silver und Gold liegen. In Fabric kannst du das mit vielen Lakehouses beantworten oder mit Schemas in einem Lakehouse.

Diese Wahl sickert in Shortcuts, SQL endpoints, Notebooks, CI/CD und darin, wie schmerzhaft spätere Umbenennungen werden. Es ist keine Vorliebe für Ordner. Es ist eine Entscheidung über die Topologie.

Abbildung 1. Die Verpackung folgt der Verantwortung. Viele Lakehouses kaufen Isolation auf Kosten von Verbindungen. Ein Lakehouse mit Schemas kauft weniger Verbindungen auf Kosten von Disziplin bei der Benennung.

Kontext und Rahmenbedingung

Teams teilen Lakehouses auf, damit es sauber ist, und ertrinken dann in Verbindungszeichenfolgen. Andere behalten ein Lakehouse ohne Schemas und sehen zu, wie es zur Rumpelkammer wird, in der Bronze und Gold aus Gewohnheit gemischt sind. Beides scheitert aus unterschiedlichen Gründen. Die richtige Antwort hängt von Verantwortung und release trains ab, nicht davon, welcher Screenshot im Workshop aufgeräumt aussah.

Zwei Topologien dominieren:

Viele Lakehouses. Klarer Blast Radius pro Domäne. Leichtere gedankliche Trennung. Mehr Artefakte zum Bereitstellen, mehr Endpoints zum Binden, mehr Fehler der Art "In welchem Lakehouse bin ich gerade?" in Notebooks. Gut, wenn die Grenzen von Verantwortung oder Sensibilität echt sind.

Ein Lakehouse mit Schemas. Medallion als Schemas (bronze_*, silver_*, gold_* oder Schemas zuerst nach Domäne mit Schichtpräfixen). Weniger Verbindungen. Größerer Bedarf an Disziplin bei der Benennung. Die Aktivierung von Schemas ist eine Eigenschaft, die beim Anlegen festgelegt wird. Erst nach dem Anlegen des Lakehouse zu merken, dass du Schemas gebraucht hättest, ist eine teure Überraschung.

Keine der beiden ist abstrakt gesehen "nativer für Fabric". Fabric unterstützt beide. Deine Fehlerbilder entscheiden, welche du betreiben kannst.

Abbildung 2 zeigt die Oberfläche zum Anlegen, auf der über die Schemas entschieden wird. Abbildung 3 zeigt Schemas in einem Lakehouse, sobald diese Entscheidung beim Anlegen gefallen ist.

Abbildung 2. Anlegen eines Lakehouse in Microsoft Fabric. Die Aktivierung von Schemas wird hier gewählt, nicht später. Quelle: Microsoft Learn: lakehouse schemas.

Abbildung 3. Schemas in einem Lakehouse. Disziplin bei der Benennung wird zum Betriebssystem. Quelle: Microsoft Learn: lakehouse schemas.

Design

1. Stabile Identitäten

Anzeigenamen von Workspaces können sich aus Branding-Gründen ändern. GUIDs von Lakehouses und Workspaces sollten nicht leichtfertig neu erzeugt werden. Behandle IDs in Konfiguration und Pipelines als Verträge. Schöne Namen sind Etiketten. Wenn in deinen Deployment-Notizen noch steht "nimm das Lakehouse namens Gold A", bist du eine Umbenennung von einem kaputten Wochenende entfernt.

2. Parametrisierte Ziele

Keine fest eincodierten Namen von Umgebungen oder Quellsystemen in gemeinsam genutzten Notebook-Schnipseln. Eine Sitzung, die an einer Domäne arbeitet, sollte nicht über eine kopierte Zelle das Standard-Lakehouse einer anderen Domäne erben. Übergib Lakehouse-ID, Schema und Umgebung als Parameter oder über ein kleines Konfigurationsmodul, das jeder Job auf dieselbe Weise importiert.

3. Shortcuts und SQL endpoints gehören dazu

Lakehouses zusammenzulegen oder aufzuteilen ändert, wie Shortcuts und Reporting gebunden sind. Plane Zeit für das Neubinden ein, wenn du die Topologie änderst. "Wir haben nur Ordner geändert" stimmt für Semantic Models, Bindungen an Direct Lake oder Nutzer des SQL endpoint selten. Zeichne die Verbindungskarte vor der Migration, nicht nach dem ersten kaputten Bericht. Abbildung 4 ist diese Karte.

Abbildung 4. Notebooks, Shortcuts, SQL endpoints und Modelle in Direct Lake sind an die Identität des Lakehouse gebunden. Änderungen an der Topologie brauchen ein Budget für das Neubinden.

4. Angriffsfläche für CI/CD

Ein Lakehouse kann weniger, aber größere Items bedeuten. Viele Lakehouses können zu lauten Deployments führen, wenn das Tooling unveränderte Artefakte über einen breiten Graphen neu veröffentlicht. Kenne dein Deployment-Werkzeug, bevor du auf eine der beiden Schönheiten optimierst. Zähl, was sich bei einem typischen Merge wirklich ändert, nicht, was ein Topologie-Diagramm verspricht.

5. Passe die Topologie an Zugriff und Verantwortung an

Governance-Werkzeuge und Workspace-Rollen passen je nachdem, wie deine Plattform Domänen trennt, besser zum einen oder zum anderen Modell. Wenn zwei Teams sich kein Ausfallfenster teilen können, sollten sie sich wahrscheinlich auch kein Lakehouse teilen. Schemas bündeln das Risiko, wenn Berechtigungen grob sind. Getrennte Lakehouses verlagern das Risiko in Wildwuchs. Wähle den Schmerz, für den du Leute hast.

Faustregel für die Entscheidung

• Nimm lieber Schemas in einem Lakehouse, wenn sich die Schichten Domäne, Team und release train teilen.
• Nimm lieber getrennte Lakehouses, wenn Domänen, Sensibilität oder Grenzen der Verantwortung echt sind und nicht nur ästhetisch.
• Nimm lieber getrennte Workspaces, wenn Lebenszyklus, Kapazität oder der Kreis der Mitwirkenden wirklich auseinandergehen, und tu nicht so, als würde die Anzahl der Lakehouses allein das lösen.
• Erfinde nie eine dritte Mischform (manche Schichten getrennt, manche zusammengelegt), ohne zuerst die Verbindungskarte zu schreiben. In Mischformen stirbt das Onboarding.

Stell im Design-Review eine unverblümte Frage: Wenn dieser Job an die falsche Stelle schreibt, wer merkt es und wie schnell? Diese Antwort sollte die Verpackung stärker bestimmen als die Vorliebe für aufgeräumte Bäume.

Abbildung 5 zeigt, warum die Aktivierung von Schemas nicht als Aufräum-Ticket aufgeschoben werden kann.

Abbildung 5. Die Aktivierung von Schemas passiert beim Anlegen. Wer sie auslässt und später Schemas braucht, bekommt Kosten für die Neuanlage, wechselnde IDs und kaputte Bindungen auf einmal.

Häufige Fehler

Für jedes Notebook ein neues Lakehouse anlegen. Topologie durch Erschöpfung. Sechs Monate später weiß niemand, welches Lakehouse das maßgebliche ist.

Die Aktivierung von Schemas auslassen und dann Schemas brauchen. Kosten für die Neuanlage und wechselnde IDs. Pipelines, Shortcuts und Dokumentation gehen alle gleichzeitig kaputt.

Lakehouse-Namen in Jobs fest eincodieren. Bricht in dem Moment, in dem du eine Sandbox oder eine zweite Umgebung hinzufügst.

Workspaces im Portal umbenennen, während die Konfiguration noch an alten Anzeigenamen hängt. Nimm lieber IDs. Anzeigenamen sind für Menschen, Verträge sind für Maschinen.

Annehmen, dass Shortcuts einer Zusammenlegung "einfach folgen". Prüfe Semantic Models, SQL endpoints und die Standardwerte in Notebooks. Sie entschuldigen sich nicht, wenn sie auf den alten Ort zeigen.

Mischform ohne Karte. Bronze in einem Lakehouse, Silver und Gold "vorerst" in einem anderen, mit Notebooks, die raten. Die Kosten für das Onboarding wachsen für immer weiter.

So übernehmen oder anpassen

So übernehmen

• Mit oder ohne Schemas, und die Kosten der Neuanlage, falls die Wahl falsch ist.
• Namenskonvention für Schemas gegenüber Lakehouses (zuerst Schicht, zuerst Domäne oder beides mit einer Regel).
• Wie Shortcuts und Direct Lake Semantic Models gebunden sind und wer für das Neubinden verantwortlich ist.
• Was in Notebooks und Pipelines parametrisiert und was fest eincodiert ist.
• Wer für jede Domänengrenze und ihren release train verantwortlich ist.
• Explizite Nicht-Ziele: keine Mischform ohne Verbindungskarte, kein Lakehouse pro Notebook.

Vor dem Einsatz anpassen

Schemas bündeln das Risiko: Ein fehlerhafter Job kann im selben Lakehouse in das falsche Schema schreiben, wenn die Berechtigungen grob sind. Du brauchst klarere Namen, klarere Standardwerte und Tests, die schichtübergreifende Schreibzugriffe früh erkennen.

Getrennte Lakehouses verlagern das Risiko in Wildwuchs und Betriebsaufwand: mehr Verbindungszeichenfolgen, mehr Deploy-Ziele, mehr Vorfälle der Art "Ich habe das falsche Lakehouse angehängt". Die Isolation ist echt, die kognitive Last aber auch.

CI/CD-Werkzeuge bestrafen beide Extreme auf unterschiedliche Weise. Ein dickes Lakehouse kann Diffs schwerer prüfbar machen. Viele dünne Lakehouses können Pipelines geschwätzig machen. Miss das tatsächliche Verhalten deines Deployment-Werkzeugs auf einem produktionsnahen Branch, bevor du die Topologie auf einer Folie für die Betriebsversammlung festschreibst.

Governance und Workspace-Rollen bilden Domänengrenzen vielleicht schon ab. Passe die Topologie daran an, wie du heute schon Zugriff vergibst, sonst kämpfst du für immer mit eigenen Ausnahmen gegen die Plattform.

Wichtigste Quellen: Lakehouse schemas, Lakehouse overview.

Medallion ist eine Bedeutung. Lakehouses und Schemas sind Verpackung. Wähle eine Verpackung, die sowohl dein CI/CD als auch deine Leute überleben.

Verwandte Notizen

• Materialized Lake Views: Können MLVs Silver- und Gold-Tabellen ersetzen? (Warehouse Views in MLVs über Lakehouses mit Schemas hinweg verschieben)