Tilstanden, domæneagenter læser: Paimon til arbejdskøen, lageret og godkendelserne

En indkøbsagent bliver bedt om at forberede en genbestilling af en komponent, der er ved at slippe op. For at gøre det godt har den brug for lagerbeholdningen på tre lagre, de åbne kundeordrer, der reserverer noget af den, de indgående leverancer, der allerede er på vej, og leverandørens aktuelle risikostatus. Hver af dem ændrede sig i den seneste time. Den natlige kopi i datavarehuset tager fejl om alle fire. Modulernes produktionstabeller har ret, men en agent, der læser dem i stor skala, er den hurtigste måde at sinke de mennesker, der arbejder i de moduler.

Det er kløften mellem de to hukommelser i et operativsystem for virksomheden: registret, der gemmer hver hændelse for altid, og den levende tilstand, som er, hvordan tingene ser ud nu. Hovedteksten beskriver begge. Denne handler om den anden, og om det tabelformat, datalaget bruger til den. Datalaget er under opbygning; det følgende er, hvordan det designes.

Hvad en domæneagent faktisk læser

Hurukans agenter er domæneagenter: én til indkøb, én til kundeservice, én til arbejdskøen i driften, og så videre. Hver af dem arbejder ud fra et lille antal tilstandstabeller, der svarer på spørgsmål i nutid.

Arbejdskøen. Hvilke job der er frigivet, hvilke der er blokeret og hvorfor, hvilken maskine eller hvilket team der er ledigt. Fødes af driftsmodulet, når job skifter status.

Lager og reservationer. Mængde på lager pr. vare og lokation, minus det, åbne ordrer allerede har gjort krav på, plus det, der er på vej ind. Fødes af hændelser fra Lager og logistik, salg og indkøb.

Godkendelsesindbakken. Hvert forslag, en agent har stillet, med dets kilder og dets risiko, og om et menneske har besluttet endnu. Fødes af agenterne selv og af menneskene i Beslutninger og opgaver.

Ingen af disse tabeller er en kopi af et moduls database. Hver bygges af de hændelser, modulerne udsender, og som registret også gemmer. Tilstandstabellen er en afledt, altid aktuel visning af registret; registret er beviset bag den.

Hvorfor det er en Paimon-tabel

En tilstandstabel ændres tusindvis af gange i timen pr. nøgle: den samme vare, det samme job, det samme forslag, opdateret igen og igen. Tabelformater bygget omkring at tilføje nye filer håndterer det dårligt, fordi hver opdatering bliver en ny fil, og tabellen drukner i små filer. Apache Paimon blev designet til præcis det tilfælde. Dets primærnøgletabeller gemmer rækker i et LSM-træ, sorteret efter nøgle inden for en bucket, så en strøm af opdateringer til de samme nøgler forbliver kompakt, og en læser altid ser den seneste version af hver række (tabeltyper, kontrolleret den 21. oktober 2026).

To Paimon-funktioner gør arbejde, der ellers ville være kode. En flettemotor (merge engine) afgør, hvad der sker, når en ny række ankommer for en eksisterende nøgle: erstat den, behold den første, aggregér, eller udfyld kun de felter, der ankom. Lagertabellen bruger den sidste: lageret skriver beholdningen, salg skriver den reserverede mængde, indkøb skriver den indgående mængde, og tabellen rummer alle tre i én række, uden at noget modul kender til de andre. En changelog-producent udsender hver ændring af tabellen som en selvstændig strøm, så en agent nedstrøms kan reagere på “lageret faldt under genbestillingspunktet” i stedet for at polle.

Den aktuelle udgivelse er Paimon 2.0.0 fra den 7. august 2026 (release catalog, kontrolleret den 21. oktober 2026). Flink skriver og læser den, og lookup join lader et streamingjob berige en hændelse med den aktuelle tilstand i en anden tabel — en ny ordre med det lager, den reserverer — uden en tur til noget andet. Spark, Trino, Hive, StarRocks og Doris læser de samme tabeller (motorer).

Agenten læser tilstanden og skriver kun et forslag

Grænsen betyder mere end formatet. En domæneagent læser tilstandstabellerne frit. Den skriver ikke til et modul, og den skriver heller ikke til tilstandstabellen. Det, den producerer, er et forslag: en udarbejdet genbestilling med de rækker, den læste, den regel, den anvendte, og den risiko, den ser. Forslaget lander i godkendelsesindbakken. Et menneske beslutter. Modulet udfører beslutningen, udsender hændelsen, og tilstandstabellen ændres, fordi hændelsen blev registreret — ikke fordi agenten ændrede den.

Det er det, der holder de to hukommelser ærlige. Hvis agenter skrev tilstand direkte, ville tilstanden indeholde ting, der aldrig skete i noget modul og aldrig blev registreret. Ved at læse tilstand og skrive forslag passerer hver ændring af det, virksomheden anser for sandt, stadig gennem et menneske og gennem registret.

Det besvarer også revisionsspørgsmålet. Paimon gemmer øjebliksbilleder, og et tag fastgør ét, så det ikke udløber. Når et forslag drages i tvivl måneder senere, viser det øjebliksbillede, der blev taget i det øjeblik, agenten læste tabellen, præcis det lager, den kø og de åbne ordrer, den så. Beslutningsloggen rummer begrundelsen; øjebliksbilledet rummer beviset.

Sekunder, minutter eller i nat

Ikke hver tilstand behøver at være en Paimon-tabel fødet af en strøm. Godkendelsesindbakken skal være aktuel til sekundet, fordi et menneske venter i den. Arbejdskøen skal være aktuel til minuttet, fordi en maskine venter. Lager til genbestilling er en beslutning, der træffes nogle få gange om dagen; en tilstand, der er nogle minutter bagud, er fin. Leverandørers risikostatus ændrer sig ugentligt.

At presse alt til sekunder koster kontinuerlig komprimering, en streamingmotor, der aldrig sover, og et driftsteam til at holde begge sunde. Så datalaget spørger, for hver tilstandstabel, hvilken beslutning der afhænger af den, og hvor hurtigt den beslutning virkelig ændrer sig — og kun de tabeller, der har brug for sekunder, får dem. “Realtid” er ikke en egenskab ved platformen; det er et budget, der bruges pr. tabel.

En test, du kan lave i dag

Vælg én beslutning, som nogen i din virksomhed træffer flere gange om dagen: at godkende et indkøb, frigive et job, love en leveringsdato. Skriv hvert tal ned, de kigger på, før de beslutter, og ved siden af hvert, hvor det kommer fra, og hvornår det sidst blev opdateret.

Hvis flere af de tal kommer fra forskellige systemer og blev opdateret på forskellige tidspunkter, laver personen allerede sammenføjningen i hovedet, ud fra en tilstand, der aldrig var konsistent i ét enkelt øjeblik. Det er den tabel, en domæneagent ville have brug for først — og den, der skal designes, før nogen agent bliver bedt om at beslutte noget.