Delta Lake: log transakcji pod Fabric i Databricks — i co nadal jest wasze

Producent na Microsoft 365 włącza Fabric, kieruje potok na ERP i MES i w ciągu tygodnia ma tabele, które czyta Power BI i z których odpowiada Copilot. Nikt w firmie nie wypowiedział słów „Delta Lake”. Pół roku później rada pracowników prosi o usunięcie danych byłego pracownika z każdego systemu, a zespół danych odkrywa, że lakehouse trzyma każdą wersję każdej tabeli tak długo, jak nikt mu nie powie inaczej.

Delta Lake jest formatem tabel pod OneLake w Microsoft Fabric, który przechowuje tabele „w otwartym formacie Delta Parquet”, i pod Databricks. Dla wielu przedsiębiorstw to pierwszy format tabel, z jakim się stykają, zwykle bez wybierania go. To rozsądny początek. Nie jest powodem, żeby części, które nadal są wasze, zostawić nierozstrzygnięte. W poradniku o dwóch pamięciach systemu AI-native lakehouse jest drugą pamięcią; Delta to jeden ze sposobów utrzymania tej pamięci w spójności, a ten tekst jest o tym, gdzie kończy się odpowiedzialność platformy.

Co robi log

Tabela Delta to katalog plików Parquet plus _delta_log/. Każdy commit to plik JSON nazwany dwudziestocyfrowym numerem wersji z zerami wiodącymi, zawierający akcje: add i remove dla plików danych, metaData dla schematu i partycjonowania, protocol dla minimalnych wersji czytelnika i pisarza, commitInfo, txn, cdc i domainMetadata. Punkty kontrolne w Parquet — w bieżących wydaniach V2 z plikami pobocznymi — podsumowują stan, a _last_checkpoint mówi czytelnikowi, od czego zacząć. Dokument protokołu jest umową; każdy silnik, który czyta lub pisze Delta, implementuje ją bezpośrednio albo przez Delta Kernel, biblioteki Java i Rust zbudowane po to, żeby konektor nie musiał.

Z logu wynikają własności, które reklamuje platforma: atomowe commity, więc nieudane ładowanie zostawia tabelę taką, jaka była; izolacja czytelników od pisarzy; podróż w czasie do każdej zachowanej wersji; MERGE, UPDATE i DELETE bez bazy danych pod spodem; jedna tabela dla paczki i strumienia.

Aktualne wydanie to Delta Lake 4.4.0, sprawdzono 21.10.2026. Zachowania poza bazowym protokołem są zamknięte za funkcjami tabeli, każda z minimalną wersją czytelnika i pisarza oraz wydaniem, w którym się pojawiła:

Funkcja	Co zmienia	Czytelnik / pisarz
Wektory usunięć (2.3.0)	Usunięcie oznacza wiersze zamiast przepisywać pliki	3 / 7
Mapowanie kolumn (1.2.0)	Zmiana nazwy lub usunięcie kolumny bez przepisywania danych	2 / 5
Change Data Feed (2.0.0)	Tabela emituje własne zmiany na poziomie wierszy	1 / 4
Śledzenie wierszy (3.2.0)	Stałe tożsamości wierszy między przepisaniami	3 / 7
Liquid clustering (3.1.0)	Układ danych po kluczach klastrowania zamiast sztywnych partycji	—
Rozszerzanie typów (GA 4.0.0)	Rozszerzenie typu kolumny w miejscu	3 / 7
Typ variant (4.0.0)	Dane półstrukturalne jako typ natywny	3 / 7
UniForm (IcebergCompatV2, 3.1.0)	Metadane Iceberg generowane obok logu	—

Źródło: wersjonowanie Delta, sprawdzono 21.10.2026. Kolumnę po prawej trzeba przeczytać przed włączeniem czegokolwiek: funkcja, która podnosi wersję czytelnika, jest niewidoczna dla każdego silnika, który jej nie dogonił.

Co platforma prowadzi za was, a czego nie

Na Fabric i Databricks log piszą silniki platformy, magazyn jest zarządzany, a katalog — OneLake albo Unity Catalog — decyduje, kto widzi którą tabelę. Zadania optymalizacji można planować z platformy. Czytanie Delta z zewnątrz jest możliwe przez otwarty protokół, a czytanie jako Iceberg przez UniForm. To dużo i dlatego format rzadko trzeba wybierać w środowisku Microsoft.

Czego platforma nie robi, to decydowanie. Cztery decyzje zostają w przedsiębiorstwie niezależnie od tego, jak zarządzana jest platforma.

Infografika

Co zostaje wasze pod zarządzaną platformą Delta

• Katalog i jego uprawnieniaKto może czytać którą tabelę, z którego silnika, pod jaką tożsamością. Format nie niesie nic z tego.
• Retencja, VACUUM i usunięciaUsunięty wiersz znika z bieżącej wersji od razu, a z plików dopiero po VACUUM. Do tego czasu nadal jest na dysku i w podróży w czasie.
• Włączanie funkcjiKażda funkcja tabeli podnosi minimalnego czytelnika lub pisarza. Włączona dla wygody może odciąć zespół czytający z innego silnika.
• Zadania serwisowe i ich kosztOPTIMIZE, klastrowanie, punkty kontrolne i VACUUM chodzą na waszych obliczeniach, według waszego harmonogramu, pod czyimś nadzorem.
• Ścieżka zapisuKtóry potok może pisać do tabeli i czy agent kodujący może go zmienić bez przeglądu.

Punkt o retencji zasługuje na szczegół. Delta domyślnie trzyma log 30 dni, a VACUUM domyślnie usuwa pliki starsze niż 7 dni (narzędzia, sprawdzono 21.10.2026). DELETE zapisuje nową wersję bez wierszy — z wektorami usunięć oznacza je — a stare pliki zostają, aż VACUUM je usunie. Żądanie usunięcia z RODO to więc dwa kroki, drugi według harmonogramu, który należy do was, i audytor może zapytać o datę tego drugiego. Podróż w czasie do wersji sprzed usunięcia musi w tym momencie przestać działać, a to cena tego, że usunięcie jest prawdziwe.

Przykład dydaktyczny: ERP i MES do Fabric

Weźmy producenta z ERP do zamówień i zapasów oraz MES do zdarzeń produkcyjnych, oba lądujące w lakehouse Fabric. To ilustracja projektu, nie opis klienta.

MES emituje stany maszyn i zakończone operacje bez przerwy; ERP zmienia zamówienia, marszruty i stany magazynowe w ciągu dnia. Oba lądują przez CDC w tabelach Delta. Agent kodujący szkicuje potoki MERGE ze schematów źródłowych i kluczy, szkicuje harmonogram OPTIMIZE i klastrowania z zaobserwowanego wzorca zapisu i włącza Change Data Feed na tabeli zamówień, żeby asystent planowania niżej czytał tylko to, co się zmieniło. Wszystko to idzie przez pull request z wynikami testów: liczby wierszy względem źródła, MERGE odtworzony dwa razy z tym samym wynikiem, odczyt z podróżą w czasie do wczorajszej wersji.

O czym decyduje inżynier i zapisuje obok tabeli: że zdarzenia produkcyjne są przechowywane przez okres gwarancji i nie dłużej; że VACUUM chodzi co tydzień, a rejestr usunięć jest z nim porównywany; że wektory usunięć są włączone, bo wszystkie silniki w środowisku czytają protokół 7, z zapisanymi wersjami czytelników; że spółka zależna na Snowflake będzie czytać te tabele przez UniForm, więc mapowanie kolumn jest włączone od początku, bo UniForm tego wymaga. Asystent planowania czyta lakehouse i warstwę semantyczną; do ERP nie zapisuje niczego inaczej niż przez interfejs ERP, jako proponowaną zmianę, którą potwierdza planista.

Jak do tego podchodzimy

Zaczynamy od żądania usunięcia i pytania audytora, nie od potoku, bo one decydują o retencji, a retencja decyduje o reszcie. Pierwsza tabela przechodzi całą ścieżkę: CDC na wejściu, MERGE, decyzje o funkcjach z zapisanymi wersjami czytelników, zadania serwisowe zaplanowane i wycenione, jeden czytelnik spoza platformy przetestowany. Agenci kodujący szkicują potoki i testy; pull request niesie uzasadnienie; imiennie wskazany inżynier zatwierdza. Wynikiem jest środowisko Delta, w którym platforma robi to, w czym jest dobra, a przedsiębiorstwo dokładnie wie, które cztery rzeczy nadal są jego.

Nasza część

W inżynierii danych AI budujemy ścieżkę Delta pod platformą Fabric albo Databricks od początku do końca — ingest, decyzje o funkcjach, retencję i zadania serwisowe, z przetestowanymi czytelnikami z zewnątrz — i zostawiamy wam tabelę, której decyzje są zapisane. Nie odsprzedajemy platform ani licencji. Więcej o predictes na stronie głównej.