Apache Paimon: één toestandstabel voor de operator, de planner en de agent

Een assemblageorder verandert elf keer van status tussen vrijgave en verzending: gepland, vrijgegeven, gestart op het eerste station, geblokkeerd voor een ontbrekend onderdeel, hervat, geïnspecteerd, één eenheid afgekeurd, nabewerkt, verpakt, bevestigd, verzonden. De operator aan het station ziet haar stap op een terminal in Bedrijfsvoering en kwaliteit. De planner ziet de order op een bord. De operationele agent, gevraagd of het weekplan nog klopt, ziet een rapport. Drie weergaven, en in de meeste bedrijven drie tabellen, ververst op drie schema’s, zodat elke middag een uur lang de operator, de planner en de agent elk iets anders geloven over dezelfde order.

De laag Data van Hurukan is zo ontworpen dat er voor die order één toestandstabel is, en iedereen leest die. De hoofdtekst legt uit waarom de actuele toestand een ander geheugen is dan het register. Deze tekst gaat over het formaat waarin die tabel wordt gebouwd, Apache Paimon, en over wat die keuze kost. De laag is in aanbouw; zo wordt ze ontworpen.

Een tabel die wordt bijgewerkt, niet aangevuld

De meeste tabelformaten in een lakehouse gaan ervan uit dat data binnenkomt en blijft. Nieuwe rijen worden nieuwe bestanden; een rij wijzigen betekent een bestand herschrijven of als verwijderd markeren. Dat is het juiste ontwerp voor een register, waarin nooit iets wordt gewijzigd. Het is het verkeerde ontwerp voor de toestand van een order die elf keer verandert voordat hij klaar is.

Apache Paimon kiest een andere vorm. Zijn tabellen met primaire sleutel houden rijen gesorteerd op sleutel binnen buckets, in een log-structured merge tree: nieuwe versies komen in een bovenste niveau binnen, en compactie op de achtergrond voegt ze naar beneden samen tot gesorteerde bestanden, zodat de tabel compact blijft hoe vaak dezelfde sleutels ook worden herschreven (Paimon table types, gecontroleerd op 21 oktober 2026). Een lezer ziet de laatste versie van elke sleutel zonder een historie te scannen. Tabellen zonder primaire sleutel zijn append-tabellen, die bij de kant van het register passen; hier gaat het om de soort met primaire sleutel. De actuele release is 2.0.0 van 7 augustus 2026 (release catalog).

Merge-engines zijn regels van de ontologie

Wat Paimon meer maakt dan een snelle upsert-tabel, is dat het formaat zelf bepaalt hoe een nieuwe versie van een rij met de oude wordt gecombineerd. Paimon noemt dit de merge engine, en in de laag Data komt elke keuze overeen met een regel die de ontologie al over een object vastlegt.

Deduplicate, de standaard: de nieuwste versie wint. De juiste regel voor de status van een order — de laatste gebeurtenis is de waarheid.

Partial update: elke schrijver vult alleen zijn eigen kolommen. De toestandsrij van de order heeft de geplande data uit planning, de werkelijke start en stop van de stationsterminal, het inspectieresultaat van kwaliteit, de verpakte hoeveelheid van het magazijn. Vier modules, één rij, en geen van hen overschrijft de anderen. Sequence groups geven elke kolomset een eigen volgorde, zodat een laat bericht van het station een later bericht van kwaliteit niet ongedaan kan maken (partial update).

Aggregation: getallen tellen op over gebeurtenissen heen — uren geboekt op een bewerking, voltooide eenheden, afgekeurde eenheden.

First row: de eerste versie blijft behouden. Bruikbaar waar de ontologie zegt dat een waarde één keer wordt gezet, zoals het moment waarop een order werd vrijgegeven.

In de ontologie zijn dit eigenschappen van het object: welk veld één keer wordt gezet, welk optelt, welk bij welke module hoort. Door ze in de tabeldefinitie uit te drukken, geldt de regel voor elke schrijver, ook voor een pijplijn die een agent bouwde en die nog niet bestond toen de regel werd opgeschreven.

Eén tabel, drie lezers, één changelog

De terminal van de operator, het bord van de planner en de weergave van de agent zijn drie lezers van dezelfde tabel, elk anders gefilterd. Flink schrijft haar vanuit de stroom van modulegebeurtenissen en leest haar terug in lookup joins. Spark, Trino, Hive, StarRocks en Doris lezen haar ook (ondersteuning per engine), zodat een rapportage-engine en een notebook dezelfde rij zien die de terminal toont.

De tabel geeft ook haar eigen wijzigingen af. Een changelog producer — input, lookup of full-compaction, per tabel gekozen — maakt van elke samengevoegde wijziging een stroom. De operationele agent abonneert zich op “order geblokkeerd” in plaats van het bord te scannen, en de planningsweergave wordt bijgewerkt omdat de tabel veranderde, niet omdat iemand op verversen drukte.

Voor de audit bewaart Paimon snapshots en laat het toe dat een tag er één permanent vastzet. Toen de agent voorstelde drie orders naar volgende week te verplaatsen, laat de tag die op dat moment werd gezet het bord zien waar hij naar keek. Het voorstel, de beslissing en de snapshot staan naast elkaar in het register.

Wat het kost

Een toestandstabel in Paimon is niet gratis, en de laag Data is eerlijk over de rekening.

Compactie stopt nooit. De merge tree wordt compact gehouden door werk op de achtergrond dat voortdurend rekenkracht verbruikt. Hoe vaker sleutels worden herschreven en hoe actueler de tabel moet zijn, hoe meer het kost. Daarom is niet elke tabel in de laag een Paimon-tabel: het register zelf, dat alleen groeit, heeft het niet nodig.

Een streaming-engine is een voorwaarde. Toestand voortdurend schrijven betekent Flink voortdurend draaien, met iemand die daarvoor verantwoordelijk is. Bedrijven zonder die capaciteit kunnen beter beginnen met tabellen die binnen minuten door batchtaken worden ververst, en pas naar stromen gaan waar een beslissing seconden nodig heeft.

De sleutel moet kloppen. Een tabel met primaire sleutel is zo goed als haar sleutel. Als de ontologie nog niet zegt wat een order over modules heen identificeert, kan de tabel niet worden gebouwd, en dan is de eerlijke eerste stap de ontologie, niet het formaat.

Agents helpen bij het routinewerk: aantallen buckets en compactieschema’s voorstellen, de pijplijn opstellen die modulegebeurtenissen op de rij afbeeldt, opmerken wanneer de achterstand van een tabel groeit. Mensen beslissen over de sleutel, de merge-regel en hoe lang snapshots worden bewaard — omdat dat uitspraken zijn over wat het bedrijf als waar beschouwt.

Een test die u vandaag kunt doen

Neem één object dat meerdere teams volgen — een order, een opdracht, een zending — en vraag elk team om te laten zien waar ze het opzoeken. Tel de schermen. Kies dan één veld, zoals de voltooide hoeveelheid, en vraag elk van hen wat er nu staat.

Als de antwoorden verschillen, hebt u de rij gevonden die de laag Data is ontworpen om één keer bij te houden. Als ze alleen overeenkomen omdat iemand ze elke middag afstemt, hebt u de persoon gevonden die met de hand doet wat een merge-engine in het formaat doet.