Databricks Lakehouse für die Verlagsgruppe: von Excel-Silos zur Single Source of Truth

Ein Data Lakehouse ist eine Datenarchitektur, die den günstigen, flexiblen Speicher eines Data Lake mit der Struktur, Governance und Zuverlässigkeit eines Data Warehouse verbindet. Rohdaten, aufbereitete Daten und business-fertige Kennzahlen liegen auf einer Plattform, auf der Reporting, Analytics und KI gemeinsam arbeiten. Damit entfällt das ständige Kopieren von Daten zwischen getrennten Systemen. In diesem Projekt bildet das Lakehouse auf Databricks (Azure) die konzernweite Datenbasis der Verlagsgruppe.

Ein Data Warehouse speichert strukturierte, aufbereitete Daten und ist stark auf Reporting und SQL-Analysen ausgelegt, stößt bei semi- und unstrukturierten Quellen aber an Grenzen. Ein Data Lake nimmt beliebige Rohdaten kostengünstig auf, bringt aber von sich aus weniger Struktur und Governance mit. Ein Data Lakehouse verbindet beides: offener, günstiger Speicher plus Governance, Datenqualität und BI-Tauglichkeit. Für die Verlagsgruppe war genau diese Kombination ausschlaggebend, weil die Quellen von Datenbanken bis zu Datei-Feeds und API-Antworten reichen.

Ein Warehouse je Bereich hätte das Ausgangsproblem fortgeschrieben, das die Verlagsgruppe lösen wollte: viele Silos, keine gemeinsame Wahrheit. Ein zentrales Lakehouse mit Multi-Workload-Blueprint erlaubt es, jeden Bereich als eigenständigen Workload zu betreiben und trotzdem Governance, konforme Dimensionen und BI-Schicht über die Gruppe hinweg zu teilen. Neue Bereiche übernehmen den Blueprint, ohne eine eigene Architektur aufzubauen.

Jeder Geschäftsbereich wird als eigenständiger, wiederverwendbarer Workload auf derselben Plattform aufgesetzt: eigene Quellsysteme, eigene Fach-Kennzahlen, eigene Berichtsempfänger. Katalog, Zugriffsmodell, Lineage und die BI-Schicht teilen sich alle Workloads. Ein Bereich bleibt fachlich eigenständig, arbeitet aber auf gemeinsamen Standards für Datenqualität, Governance und Betrieb, statt eine separate Insel aufzubauen.

Der erste Workload, Kampagnen- und Abonnement-Analytics, verbindet drei zuvor getrennte Quellsysteme auf einem gemeinsamen Master-Key für den Abonnentenbestand. Angebunden werden sie metadatengetrieben über verschiedene Wege: Datenbank-Quellen per JDBC (unter anderem SQL Server und Sybase ASE), REST-Programmierschnittstellen (REST-APIs) und Datei-Feeds. Kampagnenausgaben, Conversions und Abo-Lebenszyklus laufen so erstmals auf einer gemeinsamen Grundlage zusammen.

Die Medallion-Architektur gliedert Daten in drei Schichten: Bronze für Rohdaten, Silver für bereinigte und angereicherte Daten und Gold für business-nahe, konsumierbare Datensätze. Dieses Modell sorgt für Nachvollziehbarkeit, Datenqualität und klare Verantwortlichkeiten. Jede Schicht hat eine definierte Aufgabe: Bronze konserviert den unveränderten Ursprung, Silver harmonisiert Formate, Schlüssel und Referenzdaten, Gold liefert die fachlich abgestimmten Kennzahlen für Reporting und Analytics.

Unity Catalog ist die zentrale Governance-Schicht von Databricks. Sie regelt an einer Stelle, wer auf welche Daten zugreifen darf (Zugriffsrechte), wem Tabellen und Datenprodukte gehören (Ownership) und woher eine Kennzahl stammt (Lineage). In diesem Projekt ist Unity Catalog das Governance-Rückgrat über alle Workloads hinweg: einheitliche Regeln für die gesamte Verlagsgruppe statt getrennter Rechte je System.

Lakeflow Declarative Pipelines sind der deklarative Ansatz von Databricks, um Datenpipelines zu bauen. Statt jeden Verarbeitungsschritt manuell zu programmieren, wird das gewünschte Ergebnis inklusive Datenqualitäts-Erwartungen beschrieben; die Plattform übernimmt Ausführung, Reihenfolge und Überwachung. Im Projekt werden darüber heterogene Quellen nach demselben Muster angebunden, und Datenqualitätsprüfungen laufen inline in der Pipeline mit.

Databricks Asset Bundles bündeln Code, Pipelines, Jobs und Konfiguration eines Workloads als versionierbares, wiederholbar ausrollbares Paket. Damit wird jeder neue Geschäftsbereich aus demselben Template heraus aufgesetzt, statt jedes Mal von vorn zu konfigurieren. Genau das macht den Blueprint reproduzierbar: Onboarding eines Bereichs heißt, das Bundle mit den bereichsspezifischen Werten auszurollen.

Governance ist kein Nachgedanke, sondern Voraussetzung ab Tag 1. Über Unity Catalog sind Ownership, Zugriffsrechte und Lineage über alle Workloads hinweg definiert. Für Finance und Controlling ist nachvollziehbar, wer welche Kennzahl aus welchem System sehen darf und wie sie entstanden ist. Das trägt die gemeinsame Datenbasis, sobald mehrere Bereiche auf derselben Plattform arbeiten.

Ein neuer Bereich meldet Quellsysteme und fachliche Kennzahlen an. Aus dem bestehenden Blueprint wird ein neuer Workload über Databricks Asset Bundles ausgerollt, inklusive Katalog, Pipeline-Templates und Standard-Zugriffen. Anschließend werden die Quellsysteme über die metadatengetriebene Ingestion angeschlossen und die Silver- und Gold-Modelle bereichsspezifisch ergänzt. Die gemeinsame BI-Schicht und die konformierten Dimensionen werden mitgenutzt.

Nein. Entscheidend ist weniger die Teamgröße als die Ausgangslage: viele Quellsysteme, getrennte Reporting-Strecken und der Bedarf an einer gemeinsamen, geprüften Datenbasis. Der Blueprint und das Enablement sind so angelegt, dass interne Owner ihre Datenprodukte schrittweise selbst übernehmen. Der Aufwand skaliert mit dem Ausbau, ein großes Data-Team ist keine Vorbedingung für den ersten produktiven Workload.

Ein Lakehouse nimmt keine Governance- und Modellierungsarbeit ab, es macht sie nur systematisch. Gemeinsame Master-Keys, saubere Definitionen und klare Ownership müssen erarbeitet werden, sonst entsteht wieder Wildwuchs, nur auf einer Plattform. Für ein sehr kleines, homogenes Reporting reicht oft ein klassisches Warehouse. Der Mehrwert entsteht dort, wo heterogene Quellen, mehrere Bereiche und wachsende Analytics-/KI-Anforderungen zusammenkommen, wie bei dieser Verlagsgruppe.