DBFS znika z nowych workspace’ów. Co się zmienia od 30 września 2026 i jak się przygotować

Problem

Bardzo często widzę kod z tutoriali i starszych projektów, w których wszystko leży w dbfs:/FileStore/... albo w /mnt/.... Na workspace'ie, który pracuje w trybie legacy, taki kod dalej działa. Na nowym workspace'ie już nie, bo tych ścieżek tam po prostu nie ma.

Widzę to często, także u klientów, bo wiele systemów to wciąż legacy. Dochodzi do tego AI: asystenci do kodu dalej podpowiadają ścieżki dbfs:/ i /mnt/, choć to już nie jest dobra praktyka.

DBFS (Databricks File System) to wirtualny system plików nad storage'em w chmurze. Problem z nim jest taki, że nie ma governance: każdy użytkownik workspace'u widzi wszystko, co leży w DBFS root, a mount z kluczem do storage'u daje dostęp każdemu, kto zna ścieżkę. Unity Catalog rozwiązuje to przez Volumes, czyli pliki z uprawnieniami, audytem i lineage.

Warto tutaj od razu sprostować jedną rzecz, bo w sieci krąży uproszczona wersja: 30 września 2026 Databricks nie wyłącza DBFS wszędzie. Zmienia się to, jak powstają nowe workspace'y.

Co dokładnie się zmienia

Na labie (29.09.2026) widać to na żywo: trialowy workspace, który założyliśmy 29.09.2026, czyli dzień przed terminem, ma domyślny katalog hive_metastore. Ma więc jeszcze funkcje legacy. Workspace założony od 30.09 już by ich nie miał.

W nowych workspace'ach nie będzie czterech rzeczy:

1. DBFS root i mountów (dbutils.fs.mount, /mnt/...),
2. Hive Metastore (hive_metastore jako katalog),
3. klastrów w trybie no-isolation shared,
4. Databricks Runtime starszego niż 13.3 LTS.

Dla nas oznacza to, że workspace „UC-only” staje się standardem. Jeśli nasz kod, init scripty albo automatyzacja zakładają obecność którejś z tych rzeczy, przy następnym nowym środowisku coś się posypie.

Volumes zamiast DBFS

Volume to obiekt Unity Catalog przeznaczony na pliki (CSV, JSON, obrazy, modele, biblioteki). Ma ścieżkę w postaci /Volumes/<katalog>/<schemat>/<volume> i podlega tym samym zasadom co tabele: ma właściciela, a dostęp nadajemy przez READ VOLUME i WRITE VOLUME.

Zaczynamy od utworzenia volume'u. Działa na Free Edition:

CREATE VOLUME IF NOT EXISTS <twoj_katalog>.default.landing
COMMENT 'Pliki wgrywane ręcznie';

Plik możemy wgrać przez Catalog Explorer: Catalog → nasz katalog → default → landing → Upload to this volume. Alternatywnie: New → Add or upload data → Upload files to a volume.

Potem czytamy go zwykłą ścieżką, bez mountu i bez klucza do storage'u. Działa na Free Edition:

LANDING_PATH = "/Volumes/<twoj_katalog>/default/landing"

# Co jest w volume? (to samo co LIST '/Volumes/...' w SQL)
for f in dbutils.fs.ls(LANDING_PATH):
    print(f"{f.name:<20} {f.size:>8,} bytes")

display(spark.sql(f"""
    SELECT *
    FROM read_files('{LANDING_PATH}/stores.csv', format => 'csv', header => true)
    LIMIT 5
"""))

Wynik z labu (Databricks, 29.09.2026): volume listujemy i czytamy zwykłą ścieżką /Volumes/..., a read_files() dokłada kolumnę _rescued_data na wartości, które nie pasują do schematu.

Volume jest obiektem Unity Catalog, więc możemy go opisać tak samo jak tabelę. Działa na Free Edition:

SHOW VOLUMES IN <twoj_katalog>.default;
DESCRIBE VOLUME <twoj_katalog>.default.landing;

Jedna rzecz, o którą pada najwięcej pytań: plik w volume nie jest tabelą. read_files() i spark.read czytają go przy każdym zapytaniu od nowa. Jeśli chcemy pracować na danych jak na tabeli, ładujemy je do Delta, np. przez CREATE TABLE ... AS SELECT * FROM read_files(...) albo Auto Loader.

Checklista migracji: od czego zacząć

1. Szukamy starych ścieżek w repo, notebookach i konfiguracji jobów: dbfs:/, /dbfs/, /mnt/, dbutils.fs.mount, %fs, FileStore. Zwykły grep -rE "dbfs:/|/dbfs/|/mnt/|dbutils.fs.mount|FileStore" po repozytorium daje pierwszą listę.
2. Init scripty i biblioteki trzymane na DBFS przenosimy do Volumes albo do workspace files.
3. Mounty z kluczami storage'u zastępujemy przez Storage Credential + External Location. Dostęp nadajemy grantami, a nie przez znajomość ścieżki.
4. Tabele z Hive Metastore przenosimy do Unity Catalog (SYNC, UCX albo HMS federation). To temat na osobny artykuł, tutaj wystarczy nam lista tabel do przeniesienia.
5. Klastry no-isolation shared zamieniamy na tryby dostępu Standard albo Dedicated, a Databricks Runtime podnosimy co najmniej do 13.3 LTS.
6. Automatyzacja tworzenia workspace'ów (Terraform, CI/CD): usuwamy zależności od DBFS i Hive Metastore oraz ustawiamy automatyczne przypisanie metastore'u (auto-assign) w każdym regionie, w którym tworzymy workspace'y.
7. Test przed terminem: w account console włączamy ustawienie Disable legacy features. Dzięki temu sprawdzimy zachowanie „jak w nowym workspace'ie”, zanim zrobi to za nas data w kalendarzu.

Pułapki: kiedy migracja się komplikuje

• Pandas i lokalne API czytające /dbfs/.... Kod typu pd.read_csv("/dbfs/FileStore/...") trzeba przepisać na ścieżkę /Volumes/.... Na labie (29.09.2026) pd.read_csv("/Volumes/.../landing/stores.csv") przeczytał plik bezpośrednio (5 wierszy), bez żadnego prefiksu i bez spark.read.

Wynik z labu (Databricks, 29.09.2026): po zamianie ścieżki /dbfs/... na /Volumes/... pandas czyta plik bez dodatkowej konfiguracji.

• Ścieżki zaszyte w bibliotekach i configach. Grep po repozytorium nie wystarczy, jeśli ścieżka siedzi w parametrach jobów, zmiennych środowiskowych klastra albo w konfiguracji narzędzia zewnętrznego. Dodatkowo warto przejrzeć definicje jobów i historię uruchomień.
• Mounty dające dostęp „wszystkim”. Po przejściu na External Location nagle potrzebne są granty dla konkretnych grup. To dobra zmiana, ale trzeba ją zaplanować, bo inaczej pierwszego dnia po migracji dostaniemy serię PERMISSION_DENIED.
• Metastore na Azure. W naszym Terraformie do środowisk testowych nie tworzymy metastore'u ręcznie, bo na Azure powstaje on automatycznie per region. Jeśli nasza automatyzacja próbuje go tworzyć albo zakłada, że go nie ma, to przy nowych workspace'ach trzeba to uporządkować.
• Joby na klastrach no-isolation shared. Po przeniesieniu do nowego workspace'u taki job nie wystartuje, bo tego trybu dostępu tam po prostu nie ma.

Kiedy NIE panikować

Istniejący workspace działa dalej. Jeśli w najbliższym czasie nie tworzymy nowych workspace'ów, mamy czas na spokojną migrację. Warto ją jednak zaplanować teraz, a nie w dniu, w którym ktoś postawi nowe środowisko dla nowego zespołu albo projektu i okaże się, że połowa notebooków odwołuje się do /mnt/.

Nie każdy plik musi od razu trafić do Volume. Jeśli coś jest tylko jednorazowym eksperymentem na starym workspace'ie, wystarczy, że nie przeniesiemy go dalej.

Zobacz, jak to działa

Nagranie pokazuje cały notebook uruchomiony na labie 29.09.2026: od utworzenia volume'u, przez odczyt pliku, po sprzątanie (83 s, wszystkie komórki OK).

Pełny notebook jest w katalogu code/ (dbfs_volumes.py).

Podsumowanie

• Od 30.09.2026 nowe workspace'y powstają bez DBFS root, mountów, Hive Metastore, klastrów no-isolation shared i DBR < 13.3 LTS. Konta Azure założone po 18.12.2025 nigdy tego nie miały.
• Istniejące workspace'y nie są objęte zmianą, ale kod z dbfs:/ nie przeniesie się do nowego środowiska.
• Pierwszy krok to grep po dbfs:/, /dbfs/, /mnt/ i przeniesienie plików do Volumes.
• Przed terminem testujemy ustawienie Disable legacy features i ustawiamy auto-assign metastore'u w każdym regionie.

Stan na: 29.09.2026