hetida designer
Der hetida designer ist eine Open-Source-Plattform zur Entwicklung, Verwaltung und Ausführung datenanalytischer Workflows auf Basis von Python. Er bildet das analytische Herzstück des hetida-Ökosystems und ermöglicht es, Python-Data-Science-Artefakte — Komponenten und Workflows — strukturiert zu verwalten, zu testen und produktiv bereitzustellen, ohne externe Scheduler oder separate Datenbanken zu benötigen.
Der hetida designer richtet sich an Datenanalysten und Entwickler, die Zeitreihendaten verarbeiten, Anomalien erkennen oder komplexe Analysepipelines aufbauen möchten.
Systemarchitektur
Der hetida designer gliedert sich in drei integrierte Dienste, die unabhängig voneinander oder als gemeinsamer Stack betrieben werden können:
| Dienst | Aufgabe |
|---|---|
| Backend REST Service | Verwaltung von Workflows, Komponenten und Konfigurationen über eine REST-API |
| Runtime | Ausführung von Workflows und Komponenten in einer isolierten Python-Umgebung |
| Frontend UI | Webbasierte Benutzeroberfläche zur visuellen Workflow-Modellierung |
Der Betrieb erfolgt typischerweise über Docker Compose für lokale Umgebungen oder über Kubernetes für den produktiven Betrieb mit höherer Skalierungsanforderung.
Kernkonzepte
Komponenten
Komponenten sind die atomaren Bausteine des hetida designers. Jede Komponente kapselt eine Python-Funktion mit explizit deklarierten Ein- und Ausgängen und kann unabhängig entwickelt, getestet und in beliebig vielen Workflows wiederverwendet werden.
Eine Komponente wird mit Typen für ihre Ein- und Ausgänge deklariert, zum Beispiel SERIES, INT oder FLOAT. Der zugrundeliegende Python-Code ist in der UI einsehbar und im Entwurfszustand bearbeitbar. Der hetida designer enthält eine umfangreiche Bibliothek vorgefertigter Komponenten für gängige Zeitreihenoperationen wie Glättung, Aggregation, statistische Auswertung und Anomalieerkennung.
Workflows
Ein Workflow ist ein gerichteter, kreisfreier Graph (DAG — Directed Acyclic Graph), der Komponenten miteinander verbindet. Die Modellierung erfolgt visuell per Drag & Drop in der Frontend-UI: Die Ausgänge einer Komponente werden mit den Eingängen einer anderen verbunden, um einen definierten Datenverarbeitungspfad zu beschreiben.
Workflows unterstützen Verschachtelung: Ein abgeschlossener Workflow kann selbst als Komponente in einem übergeordneten Workflow eingesetzt werden. Auf diese Weise lassen sich modulare, hierarchisch aufgebaute Analysepipelines entwickeln, deren Teile unabhängig getestet und weiterentwickelt werden können.
Adapter und Wiring
Der Adapter-Mechanismus abstrahiert den Zugriff auf externe Datenquellen wie Zeitreihendatenbanken, Dateisysteme oder APIs. Innerhalb eines Workflows werden Adapternamen referenziert; die eigentliche Verbindung zu den Datenquellen wird außerhalb der Workflow-Logik konfiguriert. Dadurch bleibt der Workflow-Code unabhängig von konkreten Infrastrukturdetails.
Das Konzept des Wirings ergänzt dies auf Ausführungsebene: Es verknüpft zur Laufzeit konkrete Datenquellen und -senken mit den Eingängen und Ausgängen eines Workflows. Derselbe Workflow kann dadurch ohne Codeänderungen gegen Testdaten (z. B. CSV-Dateien) oder Produktionsdaten ausgeführt werden — lediglich die Wiring-Konfiguration wird ausgetauscht.
Revisionsverwaltung
Der hetida designer verwaltet Komponenten und Workflows in klar getrennten Zuständen:
- Entwurf (Draft): Das Artefakt ist editierbar. Ein Workflow, der Komponenten im Entwurfszustand enthält, kann nicht veröffentlicht werden.
- Veröffentlicht (Released): Das Artefakt ist unveränderlich und für die reproduzierbare Ausführung freigegeben. Änderungen erfordern zwingend eine neue Revision.
- Veraltet (Deprecated): Eine veröffentlichte Version bleibt weiterhin ausführbar, ist in der UI jedoch nicht mehr sichtbar. Dieser Zustand kennzeichnet Artefakte, für die neuere Revisionen existieren.
Dieses Modell sichert die Reproduzierbarkeit analytischer Ergebnisse über die Zeit und verhindert unbeabsichtigte Änderungen an produktiv genutzten Artefakten.
IO-Konfiguration
Die IO-Konfiguration eines Workflows legt fest, welche Eingänge zur Laufzeit als dynamische Parameter übergeben werden und welche als feste Werte (Constants) im Workflow hinterlegt sind. Dynamische Eingänge werden als JSON-Felder über die REST-API übergeben, was die Integration in übergeordnete Systeme und Automatisierungsprozesse ermöglicht.
Ausführung
Ein veröffentlichter Workflow ist unmittelbar als REST-Endpunkt verfügbar — ein separater Deployment-Schritt entfällt. Darüber hinaus steht ein eingebauter Kafka-Consumer für die ereignisgesteuerte (event-driven) Ausführung bereit: Workflows können als Reaktion auf eingehende Kafka-Nachrichten automatisch ausgelöst werden.
Testen innerhalb der UI
Sowohl Komponenten als auch Workflows können direkt in der Frontend-UI getestet werden. Testdaten lassen sich manuell eingeben oder als JSON- beziehungsweise CSV-Datei hochladen. Das Ergebnis wird unmittelbar dargestellt, ohne dass eine externe Ausführungsumgebung oder ein separater Test-Runner benötigt wird.
Sicherheitshinweise
Da der hetida designer beliebigen Python-Code ausführt, gelten besondere Anforderungen an den sicheren Betrieb:
- Frontend, Backend und Runtime dürfen nicht öffentlich erreichbar sein.
- Der Zugriff ist durch geeignete Authentifizierungsmaßnahmen zu schützen.
- Containerressourcen (CPU, Arbeitsspeicher, Netzwerkbandbreite) sollten explizit begrenzt werden.
- Nutzern des hetida designers sollte dasselbe Vertrauensniveau entgegengebracht werden wie Entwicklern mit Zugang zu produktiven Systemen.
Weiterführende Informationen
Das Quellcode-Repository des hetida designers ist öffentlich zugänglich: github.com/hetida/hetida-designer