Der Zustand, den Domänenagenten lesen: Paimon für Arbeitswarteschlange, Bestand und Freigaben

Ein Einkaufsagent soll eine Nachbestellung für ein Bauteil vorbereiten, das knapp wird. Um das gut zu tun, braucht er den Bestand in drei Lagern, die offenen Kundenaufträge, die einen Teil davon reservieren, die bereits unterwegs befindlichen Eingänge und den aktuellen Risikostatus des Lieferanten. Jedes davon hat sich in der letzten Stunde geändert. Die nächtliche Kopie im Warehouse liegt bei allen vieren falsch. Die Produktionstabellen der Module stimmen, aber ein Agent, der sie im großen Stil liest, ist der schnellste Weg, die Menschen auszubremsen, die in diesen Modulen arbeiten.

Das ist die Lücke zwischen den zwei Gedächtnissen eines Unternehmensbetriebssystems: der Aufzeichnung, die jedes Ereignis dauerhaft behält, und dem laufenden Zustand, der zeigt, wie die Dinge jetzt stehen. Der Grundlagentext beschreibt beide. Dieser handelt vom zweiten und vom Tabellenformat, das die Datenschicht dafür verwendet. Die Datenschicht ist im Aufbau; was folgt, ist die Art, wie sie entworfen wird.

Was ein Domänenagent tatsächlich liest

Hurukans Agenten sind Domänenagenten: einer für den Einkauf, einer für den Kundenservice, einer für die Arbeitswarteschlange im Betrieb, und so weiter. Jeder arbeitet mit einer kleinen Zahl von Zustandstabellen, die Fragen in der Gegenwart beantworten.

Die Arbeitswarteschlange. Welche Aufträge freigegeben sind, welche blockiert und warum, welche Maschine oder welches Team frei ist. Gespeist vom Betriebsmodul, wenn Aufträge den Status wechseln.

Bestand und Reservierungen. Menge je Artikel und Ort, abzüglich dessen, was offene Aufträge schon beansprucht haben, zuzüglich dessen, was unterwegs ist. Gespeist von Ereignissen aus Lager und Logistik, Vertrieb und Einkauf.

Der Freigabe-Posteingang. Jeder Vorschlag, den ein Agent gemacht hat, mit seinen Quellen und seinem Risiko, und ob eine Person schon entschieden hat. Gespeist von den Agenten selbst und von den Menschen in Entscheidungen und Aufgaben.

Keine dieser Tabellen ist eine Kopie der Datenbank eines Moduls. Jede wird aus den Ereignissen gebaut, die die Module aussenden und die auch die Aufzeichnung behält. Die Zustandstabelle ist eine abgeleitete, stets aktuelle Sicht auf die Aufzeichnung; die Aufzeichnung ist der Beweis dahinter.

Warum das eine Paimon-Tabelle ist

Eine Zustandstabelle ändert sich tausendmal pro Stunde nach Schlüssel: derselbe Artikel, derselbe Auftrag, derselbe Vorschlag, immer wieder aktualisiert. Tabellenformate, die um das Anhängen neuer Dateien herum gebaut sind, kommen damit schlecht zurecht, weil jede Aktualisierung zu einer neuen Datei wird und die Tabelle in kleinen Dateien ertrinkt. Apache Paimon wurde genau für diesen Fall entworfen. Seine Primärschlüsseltabellen speichern Zeilen in einem LSM-Baum, innerhalb eines Buckets nach Schlüssel sortiert, sodass ein Strom von Aktualisierungen derselben Schlüssel kompakt bleibt und ein Leser immer die neueste Version jeder Zeile sieht (Tabellentypen, geprüft am 21. Oktober 2026).

Zwei Paimon-Funktionen erledigen Arbeit, die sonst Code wäre. Eine Merge-Engine entscheidet, was geschieht, wenn eine neue Zeile für einen vorhandenen Schlüssel eintrifft: sie ersetzen, die erste behalten, aggregieren oder nur die Felder füllen, die angekommen sind. Die Bestandstabelle nutzt das Letzte: Das Lager schreibt die vorhandene Menge, der Vertrieb die reservierte, der Einkauf die eingehende, und die Tabelle hält alle drei in einer Zeile, ohne dass ein Modul von den anderen weiß. Ein Changelog-Producer gibt jede Änderung der Tabelle als eigenen Strom aus, sodass ein nachgelagerter Agent auf „Bestand unter den Bestellpunkt gefallen” reagieren kann, statt abzufragen.

Die aktuelle Version ist Paimon 2.0.0 vom 7. August 2026 (Release-Katalog, geprüft am 21. Oktober 2026). Flink schreibt und liest sie, und der Lookup-Join lässt einen Streaming-Job ein Ereignis mit dem aktuellen Zustand einer anderen Tabelle anreichern — einen neuen Auftrag mit dem Bestand, den er reserviert — ohne Umweg über irgendetwas anderes. Spark, Trino, Hive, StarRocks und Doris lesen dieselben Tabellen (Engines).

Der Agent liest den Zustand und schreibt nur einen Vorschlag

Die Grenze zählt mehr als das Format. Ein Domänenagent liest die Zustandstabellen frei. Er schreibt nicht in ein Modul, und er schreibt auch nicht in die Zustandstabelle. Was er erzeugt, ist ein Vorschlag: eine entworfene Nachbestellung mit den gelesenen Zeilen, der angewandten Regel und dem Risiko, das er sieht. Der Vorschlag landet im Freigabe-Posteingang. Eine Person entscheidet. Das Modul führt die Entscheidung aus, sendet das Ereignis, und die Zustandstabelle ändert sich, weil das Ereignis aufgezeichnet wurde — nicht, weil der Agent sie geändert hat.

Das hält die zwei Gedächtnisse ehrlich. Würden Agenten den Zustand direkt schreiben, enthielte der Zustand Dinge, die in keinem Modul je geschehen und nie aufgezeichnet worden sind. Indem sie Zustand lesen und Vorschläge schreiben, läuft jede Änderung dessen, was das Unternehmen für wahr hält, weiterhin durch eine Person und durch die Aufzeichnung.

Es beantwortet auch die Prüffrage. Paimon behält Schnappschüsse, und ein Tag heftet einen fest, damit er nicht abläuft. Wird ein Vorschlag Monate später hinterfragt, zeigt der Schnappschuss vom Moment, in dem der Agent die Tabelle gelesen hat, genau den Bestand, die Warteschlange und die offenen Aufträge, die er sah. Das Entscheidungsprotokoll hält die Begründung; der Schnappschuss hält den Beleg.

Sekunden, Minuten oder heute Nacht

Nicht jeder Zustand muss eine von einem Strom gespeiste Paimon-Tabelle sein. Der Freigabe-Posteingang muss sekundenaktuell sein, weil eine Person darin wartet. Die Arbeitswarteschlange muss minutenaktuell sein, weil eine Maschine wartet. Bestand für Nachbestellungen ist eine Entscheidung, die ein paar Mal am Tag fällt; ein Zustand, der ein paar Minuten hinterherhinkt, genügt. Der Risikostatus eines Lieferanten ändert sich wöchentlich.

Alles auf Sekunden zu treiben kostet dauernde Verdichtung, eine Streaming-Engine, die nie schläft, und ein Betriebsteam, das beides gesund hält. Deshalb fragt die Datenschicht für jede Zustandstabelle, welche Entscheidung von ihr abhängt und wie schnell sich diese Entscheidung wirklich ändert — und nur die Tabellen, die Sekunden brauchen, bekommen sie. „Echtzeit” ist keine Eigenschaft der Plattform; sie ist ein Budget, das je Tabelle ausgegeben wird.

Ein Test, den Sie heute machen können

Wählen Sie eine Entscheidung, die jemand in Ihrem Unternehmen mehrmals am Tag trifft: einen Einkauf freigeben, einen Auftrag freigeben, einen Liefertermin zusagen. Schreiben Sie jede Zahl auf, die die Person vor der Entscheidung ansieht, und daneben, woher sie kommt und wann sie zuletzt aktualisiert wurde.

Wenn mehrere dieser Zahlen aus verschiedenen Systemen kommen und zu verschiedenen Zeiten aktualisiert wurden, macht die Person den Join bereits im Kopf, aus einem Zustand, der zu keinem einzigen Zeitpunkt konsistent war. Das ist die Tabelle, die ein Domänenagent zuerst bräuchte — und die, die zu entwerfen ist, bevor irgendein Agent gebeten wird, irgendetwas zu entscheiden.