--- title: "Tilstanden domeneagenter leser: Paimon for arbeidskøen, lageret og godkjenningene" url: "https://hurukan.com/no/blog/tilstanden-domeneagenter-leser-paimon" description: "En domeneagent trenger virksomhetens tilstand akkurat nå, ikke en nattlig kopi. Slik holder datalaget den i Apache Paimon, og hvorfor agenter bare foreslår." --- # Tilstanden domeneagenter leser: Paimon for arbeidskøen, lageret og godkjenningene 6\. oktober 2026·4 min lesing·Redaksjonen En planlegger sett bakfra ved et ståbord på et stille ekspedisjonskontor, én bred skjerm som viser en abstrakt blågrå tavle med køede rader som oppdateres mens hun ser på, en tynn blå statusstripe langs bordets øvre kant En innkjøpsagent blir bedt om å forberede en etterfyllingsordre for en komponent det begynner å bli lite av. For å gjøre det godt trenger den lagerbeholdningen i tre lagre, de åpne kundeordrene som reserverer noe av den, de innkommende leveransene som allerede er på veien, og leverandørens gjeldende risikostatus. Hver av dem endret seg den siste timen. Den nattlige kopien i datavarehuset tar feil om alle fire. Modulenes produksjonstabeller har rett, men en agent som leser dem i stor skala, er den raskeste måten å sinke menneskene som arbeider i de modulene. Dette er gapet mellom de to minnene i et operativsystem for virksomheten: registeret, som beholder hver hendelse for godt, og nåtilstanden, som er slik tingene ser ut nå. [Hovedteksten](https://hurukan.com/no/blog/naatilstand-og-registeret-to-minner) beskriver begge. Denne handler om den andre, og om tabellformatet datalaget bruker til den. Datalaget er under bygging; det som følger, er hvordan det utformes. ## Hva en domeneagent faktisk leser Hurukans agenter er domeneagenter: én for innkjøp, én for kundeservice, én for arbeidskøen i drift, og så videre. Hver av dem arbeider ut fra et lite antall tilstandstabeller som svarer på spørsmål i presens. **Arbeidskøen.** Hvilke jobber er frigitt, hvilke er blokkert og hvorfor, hvilken maskin eller hvilket team er ledig. Mates av driftsmodulen etter hvert som jobber endrer status. **Lager og reservasjoner.** Antall på lager per vare og lokasjon, minus det åpne ordrer allerede har gjort krav på, pluss det som er på vei. Mates av hendelser fra [lager og logistikk](https://hurukan.com/no/modules/lager-og-logistikk), salg og innkjøp. **Godkjenningsinnboksen.** Hvert forslag en agent har laget, med kildene og risikoen, og om en person har besluttet ennå. Mates av agentene selv og av menneskene i [beslutninger og oppgaver](https://hurukan.com/no/modules/beslutninger-og-oppgaver). Ingen av disse tabellene er en kopi av en moduls database. Hver bygges av hendelsene modulene sender ut, som registeret også beholder. Tilstandstabellen er et avledet, alltid oppdatert bilde av registeret; registeret er beviset bak det. ## Hvorfor dette er en Paimon-tabell En tilstandstabell endres tusenvis av ganger i timen per nøkkel: samme vare, samme jobb, samme forslag, oppdatert igjen og igjen. Tabellformater bygd rundt å legge til nye filer håndterer det dårlig, fordi hver oppdatering blir en ny fil og tabellen drukner i småfiler. Apache Paimon ble utformet for nettopp dette tilfellet. Primærnøkkeltabellene lagrer rader i et LSM-tre, sortert etter nøkkel innenfor en bøtte, slik at en strøm av oppdateringer til de samme nøklene holder seg kompakt og en leser alltid ser siste versjon av hver rad ([tabelltyper](https://paimon.apache.org/docs/master/concepts/table-types/), kontrollert 21. oktober 2026). To Paimon-funksjoner gjør arbeid som ellers ville vært kode. En [sammenslåingsmotor](https://paimon.apache.org/docs/master/primary-key-table/merge-engine/overview/) (merge engine) avgjør hva som skjer når en ny rad kommer for en eksisterende nøkkel: erstatte den, beholde den første, aggregere, eller fylle inn bare feltene som kom. Lagertabellen bruker den siste: lager skriver beholdningen, salg skriver det reserverte antallet, innkjøp skriver det innkommende antallet, og tabellen holder alle tre i én rad uten at noen modul vet om de andre. En [endringsloggprodusent](https://paimon.apache.org/docs/master/primary-key-table/changelog-producer/) (changelog producer) sender ut hver endring i tabellen som en egen strøm, slik at en agent nedstrøms kan reagere på «lageret falt under bestillingspunktet» i stedet for å polle. Gjeldende utgivelse er Paimon 2.0.0 fra 7. august 2026 ([utgivelseskatalog](https://release-catalog.apache.org/paimon/), kontrollert 21. oktober 2026). Flink skriver og leser den, og [oppslagskoblingen](https://paimon.apache.org/docs/master/flink/sql-lookup/) (lookup join) lar en strømmejobb berike en hendelse med gjeldende tilstand i en annen tabell — en ny ordre med lageret den reserverer — uten en rundtur til noe annet. Spark, Trino, Hive, StarRocks og Doris leser de samme tabellene ([motorer](https://paimon.apache.org/docs/master/engines/overview/)). ## Agenten leser tilstanden og skriver bare et forslag Grensen betyr mer enn formatet. En domeneagent leser tilstandstabellene fritt. Den skriver ikke til en modul, og den skriver heller ikke til tilstandstabellen. Det den produserer, er et forslag: en utarbeidet etterfyllingsordre med radene den leste, regelen den brukte og risikoen den ser. Forslaget lander i godkjenningsinnboksen. En person beslutter. Modulen utfører beslutningen, sender ut hendelsen, og tilstandstabellen endres fordi hendelsen ble registrert — ikke fordi agenten endret den. Det er dette som holder de to minnene ærlige. Hvis agenter skrev tilstand direkte, ville tilstanden inneholde ting som aldri skjedde i noen modul og aldri ble registrert. Ved å lese tilstand og skrive forslag går hver endring i det virksomheten regner som sant, fortsatt gjennom en person og gjennom registeret. Det svarer også på revisjonsspørsmålet. Paimon beholder øyeblikksbilder, og en [tagg](https://paimon.apache.org/docs/master/maintenance/manage-tags/) fester ett slik at det ikke utløper. Når et forslag blir utfordret måneder senere, viser øyeblikksbildet tatt i det øyeblikket agenten leste tabellen, nøyaktig lageret, køen og de åpne ordrene den så. Beslutningsloggen holder begrunnelsen; øyeblikksbildet holder beviset. ## Sekunder, minutter eller i natt Ikke hver tilstand må være en Paimon-tabell matet av en strøm. Godkjenningsinnboksen må være oppdatert til sekundet, fordi en person venter i den. Arbeidskøen må være oppdatert til minuttet, fordi en maskin venter. Lager for etterfylling er en beslutning som tas noen få ganger om dagen; en tilstand som ligger noen minutter bak, er greit. Leverandørens risikostatus endres ukentlig. Å presse alt til sekunder koster kontinuerlig komprimering, en strømmemotor som aldri sover, og et driftsteam som holder begge friske. Så datalaget spør, for hver tilstandstabell, hvilken beslutning som avhenger av den og hvor raskt den beslutningen egentlig endres — og bare tabellene som trenger sekunder, får dem. «Sanntid» er ikke en egenskap ved plattformen; det er et budsjett som brukes per tabell. ## En test du kan gjøre i dag Velg én beslutning noen i virksomheten din tar flere ganger om dagen: å godkjenne et innkjøp, frigi en jobb, love en leveringsdato. Skriv ned hvert tall de ser på før de beslutter, og ved siden av hvert, hvor det kommer fra og når det sist ble oppdatert. Hvis flere av tallene kommer fra ulike systemer og ble oppdatert til ulik tid, gjør personen allerede koblingen i hodet, ut fra tilstand som aldri var konsistent i ett og samme øyeblikk. Det er tabellen en domeneagent ville trenge først — og den som bør utformes før noen agent blir bedt om å avgjøre noe som helst. - Apache Paimon - domeneagenter - nåtilstand - godkjenningsinnboks - datalag ## Les videre - [Én identitet for mennesker og agenter: hvem får gjøre hva](https://hurukan.com/no/blog/en-identitet-for-mennesker-og-agenter) - [Nåtilstand og register: to minner i et operativsystem for virksomheten](https://hurukan.com/no/blog/naatilstand-og-registeret-to-minner)