--- title: "Ślad audytu to tabela: Delta Lake, Iceberg czy Hudi" url: "https://hurukan.com/pl/blog/slad-audytu-to-tabela-delta-lake-iceberg-czy-hudi" description: "Kto co zmienił i co widział agent, gdy składał propozycję? Delta Lake, Iceberg i Hudi odpowiadają inaczej. Wybieraj według katalogu i infrastruktury." --- # Ślad audytu to tabela: Delta Lake, Iceberg czy Hudi 26 września 2026·4 min czytania·Redakcja Audytor widziany od tyłu przy długim stole w przeszklonej sali, trzy oprawione księgi otwarte obok siebie, laptop z abstrakcyjną niebiesko-szarą listą wersji, cienki pas niebieskiego światła wzdłuż krawędzi stołu Audytor zadaje proste pytanie o płatność zatwierdzoną w marcu: co widziała na ekranie osoba, która ją zatwierdziła, i co przeczytał agent, który ją przygotował, zanim złożył propozycję? W większości firm odpowiedź jest rekonstrukcją. Ktoś wyciąga kopię zapasową, ktoś inny przeszukuje skrzynkę, a wynikiem jest wykształcone przypuszczenie o stanie, którego już nie ma. W Hurukanie każda propozycja agenta i każda decyzja człowieka jest zdarzeniem w zapisie firmy, a zapis jest zaprojektowany tak, żeby to pytanie miało zwykłą odpowiedź: wersję tabel z tamtej chwili. Ta własność nie bierze się z plików. Bierze się z formatu tabeli nad nimi. Ten tekst jest o tym, co trzy otwarte formaty tabel robią z tym pytaniem i jak między nimi wybierać. Warstwa Data jest w budowie; poniżej opisujemy, jak ją projektujemy. Uzasadnienie, po co w ogóle zapis, jest w tekście o [stanie bieżącym i zapisie](https://hurukan.com/pl/blog/stan-biezacy-i-zapis-dwie-pamieci-systemu-operacyjnego-firmy). ## Czego ślad audytu wymaga od tabeli Plików w zapisie nigdy się nie edytuje. Zmiana dopisuje nowe pliki i nową wersję metadanych tabeli, która mówi, które pliki od teraz się liczą. Dla audytu wynikają z tego trzy rzeczy. **Każda wersja ma adres.** „Tabela na stan z 12 marca, godzina 14:02” musi być poprawnym zapytaniem, a nie zadaniem odtworzenia kopii. W formatach niżej to podróż w czasie i to ona stoi za pytaniem „co widział agent”. **Każda wersja ma autora.** Metadane zmiany muszą nieść, kto albo co ją wykonało: człowiek, agent działający na zatwierdzeniu człowieka albo zadanie systemowe, takie jak kompaktowanie. Hurukan zapisuje aktora we własnym rejestrze decyzji, ale wersja tabeli jest dowodem, że rejestr zgadza się z danymi. **Stare wersje wygasają celowo, nie przypadkiem.** Trzymanie każdej wersji na zawsze kosztuje; usuwanie ich to decyzja o retencji, a przy danych osobowych o usunięciu. Ta decyzja należy do człowieka, a format tabeli ma ją uczynić jawną. ## Trzy sposoby prowadzenia planu Każdy format prowadzi plan tego, które pliki składają się na tabelę. W tym planie mieszka audyt. **Delta Lake** prowadzi log: katalog `_delta_log/` z jednym plikiem JSON na commit, nazwanym dwudziestocyfrowym numerem wersji, z akcjami takimi jak `add`, `remove`, `metaData` i `protocol`, oraz z okresowymi punktami kontrolnymi w Parquet, żeby czytelnik nie odtwarzał całej historii. Definiuje go [protokół](https://github.com/delta-io/delta/blob/master/PROTOCOL.md); bieżące wydanie to [4.4.0](https://github.com/delta-io/delta/releases) (sprawdzono 21.10.2026). Retencja logu domyślnie wynosi 30 dni, a `VACUUM` 7 dni, co znaczy, że podróż w czasie sięga tylko tak daleko, jak pozwalają te dwa ustawienia. **Apache Iceberg** prowadzi drzewo: plik metadanych tabeli wskazuje migawkę, migawka listę manifestów, manifesty pliki danych i pliki usunięć wraz ze statystykami. Commit to atomowa podmiana wskaźnika na plik metadanych, a podmiana odbywa się w katalogu. [Specyfikacja](https://iceberg.apache.org/spec/) jest w wersji 3, z wektorami usunięć, pochodzeniem wierszy i typem VARIANT; bieżące wydanie to [1.12.0](https://github.com/apache/iceberg/releases) (sprawdzono 21.10.2026). **Apache Hudi** prowadzi oś czasu: każda akcja na tabeli — commit, kompaktowanie, czyszczenie, wycofanie, przywrócenie — jest chwilą ze stanem, a historia osi czasu jest archiwizowana w strukturze LSM. Rekordy mają klucze i indeks, więc zmiana jednego klienta dotyka jednej grupy plików, a nie partycji. Tabele są typu Copy-on-Write albo Merge-on-Read, a wydanie [1.2.1](https://hudi.apache.org/releases/release-1.2) dodało wersję tabeli 9 (sprawdzono 21.10.2026). Stany opisuje dokumentacja [osi czasu](https://hudi.apache.org/docs/timeline). Wszystkie trzy odpowiadają audytorowi. Różnica polega na tym, gdzie odpowiedź jest przechowywana i kto jeszcze może ją przeczytać. ## Wybieraj według katalogu, nie listy funkcji Listy funkcji się zbiegły: transakcje, podróż w czasie, ewolucja schematu, usunięcia na poziomie wiersza i zapisy strumieniowe są w każdym z nich. Nie zbiegło się miejsce, w którym ogłasza się bieżącą wersję tabeli, a to w tym miejscu rozstrzyga się suwerenność. **Dla Delta Lake jest nim sam katalog logu**, więc każdy silnik, który czyta magazyn, znajdzie bieżącą wersję. W praktyce katalogiem wokół niego jest Unity Catalog albo, w Microsoft Fabric, OneLake, który według [dokumentacji Microsoft](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview) przechowuje tabele jako Delta Parquet. **Dla Iceberga jest nim wskaźnik w katalogu**, a katalog mówi otwartą [specyfikacją REST](https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml). Implementuje ją Apache Polaris, projekt najwyższego poziomu od lutego 2026 z wydaniem 1.8.0; przez nią tabele Iceberg czytają i zapisują Snowflake, AWS S3 Tables, katalog lakehouse Google i Databricks (sprawdzono 21.10.2026). **Dla Hudi jest nim oś czasu w magazynie**, czytana natywnie przez Spark, Flink, Trino i Presto; inne platformy docierają do tabeli Hudi zwykle przez tłumaczenie metadanych. Pytanie dla firmy nie brzmi więc „który format ma najlepszy audyt”. Brzmi: na czyjej infrastrukturze działa katalog, które silniki muszą czytać zapis i czy zapis można zabrać ze sobą, gdy zmieni się vendor. Odpowiedź Hurukana jest taka, że katalog i pliki działają na infrastrukturze, którą wybiera firma, jak opisano w [bezpieczeństwie i suwerenności](https://hurukan.com/pl/system/bezpieczenstwo-i-suwerennosc), a format wynika z silników, które firma już ma, a nie odwrotnie. ## Co zostaje przy ludziach Agenci są dobrzy w mechanicznej części warstwy Data: napiszą harmonogram kompaktowania, zadanie wygaszające stare migawki, zaproponują zmianę partycji, gdy zapytania zwolnią. Każda z tych rzeczy jest propozycją w skrzynce zatwierdzeń, z dołączonym uzasadnieniem, i każda zostaje zapisana po zatwierdzeniu. Trzech decyzji nigdy się nie deleguje. **Retencja i usuwanie.** To, jak daleko sięga podróż w czasie, jest tym samym ustawieniem, co to, jak długo dane osobowe przetrwają żądanie usunięcia. Człowiek ustawia to per tabela i podpisuje. **Podniesienie protokołu.** Włączenie nowszej funkcji tabeli może odciąć starszy silnik, który nadal czyta zapis. Zysk jest realny; tak samo czytelnik, który gaśnie. Człowiek to waży. **Sam format.** Zmiana później jest możliwa, jak wyjaśnia następny tekst tej serii o [XTable i UniForm](https://hurukan.com/pl/blog/jeden-zapis-czytelny-dla-narzedzi-ktore-juz-macie-xtable-i-uniform), ale to projekt, a nie ustawienie. ## Test, który możesz zrobić dziś Weź jedną decyzję z ostatniego kwartału, o którą audytor mógłby realnie zapytać: podniesiony limit kredytowy, zatwierdzony dostawca, przyznany rabat. Spisz, wyłącznie z Twoich systemów, co widziała osoba decydująca w tamtej chwili. Policz systemy, które musiałeś otworzyć, i miejsca, w których musiałeś zgadywać. Ta liczba to odległość między Twoim obecnym zapisem a takim, którego ślad audytu jest tabelą. - formaty tabel - Delta Lake - Apache Iceberg - Apache Hudi - ślad audytu ## 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)