Geodatenmanagement mit GRETL
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 96 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/40685 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
10
17
18
20
22
32
33
41
45
55
56
62
69
71
78
79
82
84
85
88
92
00:00
Manufacturing Execution SystemProzessautomationVorlesung/Konferenz
00:45
GeodateninfrastrukturServerMAPClientWEBGeoinformationServerGeodateninfrastrukturComputeranimation
01:43
GeodateninfrastrukturPHPFehlerbehandlungServerGeodateninfrastrukturVorlesung/KonferenzBesprechung/InterviewXMLComputeranimation
02:36
LastLogdateiMomentenproblemSkriptspracheBefehl <Informatik>FehlerbehandlungDatenbankServer
04:38
SoftwareMinimalgradGebäude <Mathematik>Plug inEXTRACTp-BlockPlug inSoftwareTabelleURLInformationSkriptspracheDatenflussComputeranimation
07:54
GRADESoftwareCodeVorlesung/Konferenz
08:20
Plug inEXTRACTCodeKrankenhausinformationssystemEXTRACTDatenbankVersion <Informatik>Computeranimation
10:59
AnalogieschlussVorlesung/Konferenz
12:16
EXTRACTSQLFehlermeldungTaskPlug inDownloadingDateiJenkins CIServerRepository <Informatik>Feinstruktur <Mengenlehre>Jenkins CIVerschlingungDatensatzSQLDatenbankTaskFunktionalitätPlug inSkriptspracheKomponente <Software>DateiServerSoftwareRepository <Informatik>LogarithmusLoginDownloadingTyp <Informatik>PasswortXML
21:39
Vorlesung/KonferenzComputeranimation
22:11
Jenkins CI
22:55
MaximumDatenstromUploadingDatenbanksystemZugriffDatenbankVorlesung/Konferenz
25:45
Inferenz <Künstliche Intelligenz>
Transkript: Deutsch(automatisch erzeugt)
00:08
Herzlich willkommen zum letzten Vortrag für heute. Es geht weiter mit der Automatisierung und zwar Andreas Schmidt wird uns über Geo-Datamanagement mit Gretel erzählen. Der Name ist schon sehr vielversprechend und bin ich gespannt,
00:23
was sich dahinter verbirgt. Vielen Dank. Ja, hallo zusammen, mein Name ist Andreas Schmid. Ich erzähle euch über Geo-Datamanagement mit Gretel. Schön, dass sich doch noch einige hier eingefunden haben, auch zu dieser späten Stunde. Kurz über mich, ich bin
00:46
Geomatikingenieur und arbeite beim Amt für Geoinformation des Kantons Solothurn in der Schweiz. Ich habe euch das auf der Karte markiert, wo der Kanton Solothurn liegt. Wir betreiben die kantonale Geodateninfrastruktur und
01:06
zwar setzen wir hierfür schon seit circa 2001 Open-Source-GIS-Software ein. Das hat angefangen mit Map Server und Post-GIS. Irgendwann ist QGIS dazugekommen, irgendwann haben wir auf QGIS Server umgestellt und seit
01:25
kurzem ist auch eine neue Web-GIS Client Anwendung online, die auf QGIS Web Client basiert und weil wir, weil einige Dinge schon sehr alt sind,
01:42
stellen wir eigentlich alles um und da ist auch das Gretel fürs Geodatenmanagement hinzugekommen. Ich habe es schon erwähnt, quasi Ausgangslage. Wir haben schon rund 15 Jahre die bisherige
02:04
Geodateninfrastruktur im Betrieb und ein Aspekt davon waren immer die Datenimport- und Datenexport-Skripte und die waren nach dieser doch schon langen Zeit einfach nicht mehr überblickbar.
02:20
Einerseits waren sie oder sind sie, die sind sie immer noch in in unterschiedlichen Sprachen geschrieben, da gab es und gibt es Shellscripts und PHP-Skripts, meistens in uralten Versionen. Irgendwann sind Python-Skripts dazugekommen. Ein sehr wichtiger Import ist direkt in Java geschrieben und wahrscheinlich gibt es noch einige Sprachen mehr,
02:47
die ich da nicht aufgefunden habe. Dann nutzen die Import-Skripte auch unterschiedliche Werkzeuge, wenn sie irgendwelche externe Befehle aufrufen, beispielsweise Ogre2Ogre oder SAP2PG SQL, um Daten von einem
03:05
Shape-Format in die Posgis Datenbank zu importieren. Vielfach ist die Logik auch irgendwo in Datenbankfunktionen auf der Posgis Datenbank versteckt oder sogar irgendwo in komplizierten Views, die
03:21
dann auf irgendeine Art materialisiert werden, was dem Überblick leider nicht förderlich war. Und dann weisen die Skripte auch unterschiedliche Qualitätsstandards auf, gerade bezüglich Logging oder Fehlerbehandlung und dann auch bezüglich Überwachung. Gibt es Skripte, die da sehr vorbildlich programmiert sind und
03:43
andere, die beispielsweise genau im kritischen Moment halt eben nichts loggen. Und zu guter letzt sind all diese Skripte und Jobs auf unterschiedlichen Umgebungen. Meistens sind es Cron-Jobs, die aber zuerst
04:03
mal auf dem einen Server installiert wurden. Irgendwann wurden die neuen auf einem neuen Server installiert. Und sie sind zudem auch noch über verschiedene Benutzer-Accounts verteilt, weil man ein bestimmtes Skript eben
04:20
über die Cron-Table eines bestimmten Users laufen haben wollte, damit das mit den Berechtigungen stimmt. Aber wie schon gesagt, um irgendeinen bestimmten Job dann zu finden, muss man zuerst sehr lange suchen. Dazu gibt es ja das bekannte Kinderlicht. Und das passt sehr gut
04:43
auf unsere Situation. Auch wir verliefen uns in einem gewissen Sinn im Wald. Und es war so finster und auch so bitterkalt. Wir haben uns irgendwann einfach nicht mehr zurechtgefunden. Und wir haben gemerkt, da muss eine neue Lösung her. So die erste naheliegendste Variante
05:05
wäre gewesen, weiter wie bisher, aber besser. Wir hätten also einfach alle Skripts neu schreiben müssen, möglichst in guter Qualität. Aber wir hatten das Gefühl, da muss es noch etwas Besseres geben, etwas anderes.
05:22
Und haben uns auf die Suche gemacht. Und so langsam hat sich dann diese andere Lösung abgezeichnet. Und ich muss sagen, das ist wirklich eine coole Lösung. Und wir nennen sie eben Gretel. Ich komme noch dazu, weshalb die so heißt. Wir haben realisiert, dass so ein Geo-Datenfluss
05:43
oder allgemeinen Datenfluss oder eben ein Datenimport oder Daten-Export in aller Regel eine Verkettung von einzelnen Schritten ist, was sich da in der oberen Grafik so symbolisch dargestellt habe. Und dass es hier eine Analogie zum Bauen von Software gibt. Auch wenn man eine Software
06:04
publiziert, wird die zuerst kompiliert, dann laufen Tests, dann wird die paketiert, wird irgendwo hochgeladen und bereitgestellt usw. Und unser Credo war, dass wir möglichst auf bestehendem aufbauen wollen, eben nicht das Rad neu erfinden wollen. Und sind dann auf das Gretel-Build-Tool
06:23
gestoßen, das ich da mit der URL angegeben habe. Ist eben ein Tool ursprünglich, um Software zu bilden. Und der große Vorteil, den wir bei Gretel gesehen haben, ist, dass das diese Verkettungslogik übernimmt.
06:43
Nämlich, wenn ein Step-Fail schlägt, schlägt der ganze Job-Fail. Und das ist auch das, was wir wollen, damit nicht irgendwelche halben Sachen rauskommen. Zum Beispiel ein klassischer Fall in den alten Skripten. Es wird zunächst der Inhalt einer Tabelle komplett gelöscht,
07:00
weil ja neue Daten kommen. Wenn aber das File, das da importiert werden soll, leer ist oder einfach nicht da ist, dann bleibt am Schluss eine leere Tabelle zurück. Und solche Sachen, eben mangels kompletter Überwachung der Import-Skripte, haben wir meistens erst angemerkt, wenn
07:21
ein Kunde reklamiert hat, weil er eine leere Tabelle gefunden hat. Nun zu Gretel. Gretel haben wir als Plugin für Gradle umgesetzt. Gradle lässt sich eben erweitern mit Plugins. Ich habe da die URL
07:41
aufgeführt, wo man eine kurze Information über dieses Plugin findet, wie man es dann eben benutzt. Und damit komme ich auch zum Namen. Gretel ist eben ein ETL-Werkzeug. ETL steht für Extract Transform Load. Das kennen sicher einige. Quasi eben ein Tool, das Daten von
08:05
irgendwo extrahieren kann, sie umbauen kann und wieder in eine andere Daten-, in eine Zieldatenquelle laden kann. Und es baut auf Gradle auf. Und deshalb sind wir auf den Namen Gretel gestoßen, gekommen. Den Code von Gretel findet man auf GitHub. Und die Software
08:31
steht unter der MIT-License, das eine Open Source-Lizenz ist. Nun zu
08:41
den eigentlichen Features von Gretel. Gretel bietet sogenannte Steps an. Zunächst einmal für Import und Export von Daten, was quasi den Extract und Load Teil von ETL abdeckt. Da ist zunächst einmal der db2db-Step.
09:07
Mit diesem kann man Daten von einer Datenbank in eine andere kopieren. Das benutzen wir seit neuem sehr, sehr häufig, weil wir, bisher haben wir
09:21
eigentlich mit fast nur einer riesigen Datenbank gearbeitet. Neu trennen wir das auf und führen eine Erfassungsdatenbank und eine Publikationsdatenbank. Und da gibt es entsprechend sehr viele Jobs, die eben die Erfassungsdaten aus der Erfassungsdatenbank in die Publikationsdatenbank kopieren. Dann ein weiteres, sehr wichtiges,
09:45
sehr wichtiger Teil von Gretel sind viele Interlis-Steps. Mathias Kuhn hat in seinem Beitrag schon über Interlis gesprochen. Was das ist, ich möchte es kurz fassen, quasi beim Sterneintrag unten. Es ist eine
10:06
Beschreibung und Transfermechanismus für Geodaten, das eben eine Schweizer Norm ist, die seit 2003 existiert, in einer früheren Version sogar schon seit früher. Und diese Interlis-Steps, die nutzen
10:24
Illytopege, das Mathias Kuhn auch schon, das auch in seinem Beitrag vorgekommen ist. Mit Illytopege kann man, das ist bei mir jetzt an der letzten Stelle, quasi ein Schema importieren gemäss einem Interlis-Modell.
10:45
Das ist der Illytopege Imported Schema Step. Illytopege kann aber auch Daten eben gemäss dem Modell importieren oder gemäss dem Modell aus einem Schema exportieren. Und dann bietet es sogar noch Illytopege
11:01
Replace und Illytopege Update, um nur Teildatensätze zu importieren. Und dann ist da noch der Illy-Validator, der dient dazu, Interlis-Daten, die wir geliefert bekommen, zu validieren, ob sie einem Interlis-Modell entsprechen. Dann gibt es quasi fast das Analoge auch
11:24
für das CSV-Format, CSV-Export, CSV-Import und CSV-Validator. Auch CSV-Daten können wir so gegen ein Interlis-Modell validieren. Das ist noch speziell, aber eben sehr elegant. Dann kommt das gute,
11:46
dass wir das auch mit reingenommen haben. Wir haben es bis jetzt nicht mal wirklich eingesetzt. Ich hoffe, das wird so bleiben. Und das ist in der übernächsten Zeile, also Ausblick, Geo-Package soll da in Balde auch
12:01
noch dazukommen. Und dann habe ich sie sehen. Mein Chef hat da vor kurzem noch was eingebaut, den Postis-Raster-Export, um eben Raster-Daten, die in einer Postis-Datenbank vorliegen, in ein Bildformat zu exportieren.
12:23
Dann der andere Teil. Das ist ein Gettelstep für den Datenumbau, eben für den Transform-Teil von ETL, ist der sogenannte SQL-Executor. Der kann innerhalb einer DB, einer Datenbank, einen Datenumbau machen, indem man ihm einfach beliebiges SQL mitgeben kann,
12:46
das er dann auf der Datenbank ausführt. Da kann man dann auch ganz viele vielleicht nicht so offensichtliche Dinge machen. Man kann eigentlich eine ganze Datenbank mit Inhalt füllen, mit der man irgendwie zu arbeiten beginnen möchte. Mit diesen Steps ist eben Gettel schon ein ETL-Werkzeug.
13:15
Wir nennen es Datenbankzentrisch, weil es auf der Funktionalität
13:21
von einer Datenbank, von einer Postis-Datenbank basiert und auch weil die Sprache, um so einen Datenumbau von einem Modell in ein anderes Modell zu erreichen, einfach SQL ist. Das hat den grossen Vorteil, dass man nicht noch eine zusätzliche Sprache oder eine bestimmte Software erlernen muss, sondern wenn man SQL kann, kann man Datenumbauten machen mit Gettel.
13:47
Hervorzuheben und sehr sinnvoll finde ich die Trennung durch diese einzelnen Steps von Datenimport und Datenumbau. Wir haben in unseren alten Skripten das teilweise vermischt und das hat eigentlich fast nur Nachteile.
14:07
Und dann ist Gettel schön modular, weil das mit den einzelnen Steps funktioniert. Es lässt sich also problemlos erweitern um einzelne Steps.
14:22
Nun, wie sieht so ein Grettel-Job aus? Ich habe da quasi das Hello Grettel Beispiel zusammengestellt. Am Anfang gibt es man an, wo es einige Abhängigkeiten, eben gerade Interlis-Abhängigkeiten findet, die es braucht
14:40
und da im Pluginsbereich gibt man an, dass man eben das Grettel-Plugin verwenden will, dann noch ein, zwei Importzeilen und dann kommt eigentlich der eigentliche Task. Ich habe ihn Hello Grettel genannt, man muss ihm einen Namen geben, angeben von welchem Typ er ist. Es ist ein DB2DB-Typ.
15:03
Dann gibt man ihm per JBC die Verbindung zur Quell- und zur Zieldatenbank an mit Benutzname und Passwort und kann ihm dann eins bis mehrere Transfer-Sets übergeben. Transfer-Set umfasst eine SQL-Query,
15:25
die in einem File vorliegen muss. Mit dieser werden Daten aus der Quell-Datenbank geholt und dann gibt man ihm an das Zielschema, die Zieltabelle, wohin denn diese Daten sollen und wenn man da noch
15:41
True hinten anhängt, dann wird die Zieltabelle erst gelöscht, bevor die Daten importiert werden. Dann unten zwei Beispiele, wie eben diese SQL-Queries aussehen können. Sie können ganz simpel sein. In der zweiten habe ich sogar schon hier schon einen kleinen Datenumbau, aber so einen minimalen Datenumbau eingebaut, dass da irgendwie die Spalte 2 mit
16:02
irgendeinem Wert multipliziert wird. Um das Ding dann auszuführen, ruft man auf der Kommandazeile Grettel auf. Muss man Grettel halt zuvor installiert haben und hinten als Argument den Namen des Steps, den Grettel ausführen
16:20
soll. Grettel holt sich dann, weil wir das ja am Anfang angegeben haben, das Plugin und alle benötigten Abhängigkeiten. Dann weiter zu den Features, die nicht wir programmiert haben, sondern die ganze Fülle von Features, die eben Grettel mitbringt. Da gibt es zum Beispiel
16:41
ein Copy-Task zum Kopieren von Dateien und Verzeichnissen oder auch zum Zippen und Entzippen von Dateien. Dann bietet eben Grettel diese Kontrolle von Abhängigkeiten von Tasks untereinander. Ich habe hier ein Beispiel der Task Unsipped Data, der vom Type Copy ist. Der hängt eben von
17:00
irgendeinem vorangehenden Step Download Data ab. Dann übernimmt Grettel auch das Fehlerhandling. Man kann mit Loops über einzelne Teildatensätze iterieren und weil Grettel mit Plugins erweiterbar ist,
17:21
haben wir nochmals viele Tasks mehr zur Verfügung. Zum Beispiel nutzen wir den Download-Task aus einem Download-Plugin. Genau da wäre ein Link auf einen umfangreicheren Grettel-Job.
17:43
Da möchte ich nicht im Detail darauf eingehen. Ich habe das einfach in die Folien mit aufgenommen, falls das jemand selber anschauen möchte. Ein Job, der eben einige Schritte hintereinander ausführt mit diesen Abhängigkeiten. Dann brauchen wir
18:06
noch eine Komponente für die Steuerung der ganzen Jobs. Es waren ja Grundjobs bisher und wir brauchen irgendwas, das die Grettel-Jobs anstößt. Auch hier wieder unser Credo war, wir wollen auf bestehendem Aufbau nichts programmieren lassen, dass da irgendwelche Grettel-Jobs
18:23
und wir haben da Jenkins gefunden. Jenkins nennt sich Automation Server. Jenkins kann man eben angeben zu einem bestimmten Zeitpunkt soll dieser Job ausgeführt werden. Jenkins checkt dann den Grettel-Job aus einem
18:44
Repository aus. Wir haben alle Jobs in einem GitHub-Repository und das führt den dann aus. Vorteile von Jenkins ist zunächst einmal, dass Jenkins die Logs und den Verlauf selber vorhält. Dadurch ist das
19:03
alles sehr transparent. Jenkins bietet auch die Benutzeranmeldung, rechte Verwaltung und z.B. E-Mail-Versand, falls etwas fehlschlägt. Und wir haben hier alle Jobs an einem Ort. Alle Benutzer, die ein Login für Jenkins haben, können da schauen, was mit den Jobs gerade los ist.
19:28
Kurz einige Bilder, wie das aussieht in Jenkins. Das ist die Übersicht über alle Jobs. Hier die Ansicht eines einzelnen Jobs, wo man links außen eben den Bildverlauf, die letzten Ausführungen aufgelistet bekommt und
19:44
beim roten Punkt sieht, dass da etwas schief gelaufen ist. Wenn man da drauf klickt und die Konsolen-Ausgabe sich anzeigt, kriegt man eben die Log-Ausgabe. Jenkins bietet noch die sogenannte Blue-Ocean-Oberfläche, damit es
20:02
zwar eine etwas einfache Oberfläche ist, die erst noch gut ausschaut. Wir führen die Gretel-Jobs in einem GitHub-Repository, da habe ich die
20:23
Gretel-Jobs. GitHub unterstützt natürlich die Nachvollziehbarkeit von Änderungen dank der Versionierung. Und auch hier haben wir schön alle Job-Definitionen an einem Ort. So sieht so ein Job aus auf GitHub. Da ist das Bild-Gradle, das ist
20:41
die zentrale Komponente. Und dann sind da noch SQL-Skripte dazu, die dieses Bild-Gradle benötigt. Das ist die zweitletzte Folie. Wir betreiben das Ganze von Gretel produzieren in Docker-Container und das Ganze betreiben wir dann in einer
21:03
OpenShift-Umgebung. Jenkins als Docker-Container und Gretel als Docker-Container. Haben wir bis jetzt gute Erfahrungen damit gemacht. Und dann noch mein Fazit. Bisher läuft das wirklich alles robust und zuverlässig, ist sehr übersichtlich, flexibel und einfach erweiterbar,
21:25
dank dem STEP-Konzept. Wir sind absolut zufrieden und werden da sicher auch noch weiteres dazu entwickeln lassen. Und wir freuen uns auch, wenn das vielleicht von anderen Benutzern eingesetzt wird.
21:41
Dann danke ich für die Aufmerksamkeit. So, vielen Dank für den spannenden Vortrag. Gibt es Fragen? Ja, vielen Dank. Sieht sehr interessant aus.
22:03
Wenn ich das richtigen Kopf habe, erlaubt es Jenkins ebenfalls, einem Event-basiert Dinge auszuführen. Macht ihr alles über regelmäßige Aufträge oder habt ihr auch Logik drin, wenn da neue Daten reinkommen, dann erzeugen wir etwas anderes über Gretel?
22:20
Das haben wir bis jetzt nicht. Ein guter Teil sind regelmäßige Starts, eben über eine Krontap. Und der andere Teil sind Jobs, die man nur manuell ausführen kann. Sich also in Jenkins einlocken muss und dort auf einen Button klicken, um ihn manuell zu starten. Aber das andere wäre
22:40
durchaus möglich, weil das Jenkins eben unterstützt. Danke. Noch eine zweite Frage. Vielleicht habe ich es verpasst. Wird das andersweitig bereits eingesetzt oder ist das bis jetzt lediglich bei euch? Weil ich habe das Gefühl, das ist etwas, was wirklich noch für viele Leute interessant sein könnte. Ja, es ist bis jetzt lediglich bei uns. Aber ich hoffe, dass nach
23:01
dieser Präsentation sich das ändert. Ja, meine Frage wäre, setzt ihr das nur für interne Datenströme ein
23:22
oder ist es auch für einen Exportportal, also für einen Kollegen, der Exporte fertigt, über ein Webportal aufrufbar? Grundsätzlich kann man Jenkins absolut im Web betreiben.
23:40
Und von den Datenströmen her, ja, ist es bei uns bis jetzt nur intern. Wir werden aber zum Beispiel von einem externen FTP-Server Daten holen. Wir holen schon jetzt von einem FTP-Server Datenfiles und genau Uploads auf einen FTP-Server machen wir auch.
24:01
Ich denke auch, die Datenbanken könnten irgendwo, oder eine der Datenbanken könnte irgendwo extern sein, wenn die eben den Zugriff erlaubt.
24:20
Sie haben vorhin noch gesagt, dass man auch Rastadatensätze aus einer Postgres-Datenbank rausziehen kann und als Karte darstellen kann. Kann man umgekehrt auch zum Beispiel einen Geotiff in der Datenbank damit einspielen lassen oder gibt es da Bestrebungen in der Richtung? Ich weiß nichts von Bestrebungen, aber ich nehme an, dass das relativ
24:43
einfach umsetzbar wäre. Ok, dann habe ich noch eine Frage. Und zwar kann man mit räumlichen Daten
25:02
auf jeden Fall umgehen, aber es ist auch möglich damit nicht räumliche Daten einzuspielen. Habe ich das richtig so verstanden? Ja, absolut. Gerade das CS-Farm-Format, das sind häufig nicht räumliche Daten oder Daten, die im Maximum eine X- und Y-Koordinate mitliefern. Aber es ist absolut auch für nicht räumliche Daten nutzbar.
25:27
Ok, danke. Ok, dann wenn keine weiteren Fragen mehr sind, dann beschließen wir jetzt die Session und um 7 Uhr geht es dann weiter mit der Abendveranstaltung. Danke.
25:42
Danke.