ELT statt ETL: Warum Sie rohe MQTT-Daten zuerst landen sollten

Der erste Entwurf sieht immer gleich aus. Eine MQTT-Nachricht kommt an, wird geparst, ihr Topic zerlegt, der Wert typisiert, die Zeile in die passende Zieltabelle geschrieben. Sauber, direkt, ein Schritt. Klassisches ETL: Extract, Transform, Load.

Bei niedrigem Volumen funktioniert das. Bei industriellem Durchsatz nicht – und zwar aus einem Grund, der in der Architektur der Ingest-Schicht steckt und den Sie nicht wegoptimieren können. Dieser Artikel erklärt, warum, wie die Umkehrung zu ELT aussieht, und warum das Ergebnis nicht nur schneller, sondern auch robuster ist.

Der Grund: Ihre Ingest-Schicht batcht – und Batching schliesst Logik aus

HiveMQs Enterprise Extension für PostgreSQL ist auf Durchsatz gebaut. Sie sammelt eingehende MQTT-Nachrichten und schreibt sie gebündelt als einen einzigen mehrzeiligen INSERT in eine einfache Zieltabelle. Das ist der Hebel, der aus tausenden Einzelinserts pro Sekunde eine Handvoll Schreibvorgänge macht.

Der Preis: Dieser Schreibpfad kann nicht gleichzeitig verzweigen. Er kann eine Nachricht nicht abhängig von ihrem Topic in eine von zwölf typisierten Tabellen fächeln, keine Fremdschlüssel auflösen, keine Validierung ausführen. Die Extension schreibt Zeilen – sie führt keine Geschäftslogik aus.

Man kann versuchen, das mit Triggern auf der Zieltabelle zu umgehen. Das funktioniert im Test und fällt in Produktion um: Jeder Trigger läuft pro Zeile innerhalb der Insert-Transaktion, der Batch wird so langsam wie sein teuerster Trigger, und ein einziger Fehler lässt den gesamten Batch scheitern. Sie haben dann das Schlechteste aus beiden Welten – Batch-Semantik ohne Batch-Geschwindigkeit.

Die Umkehrung: erst landen, dann transformieren

ELT dreht die Reihenfolge um. Extract, Load, Transform: Die Rohdaten kommen unverändert in die Datenbank, und die Transformation findet dort statt – zeitversetzt, geplant, in Batches.

Konkret entstehen zwei klar getrennte Verantwortlichkeiten:

• Die Ingestion ist dumm und schnell. Der Broker schreibt Topic, Payload und Ankunftszeitpunkt in eine einzige breite Landing-Tabelle. Kein Parsing, keine Joins, keine Bedingungen im heissen Pfad.
• Die Transformation ist schlau und geplant. Ein Job in der Datenbank liest die Landing-Tabelle batchweise und übernimmt alles Weitere: parsen, typisieren, Identitäten auflösen, validieren, verteilen.

Das ist dasselbe Prinzip, das moderne Data Pipelines im Warehouse-Umfeld durchgesetzt hat – nur dass der Auslöser hier kein nächtlicher Ladelauf ist, sondern ein Broker, der nicht wartet.

Die Landing-Tabelle ist bewusst dumm

Sie hat wenige Spalten und keine Meinung: Topic als Text, Payload als Bytes oder Text, Zeitpunkt der Ankunft, vielleicht eine Client-Kennung. Kein Constraint, der eine Nachricht ablehnen könnte. Keine Fremdschlüssel. Der Grund ist einfach: Was hier nicht hineinpasst, ist verloren – und Verlust an der Aussenkante ist der teuerste Verlust, weil er unsichtbar ist.

Der Drain-Job – und wie er einen Batch sicher übernimmt

Das Herzstück ist ein Job, der die Landing-Tabelle leert. Er darf sich nicht mit sich selbst ins Gehege kommen, keine Zeile doppelt verarbeiten und keine unbegrenzte Menge auf einmal ziehen. Genau das leistet ein DELETE … RETURNING mit Zeilensperre:

WITH batch AS (
  SELECT id FROM mqtt_landing
  ORDER BY id
  LIMIT 5000
  FOR UPDATE SKIP LOCKED
)
DELETE FROM mqtt_landing l
USING batch b
WHERE l.id = b.id
RETURNING l.*;

Drei Eigenschaften auf einen Schlag: Die Zeilen verlassen die Warteschlange in dem Moment, in dem sie gelesen werden – keine Doppelverarbeitung. Parallele Drain-Läufe streiten dank SKIP LOCKED nie um dieselben Zeilen. Und das LIMIT begrenzt den Speicherbedarf eines Laufs.

Die Begrenzung ist nicht optional. Auf einer Managed-Instanz ist Arbeitsspeicher die bindende Ressource. Ein Drain ohne Obergrenze zieht bei einem Nachrichtenstau irgendwann Millionen Zeilen auf einmal – und nimmt die Instanz mit.

Kein Workaround, sondern der vorgesehene Weg

Ein häufiger Einwand: «Transformation in der Datenbank, per Scheduler – ist das nicht ein Hack?» Nein. TigerData bringt einen eigenen Job-Scheduler mit, und benutzerdefinierte Aktionen als geplante Jobs sind ein ausdrücklich vorgesehener Anwendungsfall. Der Drain läuft als einer dieser Jobs – mit demselben Monitoring, denselben Logs und derselben Fehlerbehandlung wie Compression und Retention.

ETL und ELT im direkten Vergleich

Der eigentliche Gewinn: Reprocessing

Der Durchsatz ist das Argument, mit dem man startet. Das Argument, das im Betrieb zählt, ist ein anderes: Wenn die Rohdaten unverändert erhalten bleiben, ist jeder Transformationsfehler reparierbar.

Ein falsch interpretierter Zeitstempel, eine Einheit um Faktor 1000 daneben, ein neu hinzugekommener Gerätetyp, den die Regel nicht kannte – in einer ETL-Pipeline sind das Datenverluste. In einer ELT-Pipeline sind es zwei Stunden Arbeit: Regel korrigieren, Archiv erneut durchlaufen lassen, fertig. Diese Eigenschaft rechtfertigt den Umbau allein.

Wann ETL trotzdem richtig ist

Wir behaupten nicht, dass Transformation im Schreibpfad immer falsch ist. Sie ist die richtige Wahl, wenn Sie echte Echtzeit brauchen – also eine Reaktion innerhalb von Millisekunden, etwa ein Sicherheitsabschaltsignal. Dann gehört die Logik an die Kante, typischerweise in Edge-Verarbeitung oder Stream-Processing, nicht in einen Scheduler mit Sekundentakt.

Auch bei sehr niedrigem Volumen – einige hundert Nachrichten pro Minute, ein einziges stabiles Format – ist der ELT-Aufbau Überbau. Die Grenze verläuft dort, wo Sie das erste Mal über Batch-Grössen nachdenken müssen.

Wie wir Sie unterstützen

Wir bauen genau diese Schicht: den Weg von der Maschine über den Broker in eine Datenbank, die auch im dritten Jahr noch antwortet. Operative Datensysteme und Datenplattformen sind unser Täglich-Brot – für Industrie und Logistik ebenso wie für Verkehrsbetriebe.

Sie stecken gerade in der Frage, ob Sie im Broker oder in der Datenbank transformieren sollen? → Kontakt aufnehmen – eine Stunde reicht meist, um die Weiche richtig zu stellen.

Weiterführende Glossar-Artikel

• Industrielle Time-Series-Datenplattform – die Gesamtarchitektur von MQTT bis Dashboard
• Dead-Lettering und Reconciliation – was der Drain mit dem macht, was er nicht versteht
• Time-Series-Schema auf TigerData – wohin die transformierten Daten fliessen
• Was ist eine Data Pipeline? – die Grundbegriffe
• Unified Namespace (UNS) – warum die Topic-Struktur über die Transformation entscheidet