Databricks vs Snowflake: Mythen, Marketing und Performance

Snowflake oder Databricks? Diese Frage stellen sich gegenwärtig viele Entscheidungsträger in Unternehmen, wenn es um die richtige Cloud-Plattform zur Modernisierung der eigenen Datenlandschaft geht. Oftmals lautet die Antwort „Snowflake“. Schließlich wirbt der Anbieter damit, beim hochrelevanten Thema der Datenabfrage deutlich performanter und zugleich kostengünstiger zu sein.

Aber ist dem tatsächlich so? Im Folgenden möchte ich Ihnen von einer konkreten Projektsituation berichten, die diese Argumentation – zumindest für das Power-BI-Universum – klar widerlegt. Dabei hat ein Proof of Concept (PoC) gezeigt, dass die von Snowflake kommunizierten Eckdaten zur eigenen Query Engine eher in einer Laborsituation entstehen. Zudem hat der Anbieter mit teils schon fragwürdigen Vergleichen gegenüber Databricks gearbeitet. Werden die entsprechenden Faktoren „bereinigt“, dann sehen die Ergebnisse plötzlich ganz anders aus.

Bevor ich in die Details gehe, möchte ich kurz für Sie darstellen, warum die Geschwindigkeit der Datenabfrage eines der wichtigsten Kriterien bei der Suche nach der richtigen Plattform-Software sein sollte.

Warum ist die Query Engine so wichtig?

Beim Vergleich „Databricks vs Snowflake“ stehen meist die Eigenschaften rund um den Einsatz von Künstlicher Intelligenz (KI), Machine Learning und Echtzeitanalysen im Mittelpunkt. Beide Anbieter haben sich auf diesen Gebieten in den vergangenen Jahren enorm entwickelt – mal hat der eine, mal der andere die Nase vorn. Die Query Engine fristet demgegenüber eher ein Schattendasein, obwohl die performante Direktabfrage von Daten zu den Kernanforderungen an eine Data Driven Company gehört. Dies gilt umso mehr, wenn Ihnen Anwendungsfälle aus dem KI- oder IoT-Bereich vorschweben.

Dabei sind Direktabfragen auch häufig der Datenanalyse über den InMemory-Speicher vorzuziehen, wie sie etwa in Power BI angeboten wird. Ich sehe hierfür folgende Gründe:

• Garantiert aktuelle Daten: Wer direkt auf die Daten zugreift, kann sich ihrer Aktualität immer sicher sein. Über den InMemory-Speicher lässt sich dies schon bei mittelgroßen Datasets nur noch schwerlich gewährleisten.
• Grenzenlose Skalierbarkeit: Werden Datasets InMemory bearbeitet, dann ist bei einer Größe von 400 GB Schluss. Beim Direct-Query-Modus gibt es diese Grenzen nicht.
• Massive Kostenreduktion: InMemory liefert schnelle Ergebnisse, aber ist auch teuer. Beispielsweise müssen Sie bei einer Speicherkapazität von 400 GB mit monatlichen Kosten von mehr als 80.000 € rechnen.

Zusammengefasst: Wenn Sie mit gewissen Kompromissen bei den Antwortzeiten leben können, dann bildet die Direktabfrage in vielen Anwendungssituationen die praktischere und kostengünstigere Alternative. Aber wer ist in dieser Disziplin nun wirklich besser? Databricks oder Snowflake?

Snowflake nutzt fragwürdiges Setup

Kehren wir zum eingangs erwähnten Praxisfall zurück. In dem betreffenden Projekt durfte ich erleben, wie ein Snowflake-Team die eigene Query Engine im Rahmen eines PoCs mit der von Databricks verglichen hat. Die Ergebnisse entsprachen den Werbeversprechen des Anbieters: Snowflake ist dreimal schneller und reduziert die Kosten um 50 Prozent.

Das Problem: Ein solches Ergebnis deckte sich so gar nicht mit den Erfahrungen, die sowohl ich als auch alle meine DevLead-Kollegen in unterschiedlichen Projekten gemacht haben. Ich entschloss mich dazu, die PoC-Ergebnisse noch einmal aufzuarbeiten. Zunächst habe ich mir das Setup genauer angeschaut und bin auf zwei „Besonderheiten“ gestoßen:

1. Veraltete DAX-Abfrage: Für die Abfrage aus dem Power BI Report wurde ein historisch gewachsener DAX-Code genutzt, der die Abläufe beim Einsatz von Databricks ineffizient gestaltet und dadurch die Abfragezeiten massiv erhöht. Snowflake interpretiert den vorhandenen DAX-Code anders, woraus letztendlich der Vorsprung bei der Geschwindigkeit resultiert.
2. Veraltete Databricks-Version: Tatsächlich wurden Databricks und Power BI von 2021 mit Snowflake und Power BI von 2023 verglichen. Was diese zwei Jahre Entwicklungsunterschied bei Cloud-Technologien bedeutet, dürfte jedem klar sein.

Ich habe daraufhin den DAX-Code angepasst, Databricks auf den neuesten Stand gehoben und schließlich die aktuelle Power-BI-Version verwendet – und siehe da:

Bei einem einfachen Aufruf des Power-BI-Reports ist Databricks plötzlich doppelt so schnell, wie Snowflake. Und selbst bei parallelen Abfragen von 50 Usern hat Databricks spürbar die Nase vorn. Nach diesen Ergebnissen habe ich mich natürlich mit großer Neugierde der Kostenthematik zugewandt.

Databricks ist auch günstiger

Zur Erinnerung – laut PoC hat der Einsatz von Snowflake die Kosten um sagenumwobene 50 Prozent reduziert:

Aber wie genau wurde dieser Wert ermittelt? Tatsächlich ging der PoC auch hier von unterschiedlichen Szenarien aus. Wie sich zeigte, wurde für das Snowflake Warehouse eine tägliche Nutzung von fünf Stunden veranschlagt, während es bei Databricks ein 24/7-Betrieb war. Als Begründung nannten die Tester, dass das Databricks Cluster einige Minuten für den Start benötigt. Demgegenüber sei Snowflake in Sekunden verfügbar.

Was soll ich sagen? Vor zwei Jahren hätte dieses Argument noch gegriffen. Aber spätestens seit der Veröffentlichung von Databricks SQL Serverless ist es obsolet. Folglich habe ich auch in dem Fall einfach identische Voraussetzungen geschaffen und für das Databricks Cluster eine Laufzeit von fünf Stunden angesetzt – hier das Resultat:

Die Ausgaben für Databricks betragen also plötzlich nur noch ein Drittel von dem, was Sie für Snowflake zahlen würden. Zudem stellen wir fest: „Instant Scale“ ist kein reiner Snowflake-USP mehr.

Fazit: Snowflake vergleicht Äpfel mit Birnen

Habe ich jetzt für meine Ergebnisse besonders viele Optimierungen auf der Databricks-Seite vorgenommen, die bei Snowflake gar nicht erst erforderlich sind? Ich denke, nein. Denn: Es wurde lediglich das zugrunde liegende Star Schema einer Faktentabelle mit circa 100 Milliarden Zeilen partitioniert gespeichert – was aus meiner Sicht bis heute „State-of-the-Art“ sein sollte. Auf weitere Optimierungen, wie zum Beispiel Z-Ordering habe ich bewusst verzichtet.

Währenddessen finde ich es mehr als befremdlich, mit welchen Methoden die Snowflake-Tester im konkreten Fall vorgegangen sind. Wie man so schön sagt: Hier wurden Äpfel mit Birnen verglichen. Und das kann teure Konsequenzen haben. Denn eine Migration zu Snowflake gibt es nicht umsonst. Im Gegenteil, sie ist mit enormen Kosten und Aufwänden verbunden. Insofern kann ich nur für einen sauberen und fundierten Austausch von Argumenten plädieren, der Unternehmen sichere Zukunftsentscheidungen ermöglicht. Das sollte doch immer das Kernziel einer seriösen Beratung sein.

Wollen auch Sie Ihre unternehmensweite Datenanalyse mit einer modernen Cloud-Plattform in die Zukunft führen? Dann schauen Sie doch mal auf der Seite Databricks Lakehouse vorbei oder informieren Sie sich über unser Data Strategy Assessment.