TL;DR
Viele Unternehmen betreiben heute Snowflake und Databricks parallel – und brauchen einen Ort, an dem sie die Kosten beider Plattformen im Blick behalten. Dazu kommt: Databricks ist tatsächlich schwerer zu optimieren als die meisten Plattformen. Mehr Services, mehr Stellschrauben, mehr Wege, auf denen sich Kosten ohne erkennbaren Grund verändern. Mit SELECT für Databricks geben wir Datenteams dieselbe Kostentransparenz und dieselben Optimierungsmöglichkeiten, die wir für Snowflake entwickelt haben.
Bei SELECT hatten wir die Ehre, mit über 250 Snowflake-Kunden zusammenzuarbeiten. Mit der Zeit hörten wir immer wieder dieselbe Frage: Könnt ihr das auch für Databricks?
Diese Frage war der Ausgangspunkt. Aber zwei weitere Entwicklungen haben uns dazu bewegt, Kostentransparenz und Optimierung für Databricks zu entwickeln – und sie waren entscheidend dafür, wie wir es umgesetzt haben.
Multi-Plattform ist heute der Normalfall
In den Accounts, mit denen wir arbeiten, ist der parallele Betrieb von Snowflake und Databricks längst die Regel, nicht die Ausnahme. Die Aufteilung ist für die Workloads meist sinnvoll: Snowflake für strukturierte Analysen, Databricks für rechenintensive Workloads und ML.
Teams, die beide Plattformen nutzen, wollten Workloads auf beiden Plattformen vergleichen und ihre gesamten Datenplattform-Ausgaben an einem Ort verfolgen können.
Databricks hat deutlich mehr Stellschrauben als Snowflake
Bei Snowflake ist das Compute-Angebot sehr einfach und unkompliziert in der Nutzung. Es gibt nur wenige Konfigurationsparameter bei virtuellen Warehouses, die Nutzer optimieren müssen.
Databricks ist eine ganz andere Geschichte. Es gibt mehrere Compute-Optionen und Wege, Workloads auszuführen (Jobs Compute, All Purpose/Interactive, Serverless SQL und mehr), und jeder Service bringt deutlich mehr Konfigurationsoptionen mit. Clustergröße, Auto-Scaling-Parameter, die Wahl des Instance-Typs und die Nutzung von Spot-Instances sind allesamt wichtige Entscheidungen, die sich auf Ihre Rechnung auswirken.
Mehr Konfiguration bedeutet mehr Optimierungspotenzial. Und zugleich mehr Möglichkeiten, etwas falsch zu konfigurieren – und es erst zu bemerken, wenn die Kosten bereits gestiegen sind.
Eines wissen wir sicher: Transparenz muss an erster Stelle stehen. Was man nicht sieht, kann man nicht optimieren. Genau da setzt SELECT für Databricks an: mit einer klaren Aufschlüsselung, wohin das Geld tatsächlich fließt und was Veränderungen im Zeitverlauf treibt.
Databricks wächst rasant innerhalb von Unternehmen
Databricks startete als Spezialplattform für ML und Data Engineering. Darüber ist die Plattform längst hinausgewachsen. Immer mehr Teams führen immer mehr Workload-Typen darauf aus, und die Verbreitung innerhalb von Unternehmen beschleunigt sich.
Schnelle Verbreitung bringt ein bekanntes Problem mit sich: Die Ausgaben wachsen schneller als die Prozesse, um sie zu steuern. Teams fügen Workloads hinzu, die Kosten steigen, und niemand hat ein klares Bild davon, was sie treibt – bis die Rechnung bereits höher ausfällt als erwartet.
Genau das haben wir bei Snowflake erlebt. Teams führten die Plattform schnell ein, die Kosten liefen der Transparenz davon, und dann begann die Arbeit, die Ausgaben zu verstehen und in den Griff zu bekommen. Für genau diesen Moment wurde SELECT gebaut. Dasselbe passiert jetzt mit Databricks.
Was wir entwickelt haben
SELECT für Databricks bietet Datenteams Kostenzuordnung nach Team, Workspace, Job und Query-Workload. Jeder einzelne Dollar lässt sich nachverfolgen, Nutzer werden dank unserer ML-gestützten Anomalieerkennung automatisch über Kostenanstiege informiert und können die Ursache anschließend mit unserem AI Copilot automatisch untersuchen.
Zusätzlich zur umfassenden Kosten-Observability können Nutzer ihre Compute-Ausgaben ganz ohne Aufwand automatisch senken – mit unserem Feature Automated Savings, das SQL Warehouses, All-Purpose-Cluster und Jobs Compute in Echtzeit optimiert, ohne die Performance zu beeinträchtigen.
Wenn Sie das Ganze in Aktion sehen möchten, buchen Sie einen Termin mit uns unter: select.dev/demo.