--- title: "Apache Paimon: jedna tabela dla strumienia i raportu" url: "https://predictes.com/pl/blog/apache-paimon-jedna-tabela-dla-strumienia-i-raportu" description: "Jak Apache Paimon utrzymuje czytelną tabelę aktualizowaną bez przerwy: klucz główny na drzewie LSM, silniki scalania, dziennik zmian, znaczniki, koszt scalania." --- # Apache Paimon: jedna tabela dla strumienia i raportu 18 października 2026·4 min czytania·predictes 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](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native), jest tematem tego profilu; jak agent czyta taką tabelę, opisujemy osobno w tekście o [stanie, na którym działają agenci](https://predictes.com/pl/blog/stan-na-ktorym-dzialaja-agenci-paimon-miedzy-baza-a-raportem). ## 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](https://paimon.apache.org/docs/master/concepts/table-types/) 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](https://paimon.apache.org/docs/master/project/download/), 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](https://paimon.apache.org/docs/master/primary-key-table/merge-engine/overview/) 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](https://paimon.apache.org/docs/master/primary-key-table/changelog-producer/) 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](https://paimon.apache.org/docs/master/maintenance/manage-tags/) 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](https://paimon.apache.org/docs/master/engines/overview/) 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. 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ą. Czerwony pas to miejsce, w którym pracuje silnik scalania — i do którego idzie koszt obliczeń tabeli aktualizowanej bez przerwy. ## 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](https://predictes.com/pl/services/ai-data-engineering) 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](https://predictes.com/pl). - Apache Paimon - strumieniowy lakehouse - Apache Flink - formaty tabel ## Czytaj dalej - [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem) - [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)