Unternehmen verlieren heute nicht an fehlenden Daten, sondern an Datenarchitekturen, die mit dem Geschäft nicht mitwachsen. Isolierte Fabrik-Workspaces, historisch gewachsene SSIS-Pipelines und inkonsistente Modellebenen führen zu Betriebskosten, die schneller steigen als der Nutzungswert. In diesem Leitfaden beschreiben wir das Schichtenmodell, mit dem wir Enterprise-Lakehouses auf Databricks, Snowflake und Microsoft Fabric aufbauen – inklusive der Governance-Entscheidungen, die vom ersten Tag getroffen werden müssen. Wie wir dieses Vorgehen in konkreten Projekten anwenden, zeigt unser Cloud Data Engineering & Lakehouse Angebot.
Das Wichtigste in Kürze
- Ein Lakehouse ersetzt nicht den Data Warehouse-Gedanken, sondern vereinigt Rohdaten, modellierte Business-Logik und Verbrauchsschichten auf einer Plattform mit offenen Tabellenformaten (z. B. Delta Lake).
- Skalierbarkeit entsteht durch standardisierte Schichten (Bronze, Silver, Gold) und Infrastructure-as-Code – nicht durch horizontale Sonderlösungen pro Fachbereich.
- Governance (Unity Catalog, dbt-Tests, automatisierte Lineage) ist eine Architekturentscheidung und nachträglich nur mit hohem Aufwand ergänzbar.
- In einem unserer Projekte verkürzte die Migration in ein Azure Lakehouse die ETL-Verarbeitungszeiten um über 80 % – von 2 Stunden auf 15–20 Minuten bei gleichzeitig 30 % niedrigeren Betriebskosten (siehe Carl Zeiss Vision Case Study).
- Konsolidierung isolierter Workspaces in regionale Shared-Hubs senkt Infrastrukturkosten messbar und schafft ein compliant-by-design Fundament für KI-Initiativen.
Vom Data Lake zum Lakehouse: das drei-Schichten-Modell
Ein produktionsreifes Lakehouse folgt bei uns immer demselben Schichtenprinzip. Die Schichten trennen Verantwortlichkeiten so, dass jedes Team unabhängig liefern kann, ohne die Integrität der Gesamtplattform zu gefährden.
Rohdatenschicht (Bronze)
Alle Quelldaten landen unverändert, append-only und vollständig versioniert in der Rohdatenschicht. Delta Lake oder Iceberg machen die Historie abfragbar, ohne dass Legacy-Quellsysteme zusätzlich belastet werden. Diese Schicht ist die Rückversicherung des Unternehmens: Jede Transformation kann reproduziert und korrigiert werden, weil die Ursprungsdaten niemals verändert werden.
Bereinigungs- und Modellierungsschicht (Silver)
In der Silver-Schicht werden Daten dedupliziert, validiert und nach klaren Modellierungsparadigmen strukturiert. Wir setzen hier auf standardisierte Ansätze statt auf frei wachsende Transformationsskripte – im Datenmodellierung Bereich typischerweise Data Vault 2.0 für agile Repositories und Sternschemata für den fachlichen Zugriff. Entscheidend ist: Modellierung ist Engineering, keine Nebentätigkeit.
Verbrauchsschicht (Gold)
Die Gold-Schicht enthält fachlich modellierte, testierte Datasets, die direkt in BI-Tools, Data Science Workloads und KI-Anwendungen einfließen. Sie ist der Vertrag zwischen Plattformteam und Fachbereich: klar definierte Semantik, dokumentierte Aktualisierungsintervalle und automatisierte Qualitätstests bei jeder Pipeline-Ausführung.
Snowflake, Databricks oder Microsoft Fabric?
Die Plattformwahl entscheidet über Jahre. Wir empfehlen eine Bewertung über vier Dimensionen statt über Benchmark-Slogans:
| Dimension | Snowflake | Databricks | Microsoft Fabric |
|---|---|---|---|
| Stärke | Elastisches Warehousing, einfache Kostensteuerung | Offene Lakehouse-Plattform, Data Engineering & ML in einem | BI-getriebene Integration ins Microsoft-Ökosystem |
| Modellierung | SQL-zentriert, Snowpark Python | dbt, PySpark, Delta Live Tables | Fabric-Items, dbt mit Warehouse-/Lakehouse-Zielen |
| Governance | Rollen & Policies im Service-Modell | Unity Catalog als zentraler Katalog | OneLake, Purview-Integration |
| Typisches Szenario | Konsolidierte Analytik, FinOps-Sensibilität | Streaming, ML, Multi-Cloud-Plattformen | Power-BI-lastige Konzerne |
Wichtig ist uns dabei: Die Entscheidung fällt nie isoliert. In einem globalen Migrationsprojekt für den Industrie-Sektor haben wir beispielsweise eine 5-Regionen Hub-and-Spoke Azure-Architektur aufgebaut, in der regionale Databricks-Workspaces über Unity Catalog mandantenfähig verbunden sind – die Plattformwahl ergab sich dort aus Compliance-Anforderungen (DSGVO, US-Regulatorik, China CSL/DSL), nicht aus Features.
Skalierbarkeit in der Praxis
Skalierbarkeit ist kein Größenattribut, sondern das Ergebnis von Standardisierung. Drei Hebel zeigen bei uns die größte Wirkung:
- Infrastructure-as-Code von Tag eins. Gesamte Plattformen entstehen als wiederholbares Terraform, orchestriert über Databricks Asset Bundles. Neue Umgebungen sind damit ein Deployment, kein Projekt.
- Konsolidierung isolierter Insellösungen. Fabrik- und Bereichs-Workspaces wandern in regionale Shared-Hubs mit klaren Namensräumen. Genau dieser Schritt senkte in mehreren Projekten die operativen Cloud-Kosten signifikant.
- Refactoring statt Re-Engineering. Historische T-SQL- und SSIS-Logik wird strukturiert in PySpark- und Spark-SQL-Workflows überführt. Im Projekt für Carl Zeiss Vision führte das zu einer 400 % höheren Systemskalierbarkeit bei reduzierten Betriebskosten.
Governance als Fundament, nicht als Nachtrag
Nachträglich eingeführte Governance scheitert fast immer an der Vielzahl existierender Pipelines. Wir verankern sie deshalb vom ersten Tag:
- Zentraler Katalog: Unity Catalog (oder das äquivalente Plattform-Pendant) strukturiert alle Datenobjekte mit granularen Zugriffskontrollen.
- Tests als Release-Kriterium: dbt-Tests verhindern, dass Qualitätprobleme produktiv gehen.
- Automatisierte Lineage: Nachvollziehbarkeit von der Quelle bis zum Dashboard entsteht als Nebenprodukt der Pipeline, nicht als manuelle Dokumentation.
Wie sich regulatorische Anforderungen systematisch in genau solche Architekturen übersetzen lassen, beschreiben wir im Artikel zur Data Governance im Finanzsektor.
Häufige Fragen zu Lakehouse-Architekturen
Löst ein Lakehouse das klassische Data Warehouse ab?
Ein Lakehouse ersetzt nicht die Modellierungsdiziplin eines Data Warehouses – es modernisiert die darunterliegende Plattform. Rohdaten, History und flexible Workloads profitieren vom offenen Speicher; die fachliche Modellierung nach Sternschema oder Data Vault 2.0 bleibt erforderlich und zieht in die Plattform hinein.
Wie groß muss ein Unternehmen sein, um von einem Lakehouse zu profitieren?
Entscheidend ist nicht die Unternehmensgröße, sondern die Anzahl integrierter Quellsysteme, die Regulatorik-Dichte und der Bedarf an gemeinsamer Datenbasis für BI, ML und KI. Mittelständische Umgebungen mit zehn oder mehr Quellsystemen und wachsenden KI-Plänen profitieren nachweislich.
Wie lange dauert eine Lakehouse-Migration?
Für ein belastbares Fundament (MVP) planen wir realistisch 8–12 Wochen – vom Legacy-Assessment bis zur produktionsbereiten Hub-Struktur. In der beschriebenen globalen Cloud-Migration stand das standardisierte Terraform-MVP nach 8 Wochen. Die vollständige Überführung aller Fachbereiche folgt darauf iterativ.
Welche Rolle spielt die Cloud-Wahl (Azure, AWS, GCP)?
Die Cloud-Wahl folgt häufig vorhandenen Enterprise-Agreements und Residenzanforderungen. Das Schichtenmodell ist bewusst plattformneutral – wir betreiben es auf Azure, GCP und AWS gleichermaßen, wobei sich die Governance-Werkzeuge je nach Plattform unterscheiden.
Fazit
Lakehouse-Architekturen skalieren dann, wenn Schichten, Modellierung und Governance als Einheit geplant werden. Wir konzipieren und implementieren genau solche Plattformen – vom Legacy-Assessment bis zum produktiven Betrieb. Wenn Sie eine ähnliche Transformation planen, vereinbaren Sie ein unverbindliches Erstgespräch.