Apache Paimon: en tillståndstabell för operatören, planeraren och agenten

En monteringsorder byter tillstånd elva gånger mellan frisläppning och leverans: planerad, frisläppt, påbörjad vid första stationen, stoppad för en saknad del, återupptagen, inspekterad, en enhet kasserad, omarbetad, packad, bekräftad, skickad. Operatören vid stationen ser sitt steg på en terminal i Drift och kvalitet. Planeraren ser ordern på en tavla. Driftagenten, tillfrågad om veckans plan fortfarande håller, ser en rapport. Tre vyer, och i de flesta företag tre tabeller, uppdaterade enligt tre scheman, så att operatören, planeraren och agenten under en timme varje eftermiddag var och en tror något olika om samma order.

Hurukans datalager är utformat så att det finns en tillståndstabell för den ordern, och alla läser den. Huvudtexten förklarar varför det levande tillståndet är ett separat minne från registret. Den här texten handlar om formatet den tabellen byggs i, Apache Paimon, och om vad det valet kostar. Lagret är under uppbyggnad; så här utformas det.

En tabell som uppdateras, inte läggs till

De flesta tabellformat i ett lakehouse antar att data kommer och stannar. Nya rader blir nya filer; att ändra en rad innebär att skriva om en fil eller markera den raderad. Det är rätt design för ett register, där ingenting någonsin ändras. Det är fel design för tillståndet hos en order som ändras elva gånger innan den är klar.

Apache Paimon har en annan form. Dess primärnyckeltabeller håller rader sorterade efter nyckel inuti hinkar, i ett log-strukturerat sammanslagningsträd (LSM-träd): nya versioner kommer in på en toppnivå, och bakgrundskomprimering slår ihop dem nedåt i sorterade filer, så att tabellen förblir kompakt hur ofta samma nycklar än skrivs om (Paimons tabelltyper, kontrollerat den 21 oktober 2026). En läsare ser den senaste versionen av varje nyckel utan att skanna en historik. Tabeller utan primärnyckel är tilläggstabeller, som passar registersidan; här är primärnyckelsorten poängen. Aktuell version är 2.0.0 från den 7 augusti 2026 (release catalog).

Sammanslagningsmotorer är ontologiregler

Det som gör Paimon till mer än en snabb upsert-tabell är att formatet självt avgör hur en ny version av en rad kombineras med den gamla. Paimon kallar det sammanslagningsmotorn (merge engine), och i datalagret motsvarar varje val en regel som ontologin redan anger om ett objekt.

Deduplicate, standard: den nyaste versionen vinner. Rätt regel för en orders status — den senaste händelsen är sanningen.

Partial update: varje skrivare fyller bara sina egna kolumner. Orderns tillståndsrad har de planerade datumen från planeringen, faktisk start och stopp från stationsterminalen, inspektionsresultatet från kvaliteten, den packade kvantiteten från lagret. Fyra moduler, en rad, ingen av dem skriver över de andra. Sekvensgrupper låter varje kolumnuppsättning bära sin egen ordning, så att ett sent meddelande från stationen inte kan upphäva ett senare från kvaliteten (partial update).

Aggregation: siffror summeras över händelser — bokförda timmar på en operation, färdiga enheter, kasserade enheter.

First row: den första versionen behålls. Användbart där ontologin säger att ett värde sätts en gång, som ögonblicket då en order släpptes.

I ontologin beskrivs dessa som egenskaper hos objektet: vilket fält som sätts en gång, vilket som ackumuleras, vilket som hör till vilken modul. Att uttrycka dem i tabelldefinitionen betyder att regeln gäller för varje skrivare, även ett agentbyggt flöde som inte fanns när regeln skrevs.

En tabell, tre läsare, en changelog

Operatörens terminal, planerarens tavla och agentens vy är tre läsare av samma tabell, var och en filtrerad olika. Flink skriver den från modulernas händelseström och läser tillbaka den i uppslagskopplingar. Spark, Trino, Hive, StarRocks och Doris läser den också (motorstöd), så att en rapportmotor och en anteckningsbok ser samma rad som terminalen visar.

Tabellen avger också sina egna ändringar. En changelog-producent — input, lookup eller full-compaction, vald per tabell — förvandlar varje sammanslagen ändring till en ström. Driftagenten prenumererar på “order stoppad” i stället för att skanna tavlan, och planeringsvyn uppdateras för att tabellen ändrades, inte för att någon tryckte på uppdatera.

För revision behåller Paimon ögonblicksbilder och låter en tagg fästa en permanent. När agenten föreslog att tre order skulle flyttas till nästa vecka visar taggen som togs i det ögonblicket den tavla den tittade på. Förslaget, beslutet och ögonblicksbilden ligger bredvid varandra i registret.

Vad det kostar

En Paimon-tillståndstabell är inte gratis, och datalagret är ärligt om notan.

Komprimeringen stannar aldrig. Sammanslagningsträdet hålls kompakt av bakgrundsarbete som förbrukar beräkningskraft kontinuerligt. Ju oftare nycklar skrivs om och ju färskare tabellen måste vara, desto mer kostar det. Det är skälet till att inte varje tabell i lagret är en Paimon-tabell: registret självt, som bara växer, behöver det inte.

En strömningsmotor är en förutsättning. Att skriva tillstånd kontinuerligt innebär att köra Flink kontinuerligt, med någon ansvarig för det. Företag utan den förmågan bör börja med tabeller som uppdateras på minuter av batchjobb och gå över till strömmar bara där ett beslut behöver sekunder.

Nyckeln måste vara rätt. En primärnyckeltabell är inte bättre än sin nyckel. Om ontologin ännu inte säger vad som identifierar en order över moduler kan tabellen inte byggas, och det ärliga första steget är ontologin, inte formatet.

Agenter hjälper till med rutindelen: föreslå antal hinkar och komprimeringsscheman, utarbeta flödet som mappar modulhändelser på raden, lägga märke till när en tabells fördröjning växer. Människor beslutar nyckeln, sammanslagningsregeln och hur länge ögonblicksbilder behålls — för att det är påståenden om vad företaget betraktar som sant.

Ett test du kan göra i dag

Ta ett objekt som flera team bevakar — en order, ett jobb, en sändning — och be varje team visa dig var de slår upp det. Räkna skärmarna. Välj sedan ett fält, som färdig kvantitet, och fråga var och en av dem vad det säger just nu.

Om svaren skiljer sig åt har du hittat raden som datalagret är utformat för att hålla en gång. Om de stämmer överens bara för att någon stämmer av dem varje eftermiddag har du hittat personen som för hand gör det en sammanslagningsmotor gör i formatet.