Tillståndet domänagenter läser: Paimon för arbetskön, lagret och godkännandena

En inköpsagent får i uppdrag att förbereda en påfyllningsorder för en komponent som håller på att ta slut. För att göra det väl behöver den lagersaldot i tre lager, de öppna kundorder som reserverar en del av det, de inkommande leveranser som redan är på väg, och leverantörens aktuella riskstatus. Var och en av dem ändrades under den senaste timmen. Den nattliga kopian i datalagret har fel om alla fyra. Modulernas produktionstabeller har rätt, men en agent som läser dem i stor skala är det snabbaste sättet att sinka de människor som arbetar i de modulerna.

Det här är glappet mellan de två minnena i ett operativsystem för företaget: registret, som behåller varje händelse för gott, och det levande tillståndet, som är hur saker ser ut nu. Huvudtexten beskriver båda. Den här handlar om det andra, och om det tabellformat datalagret använder för det. Datalagret är under uppbyggnad; det som följer är hur det utformas.

Vad en domänagent faktiskt läser

Hurukans agenter är domänagenter: en för inköp, en för kundservice, en för arbetskön i driften, och så vidare. Var och en av dem arbetar utifrån ett litet antal tillståndstabeller som svarar på frågor i presens.

Arbetskön. Vilka jobb som är frisläppta, vilka som är blockerade och varför, vilken maskin eller vilket team som är ledigt. Matas av driftmodulen när jobb byter status.

Lager och reservationer. Kvantitet i lager per artikel och plats, minus vad öppna order redan har gjort anspråk på, plus vad som är på väg in. Matas av händelser från Lager och logistik, handel och inköp.

Godkännandekorgen. Varje förslag en agent har lagt, med dess källor och dess risk, och om en människa har beslutat ännu. Matas av agenterna själva och av människorna i Beslut och uppgifter.

Ingen av dessa tabeller är en kopia av en moduls databas. Var och en byggs av de händelser som modulerna avger, och som registret också behåller. Tillståndstabellen är en härledd, alltid aktuell vy av registret; registret är beviset bakom den.

Varför det här är en Paimon-tabell

En tillståndstabell ändras tusentals gånger i timmen per nyckel: samma artikel, samma jobb, samma förslag, uppdaterat om och om igen. Tabellformat byggda kring att lägga till nya filer hanterar det dåligt, eftersom varje uppdatering blir en ny fil och tabellen drunknar i små filer. Apache Paimon utformades för precis det fallet. Dess primärnyckeltabeller lagrar rader i ett LSM-träd, sorterade efter nyckel inom en hink, så att en ström av uppdateringar av samma nycklar förblir kompakt och en läsare alltid ser den senaste versionen av varje rad (tabelltyper, kontrollerat den 21 oktober 2026).

Två Paimon-funktioner gör arbete som annars skulle vara kod. En sammanslagningsmotor (merge engine) avgör vad som händer när en ny rad kommer för en befintlig nyckel: ersätt den, behåll den första, aggregera, eller fyll bara i de fält som kom. Lagertabellen använder den sista: lagret skriver kvantiteten i lager, handeln skriver den reserverade kvantiteten, inköpet skriver den inkommande kvantiteten, och tabellen håller alla tre i en rad utan att någon modul känner till de andra. En changelog-producent avger varje ändring i tabellen som en egen ström, så att en agent nedströms kan reagera på “lagret föll under beställningspunkten” i stället för att fråga om och om igen.

Aktuell version är Paimon 2.0.0 från den 7 augusti 2026 (release catalog, kontrollerat den 21 oktober 2026). Flink skriver och läser den, och uppslagskopplingen (lookup join) låter ett strömmande jobb berika en händelse med det aktuella tillståndet i en annan tabell — en ny order med det lager den reserverar — utan en tur-och-retur till något annat. Spark, Trino, Hive, StarRocks och Doris läser samma tabeller (motorer).

Agenten läser tillståndet och skriver bara ett förslag

Gränsen är viktigare än formatet. En domänagent läser tillståndstabellerna fritt. Den skriver inte till en modul, och den skriver inte till tillståndstabellen heller. Det den producerar är ett förslag: en utarbetad påfyllningsorder med de rader den läste, den regel den tillämpade och den risk den ser. Förslaget landar i godkännandekorgen. En människa beslutar. Modulen verkställer beslutet, avger händelsen, och tillståndstabellen ändras för att händelsen registrerades — inte för att agenten ändrade den.

Det är det som håller de två minnena ärliga. Om agenter skrev tillstånd direkt skulle tillståndet innehålla saker som aldrig hände i någon modul och aldrig registrerades. Genom att läsa tillstånd och skriva förslag passerar varje ändring av vad företaget betraktar som sant fortfarande genom en människa och genom registret.

Det besvarar också revisionsfrågan. Paimon behåller ögonblicksbilder, och en tagg fäster en så att den inte går ut. När ett förslag ifrågasätts månader senare visar ögonblicksbilden som togs i det ögonblick agenten läste tabellen exakt det lager, den kö och de öppna order den såg. Beslutsloggen håller resonemanget; ögonblicksbilden håller bevisen.

Sekunder, minuter eller i natt

Inte varje tillstånd behöver vara en Paimon-tabell matad av en ström. Godkännandekorgen måste vara aktuell på sekunden, eftersom en människa väntar i den. Arbetskön måste vara aktuell på minuten, eftersom en maskin väntar. Lager för påfyllning är ett beslut som fattas några gånger om dagen; ett tillstånd som ligger några minuter efter duger. Leverantörers riskstatus ändras veckovis.

Att driva allt till sekunder kostar kontinuerlig komprimering, en strömningsmotor som aldrig sover, och ett driftteam som håller båda friska. Så datalagret frågar, för varje tillståndstabell, vilket beslut som beror på den och hur snabbt det beslutet verkligen ändras — och bara de tabeller som behöver sekunder får dem. “Realtid” är inte en egenskap hos plattformen; det är en budget som spenderas per tabell.

Ett test du kan göra i dag

Välj ett beslut som någon i ditt företag fattar flera gånger om dagen: godkänna ett inköp, släppa ett jobb, lova ett leveransdatum. Skriv ner varje siffra de tittar på innan de beslutar och, bredvid var och en, var den kommer ifrån och när den senast uppdaterades.

Om flera av de siffrorna kommer från olika system och uppdaterades vid olika tidpunkter gör personen redan sammanfogningen i huvudet, utifrån ett tillstånd som aldrig var konsekvent i ett enda ögonblick. Det är den tabell en domänagent skulle behöva först — och den som ska utformas innan någon agent ombeds besluta något.