Apache Hop User Meetup Vol. 5

Yes, it’s open source. The source code is available. We can integrate almost anything. Metadata
catalogues, data catalogues. I think that’s the direction we’re heading in, as I mentioned with
regard to data, catalogues and lineage. This applies here as well. There are no Hartsteiners
or unified standards. This makes global, unified metadata integration more difficult from
a technical point of view. But it‘s definitely possible. If you want to discuss it further, get in
touch. Start a GitHub discussion or feature request and we can look at it in more detail.

I‘d love to! We haven‘t discussed this on GitHub. I think dbt has a more ELT than ETL approach.
However, it would be interesting to explore the possibility of integrating dbt as a workflow
action. We could call dbt functions from a workflow. It‘s not there yet, but it‘s interesting at
least.

Yes, there is a helm chart available on the download page. There will be more in future. As a
community, I think it‘s fair to say that we are aware of them. Hopefully, the Apache Software
Foundation is a global NGO. They have headquarters in the United States. However, the
Hop developer team is largely European. Digital sovereignty is becoming a popular topic. As
an open-source platform with a large European community, I think that‘s a good thing. In
addition to the three large cloud providers, we‘ll also look at OVH and Stackit. So, yes, Stackit.
Hetzner, being German, will definitely ensure that I am aware of the deployments in those
cloud environments. However, support will need to improve. If you find a book that is specific
to Stackit, Hetzner or OVH, for example, it will definitely ensure that this is taken care of.

That’s one of the things we’ll focus on.

Soap haben wir jetzt in dem Fall nicht benutzt? Wir haben das, wie gesagt, am Anfang. probiert
mit Sub und True Data und haben dann einfach anhand, dass man, eben, um Perodator die
Daten zu parsen bzw. so schön auszulösen. Aber es war grundsätzlich möglich, eben ohne
Schmerz auch das Bsdl in eine Abfrage mit reinzupassen. Das haben wir am Anfang probiert,
es hat auch funktioniert. und man kann natürlich auch mit Soapdaten abfragen, aber es ist
natürlich extrem aufwendiger. Man muss die WSDS entsprechend den Feldlisten anpassen. Die
Freigaben müssen da sein, und man bekommt dann auch resultsets raus.

Wie gesagt, wir haben ein Tagungsfeld. Ich glaube, es war „Last Change Daytime”. Da wird ein
Timestamp gesetzt. Das ist der Zeitpunkt, zu dem eine Änderung an diesem Datensatz erfolgt
ist. Wir übergeben in dem Fall zwei Parameter für Start- und Enddatum. Dadurch erhalten wir
nur in dieser Zeitspanne Daten. Im Backend haben wir eine Datenbank, in der der Job immer
getriggert wird. Er wird also im Intervall gestartet. Er hat einen Status, das heißt, wenn die
Verarbeitung erfolgreich war. Das heißt, wenn der Status „Finish” erreicht ist, ziehen wir uns
den Zeitstempel und setzen ihn beim nächsten Lauf als Enddatum bzw. als Startdatum, sodass
wir fortan die Daten in diesem Zeitraum erhalten. Genau, einfach praktisch in einem Delta
Zeitraum, um es mit einfachen Worten zu sagen: Wir schauen uns nur die Daten an.

Ja, wir parsen ganz klassisch über ein Python-Skript. Wir bauen das Ganze in dem Format
auf, das wir benötigen, und pushen es dann rein. Wir haben heute schon viel über FeatureRequests gehört. Auf Github haben wir, glaube ich, schon einen Feature-Request gelesen, dass
das irgendwann über das Open-Lille-Format reingehen sollte. Dann könnte man das Ganze
automatisiert reinpushen. Dann bräuchten wir das nicht mehr über unsere Python-Skripte,
wie wir es aktuell machen. Wenn wir uns an diesen Open-Standard halten oder wenn das ins
Produkt wandert, würde das automatisch gehen.

Selbstverständlich bieten wir unsere Dienstleistungen an, denn wir leben nicht von Luft und
Liebe. Leider nicht. Wenn Interesse besteht, melde dich bei uns. Wir werden uns schon einigen.

Das Logging selbst ist ein GitLab-Repository. Im Logging selbst sind Workflows und Pipelines,
die gesamttechnisch an alle weitergereicht werden. Das heißt, wenn ich jetzt ein anderes
Projekt starte und mir das Logging-Repository herunterhole, dann wäre es so, dass man die
Pipeline nicht mehr raussuchen muss, sondern sie tatsächlich schon automatisch hat. Jedes
neue Projekt muss nur das Metadatenobjekt angeben. Das befindet sich im Logging-Ordner
und man muss sich um nichts mehr kümmern.
In unserem Fall wird dort sofort das Creator Statement gemacht und das gesamte Logging,
also alles, was wir haben möchten, von den Actions etc. wird mit übernommen. Für jedes
neue Projekt muss man eigentlich nur das Metadaten-Objekt angeben. Wenn du kurz auf
„Metadaten” gehst. Beim Logging gerade. Das ist jetzt der grüne Bereich. Genau, und hier
unten beim Workflow-Log haben wir die einzelnen Pipelines. Im Prinzip ist das alles, was
wirklich zu machen ist. Man muss eigentlich nur beim Workflow die Pipeline angeben. Das
muss man leider händisch machen, aber durch das komplette Laden des Projekts gibt man
hier einfach nur noch die Workflows an, an die man loggen möchte. Man muss sich um nichts
mehr kümmern und es ist überall standardisiert.
Es ist also egal, welches Projekt ich nehme. Das war ein riesiger Vorteil, denn früher hatten
wir genau das Problem, dass das Logging in PDI ein bisschen anders funktionierte. Das war
im Job. Soweit ich mich noch erinnern kann, musste man das jedes Mal anpassen, wenn ein
neues Projekt angelegt wurde. Und manchmal vergisst man das einfach. Manchmal vergisst
man einfach, dort ein Häkchen zu setzen, und wundert sich dann: Ach, hier wurde das
gelockt. Da wurde das nicht gelockt. Ich glaube, mittlerweile gibt es 6 oder 7 Projekte, die alle
zeitgleich entwickelt werden. Da wird es sehr mühselig, immer wieder durchzugehen und zu
schauen, ob man alle Häkchen gesetzt hat. Wenn man es einmal gemacht hat, läuft es mehr
oder weniger out of the box. Ich hoffe, das beantwortet deine Frage. Diese Pipeline ist in einem
Submodul enthalten und wird automatisch in jedem Projekt als Submodul eingebunden. Das
heißt, diese Pipeline steht in jedem Projekt zur Verfügung. Ähnlich ist es mit dem WorkflowLog, das ebenfalls für alle Projekte gesichert werden kann.

Es handelt sich um ein Open-Source-Projekt. Es soll auch weiterhin Open Source bleiben. Es
gibt eine Enterprise-Version davon. Diese ist von Acryldata. Die ist allerdings nur in der Cloud
verfügbar. Was in Zukunft passiert, weiß ich nicht, ich gehe aber davon aus, dass es Open
Source bleibt.