--- title: "Apache Hudi: faza współistnienia, zmiany ze starego ERP do zapisu" url: "https://hurukan.com/pl/blog/apache-hudi-faza-wspolistnienia-zmiany-ze-starego-erp-do-zapisu" description: "Moduły przejmują procesy po kolei; do tego czasu stary ERP nadal zapisuje. Jak przechwytywanie zmian i Apache Hudi utrzymują zapis aktualnym w tym czasie." --- # Apache Hudi: faza współistnienia, zmiany ze starego ERP do zapisu 9 października 2026·4 min czytania·Redakcja Korytarz serwerowni widziany wzdłuż, dwie szafy starszego szarego sprzętu po lewej i jedna nowa biała szafa po prawej połączone jedną wiązką kabli, technik od tyłu sprawdza podręczny ekran z abstrakcyjnymi niebiesko-szarymi wierszami, cienkie niebieskie lampki statusu Żadna firma nie przełącza systemu operacyjnego w poniedziałek rano. Księga zamówień, stan magazynu, otwarte faktury i dwadzieścia lat historii klientów żyją w ERP, który będzie działał dalej, podczas gdy pierwsze moduły przejmują jeden proces po drugim. Przez miesiące, czasem lata, dwa systemy zapisują tę samą firmę, a zapis musi pozostać wierny obu. To faza współistnienia i ma konkretny kształt techniczny. Stary system wciąż zmienia wiersze; zapis potrzebuje tych zmian w minutach, a nie w nocnym eksporcie; i potrzebuje ich jako zmian, żeby korekta jednej faktury nie oznaczała przeładowania roku. Apache Hudi zbudowano wokół tego kształtu. Warstwa Data w Hurukanie jest w budowie; ten tekst jest o tym, jak projektujemy ścieżkę współistnienia i gdzie mieści się w niej Hudi. Dlaczego zapis jest oddzielony od stanu bieżącego, wyjaśnia tekst o [stanie bieżącym i zapisie](https://hurukan.com/pl/blog/stan-biezacy-i-zapis-dwie-pamieci-systemu-operacyjnego-firmy). ## Czego wymaga współistnienie **Zmian, nie migawek.** ERP zmienia tysiące wierszy na godzinę: status, płatność, poprawiony adres. Nocna kopia każdej tabeli jest zarazem za wolna i za droga. Zapis potrzebuje wiersza, który się zmienił, z tym, jaki był przed i po. **Aktualizacji po kluczu.** Ten sam klient, zamówienie czy faktura przychodzą wiele razy z nowymi wartościami. Zapis musi odnaleźć poprzednią wersję tego jednego klucza i ją zastąpić, bez przepisywania partycji, w której leży. **Czytania przyrostowego.** Wszystko niżej — widok klienta w ontologii, agent przygotowujący decyzję kredytową, raport — powinno przetwarzać to, co zmieniło się od ostatniego uruchomienia, a nie całą historię od nowa. **Usuwania po kluczu.** Żądanie usunięcia w czasie współistnienia musi dotrzeć do zapisu równie pewnie, jak dociera do ERP, i być dowodnie kompletne po czyszczeniu. ## Jak przychodzi zmiana Baza ERP i tak zapisuje log własnych zmian na potrzeby własnego odtwarzania. Przechwytywanie zmian czyta ten log i publikuje każdą zmianę jako zdarzenie. W projekcie, który buduje Hurukan, to zdarzenie niesie umowę, którą seria opisuje pod [Apache Avro](https://hurukan.com/pl/blog/apache-avro-umowa-miedzy-modulami), więc odbiorca zna kształt wiersza przed i po. Stamtąd [Hudi Streamer](https://hudi.apache.org/docs/hoodie_streaming_ingestion), narzędzie ingestu projektu, czyta z Kafki albo wprost ze zdarzeń Debezium, w trybie ciągłym, z rejestrem schematów, i zapisuje tabelę (sprawdzono 21.10.2026). W typowym przypadku nie pisze się kodu; konfiguracja jest projektem, a w Hurukanie jest propozycją, którą agent przygotowuje, a człowiek zatwierdza. ## Co Hudi z tym robi Hudi nadaje każdemu rekordowi klucz i trzyma indeks tego, gdzie ten klucz leży, więc aktualizacja dotyka grupy plików z tym kluczem, a nie partycji. [Dokumentacja indeksów](https://hudi.apache.org/docs/indexes) wymienia opcje trzymane w tabeli metadanych: filtry Blooma, indeks rekordów, który może być globalny, indeksy wtórne i indeksy wyrażeń dodane w wydaniu 1.0.0 (sprawdzono 21.10.2026). Dwa typy tabel odpowiadają na dwie potrzeby opisane pod [typami tabel](https://hudi.apache.org/docs/table_types). **Copy-on-Write** przepisuje bazowy plik Parquet przy każdej zmianie; odczyt jest prosty i szybki. **Merge-on-Read** dopisuje zmiany do plików dziennika obok pliku bazowego i scala je przy odczycie; kompaktowanie składa je w tle w nowe pliki bazowe. W czasie współistnienia tabele z ERP są zwykle Merge-on-Read, bo zapisy nigdy nie ustają; tabela raportowa zmieniana raz dziennie może być Copy-on-Write. Każda akcja ląduje na [osi czasu](https://hudi.apache.org/docs/timeline) tabeli — commit, delta commit, kompaktowanie, czyszczenie, wycofanie — ze stanem zażądane, w toku i zakończone, a historia jest archiwizowana w strukturze LSM. Bieżące jest wydanie [1.2.1](https://hudi.apache.org/releases/release-1.2) z września 2026; wcześniejsze 1.1.0 i 1.0.0 przebudowały oś czasu i indeksy (sprawdzono 21.10.2026). Dla zapisu liczą się trzy konsekwencje. Zapytania mogą być **przyrostowe**: daj mi to, co zmieniło się od tej chwili, jako ostatni stan albo jako obrazy przed i po. Kilku pisarzy może dzielić tabelę Merge-on-Read pod **nieblokującą kontrolą współbieżności**, którą [dokumentacja współbieżności](https://hudi.apache.org/docs/concurrency_control) ogranicza do określonych typów indeksu i na razie nie do klastrowania. A **usunięcie po kluczu** jest zwykłym zapisem, ostatecznym po tym, jak czyściciel usunie stare wersje plików. ## Co decydują ludzie **Klucz.** Która kombinacja pól identyfikuje wiersz w starym systemie i czy pozostaje stabilna przez całą migrację. Zły klucz dubluje klientów na całe życie zapisu. **Typ tabeli i budżet kompaktowania.** Merge-on-Read trzyma niskie opóźnienie zapisu i przenosi koszt na kompaktowanie, które działa ciągle i jest ciągle opłacane. Agent zaproponuje harmonogram; człowiek podpisuje koszt. **Retencja i czyściciel.** Ile wersji plików trzymać to ta sama decyzja, co to, jak daleko sięga „co widział agent”, i to, kiedy usunięta osoba naprawdę znika. Ustawia się ją per tabela i zapisuje. **Gdzie są silniki.** Hudi czytają natywnie Spark, Flink, Trino i Presto. Firma, której pozostałe narzędzia oczekują Iceberga albo Delta, dotrze do tabeli Hudi przez tłumaczenie metadanych, z ograniczeniami, które seria opisuje dla [XTable i UniForm](https://hurukan.com/pl/blog/jeden-zapis-czytelny-dla-narzedzi-ktore-juz-macie-xtable-i-uniform). To powód, żeby trzymać Hudi tam, gdzie zarabia na swoje miejsce — na ścieżce współistnienia — a nie wszędzie. Warstwa [Data](https://hurukan.com/pl/system/dane) opisuje konektory i jeden model danych, który ta ścieżka zasila. Gdy ostatni proces przejdzie do modułu, ERP przestaje zapisywać, strumień zmian się kończy, a zapis działa dalej, nie zauważając tego. ## Test, który możesz zrobić dziś Wybierz jedną tabelę w Twoim ERP, która zmienia się cały dzień: linie zamówień albo płatności. Zapytaj, jak dziś trafia do raportowania, i spisz trzy liczby: jak stara jest kopia, gdy ktoś ją czyta, jaka część tabeli jest przeładowywana, żeby nanieść jeden dzień zmian, i ile trwa, zanim żądanie usunięcia będzie tam dowodnie kompletne. Te trzy liczby to to, co ścieżka współistnienia musi pokonać. - Apache Hudi - przechwytywanie zmian - współistnienie - migracja ERP - przetwarzanie przyrostowe ## Czytaj dalej - [Jedna tożsamość dla ludzi i agentów: kto co może](https://hurukan.com/pl/blog/jedna-tozsamosc-dla-ludzi-i-agentow) - [Stan bieżący i zapis: dwie pamięci systemu operacyjnego firmy](https://hurukan.com/pl/blog/stan-biezacy-i-zapis-dwie-pamieci-systemu-operacyjnego-firmy)