6. März 2026 von Dr. Michael Peichl
Der CFO fragt nach Zahlen – So rechnet sich die Lakehouse-Migration
Der Moment der Wahrheit: Wenn Finanzen nachrechnen
Nach der erfolgreichen technischen Validierung in der Pilotphase rückt die wirtschaftliche Bewertung in den Fokus. In Gremien wie dem Quarterly Business Review werden die variablen Kostenmodelle der Cloud (Consumption-Based Pricing) häufig kritisch den scheinbar niedrigeren Wartungskosten bestehender On-Premises-Systeme gegenübergestellt.
Hier entsteht oft eine Diskrepanz in der Bewertung: Während die IT-Leitung mit technischer Skalierbarkeit argumentiert, benötigt das Finanzmanagement Planungssicherheit. Die Herausforderung liegt im strukturellen Vergleich unterschiedlicher Kostenarten:
Klassische On-Premises-Systeme basieren auf Investitionsausgaben (CapEx), die häufig bereits abgeschrieben sind. Moderne Cloud-Plattformen hingegen erzeugen operative Ausgaben (OpEx), die mit der Nutzung skalieren. Um eine fundierte Vergleichbarkeit herzustellen, muss die Betrachtung daher von einer reinen Lizenzkostenrechnung auf eine ganzheitliche Total Cost of Ownership (TCO) erweitert werden.
Ganzheitliche Kostenanalyse: Identifikation verdeckter Kostentreiber
Bei etablierten Data-Warehouse-Systemen (wie Teradata, Oracle oder Netezza) beschränkt sich die Kostenwahrnehmung häufig auf die expliziten Lizenz- und Wartungsgebühren. Eine Vollkostenrechnung offenbart jedoch weitere wesentliche Kostentreiber, die die operative Marge belasten.
Den signifikantesten Block bilden in der Regel die operativen Personalkosten. Hochqualifizierte Data Engineers binden erfahrungsgemäß bis zu 60 % ihrer Arbeitszeit in Erhaltungsmaßnahmen („Maintenance & Operations“), wie etwa Patch-Management oder manuelles Performance-Tuning, anstatt in wertschöpfende Entwicklungstätigkeiten zu investieren.
Hinzu treten Opportunitätskosten durch eingeschränkte Agilität sowie finanzielle Risiken durch Systemausfälle (Downtime), die bei produktionskritischen Reportings hohe stündliche Ausfallkosten verursachen können. Ein weiterer Faktor ist der Vendor Lock-in, der Unternehmen in eine Abhängigkeit von der Preispolitik proprietärer Anbieter bringt.
Die folgende Kalkulation quantifiziert diese Faktoren anhand eines typischen mittelständischen Szenarios (Basis: 5 TB DWH, 50 BI-User, gemischter Workload):
| Kostenposition | Legacy DWH (On-Prem) | Databricks Lakehouse |
| Lizenzen / DBUs | 200.000 € / Jahr | 180.000 € / Jahr |
| Infrastruktur-Personal (Wartung) | 360.000 € (4 FTEs) | 90.000 € - 180.000 € (1-2 FTEs) |
| Storage & Hardware | 50.000 € (SAN/Server) | 12.000 € (Cloud Storage) |
| Downtime-Risiko | 100.000 € (2 Ausfälle) | 10.000 € (99.9% SLA) |
| Vendor Lock-in Penalty | 30.000 € (Preiserhöhung) | 0 € (Open Formats) |
| GESAMT TCO pro Jahr | ~740.000 € | ~292.000 € - 382.000 € |
Fußnote: Basierend auf Erfahrungswerten aus vielfältigen DWH-Modernisierungen bei adesso und Industrie-Benchmarks (Hitachi Vantara White Paper, 2024).
Das Ergebnis ist eindeutig: Mit der Migration senken wir die TCO um ca. 50-60 %. Selbst bei initialen Migrationskosten amortisiert sich der Business Case oft in unter 12 Monaten (Payback Period).
FinOps: Operative Kostentransparenz und Steuerung
Während die TCO-Betrachtung die strategische Budgetplanung fundiert, erfordert der operative Betrieb effektive Mechanismen zur Vermeidung ungeplanter Kostensteigerungen. Eine zentrale Herausforderung von Cloud-Modellen war in der Vergangenheit oft die mangelnde Granularität der Abrechnungsdaten.
Die Databricks-Plattform adressiert diese Anforderung durch die Integration von System Tables im Unity Catalog. Abrechnungs- und Nutzungsdaten werden hierbei als standardisierte Tabellen bereitgestellt und sind somit via SQL direkt abfragbar. Dies ermöglicht es, exakte Verbrauchsdaten mit aktuellen Preislisten zu verknüpfen, anstatt sich auf pauschale Hochrechnungen zu verlassen.
Die folgende SQL-Abfrage demonstriert, wie sich die primären Kostentreiber auf Job-Ebene präzise identifizieren lassen:
-- Top 10 teuerste Jobs der letzten 30 Tage (mit exaktem Pricing-Join)
SELECT
u.usage_metadata.job_id,
u.usage_metadata.job_name,
SUM(u.usage_quantity) AS total_dbus,
-- Berechnung der Kosten durch Multiplikation von Menge und Listenpreis
SUM(u.usage_quantity * p.pricing.default) AS estimated_cost
FROM system.billing.usage u
-- Join mit der Preistabelle, um den Preis zum Zeitpunkt der Nutzung zu finden
JOIN system.billing.list_prices p
ON u.cloud = p.cloud
AND u.sku_name = p.sku_name
AND u.usage_start_time >= p.price_start_time
AND (p.price_end_time IS NULL OR u.usage_end_time < p.price_end_time)
WHERE u.usage_date >= CURRENT_DATE() - INTERVAL 30 DAY
-- 'billing_origin_product' um Job-Kosten zu filtern
AND u.billing_origin_product = 'JOBS'
GROUP BY ALL
ORDER BY estimated_cost DESC
LIMIT 10;
Sobald wir diese Daten auf ein Dashboard legen und den Fachbereichen zeigen (Chargeback), ändert sich das Verhalten fundamental. Wenn das Marketing sieht, dass der tägliche Report 50 € kostet, wird plötzlich hinterfragt: „Brauchen wir den wirklich täglich?“ So wird Kosteneffizienz zur Teamsportart.
Kosteneffizienz durch technologische Innovation: Warum höhere Unit-Preise die Gesamtkosten senken
In verbrauchsabhängigen Cloud-Modellen korreliert Laufzeit direkt mit Kosten. Technologien, die Leerlaufzeiten eliminieren oder die Verarbeitungsgeschwindigkeit erhöhen, senken somit unmittelbar die Rechnung – selbst wenn der Preis pro Recheneinheit (DBU) nominal höher liegt.
Kostenreduktion durch Serverless Compute: Nutzung statt Bereitstellung
Klassische Cluster-Architekturen erfordern häufig die permanente Bereitstellung von Ressourcen („Provisioned Capacity“), um Wartezeiten für Nutzer zu vermeiden. Man bezahlt hierbei primär für die Verfügbarkeit, nicht für die effektive Rechenleistung.
Serverless SQL optimiert dieses Modell: Compute-Ressourcen starten in Sekundenbruchteilen und skalieren bei Inaktivität sofort auf Null.
- Szenario: Ein klassischer Cluster, der für eine hohe Verfügbarkeit den ganzen Tag läuft, verursacht bei Standard-Größen Kosten von ca. 67 $ pro Tag – oft weitgehend im Leerlauf.
- Serverless: Ein Serverless Warehouse, das nur die effektiven 2 Stunden Rechenzeit aktiv ist, kostet trotz eines höheren DBU-Preises nur ca. 14 $ pro Tag.
Dies entspricht einer Einsparung von ca. 80 %, die rein durch die Eliminierung von unproduktiven Leerlaufkosten (Idle Time) realisiert wird.
Predictive Optimization: Automatisierung von DBA-Aufgaben
In traditionellen Umgebungen erfordert die Performance-Optimierung (Indizierung, Statistik-Aktualisierung, Speicherbereinigung) hohen manuellen Aufwand durch Datenbank-Administratoren.
Im Unity Catalog übernimmt Predictive Optimization diese Aufgaben automatisiert. Das System analysiert kontinuierlich Abfragemuster und optimiert darauf basierend das physikalische Datenlayout.
Der wirtschaftliche Effekt ist zweifach:
- 1. Reduzierter Compute-Verbrauch: Abfragen laufen durch das optimierte Layout 3-5x schneller, was die berechnete Laufzeit direkt senkt.
- 2. Reduzierter Administrationsaufwand: Wartungsprozesse erfolgen autonom, ohne dass Engineering-Ressourcen gebunden werden.
Real-World Proof: Von 70% Einsparung bis 300% ROI
Die Zahlen aus der Praxis sprechen eine klare Sprache – und zwar branchenübergreifend:
- Sovrn, ein amerikanischer AdTech-Anbieter, senkte durch die Migration von AWS EMR zu Databricks die Infrastrukturkosten um 70% ($1,2 Millionen Einsparung) bei gleichzeitig 52% höherer Produktivität im Data Engineering Team. Das Team konnte sich endlich auf Wertschöpfung konzentrieren statt auf Cluster-Wartung (https://www.databricks.com/customers/sovrn).
Quelle: Sovrn Costumer Story https://www.databricks.com/customers/sovrn
- Der Telekommunikationsriese AT&T (https://www.microsoft.com/en/customers/story/20384-att-azure-databricks) stand vor der klassischen Enterprise-Herausforderung: Ein über Jahre gewachsenes On-Premises Data Warehouse mit über 80 verschiedenen Schemas, hohen Wartungskosten und fehlender Agilität. Durch die Migration auf das Databricks Lakehouse erzielte AT&T über einen Zeitraum von 5 Jahren einen ROI von 300%. Gleichzeitig wurde der Data Footprint radikal verschlankt, was die Betriebskomplexität massiv reduzierte und neue Use Cases wie Fraud Detection mit Machine Learning ermöglichte.
- Besonders bemerkenswert für den deutschen Markt: Ströer (https://www.databricks.com/blog/zero-millions-savings-stroer-transforms-advertising-success-databricks), der Out-of-Home Advertising-Marktführer, realisierte 3,5 Millionen Euro jährliche Brutto-Budgeteinsparungen durch Near Real-Time Campaign Optimization – bei gleichzeitig 25% kürzeren Report-Erstellungszeiten. Das deutsche Unternehmen beweist: Die Modernisierung finanziert sich nicht nur selbst, sie ermöglicht echte Wettbewerbsvorteile im hart umkämpften europäischen Werbemarkt.
Quelle: From Zero to Millions in Savings: Ströer Transforms Advertising Success with Databricks | Databricks Blog
Das Muster ist eindeutig: Die Migration amortisiert sich durch Effizienzgewinne in der Regel innerhalb von 12 bis 18 Monaten. Darüber hinaus schafft sie die technologische Voraussetzung für Use Cases, die auf Legacy-Systemen nicht realisierbar waren – etwa die Entwicklung autonomer KI-Assistenten.
Risikominimierung bei der Code-Migration: Der Lakebridge-Ansatz
Die Migration historisch gewachsener Business-Logik stellt oft das größte Investitionsrisiko bei DWH-Ablösungen dar. Wir nutzen hier Databricks Lakebridge (Databricks Lakebridge | Fast, Predictable Migrations to Databricks | Databricks), eine spezialisierte Lösung aus den Databricks Labs, die den Migrationszyklus durch Automatisierung beschleunigt und planbar macht. Der Prozess gliedert sich in drei Phasen:
1. Assessment & Profiling (Profiler & Analyzer):
Bevor Code migriert wird, schafft der Profiler Transparenz. Er verbindet sich mit dem Altsystem, um Metadaten und Nutzungsstatistiken zu extrahieren. Darauf aufbauend prüft der Analyzer die Code-Basis auf Komplexität und Abhängigkeiten. Ein entscheidender Vorteil: Das Tool identifiziert veraltete oder redundante Reports („Dead Code“), die oft 30–50 % der Altsysteme ausmachen. Diese werden vor der Migration ausgesortiert, um die neue Plattform schlank zu halten.
2. Automatisierte Konvertierung (Converter):
Der Converter übernimmt die Übersetzung proprietärer Dialekte (wie Teradata BTEQ, Oracle PL/SQL oder SAS) in performantes Databricks SQL oder PySpark. Lakebridge setzt hierbei auf einen hybriden Ansatz: Bewährte regelbasierte Transpiler sorgen für deterministische Genauigkeit bei der Struktur, während KI-gestützte Komponenten zunehmend komplexe Muster erkennen und übersetzen. Dies reduziert den manuellen Rewrite-Aufwand massiv.
3. Daten-Validierung (Reconciler):
Vertrauen in das neue System entsteht nur durch verifizierte Zahlen. Der Reconciler automatisiert den Abgleich zwischen Quelle und Ziel. Er führt Validierungen auf Zeilenebene oder via Aggregat-Vergleichen (Hash/Summen) durch, um sicherzustellen, dass die migrierten Pipelines exakt dieselben Ergebnisse liefern wie das Altsystem. Technologien wie Lakehouse Federation können diesen Prozess beschleunigen, indem sie direkte Vergleiche ermöglichen, ohne Daten physisch verschieben zu müssen.
Quelle: Databricks Lakebridge | Fast, Predictable Migrations to Databricks | Databricks
Operational Excellence: Risikominimierung durch Databricks Asset Bundles (DABs)
Ein wesentlicher Hebel zur Kosteneffizienz ist die Minimierung operativer Risiken und manueller Fehlerquellen. Mit Databricks Asset Bundles (What are Databricks Asset Bundles? | Databricks on AWS)(DABs) etabliert die Plattform professionelle Software-Engineering-Standards im Datenumfeld.
Dabei wird die gesamte Projektinfrastruktur – von ETL-Jobs über Delta Live Tables Pipelines bis hin zu ML-Modellen – deklarativ als Code („Infrastructure as Code“) in YAML-Konfigurationen definiert und in Versionskontrollsystemen (wie Git) verwaltet.
Der wirtschaftliche Vorteil:
- Qualitätssicherung: Änderungen an der Produktivumgebung durchlaufen zwingend automatisierte CI/CD-Pipelines (Tests, Lints) und Code-Reviews.
- Schnellere Recovery: Sollte dennoch ein Fehler auftreten, ermöglicht der code-basierte Ansatz einen sofortigen, automatisierten Rollback auf den letzten stabilen Zustand.
Dies reduziert kostspielige Ausfallzeiten (Downtime) signifikant und transformiert den Plattformbetrieb von manueller „Feuerwehrarbeit“ hin zu einem resilienten, auditierbaren Prozess.
Quelle: CI/CD pipeline with Databricks Asset Bundles https://docs.databricks.com/aws/en/dev-tools/bundles/
Fazit: Modernisierung als wirtschaftlicher Hebel
Eine isolierte Betrachtung monatlicher Cloud-Abrechnungen greift zu kurz. Während Legacy-Systeme häufig durch intransparente Fixkostenblöcke und hohe Wartungsaufwände geprägt sind, bietet die Databricks-Plattform durch granulare Steuerbarkeit Kostentransparenz. Die Modernisierung der Dateninfrastruktur ist daher nicht nur technologisch motiviert, sondern stellt eine betriebswirtschaftliche Notwendigkeit zur Sicherung der Wettbewerbsfähigkeit dar.
Durch den Einsatz technischer Optimierungsmechanismen (Serverless Compute, Predictive Optimization), organisatorischer Transparenz (System Tables) und effizienter Migrationsverfahren (Lakebridge) lassen sich die Betriebskosten (OpEx) signifikant senken. Die hierdurch freigesetzten Budgets fließen nicht mehr in den Erhalt des Status Quo, sondern stehen für wertschöpfende Innovationen zur Verfügung.