Azure Spark Services: Synapse Analytics vs Databricks

In der Opensource-Variante kann man Apache Spark sowohl im eigenen Rechencenter On-Premise installieren, als auch in der Cloud in virtuellen Maschinen, in Containern. Der Nachteil von diesem Setup ist die aufwändige Installation und Wartung. Die Konfiguration eines solchen Spark-Clusters benötigt zudem viel Fachwissen.

Eine angenehmere Lösung ist, wenn Spark als Service von einem Cloud-Provider bezogen werden kann. So kann man sich sehr viel Aufwand und Kosten sparen, profitiert von einer besseren Skalierung und kann innerhalb von Minuten neue Spark Cluster erstellen.

Es gibt verschiedene Cloud-Anbieter, bei denen man Spark als Service beziehen kann. Es handelt sich dabei um PaaS, also Platform-as-a-Service. Die Big Player sind hier AWS, Google Cloud Platform oder Microsoft Azure. In meiner beruflichen Tätigkeit verwende ich hauptsächlich die Azure Cloud, weshalb ich im vorliegenden Artikel die zwei wichtigsten Spark Services in der Azure Cloud beleuchte: Azure Databricks und Azure Synapse Analytics.

Azure Databricks ist ein schneller, einfacher und kollaborativer Apache-Spark-basierter Big-Data-Analysedienst, der für Data Science und Data Engineering entwickelt wurde. Die Firma Databricks wurde im Jahr 2013 von den Entwickler*innen von Apache Spark gegründet und bietet ihre Services nebst Azure auch auf AWS und Google Cloud Platform an.

Azure Synapse Analytics ist ein unbegrenzter Analysedienst, der Datenintegration, Data Processing und Big-Data-Analysen kombiniert. Am 4. November 2019 veröffentlichte Microsoft an der Ignite, der jährlichen Konferenz für Entwickler*innen von Microsoft, „Azure Synapsis Analytics“. Azure Synapse Analytics enthält nebst der Spark Engine noch weitere Komponenten, unter anderem das ehemalige Azure SQL Data Warehouse, ein Massive Parallel Processing Data Warehouse. Bei Azure Synapse Analytics handelt es sich also um ein eher jüngeres Projekt.

Eine häufige Frage, die mir gestellt wird, ist, welchen Service man nun verwenden soll. Eine Frage, die nicht so einfach beantwortet werden kann. Es gibt auch eine Frage auf Microsofts Doku-Seite über den Vergleich zwischen dem Spark Pool von Azure Databricks und Synapse Analytics.

Die Antwort von Microsoft am 22.04.2021 lautet: «Derzeit arbeiten wir mit dem Content-Team daran, einen Artikel zu veröffentlichen, der die Unterschiede zwischen Azure Databricks und Azure Synapse Spark Pool beschreibt. Ich werde Dich informieren, sobald er verfügbar ist.»

Bis dato habe ich noch kein solches Dokument gefunden, weshalb ich mich selbst auf die Suche nach Antworten gemacht habe.

In diesem Artikel beschreibe ich die augenscheinlichsten Unterschiede dieser beiden Spark Services in der Azure Cloud.

 

Spark Runtime

Databricks hat eine eigene, proprietäre Runtime, die Databricks Runtime. In dieser werden die aktuellsten Features eingebunden. Mit Databricks hat man also immer die neusten Funktionen und Software-Versionen. Daneben auch Funktionen, die nicht in der Opensource-Variante von Apache Spark enthalten sind.

Die Runtime von Synapse Analytics Spark baut auf der Vanilla Spark Runtime auf, der Opensource-Version von Spark. Die Spark-Version hinkt ein bisschen hinterher: Zurzeit ist die Spark-Version 3.0 im Preview erhältlich, wohingegen Databricks bereits bei Version 3.1.2 ist.

 

Provisionierung

Beide Services sind innert Minuten provisioniert. Die einfachste Provisionierung geschieht über das Azure-Portal.

Ebenfalls können beide Services via CLI, Powershell oder eine IaC-Lösung provisioniert werden.

 

Setup

Beim Setup der Spark Cluster sind bereits markante Unterschiede festzustellen. Bei Synapse Analytics spricht man von «Apache Spark Pool»:

Bei Databricks wird von «Cluster» gesprochen:

 

 

Art des Clusters

Databricks:

Beim Cluster Mode bei Databricks hat man die Auswahl zwischen Standard, High Concurrency und Single Node.

«High Concurrency» ist optimiert für die Ausführung gleichzeitiger SQL-, Python- und R-Workloads. Scala wird nicht unterstützt.

«Standard» ist empfohlen für Einzelbenutzer-Cluster und kann SQL-, Python-, R- und Scala-Workloads ausführen. Spark.NET (C#/F#) muss mit zusätzlichen Bibliotheken aktiviert werden.

Single Node ist ein Cluster ohne Worker. Das heisst, dass die Databricks Runtime auf einer einzelnen VM betrieben wird, nur als Driver Node. Dies ist empfohlen für Anwendungsfälle, bei denen mit kleinen Datenmengen gearbeitet wird.

 

Synapse:

Bei Synapse hat man (momentan) keine Möglichkeit, eine andere Cluster-Art zu erstellen ausser «Memory Optimized».

Vermutlich wird das in naher Zukunft schon ganz anders aussehen.

 

Software-Versionen

Databricks:

Für das Image, das auf den jeweiligen Nodes (die ebenfalls unterschiedliche Scala- und die Spark-Versionen enthalten) installiert wird, gibt es eine grosse Auswahl. Es gibt mehrere Versionen für Standard-Anwendungsfälle und eine ebenso grosse Auswahl extra für Machine-Learning-Projekte.

 

Synapse:

Unter erweiterten Settings kann die Spark-Version ausgewählt werden. Man hat die Wahl zwischen Spark 2.4 und Spark 3.0, wobei sich letztere noch in der Preview-Phase befindet.

Je nach gewählter Spark-Version erhält man dann Informationen zu den verwendeten Versionen von der dazugehörigen Software.

 

Memory und CPU der einzelnen Nodes

Databricks:

Bei Databricks gibt es eine sehr grosse Auswahl von unterschiedlichen Worker Types.

Zudem hat man noch die Möglichkeit, sogenannte «Spot-Instanzen» zu gebrauchen. Mit virtuellen Spot-Computern kann man von ungenutzter Computekapazität und damit von Kosteneinsparungen profitieren.

 

Synapse:

Die Grösse der Nodes bei Synapse wird in «T-Shirt-Grössen» angegeben: von Small mit 4 vCore und 32 GB RAM, bis zu XXLarge mit 80 vCores und 504 GB RAM.

Man kann also aus 6 verschiedenen Grössen auswählen.

 

Pricing

Bei beiden Services richtet sich das Pricing nach der Anzahl der virtuellen Maschinen und deren Sizing, also die darunter liegenden Spezifikationen wie CPU, RAM oder der verwendeten Datenträger wie HDD oder SSD.

Bei Databricks kommt zusätzlich zu den Kosten für die VM’s noch eine Gebühr obendrauf, die DBU. Eine DBU ist eine Einheit der Verarbeitungskapazität, die auf der Grundlage einer sekundengenauen Nutzung berechnet wird. Der DBU-Verbrauch hängt von der Grösse und dem Typ der Instanz ab, auf der Azure Databricks ausgeführt wird.

 

Notebooks

Databricks:

Databricks hat eine eigene Implementierung der Notebooks. Das Co-Authoring findet in Echtzeit statt. Das heisst, beide Autoren sehen die Änderungen des anderen in Echtzeit. Bei Databricks sind die Notebooks automatisch versioniert.

Synapse:

Bei Synapse werden Nteract Notebooks eingesetzt: https://nteract.io/. Mehrere Personen können zwar an demselben Notebook arbeiten, aber eine Person muss das Notebook speichern, bevor eine andere Person die Änderung sieht. Weiter gibt es noch keine automatische Versionierung der Notebooks.

 

Anbindung Data Lake

Databricks:

Ein Data Lake muss gemounted werden, um ihn verwenden zu können.

Synapse:

Beim Erstellen des Synapse Workspace kann ein bestehender oder ein neuer Data Lake angegeben werden, der als primärer Data Lake dient. Damit kann direkt aus den Skripts und Notebooks darauf zugegriffen werden. Weitere Data Lakes können als «Linked Services» hinzugefügt werden.

Synapse Studio bietet zudem einen integrierten Fileexplorer, aus dem man per Rechtsklick ein Spark Notebook öffnen kann, welches das ausgewählte File in ein Dataframe lädt.

 

GIT-Integration

Beide Services bieten mittlerweile eine GIT-Integration an.

 

Performance/Geschwindigkeit

Um ein Gefühl dafür zu bekommen, wie sich die beiden Technologien in Bezug auf Geschwindigkeit/Leistung vergleichen lassen, habe ich einen Test durchgeführt. Als Datenquelle habe ich die TLC Trip Record Data Yellow Cab der Stadt New York gewählt.

https://www1.nyc.gov/site/tlc/about/tlc-trip-record-data.page

Die yellow-and-green-taxi-trip-Daten enthalten Felder zur Erfassung von Abhol- und Rückgabedaten/-zeiten, Abhol- und Rückgabeorten, Fahrtentfernungen, Einzelpreisen, Tarifarten, Zahlungsarten und vom Fahrer gemeldete Fahrgastzahlen.

Für den Test wurden nur die Daten der gelben Taxifahrten verwendet. In diesem Datensatz wurden alle Datensätze von Januar 2009 bis Dezember 2020 im CSV-Format heruntergeladen und in einem Data Lake gespeichert. Die Datengrösse der CSV-Dateien beträgt 233 GB. Der Datensatz enthält insgesamt 1'620'781'620 Zeilen (1.62 Milliarden Zeilen).

Als Testumgebung habe ich je eine Spark-Umgebung mit Databricks und eine mit Azure Synapse Analytics erstellt. Da Azure Synapse Analytics weniger Auswahlmöglichkeiten für die Konfiguration der Nodes/Workers bietet, habe ich diese als erste erstellt. Den Spark-Pool habe ich mit 3 Nodes erstellt, jeder Node mit 32 GB RAM und 4 vCPU.

Um für beide Technologien annähernd gleiche Bedingungen zu schaffen, wurde im Databricks-Cluster ein ähnlicher Spark Pool angelegt. Auch 3 Worker Nodes mit je 32 GB RAM und 4vCPU wurden angelegt, zusätzlich musste ein Driver Node spezifiziert werden. Dieser wurde mit der gleichen Grösse wie die Worker Nodes provisioniert.

Autoscale habe ich ausgeschaltet, dies wäre dann ggf. in einem weiteren Schritt zu testen.

Ob der Vergleich wirklich 1:1 ist, lässt sich bei dieser Konstellation nicht mit 100 prozentiger Wahrscheinlichkeit sagen. Denn es gibt zu wenig Informationen über die bereitgestellten Virtual Machines und wie deren Architektur genau aussieht. Bei Databricks hat man mehr Informationen zu den verwendeten VM’s, bei den Synapse Spark Pools kann man lediglich zwischen den T-Shirt-Grössen auswählen. Auch die unterschiedlichen Spark-Versionen können einen Einfluss auf die Leistung haben.

Begonnen habe ich mit Databricks. Der Data Lake wurde in die Databricks-Umgebung gemounted und dann habe ich aus den CSV-Dateien ein Dataframe erstellt:

 

Das Erstellen des Dataframes hat 7.37 Sekunden gedauert.

Dieselbe Operation wurde anschliessend mit Synapse durchgeführt, die in 4.2 Sekunden abgeschlossen war:

 

Nachfolgend habe ich das Schema des Datensets ausgegeben:

Aus dem Dataframe habe ich dann jeweils einen «Temporären View» erstellt. Nachfolgend sieht man die Operation in Databricks:

So, nun kommt der erste Härtetest! Und zwar werde ich alle Einträge im jeweiligen TempView zählen.

Bei Databricks hat es 8.87 Minuten gedauert, also rund 532 Sekunden.

Bei Synapse hat dieselbe Operation 8 Minuten und 51 Sekunden gedauert, also total 531 Sekunden.

Um die Systeme jetzt mal richtig zu testen, habe ich eine Aggregationsabfrage durchgeführt. Bei Databricks kam ich auf ein Ergebnis von 11.88 Minuten, also 713 Sekunden.

Dieselbe Operation dauerte bei Synapse 18 Minuten und 38 Sekunden, das sind total 1118 Sekunden.

 

Nun möchte ich die beiden Umgebungen vergleichen, indem ich die Daten in ein anderes Datenformat bringe. Zum einen werde ich die Daten als Parquet an einem neuen Ort abspeichern, zum anderen in einem 2. Schritt als Delta.

Mit Databricks habe ich das Dataframe in das Parquet-Format in einem neuen Speicherort abgelegt. Diese Operation hat 31.05 Minuten gedauert, also 1865 Sekunden.

Dieselbe Operation mit Synapse dauerte eine Stunde und 5 Sekunden, also 3605 Sekunden:

Das ist rund doppelt so lange.

Nun zähle ich wieder die Anzahl Einträge und mache eine Aggregationsabfrage auf die Parquet-Daten. Wie bei dem CSV-Dataframe mache ich das mit Spark SQL und erstelle vorher aus dem Dataset einen Temp-View.

Die Abfrage dauerte bei Databricks 38.29 Sekunden:

 

Dieselbe Operation bei Synapse dauerte 10.279 Sekunden:

 

Die Aggregationsabfrage auf die Parquet-Daten dauerte bei Databricks 2.72 Minuten, also rund 163 Sekunden:

Dieselbe Operation bei Synapse dauerte 4 Minuten und eine Sekunde, also 241 Sekunden.

Die Tests mache ich abschliessend noch mit dem Format Delta.

Mit Databricks schreibe ich das CSV-Dataframe an einem neuen Ort im Format Delta, was 42.99 Minuten gedauert hat, also rund 2579 Sekunden:

 

Wiederum dieselbe Operation in Synapse: Die Daten wurden in 1 Stunde, 5 Minuten und 31.85 Sekunden als Delta geschrieben, das macht rund 3932 Sekunden:

Das Zählen aller Einträge im Delta-Format dauerte bei Databricks 1.16 Sekunden:

Synapse hat die Einträge im Delta-Format in 10.3 Sekunden gezählt:

Als Krönung kommt nun wiederum die Aggregationsabfrage.

Mit 2.62 Minuten (157 Sekunden) ging Databricks ins Rennen:

 

Synapse Analytics liess sich mit 4 Minuten (240 Sekunden) ein bisschen mehr Zeit:

Nachfolgend nochmal die Zusammenfassung der Resultate:

Bei den Resultaten ist zu beachten, dass unterschiedliche Delta-Versionen und/oder Spark-Versionen verwendet wurden.

Und was sagen diese Resultate? Nun, ich würde diese Zahlen nicht als alleinige Entscheidungs-Grundlage für die eine oder andere Technologie wählen.

So bin ich nicht zu 100 % sicher, ob die verwendeten Nodes (VM’s) vergleichbar sind. Sie haben zwar gleich viel RAM und vCPU, aber alles andere ist ungewiss.

Bei den Testresultaten habe ich jeweils die Resultate aus der ersten Abfrage genommen. Wenn man dieselbe Operation mehrmals ausführt, entweder gleich nacheinander oder zu unterschiedlichen Tageszeiten, erhält man unterschiedliche Resultate.

Des Weiteren sind nicht dieselben Software-Versionen eingesetzt worden. Spark 3.0 bei Synapse und Spark 3.1 bei Databricks.

Die darunter liegenden Spark Engines unterscheiden sich ebenfalls.

Interessant wäre es, wenn man den Test zu einem späteren Zeitpunkt wiederholt, wenn Synapse ebenfalls Spark Version 3.1 einsetzt.

Nachtrag (Juni 2022): Ab April 2022 bietet Synapse Analytics die Spark Version 3.1 an. Die Version 3.2 befindet sich zurzeit in der Beta-Phase.

• Databricks hat die aktuellsten Software-Versionen und Funktionen, dafür hat Synapse eine integrierte Unterstützung für .NET für Spark-Anwendungen.
• Databricks kostet zwar mehr als Synapse Spark, da zusätzlich zu den VMs noch eine DBU-Gebühr gezahlt werden muss. Dafür ist Databricks besser optimiert und effizienter bei paralleler Verarbeitung.
• Bei Szenarien, in denen komplexe Spark-Applikationen gebaut werden sollen, ist Databricks eher zu bevorzugen. Databricks bietet zurzeit mehr Features und bessere Performance-Optimierungen.
• Bei Datenplattformen, die hauptsächlich SQL-basiert sind und wenige Spark-Anwendungsfälle haben, ist sicher Synapse Analytics die bessere Wahl.
• Für grosse Datenmengen, hohe Leistung und/oder parallele Nutzung von Spark ist Databricks ein ausgereifteres, leistungsfähigeres Angebot.
• Bei Machine-Learning-Entwicklung ist eher Databricks zu bevorzugen, da Databricks über ML-optimierte Databricks-Laufzeiten verfügt, die einige der beliebtesten Bibliotheken (z. B. TensorFlow, Keras, PyTorch usw.) und GPU-fähige Cluster umfassen. Auf der anderen Seite hat Synapse eine integrierte Unterstützung für AzureML.
• Was sicher nicht ausser Acht gelassen werden sollte, ist eine Kombination von beiden Services. Je nach Anwendungsfall wird jener Service gewählt, der besser passt und das beste Preis-Leistungs-Verhältnis bietet.
• Beim Einsatz von Cosmos-DB oder Pureview ist ganz klar Synapse Analytics vorzuziehen, da die Services stark in die Synapse Workspaces eingebunden sind.
• Bei Data-Warehousing-Projekten, mit relationalen Datenmodell, gespeicherten Prozeduren usw., bietet Synapse Analytics alle SQL-Funktionen, an die sich jede*r BI-Anwender*in gewöhnt hat, einschliesslich einer vollständigen Standard-T-SQL-Erfahrung.

Wie schon am Anfang des Artikels erwähnt, befinden sich beide Technologien in aktiver Entwicklung. Es wird sowohl von Databricks wie auch von Microsoft ein hohes Tempo vorgelegt, mit dem neue Features und Optimierungen umgesetzt werden. In einem halben Jahr sieht der Vergleich schon wieder ein bisschen anders aus. Und in einem Jahr wird sich die Landschaft sicher nochmal stark verändert haben. Ich bin auf jeden Fall sehr gespannt, welche coolen Entwicklungen wir auf beiden Seiten noch erwarten können.

Ich persönlich habe noch keinen Favoriten, je nach Anwendungsfall und Projekt setze ich den einen oder den anderen Service ein.