Apache Paimon: jedna tabela stanu dla operatora, planisty i agenta

Zlecenie montażowe zmienia stan jedenaście razy między zwolnieniem a wysyłką: zaplanowane, zwolnione, rozpoczęte na pierwszym stanowisku, wstrzymane z powodu brakującej części, wznowione, skontrolowane, jedna sztuka odrzucona, poprawione, spakowane, potwierdzone, wysłane. Operator na stanowisku widzi swój krok na terminalu w module Operacje i jakość. Planista widzi zlecenie na tablicy. Agent operacyjny, zapytany, czy plan tygodnia nadal się trzyma, widzi raport. Trzy widoki i w większości firm trzy tabele, odświeżane według trzech harmonogramów, tak że przez godzinę każdego popołudnia operator, planista i agent wierzą w co innego o tym samym zleceniu.

Warstwa Data Hurukana jest projektowana tak, żeby dla tego zlecenia istniała jedna tabela stanu i żeby wszyscy czytali właśnie ją. Tekst główny wyjaśnia, dlaczego stan bieżący jest osobną pamięcią obok zapisu. Ten tekst dotyczy formatu, w którym ta tabela jest zbudowana, Apache Paimon, i tego, ile ten wybór kosztuje. Warstwa jest w budowie; poniżej opisujemy, jak jest projektowana.

Tabela, którą się aktualizuje, a nie dopisuje

Większość formatów tabel w lakehouse zakłada, że dane przychodzą i zostają. Nowe wiersze stają się nowymi plikami; zmiana wiersza oznacza przepisanie pliku albo oznaczenie go jako usunięty. To właściwy projekt dla zapisu, w którym nic nigdy nie jest zmieniane. To zły projekt dla stanu zlecenia, które zmienia się jedenaście razy, zanim zostanie zamknięte.

Apache Paimon ma inny kształt. Jego tabele z kluczem głównym trzymają wiersze posortowane po kluczu wewnątrz kubełków, w drzewie LSM (log-structured merge tree): nowe wersje trafiają na górny poziom, a scalanie w tle spycha je do posortowanych plików, więc tabela pozostaje zwarta niezależnie od tego, jak często te same klucze są nadpisywane (typy tabel Paimon, sprawdzono 21.10.2026). Czytelnik widzi ostatnią wersję każdego klucza bez przeglądania historii. Tabele bez klucza głównego to tabele dopisywane, które pasują do strony zapisu; tutaj liczy się odmiana z kluczem głównym. Bieżące wydanie to 2.0.0 z 7 sierpnia 2026 (katalog wydań).

Silniki scalania to reguły ontologii

Tym, co czyni Paimona czymś więcej niż szybką tabelą upsertów, jest to, że sam format decyduje, jak nowa wersja wiersza łączy się ze starą. Paimon nazywa to silnikiem scalania, a w warstwie Data każdy wybór odpowiada regule, którą ontologia już formułuje o obiekcie.

Deduplicate, domyślny: wygrywa najnowsza wersja. Właściwa reguła dla statusu zlecenia — ostatnie zdarzenie jest prawdą.

Partial update: każdy piszący wypełnia tylko swoje kolumny. Wiersz stanu zlecenia ma planowane daty z planowania, rzeczywisty start i stop z terminala stanowiska, wynik kontroli z jakości, ilość spakowaną z magazynu. Cztery moduły, jeden wiersz, żaden nie nadpisuje pozostałych. Grupy sekwencji pozwalają każdemu zestawowi kolumn nieść własne uporządkowanie, więc spóźniony komunikat ze stanowiska nie cofnie późniejszego z jakości (partial update).

Aggregation: liczby sumują się między zdarzeniami — godziny zaksięgowane na operacji, sztuki wykonane, sztuki odrzucone.

First row: zachowywana jest pierwsza wersja. Przydatne tam, gdzie ontologia mówi, że wartość ustawia się raz, jak moment zwolnienia zlecenia.

W ontologii są to opisane własności obiektu: które pole ustawia się raz, które narasta, które należy do którego modułu. Wyrażenie ich w definicji tabeli oznacza, że reguła obowiązuje każdego piszącego, także potok zbudowany przez agenta, który nie istniał, gdy regułę spisano.

Jedna tabela, trzech czytelników, jeden dziennik zmian

Terminal operatora, tablica planisty i widok agenta to trzej czytelnicy tej samej tabeli, każdy z innym filtrem. Flink zapisuje ją ze strumienia zdarzeń modułów i odczytuje z powrotem w lookup joinach. Czytają ją też Spark, Trino, Hive, StarRocks i Doris (wsparcie silników), więc silnik raportowy i notatnik widzą ten sam wiersz, który pokazuje terminal.

Tabela emituje też własne zmiany. Producent dziennika zmian — input, lookup albo full-compaction, wybierany dla każdej tabeli — zamienia każdą scaloną zmianę w strumień. Agent operacyjny subskrybuje „zlecenie wstrzymane” zamiast przeglądać tablicę, a widok planowania aktualizuje się dlatego, że tabela się zmieniła, nie dlatego, że ktoś nacisnął odśwież.

Na potrzeby audytu Paimon trzyma migawki i pozwala znacznikiem przypiąć jedną na stałe. Gdy agent zaproponował przesunięcie trzech zleceń na przyszły tydzień, znacznik z tej chwili pokazuje tablicę, na którą patrzył. Propozycja, decyzja i migawka leżą obok siebie w zapisie.

Ile to kosztuje

Tabela stanu w Paimonie nie jest darmowa, a warstwa Data mówi o rachunku wprost.

Scalanie nigdy się nie kończy. Drzewo scalania utrzymuje w zwartości praca w tle, która zużywa moc obliczeniową bez przerwy. Im częściej klucze są nadpisywane i im świeższa ma być tabela, tym więcej to kosztuje. To powód, dla którego nie każda tabela w warstwie jest tabelą Paimon: sam zapis, który tylko rośnie, jej nie potrzebuje.

Silnik strumieniowy jest warunkiem. Ciągłe zapisywanie stanu oznacza ciągłą pracę Flinka i kogoś, kto za niego odpowiada. Firmy bez tej kompetencji powinny zacząć od tabel odświeżanych co kilka minut zadaniami wsadowymi i przejść do strumieni tylko tam, gdzie decyzja potrzebuje sekund.

Klucz musi być właściwy. Tabela z kluczem głównym jest tak dobra jak jej klucz. Jeśli ontologia nie mówi jeszcze, co identyfikuje zlecenie między modułami, tabeli nie da się zbudować, a uczciwym pierwszym krokiem jest ontologia, nie format.

Agenci pomagają w rutynowej części: proponują liczbę kubełków i harmonogramy scalania, szkicują potok, który mapuje zdarzenia modułów na wiersz, zauważają, gdy opóźnienie tabeli rośnie. Ludzie decydują o kluczu, regule scalania i o tym, jak długo przechowywane są migawki — bo to są twierdzenia o tym, co firma uważa za prawdę.

Test, który możesz zrobić dziś

Weź jeden obiekt, który obserwuje kilka zespołów — zamówienie, zlecenie, wysyłkę — i poproś każdy zespół, żeby pokazał Ci, gdzie go sprawdza. Policz ekrany. Potem wybierz jedno pole, na przykład ilość wykonaną, i zapytaj każdego z nich, co pokazuje w tej chwili.

Jeśli odpowiedzi się różnią, znalazłeś wiersz, który warstwa Data jest zaprojektowana trzymać raz. Jeśli zgadzają się tylko dlatego, że ktoś uzgadnia je każdego popołudnia, znalazłeś osobę, która robi ręcznie to, co silnik scalania robi w formacie.