Jedna kopia danych, trzy formaty: co XTable i UniForm zmieniają w planie testów

Centrala prowadzi lakehouse na Delta Lake, pod Databricks i Microsoft Fabric. Spółka przejęta dwa lata temu pracuje na Snowflake i czyta Iceberg. Finanse grupy potrzebują jednej liczby marży, więc nocne zadanie kopiuje tabele sprzedaży z jednej strony na drugą. Osiemnaście miesięcy później są dwie marże, arkusz uzgodnień z nazwanym właścicielem i po jednym asystencie AI z każdej strony, który z przekonaniem podaje własną liczbę.

Kopia nigdy nie była problemem danych. Była problemem metadanych i to właśnie sprawia, że da się go rozwiązać bez przenoszenia jednego bajta.

Dlaczego te same pliki mogą być trzema tabelami

Każdy otwarty format tabeli przechowuje dane tak samo: jako niezmienne pliki Parquet na magazynie obiektowym. Różnią się metadane obok nich. Delta Lake prowadzi log transakcji z commitów JSON, Iceberg drzewo migawki, listy manifestów i manifestów, Hudi oś czasu. Tabelą są metadane; pliki są wspólnym gruntem. Tło jest w tekście Baza operacyjna i lakehouse.

Przetłumaczenie tabeli z jednego formatu na drugi oznacza więc zapisanie drugiego kompletu metadanych wskazującego na te same pliki: tę samą listę plików, ten sam schemat, te same wartości partycji i statystyki, wyrażone w strukturze drugiego formatu. Robią to dwa projekty.

Apache XTable, w inkubacji Apache Software Foundation, czyta metadane formatu źródłowego i zapisuje obok nich metadane jednego lub kilku formatów docelowych. Dokumentacja mówi wprost, że robi to bez kopiowania ani przenoszenia plików danych. Działa jako narzędzie albo zadanie cykliczne, w trybie FULL, który odbudowuje metadane celu ze wszystkich plików, albo INCREMENTAL, który przenosi tylko różnicę. Aktualne wydanie to 0.4.0-incubating, które dodało cel Delta Kernel oraz Paimon i Parquet jako źródła (sprawdzono 21.10.2026). Udokumentowane ograniczenia: tabele Merge-on-Read w Hudi i Icebergu oraz tabele Delta z wektorami usunięć nie są obsługiwane.

Delta UniForm robi to samo od środka Delta Lake. Z włączoną funkcją każdy commit generuje też metadane Iceberg, a w wersji zapoznawczej Hudi, asynchronicznie po commicie Delta. Dokumentacja Delta wymienia wymagania: mapowanie kolumn, wersja czytelnika 2 i pisarza 7, IcebergCompatV2, Delta 3.1 lub nowsza dla Iceberga i 3.2 dla Hudi. Widoki Iceberg i Hudi są tylko do odczytu. Wektory usunięć nie są przenoszone do czytelnika Iceberg v2, typ VOID nie jest obsługiwany, a Change Data Feed nie jest udostępniany przez Iceberg; Databricks dokumentuje, że REORG ... UPGRADE UNIFORM z tego powodu usuwa wektory usunięć.

Oba podejścia zostawiają jeden format jako format zapisu, ten, do którego się pisze. Pozostałe są jego widokami, odświeżanymi z opóźnieniem.

Infografika

Dwa sposoby, by drugi silnik dostał tę samą tabelę

Skopiować dane

• –Nocne zadanie przepisuje pliki na drugą platformę
• –Dwa zbiory plików, dwa rachunki za składowanie, dwa zegary świeżości
• –Dwie tabele, które się rozjeżdżają, i uzgodnienie, które ktoś prowadzi
• –Uprawnienia ustawiane dwa razy, zwykle inaczej
• –Każda zmiana schematu w dwóch miejscach

Przetłumaczyć metadane

• →Jeden zbiór plików Parquet, jeden format zapisu
• →Drugi komplet metadanych zapisany obok (XTable) albo przez samego pisarza (UniForm)
• →Jedna tabela, czytana natywnie przez oba silniki, ze znanym opóźnieniem
• →Uprawnienia nadal per katalog, i to jest część do przetestowania
• →Nieobsługiwane funkcje wykrywa test kontraktu, nie użytkownik

Co zmienia się w planie testów

Skopiowaną tabelę testuje się uzgodnieniem: obie strony porównuje się po ładowaniu. Przetłumaczona tabela to jedna tabela widziana dwa razy i tryby awarii się przesuwają. W dostarczaniu opartym na specyfikacji plan testów jest częścią specyfikacji, więc to są testy, które piszemy, zanim ruszy pierwsza synchronizacja.

Równoważność między formatami. Ta sama tabela czytana przez format zapisu i przez przetłumaczony widok: liczby wierszy, stały zestaw agregatów na partycję, schemat z typami i ostatni commit, który widzi każda strona. Uruchamiane po każdej synchronizacji i według harmonogramu. Rozbieżność jest defektem potoku, nie pozycją do uzgodnienia.

Opóźnienie świeżości. Przetłumaczony widok jest z założenia za zapisem: XTable o swój harmonogram, UniForm o asynchroniczne generowanie, wirtualizacja OneLake w Fabric o to, co Microsoft dokumentuje jako od pięciu sekund do dwóch minut dla tabel poniżej pięciu tysięcy commitów. Kontrakt określa opóźnienie obiecane odbiorcy; test je mierzy i pada, gdy obietnica jest złamana. Asystent, który odpowiada z widoku Iceberg, musi wiedzieć, a najlepiej mówić, jak stary jest jego widok.

Kontrakty funkcji. Każde udokumentowane ograniczenie staje się testem. Tabela z włączonymi wektorami usunięć, kolumną VOID, układem Merge-on-Read albo zależnością od Change Data Feed pada na teście kontraktu, zanim dotrze do kroku tłumaczenia, z komunikatem, który nazywa ograniczenie. Te testy są tanie w pisaniu i drogie w braku.

Zgodność uprawnień. Tłumaczenie metadanych nie mówi nic o tym, kto może czytać. Tabela Delta pod Unity Catalog i jej widok Iceberg pod katalogiem Snowflake albo Polaris mają osobne nadania. Test wylicza podmioty po obu stronach i pada na różnicy, której specyfikacja nie dopuściła.

Wycofanie widoku. Jeśli synchronizacja wytworzy błędną migawkę Iceberg, plan testów mówi, jak przywrócić widok do poprzedniej i jak odbiorcy dowiadują się, że to nastąpiło.

Kto jest właścicielem formatu zapisu

Tłumaczenie usuwa kopię i zostawia decyzję: w którym formacie się pisze. Ta decyzja wiąże silniki, które mogą pisać, katalog, który zarządza, i funkcje, z których platforma może korzystać, nie psując widoku. To decyzja architektoniczna z nazwanym właścicielem, nie flaga konfiguracji.

Kontekst rynkowy ma tu znaczenie tylko jako fakt. Databricks ogłosił przejęcie Tabular w czerwcu 2024 roku, z deklarowanym krótkoterminowym celem zgodności Delta i Iceberga przez UniForm. Microsoft dokumentuje wirtualizację tabel Delta jako Iceberg w OneLake oraz skróty Iceberg. Tableflow Confluenta materializuje tematy Kafki jako tabele Iceberg lub Delta. Kierunek jest taki, że platformy czytają wzajemnie swoje formaty; własność zapisywanego formatu i katalogu nie przesunęła się.

Gdzie pomagają agenci, a gdzie decyduje architekt

Opisane wyżej zestawy testów są powtarzalne, parametryzowane i liczne, czyli dokładnie takie, jakie agenci kodujący dobrze wytwarzają ze specyfikacji: zapytania równoważności per tabela, monitory opóźnienia, kontrole kontraktów wygenerowane z udokumentowanych ograniczeń, porównanie uprawnień. Agent potrafi też przeczytać log nieudanej synchronizacji i nazwać funkcję, która ją zepsuła. Pozwalamy agentom to wszystko naszkicować i odbieramy, uruchamiając na prawdziwych tabelach.

Decyzje zostają przy ludziach: który format jest formatem zapisu; czy tabela może włączyć funkcję, której widok nie przeniesie; jakie opóźnienie obiecano każdemu odbiorcy; czy platforma spółki zależnej jest widokiem, czy drugim pisarzem; i kiedy przetłumaczony widok jest na tyle dobry, by wyłączyć kopię. Wyłączenie jest momentem, w którym całe przedsięwzięcie się zwraca, i powinno nastąpić dopiero wtedy, gdy testy równoważności przechodzą na tyle długo, że nikt już nie czyta arkusza uzgodnień.

Jak wygląda dobry wynik

Jeden zbiór plików dla tabel sprzedaży grupy, zapisywany w jednym formacie przez jedną platformę. Silnik spółki zależnej czyta je natywnie, z opóźnieniem, które jest określone i mierzone. Nocna kopia i jej uzgodnienie zniknęły. Każde ograniczenie tłumaczenia jest testem, który uruchamia się, zanim zauważy je użytkownik. Oba asystenty podają tę samą marżę, a zapytane, jak świeża jest, odpowiadają.

Nasza część

W wytwarzaniu agentów AI opartym na specyfikacji najpierw piszemy specyfikację, razem z nią plan testów, a agentom pozwalamy wygenerować zestawy równoważności, opóźnienia i kontraktów, które czynią przetłumaczoną tabelę godną zaufania, odebrane na waszych prawdziwych tabelach, zanim kopia zostanie wyłączona. Nie odsprzedajemy platform. Więcej o predictes na stronie głównej.