Apache Paimon: én tilstandstabel for operatøren, planlæggeren og agenten

En monteringsordre skifter tilstand elleve gange mellem frigivelse og afsendelse: planlagt, frigivet, startet ved første station, standset for en manglende del, genoptaget, inspiceret, én enhed afvist, omarbejdet, pakket, bekræftet, afsendt. Operatøren ved stationen ser sit trin på en terminal i Drift og kvalitet. Planlæggeren ser ordren på en tavle. Driftsagenten, der bliver spurgt, om ugens plan stadig holder, ser en rapport. Tre visninger og i de fleste virksomheder tre tabeller, opdateret efter tre tidsplaner, så operatøren, planlæggeren og agenten i en time hver eftermiddag hver især tror noget forskelligt om den samme ordre.

Hurukans datalag er designet, så der er én tilstandstabel for den ordre, og alle læser den. Hovedteksten forklarer, hvorfor den levende tilstand er en separat hukommelse fra registret. Denne tekst handler om det format, tabellen er bygget i, Apache Paimon, og om hvad det valg koster. Laget er under opbygning; sådan bliver det designet.

En tabel, der opdateres, ikke tilføjes til

De fleste tabelformater i et lakehouse antager, at data ankommer og bliver. Nye rækker bliver nye filer; at ændre en række betyder at omskrive en fil eller markere den som slettet. Det er det rigtige design til et register, hvor intet nogensinde ændres. Det er det forkerte design til tilstanden for en ordre, der ændres elleve gange, før den er færdig.

Apache Paimon har en anden form. Dets tabeller med primærnøgle holder rækker sorteret efter nøgle inde i spande (buckets) i et log-struktureret flettetræ (LSM-træ): nye versioner ankommer i et øverste niveau, og kompaktering i baggrunden fletter dem ned i sorterede filer, så tabellen forbliver kompakt, uanset hvor ofte de samme nøgler omskrives (Paimon-tabeltyper, kontrolleret den 21. oktober 2026). En læser ser den seneste version af hver nøgle uden at scanne en historik. Tabeller uden primærnøgle er tilføjelsestabeller, som passer til registersiden; her er det primærnøgletypen, der er pointen. Den aktuelle udgivelse er 2.0.0 fra 7. august 2026 (udgivelseskatalog).

Flettemotorer er ontologiregler

Det, der gør Paimon til mere end en hurtig upsert-tabel, er, at formatet selv afgør, hvordan en ny version af en række kombineres med den gamle. Paimon kalder det flettemotoren (merge engine), og i datalaget svarer hvert valg til en regel, ontologien allerede fastslår om et objekt.

Deduplicate, standarden: den nyeste version vinder. Den rigtige regel for en ordres status — den seneste hændelse er sandheden.

Delvis opdatering (partial update): hver skribent udfylder kun sine egne kolonner. Ordretilstandsrækken har de planlagte datoer fra planlægningen, den faktiske start og stop fra stationsterminalen, inspektionsresultatet fra kvalitet, den pakkede mængde fra lageret. Fire moduler, én række, og ingen af dem overskriver de andre. Sekvensgrupper lader hvert kolonnesæt have sin egen rækkefølge, så en sen besked fra stationen ikke kan omgøre en senere fra kvalitet (delvis opdatering).

Aggregering: tal lægges sammen på tværs af hændelser — timer bogført på en operation, færdige enheder, afviste enheder.

Første række (first row): den første version beholdes. Nyttigt, hvor ontologien siger, at en værdi sættes én gang, som tidspunktet, hvor en ordre blev frigivet.

I ontologien beskrives disse som egenskaber ved objektet: hvilket felt der sættes én gang, hvilket der akkumuleres, hvilket der tilhører hvilket modul. At udtrykke dem i tabeldefinitionen betyder, at reglen gælder for hver skribent, også en agentbygget pipeline, der ikke fandtes, da reglen blev skrevet.

Én tabel, tre læsere, én ændringslog

Operatørens terminal, planlæggerens tavle og agentens visning er tre læsere af den samme tabel, hver filtreret forskelligt. Flink skriver den fra modulernes hændelsesstrøm og læser den tilbage i opslagsjoins (lookup joins). Spark, Trino, Hive, StarRocks og Doris læser den også (motorunderstøttelse), så en rapportmotor og en notesbog ser den samme række, som terminalen viser.

Tabellen udsender også sine egne ændringer. En ændringslogproducent (changelog producer) — input, lookup eller full-compaction, valgt pr. tabel — gør hver flettet ændring til en strøm. Driftsagenten abonnerer på “ordre standset” i stedet for at scanne tavlen, og planlægningsvisningen opdateres, fordi tabellen ændrede sig, ikke fordi nogen trykkede på opdater.

Til revision beholder Paimon snapshots og lader et tag fastholde ét permanent. Da agenten foreslog at flytte tre ordrer til næste uge, viser det tag, der blev taget i det øjeblik, den tavle, den så på. Forslaget, beslutningen og snapshottet ligger side om side i registret.

Hvad det koster

En Paimon-tilstandstabel er ikke gratis, og datalaget er ærligt om regningen.

Kompaktering stopper aldrig. Flettetræet holdes kompakt af baggrundsarbejde, der bruger beregningskraft løbende. Jo oftere nøgler omskrives, og jo friskere tabellen skal være, desto mere koster det. Det er grunden til, at ikke alle tabeller i laget er Paimon-tabeller: registret selv, som kun vokser, har ikke brug for det.

En streamingmotor er en forudsætning. At skrive tilstand løbende betyder at køre Flink løbende, med nogen, der har ansvaret for det. Virksomheder uden den kompetence bør starte med tabeller, der opdateres inden for minutter af batchjob, og kun gå over til strømme, hvor en beslutning kræver sekunder.

Nøglen skal være rigtig. En primærnøgletabel er kun så god som sin nøgle. Hvis ontologien endnu ikke siger, hvad der identificerer en ordre på tværs af moduler, kan tabellen ikke bygges, og det ærlige første skridt er ontologien, ikke formatet.

Agenter hjælper med den rutinemæssige del: at foreslå antal spande og kompakteringsplaner, at udarbejde den pipeline, der mapper modulhændelser til rækken, at bemærke, når en tabels forsinkelse vokser. Mennesker beslutter nøglen, fletteregelen og hvor længe snapshots beholdes — fordi det er udsagn om, hvad virksomheden anser for sandt.

En test, du kan lave i dag

Tag ét objekt, som flere teams holder øje med — en ordre, et job, en forsendelse — og bed hvert team vise dig, hvor de slår det op. Tæl skærmene. Vælg derefter ét felt, for eksempel den færdige mængde, og spørg hver af dem, hvad det viser lige nu.

Er svarene forskellige, har du fundet den række, datalaget er designet til at holde én gang. Er de kun enige, fordi nogen afstemmer dem hver eftermiddag, har du fundet den person, der i hånden gør det, en flettemotor gør i formatet.