Databricks Lakehouse: 40 % weniger Vorbereitungsaufwand durch konsolidierte Sendungsdaten

In der Ausgangslage griff jede Auswertung direkt auf die einzelnen Quellsysteme zu. Analysten zogen sich die Daten selbst aus Storage-Pfaden, Salesforce, Snowflake, SAP, Teradata und den übrigen Systemen zusammen, weil das der schnellste Weg war und die Prozesse historisch so gewachsen waren. Weil dabei jeder seine eigene Sicht auf die Daten baute, führten zwei Auswertungen zur selben Frage schnell zu unterschiedlichen Ergebnissen. Dieselbe Aufbereitung entstand mehrfach in leicht abgewandelten Workflows, und ein großer Teil der Arbeit war manuelles Zusammensuchen, Verbinden und Prüfen, bevor überhaupt eine Analyse begann.

Damit fiel eine ganze Klasse von Governance-Funktionen weg: feingranulare Zugriffskontrolle, Lineage, Katalog-Discovery, zentrales Auditing, Tagging, Data Sharing, Data-Quality-Monitoring. Wer welchen Datensatz warum ansah, war im Zweifel nicht rekonstruierbar. Ein Konzern in dieser Größenordnung kann sich das dauerhaft nicht leisten, weder regulatorisch noch operativ.

Zusätzlich lagen die eigentlichen Quellen verteilt: strukturierte Sendungsdaten in Azure Blob und ADLS, Kunden- und Vertriebsdaten in Salesforce, große historische Bestände in Snowflake, betriebswirtschaftliche Daten in SAP R/3 und S/4HANA, Data-Warehouse-Bestände in Teradata, weitere operative Systeme über REST-APIs sowie Fachbereichslisten als Excel-Dateien auf SMB-Shares und SharePoint.

Die Daten kamen teils strukturiert als Tabellen und Exporte, teils semistrukturiert als JSON, verschachtelte API-Antworten oder Excel-Dateien an. Genau diese Mischung sprach früh für Delta als gemeinsames Speicherformat. Vorher bedeutete jede neue Fragestellung manuelle Vorarbeit: Wo liegt die richtige Quelle? In welchem Format kommt sie? Wer hat Zugriff? Welche Logik wurde bereits in welchem System umgesetzt?

Für Analysten war das ein echter Produktivitätsverlust. Bevor eine Analyse starten konnte, mussten Quellen gesucht, Formate verstanden, Exporte geprüft und Daten manuell zusammengeführt werden. Durch einheitliche Datenablage, wiederverwendbare Pipelines und zentrale Zugriffsschichten konnte der manuelle Vorbereitungsaufwand in den betrachteten Analyseprozessen um bis zu 40 % reduziert werden. Aus verteilter Datenbeschaffung über mehrere Systeme wurde ein standardisierter Zugriff auf kuratierte Delta-Tabellen.

Die technische Ausgangslage ließ sich in vier Problemzonen zerlegen: fehlende Governance auf existierenden Datenbeständen, verteilte Quellsysteme ohne einheitlichen Integrationsweg, ein Datenmodell, das aus einzelnen Tabellen bestand und keine verbundenen Datenprodukte ergab, und schließlich Konsumenten außerhalb von Databricks, die trotz vorhandener Reporting-Daten außen vor blieben.

Jede dieser Baustellen ließe sich einzeln lösen. Zusammen ergeben sie das Muster, das große Konzerne kennen: An jeder Stelle funktioniert etwas, aber niemand kann zuverlässig sagen, welche Zahl aus welcher Quelle gerade die aktuelle ist. Und weil produktive Reports gleichzeitig weiterlaufen mussten, konnte die Umstellung nicht in einem Rutsch passieren. Der Weg musste rückwärtskompatibel sein: Alte Zugriffe blieben so lange möglich, bis der neue Weg produktiv war und geprüft wurde.

Der gemeinsame Zuschnitt mit ruhrdot: vier abgegrenzte Workstreams, die dasselbe Zielbild ansteuern. Unity Catalog als einzige Zugriffsschicht, Delta Lake als Speicherformat, das Lakehouse als Distributionsknoten.

Die Reihenfolge war kein Zufall. Ohne Unity Catalog als Zugriffsschicht wäre jede nachgelagerte Konsolidierung erneut über Storage-Pfade gelaufen und hätte das Problem reproduziert. Also stand die Governance-Anbindung am Anfang: existierende Bestände als Managed Tables in Unity Catalog registrieren, Zugriffe über den Katalog regeln, Lineage und Auditing aktivieren.

Nach der Stabilisierung der Basis konnten weitere Quellen deutlich schneller angebunden werden: Salesforce, SAP R/3 und S/4HANA, Teradata, Snowflake, operative REST-APIs sowie Excel-Dateien aus SMB-Shares und SharePoint.

Statt jede Quelle einzeln für neue Analysen vorzubereiten, wurden die Daten über standardisierte Ingestion-Pfade in kuratierte Delta-Tabellen überführt und zentral über Unity Catalog verwaltet. Damit entstand ein einheitlicher Zugriff auf sehr unterschiedliche Datenbestände: Tabellen, API-Daten, historische Warehouse-Bestände und Fachbereichsdateien.

Das Datenmodell setzte darauf auf und folgt der Medallion-Architektur: Bronze für die Rohdaten je Quelle, Silver für bereinigte und konformierte Stände, Gold für das konsumierbare Modell. Im Gold-Layer entsteht ein Star-Schema auf Sendungsebene, dessen Dimensionen aus den verschiedenen Quellsystemen gespeist werden: Kunden- und Vertriebsdaten aus Salesforce, Organisations- und Stammdaten aus SAP, historische Bezüge aus Teradata und Snowflake, operative Merkmale über die REST-APIs. Der Golden Record auf Sendungsebene bildet die kuratierte Faktengrundlage dieses Schemas. Er bündelt die kuratierte Version der am häufigsten genutzten geschäftskritischen Attribute in einer Delta-Tabelle, mit standardisierter Join-Logik, Deduplizierungsregeln und Business-Transformationen. Einmal umgesetzt, mehrfach nutzbar.