Hochparallele Spatial-Integration umfangreicher heterogener Geodaten. disy Informationssysteme GmbH

Transkript

1 Hochparallele Spatial-Integration umfangreicher heterogener Geodaten disy Informationssysteme GmbH

2 Wachsender Bedarf zur flächendeckenden Verarbeitung und Auswertung umfangreicher Datenmengen Beispiele: Belastung durch Verkehrslärm (Straße, Schiene, Flugverkehr) Hochwassergefährdung Breitband-/Mobilabdeckung Bildquelle: Flächendeckend sichere Aussagen zu Belastung/Gefährdung/Versorgung Verbesserungsbedarf und Potenzial ermitteln

3 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

4 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

5 Herausforderungen des Projekts (1) Datenmenge: ca. 150 GB Rohdaten 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

6 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

7 Projektaufgabe in einer Metapher

8 Projektaufgabe in einer Metapher Rohmaterial Mehrere Teilesätze: Varianten, Gebrauchtteile Entscheidung über Farbe erst am fertigen Modell Probefahrt mit verkleinertem Modell zur Projekthalbzeit

9 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!

10 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

11 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

12 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 E C mit HT + Turbo (entspr. 32 CPUs) 384GB RAM 2 x 10 Gbit + weitere flankierende Systeme

13 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

14 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

15 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: Gebäudepolygone (3,3 Mio. Stützpunkte) Rechenzeit: 3,5 Tage Sehr gute Leistungsfähigkeit für große Aufgaben

16 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

17 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 p ) 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?

18 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 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

20 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 Fax disy Informationssysteme GmbH Erbprinzenstraße Karlsruhe Tel Fax IT-Lösungen für räumliches Datenmanagement und -analyse