Apache Spark: Einheitliche Analyse-Engine mit Spark SQL, MLlib und Structured Streaming
Apache Spark – Eine einheitliche Analyse-Engine für die Verarbeitung großer Datenmengen.
Auf einen Blick
- Was ist das?
- Spark bündelt SQL, maschinelles Lernen, Graphverarbeitung und Streamverarbeitung in einer Engine. Wir sehen uns Build, Shells, Hadoop-Zwang und die CI-Matrix an und grenzen gegen Flink ab.
- Für wen ist es gedacht?
- Spark passt zu Teams, die Batch-Auswertung, SQL, maschinelles Lernen und Streamverarbeitung in einer einzigen Engine bündeln wollen und Scala, Java oder Python einsetzen. Weniger geeignet ist es für neue Vorhaben mit R, weil die README diese Schnittstelle als veraltet kennzeichnet, und für reine Ereignisstrom-Verarbeitung mit strengen Latenzzielen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Scala, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Spark als einheitliche Analyse-Engine mit Scala, Java, Python und R
Die README von apache/spark führt Spark als einheitliche Analyse-Engine für großflächige Datenverarbeitung ein. Sie bietet Schnittstellen in Scala, Java, Python und R, wobei R ausdrücklich als veraltet gekennzeichnet ist, sowie eine optimierte Engine, die allgemeine Berechnungsgraphen für Datenanalyse unterstützt.
Diese Formulierung erklärt die Stellung des Projekts. Eine Engine, die beliebige Berechnungsgraphen ausführt, kann sehr unterschiedliche Werkzeuge tragen, statt für jeden Zweck ein eigenes System zu verlangen.
Die Metadaten nennen Scala als Hauptsprache, Apache-2.0 als Lizenz und master als Standardzweig. Zum Zeitpunkt der Erhebung weist GitHub 43.898 Sterne, 29.350 Forks und 495 offene Issues aus. Auffällig: Im Material sind keine Releases verzeichnet. Wer eine Version festschreiben will, muss sie über die Projektseite bestimmen, statt auf einen GitHub-Tag zu verweisen.
Spark SQL, pandas API on Spark, MLlib, GraphX und Structured Streaming
Über der Engine liegen laut README mehrere Werkzeuge. Spark SQL deckt SQL und DataFrames ab. Die pandas API on Spark richtet sich an Arbeitslasten, die aus dem pandas-Umfeld kommen, und erlaubt es, vertraute Ausdrücke auf verteilten Daten zu verwenden. MLlib bringt maschinelles Lernen, GraphX die Graphverarbeitung, und Structured Streaming übernimmt die Verarbeitung von Datenströmen.
Diese Aufteilung ist der eigentliche Grund für die Verbreitung von Spark. Ein Team kann dieselbe Infrastruktur für nächtliche Auswertungen, Modelltraining und laufende Ströme nutzen und spart sich drei getrennte Systeme samt dreifacher Betriebsarbeit.
Der Preis ist eine große Oberfläche. Wer nur eines dieser Werkzeuge braucht, bekommt den Rest als Ballast mit, und die README macht keine Angabe dazu, wie sich die Werkzeuge einzeln abschalten lassen.
./build/mvn -DskipTests clean package und der Hadoop-Versionsabgleich
Zum Bauen aus dem Quelltext nennt die README den Befehl ./build/mvn -DskipTests clean package. Sie stellt klar, dass dieser Schritt entfällt, wenn man ein fertiges Paket heruntergeladen hat. Welche Maven-Version nötig ist und welche Voraussetzungen gelten, steht dort nicht; diese Angaben liegen in der Build-Dokumentation der Projektwebsite.
Eine Stelle verdient besondere Aufmerksamkeit. Spark nutzt die Hadoop-Kernbibliothek, um mit HDFS und anderen von Hadoop unterstützten Speichersystemen zu sprechen. Weil sich die Hadoop-Protokolle zwischen Versionen ändern, verlangt die README, Spark gegen dieselbe Hadoop-Version zu bauen, die der eigene Cluster einsetzt.
Wer diesen Punkt übersieht, verliert Zeit mit Fehlern, die wie Netzwerkprobleme aussehen. Welche Hadoop-Versionen derzeit unterstützt werden, gibt die README nicht an. Für Cluster mit YARN oder einer bestimmten Hive-Verteilung verweist sie auf die Build-Dokumentation.
spark-shell, pyspark und spark.range(1000 * 1000 * 1000).count()
Für den Einstieg stellt die README interaktive Shells bereit. Die Scala-Shell startet mit ./bin/spark-shell, die Python-Shell mit ./bin/pyspark. Als erster Ausdruck wird spark.range(1000 * 1000 * 1000).count() genannt, der in beiden Shells eine Milliarde zurückgeben soll. Damit lässt sich prüfen, ob die Installation überhaupt rechnet, ohne echte Daten zu laden.
Beispielprogramme liegen im Verzeichnis examples und werden mit ./bin/run-example gefolgt von Klassenname und Parametern gestartet, im README als ./bin/run-example SparkPi gezeigt. Über die Umgebungsvariable MASTER lassen sich Beispiele an einen Cluster schicken, etwa mit einer spark://-Adresse oder den Werten yarn und local[N].
Wie die Shells installiert werden und ob sie einen laufenden Cluster voraussetzen, beschreibt die README nicht.
Die Build-Pipeline mit branch-4.x, Java 17 bis 25 und Python 3.14
Ein großer Teil der README besteht aus einer Tabelle mit dem Zustand der Build-Pipeline. Sie führt den Entwicklungszweig master sowie die Zweige branch-4.x und branch-4.3 auf und listet für jeden eine lange Reihe von Workflows.
Aus dieser Liste lässt sich die unterstützte Umgebung ablesen. Es gibt Builds mit Java 17, 21 und 25, Maven-Varianten davon, Läufe für Arm-Plattformen und für macOS, Prüfläufe für Python 3.11 bis 3.14 einschließlich eines Laufs ohne Global Interpreter Lock, eigene Workflows für Connect, für SparkR sowie für Codegenerierung und ein RockDB-Backend für die Oberfläche.
Diese Breite ist ein starkes Signal für eine gepflegte Matrix, und sie erklärt den Ressourcenbedarf des Projekts. Umgekehrt bedeutet sie, dass nicht jede Kombination gleich gut getestet ist; eine Gewichtung, welche Kombination als Standard gilt, nennt die README nicht.
Konfiguration, ./dev/run-tests und Flink als Alternative
Tests laufen laut README nach dem Bau über ./dev/run-tests. Für Tests einzelner Module oder einzelner Testfälle verweist die README auf die Dokumentation der Entwicklerwerkzeuge, ebenso für einen Integrationstest mit Kubernetes unter resource-managers/kubernetes/integration-tests/. Angaben zur Dauer eines Testlaufs fehlen.
Die Konfiguration wird nicht in der README behandelt. Sie verweist auf das Online-Konfigurationshandbuch, und dasselbe gilt für Beiträge über den Leitfaden Contribution to Spark. Rechtlich steht Spark unter Apache License 2.0, die Nutzung und Veränderung erlaubt, den Lizenztext mitzuführen verlangt und Patentansprüche der Beitragenden regelt.
Als Alternative bietet sich Apache Flink an. Es ist von Grund auf auf Ereignisströme ausgelegt und behandelt Batch-Arbeit als Sonderfall, während Spark aus der Batch-Verarbeitung kommt und Structured Streaming darüber legt. Für Verarbeitung mit strengen Latenzzielen und Ereigniszeit-Semantik ist Flink häufig die passendere Wahl; für gemischte Arbeitslasten mit viel SQL und maschinellem Lernen bleibt Spark die breitere Lösung.
Redaktionelles Fazit
Spark passt zu Teams, die Batch-Auswertung, SQL, maschinelles Lernen und Streamverarbeitung in einer einzigen Engine bündeln wollen und Scala, Java oder Python einsetzen. Weniger geeignet ist es für neue Vorhaben mit R, weil die README diese Schnittstelle als veraltet kennzeichnet, und für reine Ereignisstrom-Verarbeitung mit strengen Latenzzielen. Vor einer Entscheidung sollte ./build/mvn -DskipTests clean package gegen dieselbe Hadoop-Version laufen wie der eigene Cluster, und ./bin/run-example SparkPi muss auf der Zielumgebung Ergebnisse liefern.
Community-Notizen