Streaming-Datenverarbeitung auf Elixir: Architektur und Implementierung

Elixir-Architektur für Streaming-Datenverarbeitung: Vom Hello World zum lockeren Coupling

Beim Aufbau eines Systems aus interagierenden Engines in Elixir ist eine klare Trennung der Schichten und eine reibungslose Integration externer Abhängigkeiten entscheidend. Dieser Artikel taucht tief in die Implementierung zentraler Knoten für Streaming-Datenverarbeitung ein – inklusive Quellen, Senken und einem zentralen Dispatcher – mit Fokus auf solide Architekturprinzipien und praxisnahe Lösungen.

Klassifizierung von Hardware-Knoten und Datenquellen

In der Streaming-Datenverarbeitung sind die Endknoten im Graphen entscheidend – sie verbinden sich direkt mit der Hardware. Auf der unteren Ebene sitzen die Datenquellen, klassifiziert nach Eingabetyp:

• Tastatur (Setpoint): Für die Eingabe alphanumerischer Daten, wie Sollwerte in Regelungssystemen.
• Regelmäßige Gateways (R_gateway): Treiber für Busse mit kontinuierlichen Datenströmen, z. B. Modbus in der Industrieautomatisierung.
• Unregelmäßige Gateways (Ir_gateway): Adapter für sporadische Datenbursten, wie CAN-Bus in modernen Fahrzeugen, der mit der Zentraleinheit verbunden ist.

Auf der oberen Ebene gruppieren sich die Datenverbraucher unter der Stock-Klasse:

• Anzeigen zur Darstellung von Infos.
• Dateisysteme zum Protokollieren von Ereignissen und Fehlern.
• Datenbanken oder Repositories als Zwischenspeicher.
• Höherstufige Systeme, die Engines über Gateway-Knoten verkettet.

Diese Struktur bildet einen Datenflussgraphen, in dem tieferliegende Knoten Infos nach oben pumpen und die mittlere Engine-Schicht zu Beginn überspringen.

Implementierung zentraler Knoten und Simulation von Streams

Zur Demonstration haben wir drei Quellknoten und einen Senkenknoten gebaut – ohne GenServer OTP. Diese nutzen einfache zyklische loop-Funktionen und bleiben leichtgewichtig:

• Terminal-Eingabe-Modul: Ermöglicht die Eingabe alphanumerischer Daten, wie das klassische „Hallo, Welt!“.
• Regelmäßiger Daten-Simulator: Läuft endlos und pumpt alle Sekunden „Hallo, “ in den Stream.
• Unregelmäßiger Daten-Simulator: Läuft endlos und feuert „Welt! “ in Intervallen bis zu 1 Sekunde in den Stream.
• Terminal-Ausgabe-Senke: Zeigt alle eingehenden alphanumerischen Daten aus beliebigen Quellen auf dem Bildschirm an.

Die mittlere Engine-Schicht bleibt in diesem ersten Build bewusst leer. Der vollständige Code mit funktionierenden Engines kommt auf GitHub für Transparenz und einfache Erweiterung.

Verteilung von Terminals und zentraler Dispatcher

Eine große Herausforderung war die Behandlung von Terminal-I/O, das an lokale Prozesse gebunden ist. Standardmäßig leitet Erlang alle I/O von Knoten auf ein einziges Terminal um – was in verteilten Setups nicht immer passt. Die Lösung? Dieser Operator:

:global.register_name(:stock_ldr, :erlang.group_leader)

Er verteilt das System auf dedizierte Terminals, auch wenn die Dokumentation lückenhaft war und die Jagd ewig dauerte.

Zum Laden und Starten des Systems kommt ein zentraler Dispatcher hinzu. Bei der Integration Drittanbieter-Bibliotheken in Elixir ist Best Practice ein einziges internes Modul als Gateway zu Äußeren – für lockeres Coupling. Die hexagonale Architektur schiebt Abhängigkeiten an die Ränder und isoliert die Business-Logik von Nebenwirkungen. In der Praxis wird das aber knifflig mit vielen externen Modulen wie Hardware-Gateways und Daten-Senken.

Architekturprinzipien und Skalierbarkeit

Das Engine-System ist für einfache Erweiterung ausgelegt: Jeder Graph-Endpunkt dient als Gateway zur Außenwelt. So können eigene Komponenten flexibel angedockt werden, um reale Anwendungen zu entstehen. Wichtige Erkenntnis: Das System wächst „nach unten“ in Anwendungen hinein und kehrt das übliche Top-Down-Denken um.

Tipps für Entwickler:

• Einfache loop-basierte Prozesse schlagen GenServer OTP für Basisknoten – leichter umzusetzen, aber Fehlerbehandlung sorgfältig planen.
• :global.register_name löst Erlangs zentrales I/O-Problem.
• Lockeres Coupling mit Äußeren ist schwer, selbst mit hexagonalen Idealen.

Wichtige Erkenntnisse:

• Knotenklassen wie R_gateway, Ir_gateway, Setpoint und Stock geben Streaming klare Struktur.
• Daten-Simulatoren beweisen, dass das System ohne mittlere Engines läuft.
• Terminal-Verteilung erfordert clevere Erlang-Tricks.
• Zentraler Dispatcher und externe Integrationen setzen auf lockeres Coupling.
• Gateway-Knoten machen das System erweiterbar für Praxisanwendungen.

— Editorial Team