Stan, który czytają agenci domenowi: Paimon dla kolejki pracy, magazynu i zatwierdzeń

Agent zakupowy dostaje zadanie: przygotować zamówienie uzupełniające na komponent, którego zaczyna brakować. Żeby zrobić to dobrze, potrzebuje stanu zapasu w trzech magazynach, otwartych zamówień klientów, które część tego zapasu rezerwują, dostaw przychodzących, które są już w drodze, i bieżącego statusu ryzyka dostawcy. Każda z tych rzeczy zmieniła się w ostatniej godzinie. Nocna kopia w hurtowni myli się co do wszystkich czterech. Tabele produkcyjne modułów są poprawne, ale agent czytający je na dużą skalę to najszybszy sposób, żeby spowolnić ludzi, którzy w tych modułach pracują.

To jest luka między dwiema pamięciami systemu operacyjnego firmy: zapisem, który trzyma każde zdarzenie na zawsze, i stanem bieżącym, czyli tym, jak sprawy wyglądają teraz. Tekst główny opisuje obie. Ten dotyczy drugiej i formatu tabel, którego używa do niej warstwa Data. Warstwa Data jest w budowie; poniżej opisujemy, jak jest projektowana.

Co naprawdę czyta agent domenowy

Agenci Hurukana są agentami domenowymi: jeden od zakupów, jeden od obsługi klienta, jeden od kolejki pracy w operacjach i tak dalej. Każdy pracuje na niewielkiej liczbie tabel stanu, które odpowiadają na pytania w czasie teraźniejszym.

Kolejka pracy. Które zlecenia są zwolnione, które zablokowane i dlaczego, która maszyna albo który zespół jest wolny. Zasilana przez moduł operacji, gdy zlecenia zmieniają status.

Zapas i rezerwacje. Ilość dostępna na indeks i lokalizację, minus to, co już zajęły otwarte zamówienia, plus to, co jest w drodze. Zasilana zdarzeniami z modułu Magazyn i logistyka, handlu i zakupów.

Skrzynka zatwierdzeń. Każda propozycja złożona przez agenta, z jej źródłami i ryzykiem, oraz informacja, czy człowiek już zdecydował. Zasilana przez samych agentów i przez ludzi w module Decyzje i zadania.

Żadna z tych tabel nie jest kopią bazy modułu. Każda jest budowana ze zdarzeń, które moduły emitują, a które zapis również przechowuje. Tabela stanu to pochodny, zawsze aktualny widok zapisu; zapis jest dowodem, który za nim stoi.

Dlaczego to jest tabela Paimon

Tabela stanu zmienia się tysiące razy na godzinę po kluczu: ten sam indeks, to samo zlecenie, ta sama propozycja, aktualizowane raz za razem. Formaty tabel zbudowane wokół dopisywania nowych plików radzą sobie z tym źle, bo każda aktualizacja staje się nowym plikiem i tabela tonie w małych plikach. Apache Paimon został zaprojektowany dokładnie do tego przypadku. Jego tabele z kluczem głównym przechowują wiersze w drzewie LSM, posortowane po kluczu w obrębie kubełka, więc strumień aktualizacji tych samych kluczy pozostaje zwarty, a czytelnik zawsze widzi ostatnią wersję każdego wiersza (typy tabel, sprawdzono 21.10.2026).

Dwie funkcje Paimona wykonują pracę, która inaczej byłaby kodem. Silnik scalania decyduje, co się dzieje, gdy dla istniejącego klucza przychodzi nowy wiersz: zastąpić go, zachować pierwszy, zagregować albo uzupełnić tylko te pola, które przyszły. Tabela zapasu używa tej ostatniej opcji: magazyn zapisuje ilość dostępną, handel ilość zarezerwowaną, zakupy ilość w drodze, a tabela trzyma wszystkie trzy w jednym wierszu, choć żaden moduł nie wie o pozostałych. Producent dziennika zmian emituje każdą zmianę tabeli jako osobny strumień, więc agent niżej może zareagować na „zapas spadł poniżej punktu zamawiania” zamiast odpytywać tabelę w kółko.

Bieżące wydanie to Paimon 2.0.0 z 7 sierpnia 2026 (katalog wydań, sprawdzono 21.10.2026). Flink go zapisuje i czyta, a lookup join pozwala zadaniu strumieniowemu wzbogacić zdarzenie o bieżący stan innej tabeli — nowe zamówienie o zapas, który rezerwuje — bez odpytywania czegokolwiek innego. Spark, Trino, Hive, StarRocks i Doris czytają te same tabele (silniki).

Agent czyta stan i pisze tylko propozycję

Granica znaczy więcej niż format. Agent domenowy czyta tabele stanu swobodnie. Nie pisze do modułu i nie pisze też do tabeli stanu. To, co wytwarza, to propozycja: szkic zamówienia uzupełniającego z wierszami, które przeczytał, regułą, którą zastosował, i ryzykiem, które widzi. Propozycja trafia do skrzynki zatwierdzeń. Człowiek decyduje. Moduł wykonuje decyzję, emituje zdarzenie, a tabela stanu zmienia się dlatego, że zdarzenie zostało zapisane — nie dlatego, że zmienił ją agent.

To właśnie utrzymuje obie pamięci w uczciwości. Gdyby agenci pisali stan bezpośrednio, stan zawierałby rzeczy, które nigdy nie wydarzyły się w żadnym module i nigdy nie zostały zapisane. Czytając stan i pisząc propozycje, każda zmiana tego, co firma uważa za prawdę, nadal przechodzi przez człowieka i przez zapis.

Odpowiada to też na pytanie audytu. Paimon trzyma migawki, a znacznik przypina jedną z nich, żeby nie wygasła. Gdy propozycja zostanie zakwestionowana po miesiącach, migawka wykonana w chwili, w której agent czytał tabelę, pokazuje dokładnie ten zapas, tę kolejkę i te otwarte zamówienia, które widział. Rejestr decyzji trzyma rozumowanie; migawka trzyma dowód.

Sekundy, minuty albo dziś w nocy

Nie każdy stan musi być tabelą Paimon zasilaną strumieniem. Skrzynka zatwierdzeń musi być aktualna co do sekundy, bo czeka w niej człowiek. Kolejka pracy musi być aktualna co do minuty, bo czeka maszyna. Zapas pod uzupełnienie to decyzja podejmowana kilka razy dziennie; stan opóźniony o kilka minut w zupełności wystarcza. Status ryzyka dostawcy zmienia się co tydzień.

Sprowadzenie wszystkiego do sekund kosztuje ciągłe scalanie, silnik strumieniowy, który nigdy nie śpi, i zespół utrzymania, który dba o jedno i drugie. Dlatego warstwa Data pyta dla każdej tabeli stanu, która decyzja od niej zależy i jak szybko ta decyzja naprawdę się zmienia — i tylko tabele, które potrzebują sekund, je dostają. „Czas rzeczywisty” nie jest cechą platformy; to budżet wydawany osobno na każdą tabelę.

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

Wybierz jedną decyzję, którą ktoś w Twojej firmie podejmuje kilka razy dziennie: zatwierdzenie zakupu, zwolnienie zlecenia, obietnicę terminu dostawy. Zapisz każdą liczbę, na którą ta osoba patrzy przed decyzją, a obok każdej — skąd pochodzi i kiedy była ostatnio odświeżona.

Jeśli kilka z tych liczb pochodzi z różnych systemów i było odświeżanych o różnych porach, ta osoba już dziś składa je w głowie, ze stanu, który nigdy nie był spójny w jednej chwili. To jest tabela, której agent domenowy potrzebowałby w pierwszej kolejności — i którą trzeba zaprojektować, zanim jakikolwiek agent zostanie poproszony o cokolwiek decydować.