--- title: "Delta Lake: log transakcji pod Fabric i Databricks — i co nadal jest wasze" url: "https://predictes.com/pl/blog/delta-lake-log-transakcji-pod-fabric-i-databricks-i-co-nadal-jest-wasze" description: "Delta Lake to format pod Microsoft Fabric i Databricks. Platforma prowadzi log; retencja, usunięcia, włączanie funkcji i zadania serwisowe zostają wasze." --- # Delta Lake: log transakcji pod Fabric i Databricks — i co nadal jest wasze 30 września 2026·4 min czytania·predictes 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](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview), 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](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-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](https://github.com/delta-io/delta/blob/master/PROTOCOL.md) jest umową; każdy silnik, który czyta lub pisze Delta, implementuje ją bezpośrednio albo przez [Delta Kernel](https://docs.delta.io/latest/delta-kernel.html), 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](https://github.com/delta-io/delta/releases), 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](https://docs.delta.io/latest/versioning.html), 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. - 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. Czerwona pozycja to miejsce, w którym pada odpowiedź na pytanie o RODO z pierwszego akapitu. 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](https://docs.delta.io/latest/delta-utility.html), 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](https://predictes.com/pl/services/ai-data-engineering) 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](https://predictes.com/pl). - Delta Lake - Microsoft Fabric - Databricks - retencja danych ## Czytaj dalej - [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem) - [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)