Hochparallele Spatial-Integration umfangreicher heterogener

Hochparallele Spatial-Integration
umfangreicher heterogener Geodaten
disy Informationssysteme GmbH
Wachsender Bedarf zur flächendeckenden Verarbeitung
und Auswertung umfangreicher Datenmengen
Beispiele:
• Belastung durch Verkehrslärm (Straße, Schiene, Flugverkehr)
• Hochwassergefährdung
• Breitband-/Mobilabdeckung
Bildquelle: http://www.soundplan-uk.com/Graphics.html
→ Flächendeckend sichere Aussagen zu Belastung/Gefährdung/Versorgung
→ Verbesserungsbedarf und Potenzial ermitteln
19.6.2013
2
Projektauftrag – Überblick
Eingangsdaten
Adressen
(Krankenhäuser,
Schulen etc.)
Gebäude
frühere
Ergebnisse
Zielbereiche
DGM (10 m)
Verarbeitung
Gebäudedaten
DGM
Klötzchenmodell, Metadaten
als TIN
Ergebnisdaten
19.6.2013
3
Projektauftrag – Beispiele durchzuführender Verarbeitungsschritte
• Auswahl tatsächlich zu verwendender Eingangsdaten
• Korrektur (SDO-Konformität)
• Vereinfachung der Geometrien (Datenreduktion!)
63
5
• Vereinheitlichung der Koordinatensysteme
• Prüfung auf Vollständigkeit
• Zusammenführung der Einzeldatensätze
• Zuordnung Adressen zu Gebäuden (Nutzung)
• Triangulierung und Ausdünnen des DGM
• Zuordnung DGM-Höhe zu Gebäude
• Reduktion auf Zielbereiche
• …
19.6.2013
4
Herausforderungen des Projekts (1)
Datenmenge: ca. 150 GB Rohdaten
• 30.000 Dateien mit Gebäudedaten (ca. 90 Mio. Gebäude)
• > 30 Mio. Adressdatensätze
• > 75 GB Höhendaten DGM 10 m
Datenqualität:
Ausgangsdaten:
Aus > 50 verschiedenen Quellen
Unterschiedliche Dateiformate
Redundante, teils widersprüchliche Daten
Unbekannte, oft nicht ausreichende Qualität
Anforderungen an die Ergebnisse:
Geeignet als Grundlage weiterer Berechnungen
Anforderungen aus EU-Vorgaben
19.6.2013
5
Herausforderungen des Projekts (2)
Komplexität
Mehr als 250 Prozess-Schritte!
Zeitrahmen
• Gesamtlaufzeit ca. 6 Monate
• Arbeitsprobe bereits nach ca. 3 Monaten
Zusätzliche Anforderungen
• ggf. Nachbeschaffung von Daten
• Jederzeit kurzfristig: Abgabe einer Arbeitsprobe
• Anzusetzende Qualitätsmaßstäbe sind interaktiv mit dem Auftraggeber
abzustimmen
• …
19.6.2013
6
Projektaufgabe in einer Metapher
19.6.2013
7
Projektaufgabe in einer Metapher
Rohmaterial
Probefahrt mit
verkleinertem Modell
zur Projekthalbzeit
Entscheidung über
Farbe erst am
fertigen Modell
19.6.2013
Mehrere Teilesätze:
Varianten,
Gebrauchtteile
8
Unser Lösungsansatz in der Metapher
Hochflexibel
Schnell
Präzise
Wir bauen eine Fabrik!
…und produzieren bereits,
während sich die Fabrik
noch im Aufbau befindet!
19.6.2013
9
Der Lösungsansatz im Projekt – Übersicht
Ausgangsdaten
Auswertung
Ergebnisdaten
Cadenza
PL/SQL
Hudson CI
Ablaufumgebung
Tasks
GIS-
Testumgebung
Bibliotheken
Eclipse / Java
SVN
Das Fabrikgelände
19.6.2013
10
Modellierung der Prozess-Schritte
Zustand jedes Datensatzes: Statustabellen in der Datenbank
Status-Flag
Prozess-Schritte: Zeitstempel
Task = Java-Klasse
• Führt einen fachlichen Prozess-Schritt aus
• Bearbeitet jeweils eine atomare Dateneinheit
• Nutzt wahlweise PL/SQL, Java GIS-Bibliotheken, Java+SQL, …
Task-Ausführung: einfache, Java-basierte Ablaufumgebung
19.6.2013
11
Infrastruktur
Bottleneck:
IO-Operationen!
Lösung:
Die Datenbank liegt auf einer 250GB RAM-Disk
Bewusster Verzicht auf Sicherheit zugunsten von Performance!
Dedizierter Datenbankrechner:
• 2 x E5-2660 8C mit HT + Turbo (entspr. 32 CPUs)
• 384GB RAM
• 2 x 10 Gbit
+ weitere flankierende Systeme
19.6.2013
12
Backup-Strategie
Backup nur dediziert durch Anhalten der Datenbank
ca. 2 mal wöchentlich, Entscheidung durch Rechenbetreuer
Nachteile:
Systemausfall = Verlust mehrerer Tage Rechenzeit
Anhalten kostet Zeit:
• Overhead „Laufende Tasks zu Ende rechnen lassen“
• 15min Spiegeln der Daten auf Storage-System
Erfahrung:
Ausfallrisiko 2 Mal eingetreten:
• Schreiben der RAM-Disk gescheitert
• Unkontrollierter Shutdown durch Bedienfehler
Gesamtstrategie durch hohe Performance während der
Gesamtrechenzeit über viele Wochen erfolgreich
19.6.2013
13
Parallelisierung
Ziele:
•
•
Optimale Nutzung der CPUs
Keine Verzögerung durch unfertige
Prozess-Schritte
Strategie:
•
•
Beliebige Tasks laufen parallel
Unabhängige Datensätze werden
parallel verarbeitet
Umsetzung:
•
•
Aufbrechen in kleine, unabhängige Schritte
Modellierung über Status: „Pausiert“
Erfahrungen:
•
•
24 Threads bei 32 Kernen guter Wert
Falle: Zeitaufwändige Aktualisierung von Indexen
insbes. Schreiben mehrerer Threads in dieselbe Tabelle
→ permanentes Monitoring der Performance, Indexe temporär deaktivieren
19.6.2013
14
Leistungsfähigkeit von Oracle Spatial – Beispiel-Prozess-Schritt
Vereinigung
gepufferter
Gebäudepolygone
PROCEDURE merge_big(v_table_id IN NUMBER)
IS
v_tablename VARCHAR2(38) := 'tmp_simple_buffered_' || v_table_id;
l_merged_buffer MDSYS.sdo_geometry;
BEGIN
EXECUTE IMMEDIATE
'select SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE(buffered, 0.005)) GEOM
FROM ' || v_tablename
INTO l_merged_buffer;
EXECUTE IMMEDIATE 'delete from tmp_big_merged_buffers where identifier = :table_id'
USING v_table_id;
EXECUTE IMMEDIATE
'insert into tmp_big_merged_buffers(identifier, geometry) values (:identifier, :geometry)'
USING v_table_id, l_merged_buffer;
END;
Konkretes Beispiel: 365.441 Gebäudepolygone (3,3 Mio. Stützpunkte)
Rechenzeit: 3,5 Tage
→ Sehr gute Leistungsfähigkeit für große Aufgaben
19.6.2013
15
Zuverlässigkeit von Oracle Spatial
Bugs in Oracle Spatial:
• In Projekten dieser Größe stößt man zwangsläufig auf Fehler!
• Für Softwareprodukte dieser Größe ist das normal!
Positive Erfahrungen:
• Die wenigsten Fehler waren kritisch
• Die meisten waren kurz zuvor behoben worden, Patches verfügbar
• Es gibt oft Alternativwege (oft nicht offiziell dokumentiert)
• Oft die Rettung: Hints
Strategie im Projekt:
• Nicht lange an Fehlern aufhalten!
• Stattdessen alternativen Weg oder Technologie nutzen
→ Die Zuverlässigkeit ist in Anbetracht des Funktionsumfangs gut
19.6.2013
16
Oracle Spatial Geocoder: Zuordnung von Adressen zu Gebäuden
Nachteil: Hoher initialer Aufwand
• Dokumentation: Fokus auf Nutzung einer bestehenden
Geocoder-Befüllung
• Geht nicht Out-of-the-Box (Patch p15926096)
• Aufbau/Befüllen des komplexen Schemas nicht trivial!
Vorteile:
• Unscharfes Matching mit Ausgabe eines Match-Vektors
• Detaillierte Rückschlüsse auf Qualität der Treffer möglich
• Auch nutzbar, wenn man nur Teile des Schemas befüllt
Hat sich sehr gut bewährt für die Verarbeitung der
vorliegenden Rohdaten
→ Separates zukünftiges Vortragsthema?
19.6.2013
17
Wichtige Aspekte im Vorgehen
Konsistenz
Daten und Zustand jederzeit in der Datenbank
Inkrementelles Vorgehen
Tasks werden im laufenden Betrieb ergänzt und erweitert
Daten werden soweit verarbeitet, wie technisch jeweils bereits möglich
Flexibilität in der Werkzeugwahl
PL/SQL, Java GIS-Bibliotheken, Java+SQL, …
Agiles Vorgehen
Anwendung agiler Techniken zum Aufbau der „Fabrik“
Do the simplest thing that could possibly work
Transparenz – keine Black Box
Zustandstabellen → Fortschritt, Status
Zwischentabellen → Nachvollziehbarkeit
Automatisierung
Faktor Mensch nur da, wo er einen Mehrwert bringt
Qualität
Testabdeckung
Nachvollziehbarkeit durch Protokollierung in der Datenbank
19.6.2013
18
Ergebnis des Projekts, Fazit
Projektabschluss: in Time und in Budget
→ Hochautomatisierte Datenverarbeitung kann auch für einmalige
Datenaufbereitung eine Alternative zu traditionellen Herangehensweisen sein
→ Oracle Spatial ist eine leistungsfähige und verlässliche Kernkomponente einer
solchen Lösung
Das produzierte Auto entspricht den
hohen Erwartungen des Kunden
Das Auto ist pünktlich zum Termin vom Band gelaufen
…obwohl die Fabrik erst zwei Tage zuvor fertiggestellt wurde
19.6.2013
19
Sie haben Fragen, Anmerkungen, ähnliche oder gar
konträre Erfahrungen?
Sprechen Sie
uns bitte an,
wir freuen uns:
Torsten Brauer
Dipl.-Geoökol.
Berater, Projektleiter
Markus Gebhard
disy Informationssysteme GmbH
Dipl.-Informatiker
Entwicklungsleiter,
Leiter Business-Team IT/GIS
Tel. +49 721 16006-228
Fax +49 721 16006-05
[email protected]
disy Informationssysteme GmbH
Erbprinzenstraße 4-12
76133 Karlsruhe
www.disy.net
Tel. +49 721 16006-237
Fax +49 721 16006-05
[email protected]
IT-Lösungen für räumliches Datenmanagement und -analyse