Apache Paimon: jedna tabela dla strumienia i raportu

Producent seryjny trzyma stan zlecenia produkcyjnego w trzech miejscach. MES wie, która operacja trwa i ile sztuk przeszło. ERP wie, ile zamówiono, na kiedy i dla kogo. System jakości wie, ile jest braków. Planista otwiera co rano wszystkie trzy i wpisuje prawdziwy stan do arkusza, bo żaden pojedynczy system go nie ma.

Asystent planowania w systemie AI-native nie może pracować z tego arkusza i nie powinien też otwierać trzech systemów. Potrzebuje jednej tabeli, w której stan zlecenia jest już złożony i pozostaje aktualny w miarę ruchu hali. Spośród otwartych formatów tabel Apache Paimon jest tym, który zaprojektowano z myślą o takiej tabeli. Gdzie leży w dwóch pamięciach systemu przedsiębiorstwa, jest tematem tego profilu; jak agent czyta taką tabelę, opisujemy osobno w tekście o stanie, na którym działają agenci.

Dlaczego tabela aktualizowana bez przerwy jest trudna

Formaty tabel zbudowane pod ładowanie wsadowe przechowują dane w niezmiennych plikach Parquet i opisują je metadanymi. Aktualizacja jednego wiersza oznacza zapis nowego pliku i oznaczenie starego albo zapisanie usunięcia wobec niego. Przy kilku aktualizacjach na minutę to działa. Przy strumieniu zdarzeń z MES każda mikropaczka produkuje nowe pliki, metadane rosną, a zadanie kompaktowania musi pracować bez przerwy tylko po to, żeby odczyt nie otwierał tysięcy plików. Format nie był zły; był zbudowany pod inny wzorzec zapisu.

Paimon zaczyna od wzorca zapisu. Jego tabele z kluczem głównym są zorganizowane jako drzewo LSM (log-structured merge-tree) na kubełek: przychodzące wiersze lądują posortowane w małym górnym poziomie, a scalanie spycha poziomy w dół, utrzymując jedną bieżącą wersję na klucz. Scalanie jest częścią modelu składowania, a nie zadaniem utrzymaniowym doklejonym z boku. Tabele bez klucza głównego to tabele dopisywane; przyjmują tylko wstawienia i obsługują wsadowe DELETE, UPDATE i MERGE INTO.

Bieżące wydanie to Paimon 2.0.0 z 7 sierpnia 2026, wydany razem z PyPaimon 2.0.0; 1.4.2 ukazał się w czerwcu, a 1.3.0 w październiku 2025 (sprawdzono 21 października 2026). Opisana niżej architektura pochodzi z dokumentacji projektu i nie zmieniła się między tymi wersjami.

Elementy, które mają znaczenie dla architekta

Kubełki i partycje. Tabela z kluczem głównym dzieli się na partycje, a w ich obrębie na kubełki według skrótu klucza. Kubełek jest jednostką drzewa LSM i równoległego zapisu. Liczba kubełków to decyzja wymiarowania, nie domyślna wartość do zaakceptowania.

Silniki scalania. To ta cecha, która przenosi logikę biznesową z zadania strumieniowego do tabeli. Silnik scalania mówi, co się dzieje, gdy dla tego samego klucza przychodzi drugi wiersz. deduplicate, domyślny, zostawia najnowszy. partial-update wypełnia tylko te kolumny, które niesie nowy wiersz, więc trzy systemy mogą pisać każdy swoje kolumny jednego wiersza zlecenia; grupy sekwencji rozstrzygają, które źródło wygrywa w której grupie kolumn. aggregation stosuje funkcję na kolumnę — sumę, maksimum, ostatnią wartość. first-row zostawia pierwszy i pomija resztę. U producenta tabela stanu zlecenia jest tabelą partial-update: ERP pisze ilość i termin, MES pisze operację i sztuki wykonane, system jakości pisze braki, a nikt nie pisze złączenia.

Producenci dziennika zmian. Konsument niżej w łańcuchu musi wiedzieć, co się zmieniło, a nie tylko, co jest aktualne. Ustawienie producenta dziennika zmian rozstrzyga, jak tabela to emituje: none, input, gdy strumień już niesie kompletne rekordy zmian, lookup, gdy tabela ma sama wyliczyć obrazy przed i po w chwili zapisu, full-compaction, gdy wystarczy emitować je przy każdym pełnym scaleniu. Wybór wymienia opóźnienie zapisu na koszt; należy do specyfikacji.

Migawki i znaczniki. Każdy commit tworzy migawkę; migawki wygasają według harmonogramu. Znacznik przypina pliki migawki, żeby stan — koniec zmiany, koniec miesiąca, chwila podjęcia decyzji planistycznej — dało się odczytać ponownie, gdy sąsiednich migawek już nie ma.

Silniki. Macierz silników wymienia Flink i Spark do odczytu i zapisu, Hive, Trino i Presto do zapytań oraz StarRocks i Doris do odczytu. Flink jest silnikiem, z którym format dorastał, a zapis strumieniowy w praktyce oznacza Flinka.

Infografika

Wnętrze tabeli Paimon z kluczem głównym

1. 01Przychodzące zdarzeniaWiersze z ERP, MES i systemu jakości, każdy z kluczem zlecenia.
2. 02Poziom 0Nowe wersje lądują posortowane po kluczu w małych plikach; ostatni zapis jest widoczny od razu.
3. 03Poziomy scalaniaScalanie w tle stosuje silnik scalania i utrzymuje jeden bieżący wiersz na klucz na poziom.
4. 04Migawka i znacznikKażdy commit to migawka; znacznik przypina stan w wybranej chwili.
5. 05CzytelnicyFlink i Spark czytają i piszą; Trino, Hive, Presto, StarRocks i Doris czytają.

Tabela stanu zlecenia u producenta

Weźmy producenta seryjnego z ERP, MES i systemem jakości, który buduje jedną tabelę stanu zleceń produkcyjnych. To ilustracja, nie przypadek klienta.

Przedtem: planista składa stan ręcznie każdego ranka. Operator widzi tylko MES. Dział sprzedaży pyta planistę. Asystent planowania, gdyby istniał, nie miałby nic spójnego do czytania.

Z Paimonem: zdarzenia zmian z trzech systemów trafiają do Kafki z zarejestrowanymi schematami; Flink zapisuje je do tabeli partial-update z kluczem zlecenia produkcyjnego, z grupą sekwencji na system źródłowy, żeby MES nie mógł nadpisać terminu z ERP. Planista, ekran operatora i agent planowania czytają tę samą tabelę. Na koniec każdej zmiany powstaje znacznik. Agent proponuje zmianę kolejności, gdy odsetek braków przekroczy próg; planista decyduje, a decyzja jest wprowadzana w ERP, skąd wraca do tabeli jak każda inna zmiana.

Co mierzyć: opóźnienie od zdarzenia MES do jego widoczności w tabeli; liczbę miejsc, w których trzymany jest „stan zlecenia”, która powinna spaść do jednego; miesięczny koszt Flinka i scalania; oraz czas odpowiedzi na pytanie „co planista widział o 14:00” ze znacznika.

Dokąd idzie koszt i gdzie leżą decyzje

Tabela Paimon nigdy nie kończy zapisu. Scalanie pracuje, dopóki przychodzą zdarzenia, a jego obliczenia to stały koszt, którego tabela wsadowa nie ma. Producent dziennika lookup dokłada pracy przy zapisie; producent full-compaction dokłada opóźnienia. Za mała liczba kubełków ogranicza równoległość zapisu; za duża mnoży małe pliki. To są liczby, które rozstrzygają, czy jedna tabela kosztuje mniej niż trzy, które zastępuje.

W cyklu wytwarzania systemów AI (AI SDLC) konfiguracja silnika scalania, grupy sekwencji, producent dziennika zmian i liczba kubełków są częścią specyfikacji tabeli, spisanej przed zadaniem strumieniowym, z osobą, która zatwierdziła każdą z nich. Testem odbiorczym jest odtworzenie: dzień zdarzeń z trzech systemów puszczony do świeżej tabeli i wynik porównany wiersz po wierszu ze stanem, który planista miał w arkuszu. Agenci kodujący dobrze szkicują zadanie Flinka, proponują konfigurację scalania ze schematów zdarzeń i generują uprząż do odtwarzania. Nie powinni decydować, które źródło wygrywa kolumnę, jak długo żyją migawki ani czy decyzja potrzebuje sekund; to podpisy inżyniera i właściciela procesu.

Jak wygląda dobry wynik

Jedna tabela stanu zleceń, którą czytają trzy role i jeden agent, z opublikowanym opóźnieniem, znacznikiem na zmianę i rachunkiem za scalanie oszacowanym, zanim przyszło pierwsze zdarzenie. Mniej miejsc, w których trzymany jest stan, nie więcej. I test odtworzeniowy uruchamiany przed każdą zmianą reguł scalania.

Nasza część

W inżynierii danych AI specyfikujemy i budujemy takie tabele: kontrakty zdarzeń, silniki scalania i grupy sekwencji, ustawienia dziennika zmian, znaczniki i testy odtworzeniowe — z kosztem scalania oszacowanym z góry i właścicielem każdego ustawienia, które może zmienić stan. Nie odsprzedajemy platform. Więcej o predictes na stronie głównej.