Apache Sedona 1.9.1: Cluster-Framework für Geodaten mit SedonaDB und SpatialBench
Ein Cluster-Computing-Framework zur Verarbeitung umfangreicher Geodaten.
Auf einen Blick
- Was ist das?
- Apache Sedona verarbeitet großflächige Geodaten im Cluster, ergänzt um das Unterprojekt SedonaDB für einen einzelnen Knoten und SpatialBench als Vergleichsmaßstab. Wir sehen uns an, was die README belegt.
- Für wen ist es gedacht?
- Sedona passt zu Teams, die Geodaten in einem Cluster verarbeiten müssen und eine Umgebung mit Spark oder Flink betreiben, sowie zu Entwicklern, die über SedonaDB einen einzelnen Knoten ohne Cluster-Komplexität nutzen wollen. Weniger geeignet ist es für Vorhaben mit wenigen Gigabyte an Geodaten und einer bestehenden Datenbank, weil dort die Cluster-Schicht zusätzlichen Betrieb bedeutet und die README keine Kompatibilitätsmatrix nennt.
- 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. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Java, 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
Apache Sedona 1.9.1 und die Verarbeitung großflächiger Geodaten
Die Kurzbeschreibung des Repositorys apache/sedona nennt ein Cluster-Framework für die Verarbeitung großflächiger Geodaten. Die einzeilige GitHub-Beschreibung ist damit enger als die Selbstbeschreibung im README, das Sedona als räumliche Rechenplattform einführt, die das Laden, Indizieren, Partitionieren und die Abfrageverarbeitung samt Optimierung übernimmt.
Die Metadaten liefern den Rahmen. Hauptsprache ist Java, die Lizenz Apache-2.0, der Standardzweig heißt master. Zum Zeitpunkt der Erhebung weist GitHub 2.392 Sterne, 775 Forks und 98 offene Issues aus, zuletzt gepusht am 5. August 2026. Das jüngste Release ist Apache Sedona 1.9.1 vom selben Tag, davor liegen 1.9.0 vom April 2026 und 1.8.1 vom Januar 2026.
Die Zahl offener Issues ist im Vergleich zu anderen Apache-Projekten dieser Größe niedrig. Das kann auf einen gepflegten Rückstand hindeuten oder auf ein anderes Meldungsverhalten in der Gemeinschaft; eine Begründung dafür gibt das Material nicht.
SedonaDB: Sedona-Unterprojekt für einen einzelnen Knoten
Oben in der README stehen zwei Unterprojekte, die das Projekt als Neuigkeit hervorhebt. SedonaDB wird als Analyse-Datenbank-Engine für einen einzelnen Knoten beschrieben, in der Geodaten als gleichberechtigte Größe behandelt werden. Als Zielgruppe nennt die README Entwickler, die die räumliche Analytik von Sedona ohne die Komplexität verteilter Systeme nutzen wollen.
Diese Einordnung ist eine Ansage gegen die eigene Historie. Ein Cluster-Framework verlangt Planung, Koordinierung und Fehlersuche über Knoten hinweg; wer nur wenige Millionen Geometrien hat, zahlt diese Kosten ohne Gewinn.
Das README verlinkt eine Ankündigung im Blog unter sedona.apache.org, datiert auf den 24. September 2025, sowie eine eigene Seite unter sedona.apache.org/sedonadb. Welche Abfragesprache SedonaDB spricht und wie es sich in bestehende Werkzeuge einbindet, steht im Material nicht.
SpatialBench als Maßstab für räumliche SQL-Abfragen
Das zweite Unterprojekt heißt SpatialBench und wird als umfassender Benchmark beschrieben, der die Abfrageleistung räumlicher SQL-Analytik über Datenbanksysteme hinweg bewertet. Es hat eine eigene Seite unter sedona.apache.org/spatialbench.
Ein solcher Maßstab ist mehr als Eigenwerbung. Räumliche Abfragen verhalten sich anders als tabellarische, weil Selektivität von Geometriegröße und Indexgüte abhängt. Wer zwei Systeme vergleicht, braucht dieselben Datensätze und dieselben Abfragen, sonst misst man Zufall.
Allerdings liegt das Interesse des Anbieters auf der Hand. Ergebnisse eines vom Projekt selbst gepflegten Benchmarks sollte man als selbst berichtet behandeln und nachvollziehen, ob die eigene Abfragemenge darin vorkommt. Zahlen zu konkreten Ergebnissen nennt die README nicht.
Verteilung über Maven, PyPI, conda-forge, CRAN und DockerHub
Eine Tabelle in der README weist die Bezugswege aus. Für Apache Sedona werden über Maven laut README 330.000 Downloads im Monat gezählt; die archivierten GeoSpark-Releases kommen auf 10.000 im Monat. GeoSpark ist der frühere Name des Projekts, sodass hier Altlasten mitlaufen.
Als Paketquellen nennt die README PyPI unter dem Namen apache-sedona, conda-forge, CRAN unter dem Namen apache.sedona und DockerHub unter apache/sedona. Für Python ist damit pip install apache-sedona der greifbare Einstieg, für R entsprechend das Paket apache.sedona, und für Container-Umgebungen das Image apache/sedona.
Diese Breite erklärt, weshalb das Projekt in sehr unterschiedlichen Umgebungen auftaucht. Sie hat aber eine Kehrseite: Versionen von Maven-Artefakt, Python-Paket und R-Paket müssen zueinander passen. Eine Tabelle, welche Paketversion zu welchem Sedona-Release gehört, enthält das Material nicht.
Was das Inhaltsverzeichnis der Sedona-README ankündigt
Das Inhaltsverzeichnis der README gibt einen Überblick über die Abschnitte, auch wenn sie im verfügbaren Material nicht vollständig vorliegen. Unter When to use Sedona? finden sich Anwendungsfälle und ein Codebeispiel, das in vier Schritte zerfällt: Zunächst werden New Yorker Taxifahrten und Taxizonen aus CSV-Dateien auf AWS S3 geladen, dann folgen eine räumliche SQL-Abfrage, die nur Fahrten in Manhattan zurückgibt, ein räumlicher Join zwischen Fahrten- und Zonen-Dataframe sowie die Darstellung mit GeoPandas.
Diese Reihenfolge beschreibt den typischen Arbeitsablauf einer räumlichen Analyse recht genau: laden, filtern, verknüpfen, darstellen. Dass die Darstellung mit GeoPandas erfolgt, zeigt die Anbindung an das Python-Umfeld.
Weitere Abschnitte im Verzeichnis sind Docker image, Building Sedona, Documentation und Powered by. Konkrete Konfigurationsschlüssel für Spark oder Flink stehen im verfügbaren Material nicht.
Community, Apache-2.0 und PostGIS als Alternative
Für die Gemeinschaft nennt die README eine Sprechstunde alle vier Wochen, zu der man sich anmelden soll, sowie eine Mailingliste, für die man sich per leerer E-Mail an dev-subscribe@sedona.apache.org einträgt. Im Repository liegen CI-Workflows unter anderem für Python, pyflink, R und Java, was auf gepflegte Sprachanbindungen hindeutet.
Rechtlich steht Sedona unter Apache License 2.0. Das erlaubt die Nutzung in eigenen Produkten, verlangt die Weitergabe des Lizenztextes und regelt Patentansprüche der Beitragenden.
Als Alternative im räumlichen Umfeld bietet sich PostGIS an. Die Erweiterung für PostgreSQL ist ausgereift, arbeitet transaktional und deckt einen großen Teil der räumlichen SQL-Funktionen ab, skaliert aber über einen Datenbankknoten und nicht über einen Rechencluster. Sedona richtet sich genau auf die andere Seite dieser Grenze: Datenmengen, die auf einem Knoten nicht mehr enden. Wer unterhalb dieser Grenze arbeitet, fährt mit PostGIS kürzer; wer sie überschreitet, findet bei Sedona das passendere Modell.
Redaktionelles Fazit
Sedona passt zu Teams, die Geodaten in einem Cluster verarbeiten müssen und eine Umgebung mit Spark oder Flink betreiben, sowie zu Entwicklern, die über SedonaDB einen einzelnen Knoten ohne Cluster-Komplexität nutzen wollen. Weniger geeignet ist es für Vorhaben mit wenigen Gigabyte an Geodaten und einer bestehenden Datenbank, weil dort die Cluster-Schicht zusätzlichen Betrieb bedeutet und die README keine Kompatibilitätsmatrix nennt. Vor einer Entscheidung sollte mit pip install apache-sedona und dem Stand sedona-1.9.1 ein räumlicher Join auf den eigenen Datenbestand laufen, bevor über einen Umstieg gesprochen wird.
Community-Notizen