--- title: "Apache Paimon: én tilstandstabell for operatøren, planleggeren og agenten" url: "https://hurukan.com/no/blog/apache-paimon-en-tilstandstabell-for-alle" description: "Hvordan Apache Paimon holder en tabell som oppdateres tusenvis av ganger i timen, hvordan sammenslåingsmotorer uttrykker ontologiregler, og hva den koster." --- # Apache Paimon: én tilstandstabell for operatøren, planleggeren og agenten 19\. oktober 2026·4 min lesing·Redaksjonen Et produksjonsplanleggingsrom sett fra siden: en planlegger ved en pult med én skjerm som viser en abstrakt blågrå jobbtavle, bak glassveggen en monteringslinje der en operatør ser på en veggmontert terminal med de samme formene, ett blått indikatorlys over linjen En monteringsordre endrer tilstand elleve ganger mellom frigivelse og forsendelse: planlagt, frigitt, startet på første stasjon, holdt tilbake for en manglende del, gjenopptatt, kontrollert, én enhet avvist, omarbeidet, pakket, bekreftet, sendt. Operatøren på stasjonen ser sitt steg på en terminal i [Drift og kvalitet](https://hurukan.com/no/modules/drift-og-kvalitet). Planleggeren ser ordren på en tavle. Driftsagenten, spurt om ukens plan fortsatt holder, ser en rapport. Tre visninger, og i de fleste virksomheter tre tabeller, oppdatert etter tre tidsplaner, slik at operatøren, planleggeren og agenten i en time hver ettermiddag tror hver sin ting om den samme ordren. Datalaget i Hurukan er utformet slik at det finnes én tilstandstabell for den ordren, og alle leser den. [Hovedteksten](https://hurukan.com/no/blog/naatilstand-og-registeret-to-minner) forklarer hvorfor nåtilstanden er et eget minne, atskilt fra registeret. Denne teksten handler om formatet tabellen bygges i, Apache Paimon, og om hva det valget koster. Laget er under bygging; dette er hvordan det utformes. ## En tabell som oppdateres, ikke fylles på De fleste tabellformater i et lakehouse forutsetter at data kommer og blir liggende. Nye rader blir nye filer; å endre en rad betyr å skrive om en fil eller merke den som slettet. Det er riktig utforming for et register, der ingenting noen gang endres. Det er feil utforming for tilstanden til en ordre som endres elleve ganger før den er ferdig. Apache Paimon har en annen form. Tabellene med primærnøkkel holder rader sortert etter nøkkel inne i bøtter, i et loggstrukturert sammenslåingstre (LSM-tre): nye versjoner kommer inn på et øverste nivå, og komprimering i bakgrunnen slår dem sammen nedover i sorterte filer, slik at tabellen holder seg kompakt uansett hvor ofte de samme nøklene skrives om ([Paimon-tabelltyper](https://paimon.apache.org/docs/master/concepts/table-types/), kontrollert 21. oktober 2026). En leser ser den nyeste versjonen av hver nøkkel uten å skanne en historikk. Tabeller uten primærnøkkel er tilleggstabeller (append tables), som passer på registersiden; her er det primærnøkkeltypen som er poenget. Gjeldende utgave er 2.0.0 fra 7. august 2026 ([release catalog](https://release-catalog.apache.org/paimon/)). ## Sammenslåingsmotorer er ontologiregler Det som gjør Paimon til mer enn en rask upsert-tabell, er at formatet selv avgjør hvordan en ny versjon av en rad kombineres med den gamle. Paimon kaller dette [sammenslåingsmotoren](https://paimon.apache.org/docs/master/primary-key-table/merge-engine/overview/) (merge engine), og i datalaget svarer hvert valg til en regel ontologien allerede uttrykker om et objekt. **Deduplicate**, standardvalget: den nyeste versjonen vinner. Riktig regel for en ordres status — den siste hendelsen er sannheten. **Partial update**: hver skriver fyller bare sine egne kolonner. Raden for ordretilstanden har de planlagte datoene fra planleggingen, faktisk start og stopp fra stasjonsterminalen, kontrollresultatet fra kvalitet, den pakkede mengden fra lageret. Fire moduler, én rad, ingen av dem overskriver de andre. Sekvensgrupper (sequence groups) lar hvert kolonnesett ha sin egen rekkefølge, slik at en sen melding fra stasjonen ikke kan oppheve en senere fra kvalitet ([partial update](https://paimon.apache.org/docs/master/primary-key-table/merge-engine/partial-update/)). **Aggregation**: tall summeres over hendelser — timer ført på en operasjon, ferdige enheter, avviste enheter. **First row**: den første versjonen beholdes. Nyttig der ontologien sier at en verdi settes én gang, som tidspunktet en ordre ble frigitt. I ontologien beskrives disse som egenskaper ved objektet: hvilket felt som settes én gang, hvilket som akkumuleres, hvilket som tilhører hvilken modul. Å uttrykke dem i tabelldefinisjonen betyr at regelen gjelder for hver skriver, også en agentbygd pipeline som ikke fantes da regelen ble skrevet. ## Én tabell, tre lesere, én endringslogg Operatørens terminal, planleggerens tavle og agentens visning er tre lesere av den samme tabellen, hver filtrert ulikt. Flink skriver den fra modulenes hendelsesstrøm og leser den tilbake i [oppslagskoblinger](https://paimon.apache.org/docs/master/flink/sql-lookup/) (lookup joins). Spark, Trino, Hive, StarRocks og Doris leser den også ([motorstøtte](https://paimon.apache.org/docs/master/engines/overview/)), så en rapportmotor og en notatbok ser den samme raden som terminalen viser. Tabellen sender også ut sine egne endringer. En [endringsloggprodusent](https://paimon.apache.org/docs/master/primary-key-table/changelog-producer/) (changelog producer) — `input`, `lookup` eller `full-compaction`, valgt per tabell — gjør hver sammenslått endring om til en strøm. Driftsagenten abonnerer på «ordre holdt tilbake» i stedet for å skanne tavlen, og planleggingsvisningen oppdateres fordi tabellen endret seg, ikke fordi noen trykket på oppdater. For revisjon beholder Paimon øyeblikksbilder og lar en [tag](https://paimon.apache.org/docs/master/maintenance/manage-tags/) feste ett for godt. Da agenten foreslo å flytte tre ordrer til neste uke, viser taggen tatt i det øyeblikket tavlen den så på. Forslaget, beslutningen og øyeblikksbildet ligger ved siden av hverandre i registeret. ## Hva det koster En tilstandstabell i Paimon er ikke gratis, og datalaget er ærlig om regningen. **Komprimeringen stopper aldri.** Sammenslåingstreet holdes kompakt av bakgrunnsarbeid som bruker regnekraft kontinuerlig. Jo oftere nøkler skrives om og jo ferskere tabellen må være, desto mer koster det. Det er grunnen til at ikke hver tabell i laget er en Paimon-tabell: selve registeret, som bare vokser, trenger det ikke. **En strømmemotor er en forutsetning.** Å skrive tilstand kontinuerlig betyr å kjøre Flink kontinuerlig, med noen som er ansvarlig for det. Virksomheter uten den kapasiteten bør starte med tabeller som oppdateres i løpet av minutter av batchjobber, og gå over til strømmer bare der en beslutning trenger sekunder. **Nøkkelen må være riktig.** En primærnøkkeltabell er bare så god som nøkkelen sin. Hvis ontologien ennå ikke sier hva som identifiserer en ordre på tvers av moduler, kan tabellen ikke bygges, og det ærlige første steget er ontologien, ikke formatet. Agenter hjelper med rutinedelen: foreslår antall bøtter og komprimeringsplaner, utarbeider pipelinen som kartlegger modulhendelser til raden, legger merke til når en tabells etterslep vokser. Mennesker avgjør nøkkelen, sammenslåingsregelen og hvor lenge øyeblikksbilder beholdes — fordi det er utsagn om hva virksomheten anser som sant. ## En test du kan gjøre i dag Ta ett objekt som flere team følger med på — en ordre, en jobb, en forsendelse — og be hvert team vise deg hvor de slår det opp. Tell skjermene. Velg så ett felt, for eksempel ferdig mengde, og spør hver av dem hva det står akkurat nå. Hvis svarene er ulike, har du funnet raden datalaget er utformet for å holde én gang. Hvis de bare stemmer fordi noen avstemmer dem hver ettermiddag, har du funnet personen som for hånd gjør det en sammenslåingsmotor gjør i formatet. - Apache Paimon - LSM-tre - sammenslåingsmotor - drift - datalaget ## 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)