Delta Lake: gdy firma stoi na Microsoft

Firma od piętnastu lat działa na Microsoft. Poczta, dokumenty i spotkania w Microsoft 365, raporty w Power BI, a od niedawna obszar roboczy Fabric, w którym zespół danych ląduje wyciągi z ERP. Gdy taka firma rozważa system operacyjny dla całego przedsiębiorstwa, pierwsze pytanie działu IT jest rozsądne: czy zapis trafi tam, gdzie nasze narzędzia nadal go przeczytają?

Dla firmy w tej sytuacji odpowiedź biegnie przez Delta Lake. OneLake, magazyn pod Fabric, przechowuje tabele jako Delta Parquet według dokumentacji Microsoft, więc zapis w Delta jest zapisem, który Fabric czyta bez kopii. Integracja Hurukana z Microsoft 365 Copilot jest planowana, a nie działająca, a warstwa Data jest w budowie; ten tekst jest o tym, co Delta Lake daje zapisowi w takim układzie i co pozostaje decyzją firmy. Po co w ogóle zapis, wyjaśnia tekst o stanie bieżącym i zapisie.

Co robi log

Delta Lake dodaje do katalogu plików Parquet jedną rzecz: log transakcji. _delta_log/ trzyma jeden plik JSON na commit, nazwany numerem wersji, z listą plików dodanych i usuniętych oraz ze schematem i protokołem. Okresowe punkty kontrolne w Parquet podsumowują log, żeby czytelnik nie odtwarzał go od początku. Definiuje to dokument protokołu; bieżące wydanie to 4.4.0 (sprawdzono 21.10.2026).

Z tego jednego mechanizmu wynika wszystko, czego potrzebuje zapis. Zapis jest atomowy, bo plik commitu albo istnieje, albo nie. Czytelnicy widzą całą wersję, bo czytają numerowany commit, a nie listing katalogu. Dwaj pisarze nie psują sobie danych, bo optymistyczna kontrola współbieżności wykrywa konflikt przy commicie. A „tabela taka, jaka była, gdy agent to zaproponował” to numer wersji — i to właśnie czyni pytanie audytu możliwym do odpowiedzenia.

Funkcje, które mają znaczenie dla zapisu

Funkcje tabeli w Delta włącza się per tabela i niesie w protokole, więc czytelnik wie, czy potrafi przeczytać to, na co patrzy. Strona o wersjonowaniu wymienia je razem z wymaganymi wersjami czytelnika i pisarza (sprawdzono 21.10.2026). Cztery z nich kształtują zapis firmy.

Wektory usunięć oznaczają wiersze jako usunięte bez przepisywania pliku, więc żądanie usunięcia danych jednej osoby nie przepisuje roku faktur. Usunięcie staje się ostateczne, gdy stare pliki zostaną wyczyszczone, a to jest ustawienie retencji, a nie automatyczny skutek.

Change Data Feed udostępnia, co zmieniło się między dwiema wersjami; tak tabele niżej i agenci dowiadują się o zmianie bez ponownego czytania wszystkiego.

Liquid clustering zastępuje sztywne partycje kluczami klastrowania, które można później zmienić, więc układ może podążać za tym, jak zapis jest naprawdę odpytywany.

UniForm zapisuje metadane Iceberg obok logu Delta, więc silniki czytające Iceberg widzą tę samą tabelę. Wymaga mapowania kolumn, od strony Iceberga jest tylko do odczytu i ma udokumentowane ograniczenia wokół wektorów usunięć i danych o zmianach, opisane pod Delta UniForm. Tekst serii o XTable i UniForm rozwija, co to daje.

Co prowadzi Fabric, a czego nie

Zarządzana platforma zdejmuje z firmy realną pracę: magazyn, moc obliczeniową, silniki, połączenie z Power BI, coraz częściej zadania serwisowe. To rozsądne miejsce dla zapisu, jeśli firma już zdecydowała, że stoi na Microsoft. Cztery rzeczy pozostają firmy, niezależnie od tego, czy to zauważy.

Katalog. OneLake decyduje, jak tabela się nazywa, kto może ją czytać i gdzie ogłaszana jest jej bieżąca wersja. Pliki są otwarte; spis plików należy do platformy. Plan wyjścia, który mówi „mamy Parquet w jeziorze”, nie uwzględnił tego spisu.

Retencja i usuwanie. Retencja logu i progi czyszczenia to ustawienia tabeli. Wyznaczają, jak daleko sięga podróż w czasie i kiedy usunięta osoba naprawdę znika. Nikt po stronie platformy nie ustawia ich za Ciebie, a agent w Hurukanie może je zaproponować, ale ich nie zatwierdza.

Włączanie funkcji. Włączenie nowszej funkcji podnosi wersję protokołu i może odciąć starszy czytnik gdzie indziej w firmie. Zysk jest realny; tak samo czytnik, który przestaje działać. Człowiek decyduje, per tabela, z listą czytelników przed sobą.

Ścieżka zapisu. Delta może być zapisywana przez wiele silników, ale silnik, który zapisuje daną tabelę, jest decyzją projektową, bo tam siedzi własność danych. W Hurukanie moduły zapisują przez własną ścieżkę zapisu, a platforma czyta; odwrotność to inna architektura.

Które z tych rzeczy firma posiada, to dokładnie pytanie spod bezpieczeństwa i suwerenności: infrastruktura, którą firma wybiera, dane i modele, które pozostają firmy, wyjście możliwe w praktyce.

Gdzie agenci pomagają, a gdzie się zatrzymują

Utrzymanie zapisu w Delta jest mechaniczne i ciągłe: kompaktowanie, czyszczenie, statystyki, klastrowanie. Agenci dobrze piszą te zadania i lepiej niż dashboard tłumaczą, czemu zapytanie jest wolne. W Hurukanie każde takie zadanie jest propozycją w skrzynce zatwierdzeń z dołączonym uzasadnieniem, zatwierdzaną przez człowieka i zapisywaną jak każda inna zmiana.

Czego agenci nie robią: nie decydują o retencji, nie zatwierdzają podniesienia protokołu, nie wybierają ścieżki zapisu. Te trzy decyzje wyznaczają, co zapis będzie w stanie później udowodnić, a firma musi umieć powiedzieć, kto je podjął.

Test, który możesz zrobić dziś

Otwórz jedną tabelę, którą Twój obszar roboczy Fabric już trzyma, i znajdź trzy ustawienia: retencję logu, próg czyszczenia i wersję protokołu, której wymaga od czytelnika. Jeśli wszystkie trzy są tam, gdzie zostawiła je platforma, nikt jeszcze nie zdecydował, jak daleko sięga Twój zapis ani które z Twoich narzędzi przeczytają go za rok. To pierwsza decyzja, jakiej potrzebuje zapis firmy, i nic nie kosztuje.