Delta Lake, Iceberg czy Hudi: wybierajcie po katalogu, nie po liście funkcji

Przegląd architektury w grupie z czterema zakładami i dwoma ERP dochodzi do slajdu „format tabeli”. Trzy kolumny, czterdzieści wierszy znaczników: ACID, podróż w czasie, ewolucja schematu, MERGE, strumienie. Prawie każda komórka jest zielona w każdej kolumnie. Spotkanie spędza godzinę nad trzema komórkami, które nie są, i nikt nie zadaje dwóch pytań, które naprawdę zdecydują o następnych pięciu latach: który katalog będzie trzymał wskaźnik do tych tabel i które silniki muszą do nich pisać.

Delta Lake, Apache Iceberg i Apache Hudi zbiegły się w tych samych obietnicach. Różnią się tym, jak trzymają plan tabeli, a ta różnica wychodzi w katalogu, w silnikach i w koszcie utrzymania długo po tym, jak lista funkcji pójdzie w zapomnienie. To druga pamięć systemu AI-native opisana w poradniku o bazie operacyjnej i lakehouse; tu schodzimy piętro niżej, do tego, jak każdy format utrzymuje tę pamięć w porządku.

Trzy sposoby trzymania planu tabeli

Wszystkie trzy zostawiają dane w niezmiennych plikach Parquet i opisują, które pliki składają się na tabelę w danej chwili. Cała różnica tkwi w tym, gdzie trzymają ten opis.

Delta Lake prowadzi log. Katalog _delta_log/ zawiera ponumerowane commity w JSON, każdy jako lista akcji: add, remove, metaData, protocol, commitInfo, cdc. Okresowe punkty kontrolne w Parquet podsumowują stan, żeby czytelnik nie odtwarzał całej historii. Pisarz zatwierdza, zapisując następny numerowany plik; dwaj pisarze walczący o ten sam numer rozstrzygają konflikt optymistycznie. Aktualne wydanie to Delta Lake 4.4.0, sprawdzono 21.10.2026, a protokół zamyka nowsze zachowania za funkcjami tabeli, które podnoszą minimalną wersję czytelnika i pisarza.

Iceberg prowadzi drzewo. Plik metadanych tabeli wskazuje bieżącą migawkę; migawka wskazuje listę manifestów; każdy manifest, sam zapisany w Avro, wylicza pliki danych i pliki usunięć wraz ze statystykami. Niczego w drzewie nigdy się nie edytuje. Commit zapisuje nowy plik metadanych i prosi katalog o atomową podmianę wskaźnika. Ta jedna podmiana jest jedyną zmienną operacją w całym projekcie, dlatego wiele silników może bezpiecznie pisać do tej samej tabeli i dlatego katalog znaczy tak dużo. Specyfikacja jest w wersji 3 — wektory usunięć, pochodzenie wierszy, typ variant, wartości domyślne kolumn — a wersja 4 jest w pracach i nieprzyjęta. Wydanie biblioteki to 1.12.0, sprawdzono 21.10.2026.

Hudi prowadzi oś czasu. Każda akcja — commit, delta commit, kompaktowanie, klastrowanie, czyszczenie, wycofanie — jest chwilą na osi czasu ze stanem zażądanym, w toku i zakończonym; w linii 1.x zarchiwizowana historia leży w strukturze LSM. Obok jest tabela metadanych z indeksami: filtry Blooma, indeks na poziomie rekordu, indeksy wtórne i wyrażeń. Hudi oferuje dwa typy tabel: Copy-on-Write przepisuje pliki bazowe przy zmianie, Merge-on-Read dopisuje pliki dziennika i kompaktuje później. Wydanie 1.2.1, sprawdzono 21.10.2026, a nieblokująca kontrola współbieżności pozwala kilku pisarzom aktualizować tabelę Merge-on-Read z blokadami tylko na metadanych osi czasu.

Log, drzewo i oś czasu nie są lepsze ani gorsze. Log jest najprostszy w rozumowaniu i na nim budują Databricks i Microsoft Fabric. Drzewo oddziela tabelę od pojedynczego silnika i czyni katalog punktem kontroli. Oś czasu jest zbudowana dla tabel, których wiersze ciągle się zmieniają.

Tabela decyzji

Wybierajcie według środowisku, który macie, nie według formatu, który się wam podoba.

Wasza sytuacja	Co decyduje	Zwykła odpowiedź
Platformą jest Databricks albo Microsoft Fabric; piszą Spark i silniki Fabric	OneLake i Unity Catalog przechowują i zarządzają Delta natywnie; wszystko inne czyta Delta przez UniForm albo XTable	Delta Lake
Kilka silników (Trino, Spark, DuckDB), Snowflake albo BigQuery w środowisku, więcej niż jedna chmura, plan wyjścia wpisany w architekturę	Specyfikacja katalogu REST, Apache Polaris, S3 Tables i BigLake mówią Icebergiem; pisarze różnych vendorów mogą dzielić tabelę	Apache Iceberg
Wiersze zmieniają się bez przerwy — CDC z ERP, deduplikacja po kluczu, aktualizacje w minutach — a potoki prowadzi Spark albo Flink	Indeks na poziomie rekordu, Merge-on-Read, zapytania przyrostowe i Hudi Streamer są do tego zbudowane	Apache Hudi
Jeden silnik hurtowni, nocne ładowania, nikt poza nim nie potrzebuje plików	Format tabeli jest szczegółem implementacyjnym platformy	To, co platforma daje domyślnie, zapisane jako decyzja

Wiersze się nie wykluczają. Środowisko Fabric ze spółką zależną na Snowflake to decyzja Delta z czytelnikiem Iceberg, do czego służą XTable i UniForm. Przejęcie Tabular przez Databricks, ogłoszone 4 czerwca 2024 z deklarowanym celem zgodności Delta i Iceberg przez UniForm, jest najwyraźniejszym publicznym znakiem, że dwa największe formaty raczej się zbliżają, niż konkurują. Nie jest powodem, żeby przestać decydować.

Infografika

Gdzie format tabeli jest prawdziwą decyzją

Ciągłe aktualizacjeGłównie dopisywanie

Domyślne platformyWeźcie to, co daje platforma, zapiszcie wybór, zachowajcie ścieżkę wyjścia.

Decyduje katalogIceberg z katalogiem pod waszą kontrolą; Delta z UniForm, jeśli środowisko jest Microsoft albo Databricks.

Decyduje ścieżka aktualizacjiHudi albo Delta z wektorami usunięć; pytanie brzmi, kto prowadzi kompaktowanie.

Decyduje jedno i drugieWiele silników i duża zmienność: katalog, model współbieżności i zadania serwisowe potrzebują właściciela.

Środowisko jednego vendoraWiele silników i chmur

Co agent kodujący robi dobrze z każdym formatem, a gdzie musi się zatrzymać

Większość kodu potoków w tych projektach pisze dziś na brudno agent kodujący. To dobre dla części mechanicznych i testowalnych, a niebezpieczne dla części, które są decyzjami przebranymi za konfigurację.

Agenci dobrze szkicują: MERGE ze strumienia CDC do tabeli Delta albo Iceberg z właściwymi kluczami; harmonogram OPTIMIZE albo kompaktowania z opisu wzorca zapisu; konfigurację katalogu dla punktu REST; konfigurację Hudi Streamer z tematu Kafki i rejestru schematów; testy kontraktowe, które czytają tabelę przez dwa silniki i porównują liczby wierszy, agregaty i znacznik czasu ostatniej migawki. Mając dokumentację formatu i próbkę prawdziwych plików, ta praca idzie szybciej i zwykle jest pełniejsza niż pierwsze podejście człowieka.

Agenci nie mogą decydować o: retencji i oknach VACUUM, bo to różnica między audytem z podróżą w czasie, który działa, a takim, który nie działa, i między usunięciem RODO, które jest ostateczne, a takim, które nie jest; o samych żądaniach usunięcia; o podniesieniu protokołu albo wersji formatu, bo włączenie funkcji tabeli w Delta albo przejście na Iceberg v3 może odciąć starszego czytelnika w innym zespole; o wyborze katalogu, bo to wybór tego, kto nadaje dostęp; o typie tabeli w Hudi, bo Copy-on-Write i Merge-on-Read przesuwają koszt między pisarzami, czytelnikami i zadaniem kompaktowania.

Zasada robocza w naszych zleceniach: agent może zaproponować każdą z tych rzeczy w pull requeście z uzasadnieniem i wynikami testów, a zatwierdza imiennie wskazany inżynier. Zatwierdzenie jest zapisane obok tabeli, nie na czacie.

Testy kontraktowe przed przyjęciem formatu

Zanim format zostanie przyjęty dla środowisku, jedna tabela jest budowana od początku do końca i czytana z każdego silnika, który będzie jej potrzebował, z testami, które chodzą w potoku, a nie raz na laptopie. Testy są proste i agent może je napisać: ta sama liczba i te same sumy przez silnik A i silnik B; zmiana schematu (dodanie kolumny, rozszerzenie typu) wykonana z jednego silnika i odczytana z drugiego; usunięcie wykonane z jednego silnika i niewidoczne z drugiego po tej samej migawce; odczyt z podróżą w czasie do migawki sprzed usunięcia. Tam, gdzie test pada, sprawdza się matrycę formatów w dokumentacji vendora dla używanej wersji — „obsługuje Iceberg” często znaczy wersję 2 bez wektorów usunięć, a to fakt do zapisania, nie niespodzianka do odkrycia na produkcji.

Jak wygląda dobry wynik

Dokument architektury nazywa format, katalog, silniki, którym wolno pisać, i silniki, którym wolno czytać, z wersjami. Zadania serwisowe — kompaktowanie, klastrowanie, wygaszanie migawek, przepisywanie manifestów — mają właściciela, harmonogram i pozycję kosztową. Jest jedna tabela, którą każdy silnik w środowisku czytał i zapisywał w teście, i ten test nadal chodzi. Nikogo nie prosi się już o wybór formatu z listy znaczników, bo decyzja jest zapisana z powodami, które będą obowiązywać, gdy lista się zmieni.

Nasza część

W inżynierii danych AI budujemy pierwszą tabelę od początku do końca — format, katalog, pisarzy, czytelników, zadania serwisowe i testy kontraktowe — żeby decyzja o formacie zapadła na waszym środowisku, a nie na slajdzie. Potoki szkicujemy z agentami kodującymi i odbieramy testami; decyzje zostają u waszego architekta. Nie odsprzedajemy platform. Więcej o predictes na stronie głównej.