Data Mesh auf Databricks: Guardrails für einen europäischen Energieversorger

Vor dem Projekt war Databricks bereits produktiv im Einsatz. Mehrere Teams nutzten eigene Accounts und Workspaces, bauten Datenstrecken auf und entwickelten Lösungen für Reporting, Anlagenanalytik, Machine Learning und AI. Technisch funktionierte vieles, aber die Nutzung wuchs schneller als das gemeinsame Betriebsmodell.

Daten aus SAP, SCADA-Systemen und weiteren technischen Quellen wurden an mehreren Stellen parallel integriert. Dadurch entstanden doppelte Aufwände, unterschiedliche Datenstände und lokale Silver-Strukturen, die außerhalb des jeweiligen Teams nur schwer wiederverwendbar waren. Was für einzelne Use Cases funktionierte, wurde auf Plattformebene zunehmend unübersichtlich.

Auch Governance und Kostensteuerung waren verteilt. Jeder Workspace folgte eigenen Standards für Compute, Jobs, Tagging, Berechtigungen und Deployments. Cluster und Warehouses liefen teilweise länger oder größer als nötig, fehlschlagende Jobs wurden nicht immer zentral sichtbar, und Kosten ließen sich nicht durchgängig einem Team, Use Case oder Datenprodukt zuordnen.

Für die Organisation wurde damit nicht Databricks selbst zur Herausforderung, sondern der skalierte Betrieb: Wie lassen sich Wind-Erträge, Anlagen-Performance, Reporting und ML-Vorhersagen auf einer gemeinsamen Plattform betreiben, ohne dass Kosten, Governance und Datenprodukte je Team auseinanderlaufen?

Die Zielrichtung war klar: Daten aus SAP, SCADA-Systemen und weiteren technischen Quellen sollten nicht mehr mehrfach je Team angebunden werden. Stattdessen sollte eine zentrale Plattform die Daten einmal aufnehmen, kuratieren und als standardisierte Silver-Datenprodukte für Reporting, Machine Learning und AI bereitstellen.

Die Herausforderung lag weniger in der Zielarchitektur als im täglichen Betrieb. Viele Nutzer waren neu auf Databricks, gleichzeitig wuchs die Zahl der Workloads, Jobs und Compute-Ressourcen. Ohne gemeinsame Transparenz blieb schwer erkennbar, welche Jobs zu lange laufen, welche Warehouses überdimensioniert sind, welche Cluster ungenutzt bleiben und welche Kosten welchem Team oder Use Case zugeordnet werden müssen.

Dazu kam die Frage nach Durchsetzung im Alltag. Standards für Tagging, Deployments, Job-Betrieb und Compute-Nutzung helfen nur, wenn sie nicht in einer Dokumentation verschwinden. Die Plattform brauchte Guardrails, die Nutzer unterstützen, Fehlentwicklungen früh sichtbar machen und wiederkehrende Probleme automatisch begrenzen.

Gemeinsam mit ruhrdot bewertete die Sparte deshalb konkrete Betriebsszenarien: Wie werden ungenutzte Cluster erkannt? Wann sollen wiederholt fehlschlagende Jobs automatisch gestoppt werden? Wie werden Kosten nach Team, Use Case und Umgebung sichtbar? Und wie werden neue Deployments so standardisiert, dass Teams schnell liefern können, ohne eigene Sonderwege aufzubauen?

Bevor technische Regeln umgesetzt wurden, entstand gemeinsam mit ruhrdot ein klares Betriebsmodell für die zentrale Databricks-Plattform. Im Mittelpunkt standen drei Fragen: Wie bekommt das Plattformteam Transparenz über Nutzung, Kosten und Stabilität? Welche Standards müssen automatisiert durchgesetzt werden, damit sie im Alltag wirken? Und wie werden neue Datenprodukte einheitlich ausgeliefert?

Daraus entstand ein Guardrail-Ansatz auf drei Ebenen. Monitoring macht sichtbar, welche SQL Warehouses, Cluster, Jobs und Apps aktiv sind, wie stabil sie laufen und welche Kosten je Team oder Workload entstehen. Enforcement begrenzt wiederkehrende Probleme automatisch, etwa ungetaggte Ressourcen, dauerhaft fehlschlagende Jobs oder nicht mehr genutzte Compute-Umgebungen. Databricks Asset Bundles wurden als Standard für Deployments etabliert, damit Jobs, Apps und Dashboards über Azure DevOps nach einem einheitlichen Muster ausgeliefert werden.

Wichtig war dabei: Die Guardrails sollten Teams nicht ausbremsen, sondern Orientierung geben. Neue Nutzer bekommen ein vorbereitetes Muster für Entwicklung, Deployment und Betrieb. Das Plattformteam muss Regeln nicht manuell nachhalten, sondern steuert über Dashboards, Alerts und automatisierte Maßnahmen.

Enablement lief von Beginn an mit. Die Plattform-Maintainer wurden befähigt, Templates weiterzuentwickeln, Deployment-Pipelines zu pflegen und neue Teams an die Standards heranzuführen. So bleibt der Plattformbetrieb nicht von externer Unterstützung abhängig, sondern kann intern weiter skaliert werden.