Geocoding wandelt Adressen in geografische Koordinaten um und ist ein zentraler Bestandteil vieler Datenprozesse. In diesem Beitrag stellen wir einige Tipps und Tricks vor, wie Sie die Geocoding-Leistung in Ihrem Spark-Cluster mit der GeoAnalytics Engine gezielt verbessern können.
Geocoding ist der Prozess, bei dem Adressen in geografische Koordinaten umgewandelt werden, und stellt eine häufige Aufgabe in vielen Datenverarbeitungs-Pipelines dar. Die ArcGIS GeoAnalytics Engine enthält Geocoding-Tools, die die Skalierbarkeit von Apache Spark nutzen, um große Mengen von Adressen und Standorten schnell zu verarbeiten. In diesem Beitrag stellen wir einige Tipps und Tricks vor, worauf Sie in Ihrem Spark-Cluster achten sollten, um die Geocoding-Leistung mit der GeoAnalytics Engine zu verbessern.
Partitionierung: Der Schlüssel zur Verbesserung der Geocoding-Leistung
In Spark spielt die Datenpartitionierung eine entscheidende Rolle für die Geocoding-Leistung. Um die Gründe dafür nachvollziehen zu können, ist es hilfreich, zunächst zu verstehen, wie Spark einen Auftrag verarbeitet.
Spark-Grundlagen
Wenn Spark einen Auftrag verarbeitet, unterteilt es die Arbeit in kleinere Einheiten, sogenannte Tasks (Aufgaben). Eine Task ist die Ausführung einer Operation auf einem einzelnen Datenabschnitt – zum Beispiel das Geocodieren eines Satzes von Adressen. Jeder Datenabschnitt wird als Partition bezeichnet und stellt eine Teilmenge der Eingangsdaten dar, etwa einen Teil einer CSV- oder Parquet-Datei.
Spark verteilt die Tasks auf die Workerknoten in einem Cluster. Jeder Workerknoten führt Prozesse aus, die als Executor bezeichnet werden und die Tasks parallel verarbeiten – typischerweise eine Task pro Kern. Das bedeutet, dass die Partitionierung die Anzahl der Tasks und damit den Grad der Parallelisierung bestimmt, den Ihr Cluster erreichen kann.
Weitere Informationen zur Spark-Architektur finden Sie in der Spark-Dokumentation zum Thema Cluster-Architektur.
Was das für das Geocoding bedeutet
Spark versucht, die Eingangsdaten optimal zu partitionieren, aber wir empfehlen, die Partitionierung zu überprüfen und gegebenenfalls festzulegen, um sicherzustellen, dass es in Ihrem Cluster für die beste Geocoding-Leistung 2–4 Partitionen pro Kern gibt.
So überprüfen und ändern Sie Partitionen
- Überprüfen der Partitionen: Sie können die Anzahl der Partitionen in einem DataFrame mit folgendem Code überprüfen:
df.rdd.getNumPartitions()
- Neu-Partitionierung von DataFrames: Durch die Neu-Partitionierung kann die Arbeitslast effizienter auf Executor und Worker verteilt werden. Wenn Sie die Partitionierung optimieren möchten, können Sie Ihr DataFrame mit der Methode .repartition() neu partitionieren. Sie können sparkContext.defaultParallelism verwenden, um eine geeignete Anzahl von Partitionen abzuschätzen.
# Get the current number of partitions in the DataFrame
num_partitions = df.rdd.getNumPartitions()
# Get the number of available cores in the Spark cluster
available_cores = spark.sparkContext.defaultParallelism
# Check if the number of partitions is less than twice the available cores
if num_partitions < (available_cores * 2):
# Set the minimum target number of partitions to 2x the available cores min_target_partitions = available_cores *2
# Repartition the DataFrame to improve parallelism df = df.repartition(min_target_partitions)
Verfügbare Kerne in einem automatisch skalierenden Cluster
Spark verfügt über eingebaute Mechanismen, um die Anzahl der Executor und den Parallelisierungsgrad während eines Jobs anzupassen. Beachten Sie jedoch, dass automatisches Skalieren nicht immer zu einer optimalen Partitionierungsstrategie führt. Die Standardparallelisierung wird häufig auf die Anzahl der Kerne aller Executor gesetzt, die beim Initialisieren der Spark-Session verfügbar sind.
Wenn Sie beispielsweise ein automatisch skalierendes Cluster mit 3 Knoten starten und später auf 10 Knoten hochskalieren, gibt spark.sparkContext.defaultParallelism nur die Anzahl der Kerne in den ursprünglichen 3 Knoten zurück, die beim Start der Spark-Anwendung verfügbar waren.
Um dies zu vermeiden, empfehlen wir, Ihre Eingangsdaten auf das 2–4-fache der Anzahl der Kerne im Cluster bei voller Skalierung neu zu partitionieren. Dies kann zwar zu einem leichten Overhead führen, wenn das Cluster nicht hochskaliert ist, stellt aber eine effiziente Ressourcennutzung sicher, sobald das Cluster seine maximale Kapazität erreicht.
Im obigen Beispiel mit einer maximalen Kapazität von 10 Workerknoten und insgesamt 40 Kernen (jeder Knoten hat 4 Kerne) sollten Sie das Eingabe-DataFrame mindestens auf 80 Partitionen (210 Workerknoten4 Kerne/Knoten) neu partitionieren.
Locator-Nähe: Daten lokal halten
Beim Arbeiten mit Geocoding in der GeoAnalytics Engine ist es ein weiterer Leistungsfaktor, die Locator-Dateien möglichst nah am Spark-Cluster zu halten. Idealerweise sollten Geocoding-Tools mit lokal gespeicherten Locators arbeiten, entweder auf der Festplatte oder im Arbeitsspeicher, um Leistungseinbußen durch Netzwerkzugriffe zu vermeiden.
- Locator-Dateien mit Init-Skripten von Cloud-Speicher lokal auf die Festplatte kopieren: Sie können die Locator-Dateien mit einem Init-Skript auf jeden Workerknoten Ihres Spark-Clusters kopieren. Dies muss beim Erstellen des Spark-Clusters erfolgen.
- addFile: Sie können auch die Funktion sc.addFile verwenden, um die Locator-Datei nach der Initialisierung von Spark zu jedem Workerknoten hinzuzufügen.
Weitere ausführliche Beispiele finden Sie in der GeoAnalytics-Dokumentation zur Einrichtung von Locator und Netzwerk-Dataset.
Arbeitsspeichergröße der Worker
Ein weiterer wichtiger Faktor zur Verbesserung der Geocoding-Leistung ist die Optimierung der Arbeitsspeichergröße der Worker im Verhältnis zur Größe der Locator-Datei. Da das Lesen aus dem Locator häufig der Engpass bei einer Geocoding-Operation ist, versucht die GeoAnalytics Engine, den Locator mithilfe eines Prozesses namens Memory Mapping in den Arbeitsspeicher zu laden. Dadurch wird das Geocoding beschleunigt, da das Lesen aus dem Arbeitsspeicher wesentlich schneller ist als von der Festplatte.
Damit diese Optimierung greift, ist es wichtig, dass der Workerknoten über genügend verfügbaren Arbeitsspeicher verfügt, um den Locator zu speichern.
Empfohlene Speicherformel
Für jeden Worker beträgt die empfohlene minimale Arbeitsspeichergröße für Geocoding-Operationen:
Empfohlener Mindestarbeitsspeicher = Locator-Größe + (Locator-Größe * Anzahl der Kerne pro Worker / 20)
Zum Beispiel sollten Sie auf Azure Databricks mit dem ArcGIS StreetMap Premium North America Locator (ca. 20 GB) einen Worker-Knoten mit 4 Kernen und mindestens 24 GB Arbeitsspeicher wählen.
Weitere Leistungsaspekte
Neben der Optimierung Ihrer Spark-Umgebung sollten Sie auch den Einfluss der Qualität Ihrer Adressdaten, des Analyseumfangs sowie des benötigten Auflösungsgrades der Geocodes berücksichtigen.
Adressqualität: Sie werden wahrscheinlich eine Verlangsamung der Leistung feststellen, wenn Adresszeichenfolgen Tippfehler, fehlende Informationen (z. B. keine Straßenrichtung wie „Nordost“ oder kein Straßenendungszusatz wie „Straße“, „Weg“, „Blvd“), oder die Verwendung nicht standardisierter Abkürzungen für Straßennamen, Bundesland oder Land usw. enthalten.
Analyseumfang: Achten Sie bei der Auswahl eines Locators darauf, dass dessen räumliche Ausdehnung die Ihrer Eingabeadressen abdeckt. Wenn Ihr Datensatz beispielsweise hauptsächlich Adressen aus Boston enthält, ist es am besten, einen Locator zu verwenden, der auf diese Region fokussiert ist, z. B. einen Stadt- oder Bundesland-Locator.
In manchen Fällen ist ein Locator mit größerer räumlicher Ausdehnung erforderlich – etwa ein US-weiter Locator für einen Datensatz, der zwar hauptsächlich Adressen aus Boston enthält, aber auch einzelne Ausreißer-Adressen entlang der Ostküste. Beachten Sie jedoch, dass die Verwendung eines Locators mit deutlich größerer räumlicher Ausdehnung als nötig die Verarbeitungszeit erhöhen kann, da es länger dauert, die größere Locator-Datei nach Übereinstimmungen zu durchsuchen.
Auflösungsgrad: Das Geocoding ist in der Regel schneller für allgemeinere Standorte, z. B. wenn ein geokodierter Punkt auf Stadt- oder Postleitzahlenebene zurückgegeben wird statt auf Adress- oder Flurstücksebene.
Eingabedatenformate: Speichern Sie Adressen mit hohem Datenvolumen nach Möglichkeit in spaltenbasierten Speicherformaten wie Parquet und ORC. Diese unterstützen effiziente Komprimierung und Predicate Pushdown und bieten in der Regel deutlich schnellere Leseleistung im Vergleich zu zeilenbasierten Formaten wie CSV oder JSON. Außerdem können große, unkomprimierte Textdateien erhebliche Netzwerk- und Festplattenressourcen beanspruchen, was zu erhöhtem I/O-Overhead und langsamerer Verarbeitung in Spark führt.
Fazit
Die Verbesserung der Geocoding-Leistung in der ArcGIS GeoAnalytics Engine erfordert einen durchdachten Ansatz bei der Spark-Konfiguration, der Datenpartitionierung, dem Speichermanagement und der Platzierung der Locator-Dateien. Testen und Iterieren auf Basis Ihrer eigenen Daten und Infrastruktur liefert die besten Ergebnisse, aber durch Anwendung der in diesem Beitrag beschriebenen Best Practices – wie das Abstimmen der Partitionierungsanzahl, das lokale Speichern der Locator-Dateien und das Sicherstellen von ausreichend Arbeitsspeicher auf jedem Worker – können Sie die Geschwindigkeit und Effizienz Ihrer Geocoding-Workflows deutlich steigern.
So haben wir beispielsweise einen Datensatz mit 125 Millionen US-Gebäudeadressen (basierend auf dem Microsoft Building Footprint Dataset) mit verschiedenen Partitionierungsschemata getestet. Ohne Neu-Partitionierung benötigt das Geocode-Tool etwa 4,38 Stunden zur Verarbeitung auf einem Cluster mit 400 Kernen, mit Neu-Partitionierung sind es nur 2,87 Stunden. Diese Anpassung innerhalb der GeoAnalytics Engine macht einen erheblichen Unterschied in der Performance.
Wir hoffen, dass diese Informationen zum Geocoding hilfreich für Ihre Analyse-Workflows sind! Wir sind gespannt, was Sie mit den Geocoding-Tools in der GeoAnalytics Engine umsetzen.
Dieser Beitrag ist eine Übersetzung des amerikanischen Original-Beitrags.
Hier geht es zum Original-Beitrag!
