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 Gebäude Adressen (Krankenhäuser, Schulen etc.) frühere Ergebnisse DGM (10 m) Zielbereiche Verarbeitung Gebäudedaten Klötzchenmodell, Metadaten DGM 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 Zeitrahmen Gesamtlaufzeit ca. 6 Monate Arbeitsprobe bereits nach ca. 3 Monaten Zusätzliche Anforderungen ggf. Nachbeschaffung von Daten Mehr als 250 Prozess-Schritte! 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 Mehrere Teilesätze: Varianten, Gebrauchtteile Entscheidung über Farbe erst am fertigen Modell Probefahrt mit verkleinertem Modell zur Projekthalbzeit 19.6.2013 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 Ergebnisdaten Auswertung Cadenza PL/SQL Hudson CI Ablaufumgebung Tasks GIS- Bibliotheken Testumgebung Eclipse / Java Das Fabrikgelände SVN 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: Lösung: IO-Operationen! 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 Dipl.-Informatiker Entwicklungsleiter, Leiter Business-Team IT/GIS disy Informationssysteme GmbH Tel. +49 721 16006-228 Fax +49 721 16006-05 torsten.brauer@disy.net disy Informationssysteme GmbH Erbprinzenstraße 4-12 76133 Karlsruhe www.disy.net Tel. +49 721 16006-237 Fax +49 721 16006-05 markus.gebhard@disy.net IT-Lösungen für räumliches Datenmanagement und -analyse