Apache Paimon: eine Zustandstabelle für den Bediener, den Planer und den Agenten

Ein Montageauftrag wechselt zwischen Freigabe und Versand elfmal den Zustand: geplant, freigegeben, an der ersten Station begonnen, wegen eines fehlenden Teils angehalten, fortgesetzt, geprüft, eine Einheit abgelehnt, nachgearbeitet, verpackt, bestätigt, versandt. Die Bedienerin an der Station sieht ihren Schritt auf einem Terminal in Betrieb und Qualität. Der Planer sieht den Auftrag auf einer Tafel. Der Betriebsagent, gefragt, ob der Wochenplan noch hält, sieht einen Bericht. Drei Sichten, und in den meisten Unternehmen drei Tabellen, nach drei Zeitplänen aktualisiert, sodass jeden Nachmittag eine Stunde lang Bedienerin, Planer und Agent jeweils etwas anderes über denselben Auftrag glauben.

Die Datenschicht von Hurukan ist so entworfen, dass es für diesen Auftrag eine Zustandstabelle gibt und alle sie lesen. Der Grundlagentext erklärt, warum der laufende Zustand ein eigenes Gedächtnis neben der Aufzeichnung ist. Dieser Text handelt vom Format, in dem diese Tabelle gebaut wird, Apache Paimon, und davon, was diese Wahl kostet. Die Schicht ist im Aufbau; so wird sie entworfen.

Eine Tabelle, die aktualisiert wird, nicht angehängt

Die meisten Tabellenformate in einem Lakehouse gehen davon aus, dass Daten ankommen und bleiben. Neue Zeilen werden zu neuen Dateien; eine Zeile zu ändern heißt, eine Datei neu zu schreiben oder als gelöscht zu markieren. Das ist der richtige Entwurf für eine Aufzeichnung, in der nie etwas geändert wird. Es ist der falsche Entwurf für den Zustand eines Auftrags, der sich elfmal ändert, bevor er fertig ist.

Apache Paimon hat eine andere Form. Seine Primärschlüsseltabellen halten Zeilen innerhalb von Buckets nach Schlüssel sortiert, in einem Log-Structured Merge Tree: Neue Versionen kommen in einer obersten Ebene an, und Hintergrundverdichtung führt sie nach unten in sortierte Dateien zusammen, sodass die Tabelle kompakt bleibt, so oft dieselben Schlüssel auch neu geschrieben werden (Paimon-Tabellentypen, geprüft am 21. Oktober 2026). Ein Leser sieht die neueste Version jedes Schlüssels, ohne eine Geschichte zu durchsuchen. Tabellen ohne Primärschlüssel sind Append-Tabellen, die zur Aufzeichnungsseite passen; hier geht es um die Primärschlüsselart. Die aktuelle Version ist 2.0.0 vom 7. August 2026 (Release-Katalog).

Merge-Engines sind Ontologieregeln

Was Paimon zu mehr als einer schnellen Upsert-Tabelle macht, ist, dass das Format selbst entscheidet, wie eine neue Version einer Zeile sich mit der alten verbindet. Paimon nennt das die Merge-Engine, und in der Datenschicht entspricht jede Wahl einer Regel, die die Ontologie bereits über ein Objekt aussagt.

Deduplicate, der Standard: Die neueste Version gewinnt. Die richtige Regel für den Status eines Auftrags — das letzte Ereignis ist die Wahrheit.

Partial update: Jeder Schreiber füllt nur seine eigenen Spalten. Die Zustandszeile des Auftrags hat die geplanten Termine aus der Planung, den tatsächlichen Beginn und das Ende vom Stationsterminal, das Prüfergebnis aus der Qualität, die verpackte Menge aus dem Lager. Vier Module, eine Zeile, keines überschreibt die anderen. Sequenzgruppen lassen jeden Spaltensatz seine eigene Reihenfolge tragen, sodass eine verspätete Nachricht von der Station keine spätere aus der Qualität rückgängig machen kann (partial update).

Aggregation: Zahlen summieren sich über Ereignisse — gebuchte Stunden auf einem Arbeitsgang, fertige Einheiten, abgelehnte Einheiten.

First row: Die erste Version wird behalten. Nützlich, wo die Ontologie sagt, dass ein Wert einmal gesetzt wird, wie der Moment, in dem ein Auftrag freigegeben wurde.

In der Ontologie werden diese als Eigenschaften des Objekts beschrieben: welches Feld einmal gesetzt wird, welches sich ansammelt, welches zu welchem Modul gehört. Sie in der Tabellendefinition auszudrücken bedeutet, dass die Regel für jeden Schreiber gilt, auch für eine von Agenten gebaute Pipeline, die es noch nicht gab, als die Regel geschrieben wurde.

Eine Tabelle, drei Leser, ein Changelog

Das Terminal der Bedienerin, die Tafel des Planers und die Sicht des Agenten sind drei Leser derselben Tabelle, jeder anders gefiltert. Flink schreibt sie aus dem Ereignisstrom der Module und liest sie in Lookup-Joins zurück. Spark, Trino, Hive, StarRocks und Doris lesen sie ebenfalls (Engine-Unterstützung), sodass eine Berichts-Engine und ein Notebook dieselbe Zeile sehen, die das Terminal zeigt.

Die Tabelle gibt auch ihre eigenen Änderungen aus. Ein Changelog-Producer — input, lookup oder full-compaction, je Tabelle gewählt — verwandelt jede zusammengeführte Änderung in einen Strom. Der Betriebsagent abonniert „Auftrag angehalten”, statt die Tafel zu durchsuchen, und die Planungssicht aktualisiert sich, weil sich die Tabelle geändert hat, nicht weil jemand auf Aktualisieren gedrückt hat.

Für die Prüfung behält Paimon Schnappschüsse und lässt ein Tag einen dauerhaft festheften. Als der Agent vorschlug, drei Aufträge in die nächste Woche zu verschieben, zeigt das in diesem Moment gesetzte Tag die Tafel, auf die er blickte. Vorschlag, Entscheidung und Schnappschuss liegen in der Aufzeichnung nebeneinander.

Was es kostet

Eine Paimon-Zustandstabelle ist nicht umsonst, und die Datenschicht ist ehrlich bei der Rechnung.

Die Verdichtung hört nie auf. Der Merge-Baum wird durch Hintergrundarbeit kompakt gehalten, die dauerhaft Rechenleistung verbraucht. Je öfter Schlüssel neu geschrieben werden und je frischer die Tabelle sein muss, desto mehr kostet es. Das ist der Grund, warum nicht jede Tabelle der Schicht eine Paimon-Tabelle ist: Die Aufzeichnung selbst, die nur wächst, braucht das nicht.

Eine Streaming-Engine ist Voraussetzung. Zustand dauerhaft zu schreiben heißt, Flink dauerhaft zu betreiben, mit jemandem, der dafür verantwortlich ist. Unternehmen ohne diese Fähigkeit sollten mit Tabellen beginnen, die von Batch-Jobs in Minuten aktualisiert werden, und erst dort zu Strömen übergehen, wo eine Entscheidung Sekunden braucht.

Der Schlüssel muss stimmen. Eine Primärschlüsseltabelle ist nur so gut wie ihr Schlüssel. Sagt die Ontologie noch nicht, was einen Auftrag über Module hinweg identifiziert, kann die Tabelle nicht gebaut werden, und der ehrliche erste Schritt ist die Ontologie, nicht das Format.

Agenten helfen beim Routineteil: Bucket-Zahlen und Verdichtungspläne vorschlagen, die Pipeline entwerfen, die Modulereignisse auf die Zeile abbildet, bemerken, wenn der Rückstand einer Tabelle wächst. Menschen entscheiden den Schlüssel, die Merge-Regel und wie lange Schnappschüsse aufbewahrt werden — weil das Aussagen darüber sind, was das Unternehmen für wahr hält.

Ein Test, den Sie heute machen können

Nehmen Sie ein Objekt, das mehrere Teams beobachten — einen Auftrag, einen Arbeitsgang, eine Sendung — und bitten Sie jedes Team, Ihnen zu zeigen, wo es ihn nachschlägt. Zählen Sie die Bildschirme. Wählen Sie dann ein Feld, etwa die fertige Menge, und fragen Sie jedes Team, was es gerade sagt.

Weichen die Antworten voneinander ab, haben Sie die Zeile gefunden, die die Datenschicht einmal halten soll. Stimmen sie nur überein, weil jemand sie jeden Nachmittag abgleicht, haben Sie die Person gefunden, die von Hand tut, was eine Merge-Engine im Format tut.