Blog

Databricks FinOps: Praktische Optimierungsstrategien und Beispiele aus der Praxis

Kacper Glugla

Aktualisiert September 29, 2026
11 Minuten
‌

In der Welt moderner Datenplattformen liegt das Versprechen der Cloud vor allem in grenzenloser Skalierbarkeit und Innovation. Cloud-Plattformen erleichtern die Skalierung von Daten und KI-Workloads; doch dies ist ein zweischneidiges Schwert. Die Freiheit zur Skalierung ist zwar ein großer Vorteil, führt jedoch ohne angemessene Kontrolle leicht zu unzureichend ausgelasteten Rechenressourcen, ineffizienten Workloads, erhöhten Speicherkosten, einer eingeschränkten Kostenzuordnung zwischen den Teams und letztendlich zu überhöhten Ausgaben und Verlusten für das Unternehmen. Das kürzlich von Xebia veranstaltete Webinar „FinOps für die Databricks-Plattform: Operative Effizienz im Zeitalter des Lakehouse“ hat sich genau mit dieser Herausforderung befasst.

Dieser Artikel befasst sich mit praktischen FinOps-Strategien für Databricks, die auf Erkenntnissen und Schlüsselthemen aus dieser Sitzung basieren. Erfahren Sie, wie Sie mithilfe von Databricks-Systemtabellen die Kostentransparenz verbessern, eine proaktive Überwachung implementieren, Rechen- und Speicherressourcen optimieren sowie Möglichkeiten zur Reduzierung unnötiger Cloud-Ausgaben identifizieren können. Außerdem werden wir uns konkrete Optimierungsbeispiele ansehen, beispielsweise wie Sie durch geeignete SQL-Warehouse-Einstellungen eine Rechenoptimierung von 75 % für Streaming-Workflows sowie monatliche Einsparungen von mehr als 30.000 US-Dollar erzielen können.

Von CapEx zu OpEx: Warum der Ansatz zum Cloud-Kostenmanagement von Bedeutung ist

Um zu verstehen, warum das Kostenmanagement so entscheidend ist, wollen wir uns ansehen, was bei der Einführung der Cloud geschah. Zuvor handelte es sich bei den Kosten in erster Linie um Investitionsausgaben (CapEx): der Kauf von Servern, Speichermedien und Racks, was mit hohen Vorabinvestitionen verbunden war. Bei CapEx ließen sich die Kosten mit hoher Genauigkeit vorhersagen, doch beim Umstieg auf die Cloud wird diese Last auf die Cloud-Anbieter verlagert. Das Kostenmodell wandelt sich in Betriebsausgaben (OpEx) um , was bedeutet, dass Sie für das bezahlen, was Sie tatsächlich nutzen – sei es Speicherplatz, Rechenzeit oder Netzwerkressourcen.

Dieser Wandel verändert alles, da er Flexibilität und Experimentierfreudigkeit ermöglicht. Er bringt jedoch eine neue Herausforderung mit sich: Ohne die physischen Einschränkungen durch Hardware ist es sehr einfach, virtuelle Ressourcen bereitzustellen und dabei den Überblick über die Ausgaben zu verlieren – genauso wie man bei der Verwendung von Kreditkarten im Vergleich zu Bargeld leicht den Überblick über die Ausgaben verliert. Im Gegensatz zu CapEx lassen sich OpEx bestenfalls schätzen; und selbst diese Schätzungen bleiben ungewiss, da jeder neue Prozess oder jede neue Arbeitslast das Potenzial birgt, erhebliche zusätzliche Kosten zu verursachen, was eine zuverlässige Budgetplanung erheblich erschwert.

Das Kostenmodell von Databricks verstehen

Das Webinar verdeutlichte, wie die Weiterentwicklung der Datenarchitektur sowohl die Leistungsfähigkeit als auch die Komplexität des Kostenmanagements beeinflusst. Die Entwicklung hat sich von starren, kostspieligen und an bestimmte Systeme gebundenen Data Warehouses hin zu einer flexibleren Data-Lakehouse-Architektur vollzogen.

Bei der Data-Lakehouse-Architektur geht es um die Trennung von Speicher- und Rechenressourcen. In einem herkömmlichen Data Warehouse sind diese Komponenten eng miteinander verknüpft, was zu einer kontinuierlichen Auslastung der Rechenressourcen führt – selbst in Zeiten geringer Aktivität wie nachts oder am Wochenende. Im Gegensatz dazu ermöglicht ein Data Lakehouse die Bereitstellung von Rechenressourcen ausschließlich für die Datenverarbeitung, gefolgt von deren anschließender Beendigung nach Abschluss der Arbeitslast, wodurch sichergestellt wird, dass Sie nur für die tatsächlich benötigte Zeit der Rechenressourcen bezahlen.

Hier zeigen Technologien wie Apache Spark ihren Wert. Spark nutzt einen Treiberknoten, der einen großen Datensatz in kleine Aufgaben aufteilt und diese zur parallelen Verarbeitung auf die Arbeitsknoten verteilt. Diese Architektur ermöglicht die Verarbeitung umfangreicher Datensätze mit außergewöhnlicher Effizienz. Daher stellt dies eine erhebliche Herausforderung dar: Es muss sichergestellt werden, dass Rechenressourcen für Workloads, die eine solche Kapazität nicht erfordern, nicht überdimensioniert bereitgestellt werden. Hier ist die richtige Anpassung der Rechenressourcen von entscheidender Bedeutung.

Innerhalb dieses Ökosystems führt das Delta-Lake-Tabellenformat eine zusätzliche Ebene der Verwaltungsverantwortung ein. Jeder Einfüge-, Aktualisierungs- oder Löschvorgang erzeugt eine neue Datei. Werden die Befehle OPTIMIZE und VACUUM nicht regelmäßig ausgeführt, um kleine Dateien zu komprimieren und veraltete Daten zu entfernen, führt dies häufig zu einer erheblichen Leistungsminderung, die mit erhöhten Speicherkosten einhergeht.

Obwohl Databricks diese Wartungsvorgänge durch die „Predictive Optimization“ für von Unity Catalog verwaltete Tabellen (verfügbar ab Databricks Runtime 12.2) automatisiert hat, weist eine beträchtliche Anzahl von Tabellen weiterhin eine suboptimale Dateianzahl im Speicher auf. Dieser Zustand führt unmittelbar zu einer langsameren Abfrageausführung, einer längeren Datenverarbeitung und erhöhten Plattformkosten.

Die Supermarkt-Analogie: Warum sich die Kosten bei Databricks so schwer nachverfolgen lassen

Um wirklich zu verstehen, wie komplex das Kostenmanagement bei Databricks ist, stellen wir uns doch einmal einen Supermarkt vor.

Stufe 1: Sie erledigen den Einkauf selbst und erhalten direkt nach jedem Einkauf einen Kassenbon, aus dem genau hervorgeht, was jeder Artikel gekostet hat. Das lässt sich leicht nachverfolgen.

Stufe 2: Sie kaufen weiterhin alleine ein, erhalten nun jedoch nur noch eine monatliche Rechnung, auf der alle Artikel aufgeführt sind, und der Betrag wird automatisch von Ihrem Konto abgebucht. Das ist immer noch überschaubar, erfordert jedoch etwas mehr Aufwand bei der Überprüfung.

Stufe 3: Sie und die übrigen Haushaltsmitglieder kaufen getrennt ein. Alles wird auf einer einzigen monatlichen Rechnung zusammengefasst, auf der die einzelnen Posten weiterhin aufgeführt sind, und der Betrag wird automatisch vom Konto abgebucht. An dieser Stelle wird es langsam unübersichtlich.

Stufe 4: Gleicher Haushalt, gleiches getrenntes Einkaufen, doch in der monatlichen Abrechnung werden nun alle Posten in Kategorien zusammengefasst (Bäckerei, Gemüse, Getränke …). Sie können nicht mehr genau erkennen, welche Artikel gekauft wurden und wer sie gekauft hat.

Stufe 5: Nun kauft die gesamte Großfamilie (Tanten, Onkel, Cousins und Cousinen, Großeltern) eigenständig ein. Sie erhalten weiterhin eine monatliche Rechnung, in der die Kosten lediglich nach Kategorien aufgeführt sind. Es ist unmöglich zu erkennen, wer was gekauft hat.

Stufe 6: Und auf der höchsten Stufe … gibt es ein Familienmitglied, das auf völlig unüberlegte und rücksichtslos Weise am meisten Geld ausgibt (indem es sich alles schnappt, ohne auch nur einen Moment nachzudenken) und letztendlich den Großteil der Kosten verursacht, und Sie wissen nicht, wer es ist.

Genau aus diesem Grund ist eine FinOps-Strategie von Bedeutung, denn sie stellt sowohl einen kulturellen Wandel als auch einen praktischen Rahmen dar, um die Cloud-Ausgaben unter Kontrolle zu halten.

FinOps für Databricks: Praktische Strategien

Ein FinOps-Tool allein mag zwar effizient sein, doch ohne einen erfahrenen Data Engineer im Hintergrund kann es auch ins Hintertreffen geraten. Die Kombination eines erfahrenen Data Engineers mit dem richtigen Tool kann Ihrem Unternehmen zugutekommen, indem sie Spark-Workloads optimiert, Engpässe beseitigt und Ihnen dabei hilft, das richtige Tool für die jeweilige Aufgabe einzusetzen, die Sie benötigen.

Im Webinar haben wir zudem eine praktische Lösung erörtert, wie man vom Chaos zur Kontrolle gelangt, wobei wir uns auf mehrere Schlüsselbereiche konzentriert haben.

Transparenz vor der Optimierung

Bevor wir uns mit konkreten Optimierungsmaßnahmen befassen, ist es von entscheidender Bedeutung, ein grundlegendes Prinzip von FinOps zu verstehen: Man kann nicht optimieren, was man nicht sieht.

Ohne klare Transparenz sind alle Optimierungsbemühungen im Grunde genommen reine Spekulation. Sie stoßen vielleicht auf einige offensichtliche Verbesserungsmöglichkeiten, werden jedoch niemals ein umfassendes Verständnis Ihrer Kostentreiber erlangen. Hier gilt das Pareto-Prinzip: Wie im Webinar erwähnt, sind in vielen Unternehmen etwa 20 % der Prozesse für 80 % der verschwendeten Ressourcen verantwortlich. Ohne die entsprechenden Daten ist es jedoch unmöglich, diese zu identifizieren und zu optimieren.

Betriebliche Einblicke – die Möglichkeit, genau zu erkennen, was gerade läuft, wer dafür verantwortlich ist und wie hoch die Kosten sind – bilden das Fundament jeder erfolgreichen FinOps-Strategie. Diese Einblicke ermöglichen es Ihnen, Kosten präzise bestimmten Teams oder Projekten zuzuordnen und Anomalien zu erkennen, bevor sie zu große Ausmaße annehmen.

Erst wenn Sie über diese Transparenz verfügen, können Sie den Übergang vom reaktiven „Feuerlöschen“ zu einem proaktiven Kostenmanagement vollziehen. Auf dieser Grundlage wollen wir nun untersuchen, welche konkreten Schritte Sie unternehmen können, um die Kontrolle zu erlangen.

Schritt 1: Kostenzuordnung und Transparenz

Der erste und wichtigste Schritt zur Kostenkontrolle besteht darin, zu wissen, wohin das Geld fließt. Dies beginnt damit, alle Rechenressourcen (Cluster, Jobs, Data Warehouses) mit Tags zu versehen. Durch die Durchsetzung einer Richtlinie, Ressourcen mit Kennungen wie „Abteilung“, „Projekt“ oder „Umgebung“ (z. B. Dev, Prod) zu kennzeichnen, ist es möglich, Ihre Kosten schrittweise aufzuschlüsseln. Die Databricks-Plattform erfasst diese Informationen in ihren Systemtabellen und stellt damit eine umfangreiche Quelle für betriebliche Metadaten bereit.

Systemtabellen allein reichen jedoch nicht aus. Im Webinar wurde deutlich, dass Sie auch Daten erfassen müssen, die in Systemtabellen nicht ohne Weiteres verfügbar sind, wie zum Beispiel:

  • Metadaten der Delta-Tabelle (Größe, Anzahl der Dateien, Zeitpunkt der letzten Abfrage).
  • Metadaten zum Speicherplatz (Größe der einzelnen Ordner).
  • Eine Zuordnung von Arbeitsbereichs- und Dienstprinzipal-IDs zu aussagekräftigen Namen.
  • Kosten für die Cloud-Infrastruktur im Bereich der klassischen Rechenleistung (VMs).

Schritt 2: Proaktive Überwachung und Warnmeldungen

Sie sollten nicht erst auf die Monatsabrechnung warten, um festzustellen, dass bereits ein verstecktes Problem vorliegt. Der FinOps-Ansatz umfasst die Einrichtung von Warnmeldungen bei Kostenabweichungen sowie die Festlegung von Budgets für verschiedene Abteilungen oder Projekte. Auf diese Weise können Sie proaktiv statt reaktiv handeln.

Dank des Überwachungsmoduls können Sie einen Kostenanstieg frühzeitig erkennen, noch bevor er Zeit hat, sich auszubreiten und sich bis zum Monatsende zu einem weitaus größeren Problem auszuwachsen. Wenn ein Kostenanstieg am Dienstag einsetzt, kann Sie die Benachrichtigung bereits am Mittwoch darauf hinweisen, sodass Sie Zeit haben, der Sache nachzugehen und die Verschwendung frühzeitig zu unterbinden.

Schritt 3: Optimierung (Beispiele aus der Praxis)

Das Webinar bot zahlreiche Beispiele aus der Praxis, die verdeutlichten, wie diese Strategien zu erheblichen Einsparungen führen.

  • Das rund um die Uhr im Leerlauf befindliche Data Warehouse: Ein Kunde verfügte über ein SQL-Data-Warehouse, das rund um die Uhr in Betrieb blieb, nur um stündlich einen Bericht zu aktualisieren. Das FinOps-Tool erkannte dies, und durch die einfache Umstellung der Konfiguration auf serverloses Betrieb und die Anpassung der automatischen Beendigungszeit sanken die monatlichen Kosten von satten 30.000 US-Dollar auf nur noch 3.000 US-Dollar.
  • Überdimensionierte Rechenkapazität: In einem anderen Fall war ein riesiger Cluster mit mindestens 18 und höchstens 24 Workern (jeweils mit 32 Kernen und 128 GB Arbeitsspeicher) rund um die Uhr in Betrieb. Eine Analyse ergab, dass die CPU-Auslastung bei diesen Knoten nahezu null betrug. Durch die optimale Dimensionierung des Clusters erzielte der Kunde bei dieser einzelnen Arbeitslast Einsparungen von 75 % und senkte die Kosten von 200 $ pro Stunde auf 50 $ pro Stunde.
  • Die 140-Terabyte-Tabelle: Eine einzige Tabelle belegte 140 Terabyte teuren Speicherplatz, da sie nie bereinigt worden war. Dies bedeutete jährliche Kosten in Höhe von 21.000 US-Dollar für nur eine einzige Tabelle – ein Problem, das in großen Organisationen weitaus häufiger auftritt, als vielen bewusst ist.
  • Der doppelte Streaming-Auftrag: Zwei verschiedene Abteilungen hatten nahezu identische Streaming-Aufträge erstellt, um dieselben Daten aus Kafka abzurufen, wodurch sich die Kosten unnötigerweise verdoppelten. Dank der durch das FinOps-Tool bereitgestellten Transparenz konnte diese Doppelung erkannt werden, sodass ein Auftrag eingestellt werden konnte.

Doch auch hier gilt: Das FinOps-Tool allein reicht möglicherweise nicht aus. Den größten Nutzen erzielt man durch die Kombination der richtigen Plattform, der Betriebsdaten (wie beispielsweise der Databricks-Systemtabellen) und des technischen Fachwissens.

Die wichtigsten Erkenntnisse: Die Kontrolle zurückgewinnen

Die wichtigste Botschaft des Webinars lautet, dass es in der Cloud immer eine gewisse Verschwendung geben wird. Das liegt in der Natur des Modells. Durch die Umsetzung eines strukturierten FinOps-Ansatzes haben Sie diese Verschwendung jedoch stets unter Ihrer direkten Kontrolle. Sie können vermeiden, zu viel für Speicher und Rechenleistung zu bezahlen, Ihre Prozesse durch die ordnungsgemäße Pflege von Tabellen und die richtige Dimensionierung von Ressourcen beschleunigen und sich einen klaren, umsetzbaren Überblick über Ihre Cloud-Ausgaben verschaffen.

Für Unternehmen, die Databricks einsetzen, umfasst der weitere Weg Folgendes:

  1. Einführung einer soliden Tagging-Strategie zur korrekten Zuordnung von Kosten.
  2. Erstellung von Dashboards und Warnmeldungen, um die Nutzung zu überwachen und Abweichungen so schnell wie möglich zu erkennen.
  3. Durchsetzung von Richtlinien für Rechenressourcen, um eine Überprovisionierung und Verschwendung durch Leerlauf zu verhindern.
  4. Regelmäßige Überprüfung von Datentabellen auf Optimierungsmöglichkeiten und ungenutzten Speicherplatz.

Ein FinOps-Tool ist zwar sehr leistungsstark, doch erst durch die Kombination mit dem Fachwissen eines erfahrenen Dateningenieurs, der Spark-Workloads versteht und optimieren kann, erschließen Sie das wahre Potenzial Ihrer Datenplattform. Der Weg vom Chaos zur Kontrolle ist machbar, und die Vorteile sowohl für Ihr Budget als auch für die Leistung Ihrer Plattform lassen sich immer schwerer leugnen.

Beginnen Sie noch heute Ihre Reise mit Xebia und erfahren Sie mehr über Lake Warden.

Möchten Sie weiter erkunden, welche Möglichkeiten Databricks bietet?

Kosteneffizienz ist nur ein Aspekt beim Betrieb einer ausgereiften Databricks-Umgebung. Governance und Zugänglichkeit sind ebenso wichtig. Nehmen Sie an unserer Webinar-Reihe „Talk To Your Data“ teil, die auf realen Projektbeispielen basiert:

„Talk To Your Data“: DSGVO-konform auf Databricks
Schaffen Sie mit Unity Catalog eine kontrollierte, DSGVO-konforme Datenbasis.
8. Oktober, 11:00 Uhr MEZ | 08:00 Uhr EDT | 07:00 Uhr CDT | 17:30 Uhr IST | Hier registrieren

„Talk To Your Data“: Konversationsanalytik für Geschäftsteams
Erfahren Sie, wie Geschäftsteams mit Genie Agents Fragen zu Daten in natürlicher Sprache stellen können – ganz ohne SQL.
22. Oktober, 14:00 Uhr MEZ | 08:00 Uhr EDT | 07:00 Uhr CDT | 17:30 Uhr IST | Hier registrieren

Häufig gestellte Fragen zu FinOps für Databricks

Verfasst von

Kacper Glugla

Contact

Let’s discuss how we can support your journey.

‌
‌
‌
‌
‌
‌
‌
‌
‌