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 nedoporuč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 povoleným katalogem 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 v hive_metastore používají starší vzory přístupu k datům, které můžou zahrnovat přihlašovací údaje pro data a úložiště spravované dbFS. Spravované tabulky v rámci pracovního prostoru hive_metastore 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 hive_metastore 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í. Vzhledem k tomu, že ANY FILE umožňuje uživatelům obejít seznamy ACL starších tabulek v hive_metastore a přistupovat ke všem datům spravovaným DBFS, Databricks doporučuje postupovat s opatrností při udělování tohoto oprávnění.
Nepoužívejte DBFS s externími umístěními katalogu Unity.
Katalog Unity zabezpečuje přístup k datům na externích umístěních pomocí úplných cloudových URI cest pro identifikaci oprávnění k adresářům spravovaného objektového úložiště. Připojení DBFS používají zcela jiný model přístupu k datům, který zcela obchází katalog Unity. Databricks doporučuje, abyste znovu nepoužívali svazky objektového úložiště v cloudu mezi připojeními DBFS a externími svazky UC, ani při 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á ú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í společnost Databricks doporučuje načítat úložné účty do externích lokalit až po odvolání všech ostatních autentizačních údajů úložiště a přístupových metod.
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 k systému souborů Unity Catalog.
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ám
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 definována v hive_metastore v umístění a/b/c a externí umístění je definováno v katalogu Unity v a/b/, 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")