Apache Hudi: faza współistnienia, zmiany ze starego ERP do zapisu

Ż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.

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, więc odbiorca zna kształt wiersza przed i po.

Stamtąd Hudi Streamer, 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 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. 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 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 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 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. To powód, żeby trzymać Hudi tam, gdzie zarabia na swoje miejsce — na ścieżce współistnienia — a nie wszędzie.

Warstwa Data 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ć.