Osvědčené postupy pro DBFS a katalog Unity
Katalog Unity zavádí řadu nových konfigurací a konceptů, které přistupují k zásadám správného řízení dat zcela jinak než DBFS. Tento článek popisuje několik osvědčených postupů pro práci s externími umístěními katalogu Unity a DBFS.
Databricks doporučuje používat DBFS a připojené cloudové úložiště objektů pro většinu případů použití v pracovních prostorech Azure Databricks s podporou katalogu Unity. Tento článek popisuje několik scénářů, ve kterých byste měli použít připojené cloudové úložiště objektů. Upozorňujeme, že Databricks nedoporučuje používat kořenový adresář DBFS ve spojení s katalogem Unity, pokud není nutné migrovat soubory nebo data uložená v katalogu Unity.
Jak se dbFS používá v pracovních prostorech s podporou katalogu Unity?
Akce prováděné s tabulkami ve hive_metastore starších vzorech přístupu k datům, které můžou zahrnovat přihlašovací údaje pro data a úložiště spravované dbFS. Spravované tabulky v oboru hive_metastore pracovního prostoru jsou uložené v kořenovém adresáři DBFS.
Jak funguje DBFS v režimu přístupu jednoho uživatele?
Clustery nakonfigurované v režimu přístupu jednoho uživatele mají úplný přístup k DBFS, včetně všech souborů v kořenovém adresáři DBFS a připojených dat.
Jak funguje DBFS v režimu sdíleného přístupu?
Režim sdíleného přístupu kombinuje zásady správného řízení dat katalogu Unity s seznamy ACL starších tabulek Azure Databricks. Přístup k datům v této hive_metastore oblasti je k dispozici pouze uživatelům, kteří mají explicitně udělená oprávnění.
Pokud chcete pracovat se soubory přímo pomocí DBFS, musíte mít udělená ANY FILE oprávnění. Protože ANY FILE umožňuje uživatelům obejít seznamy ACL starších tabulek v hive_metastore seznamech ACL a přistupovat ke všem datům spravovaným dbFS, doporučuje Databricks při udělování tohoto oprávnění upozornění.
Nepoužívejte DBFS s externími umístěními katalogu Unity.
Katalog Unity zabezpečuje přístup k datům v externích umístěních pomocí úplných cest URI cloudu k identifikaci grantů pro adresáře úložiště spravovaných objektů. Připojení DBFS používají zcela jiný model přístupu k datům, který zcela obchází katalog Unity. Databricks doporučuje, abyste mezi připojeními DBFS a externími svazky UC nepoužívají svazky cloudového úložiště objektů, včetně sdílení dat mezi pracovními prostory nebo účty.
Zabezpečení úložiště spravovaného katalogem Unity
Katalog Unity využívající spravovaná umístění úložiště k ukládání datových souborů pro spravované tabulky a svazky.
Databricks doporučuje pro spravovaná umístění úložiště následující:
- Používejte nové účty úložiště nebo kontejnery.
- Definujte vlastní zásady identity pro katalog Unity.
- Omezte veškerý přístup ke službě Azure Databricks spravované službou Unity Catalog.
- Omezte veškerý přístup k zásadám přístupu k identitám vytvořeným pro katalog Unity.
Přidání existujících dat do externích umístění
Existující účty úložiště je možné načíst do katalogu Unity pomocí externích umístění. Pro zajištění nejvyššího zabezpečení doporučuje Databricks načítat pouze účty úložiště do externích umístění po odvolání všech ostatních přihlašovacích údajů úložiště a vzorů přístupu.
Nikdy byste neměli načítat účet úložiště používaný jako kořen DBFS jako externí umístění v katalogu Unity.
Konfigurace clusteru jsou ignorovány přístupem systému souborů Katalogu Unity.
Katalog Unity nerespektuje konfigurace clusteru pro nastavení systému souborů. To znamená, že nastavení systému souborů Hadoop pro konfiguraci vlastního chování v cloudovém úložišti objektů nefunguje při přístupu k datům pomocí katalogu Unity.
Omezení ohledně přístupu k více cestě
Přestože můžete obecně používat katalog Unity a DBFS společně, cesty, které jsou stejné nebo sdílejí vztah nadřazený/podřízený, nelze odkazovat ve stejném příkazu nebo v buňce poznámkového bloku pomocí různých metod přístupu.
Pokud je například externí tabulka foo definovaná v hive_metastore umístění a/b/c a externí umístění je definováno v katalogu a/b/Unity, následující kód vyvolá chybu:
spark.read.table("foo").filter("id IS NOT NULL").write.mode("overwrite").save("a/b/c")
K této chybě by nedošlo, pokud je tato logika rozdělená do dvou buněk:
df = spark.read.table("foo").filter("id IS NOT NULL")
df.write.mode("overwrite").save("a/b/c")