Regelverk för DBFS och Unity Catalog

Unity Catalog introducerar ett antal nya konfigurationer och begrepp som närmar sig datastyrning helt annorlunda än DBFS. Den här artikeln beskriver flera metodtips för att arbeta med externa platser i Unity Catalog och DBFS.

Databricks rekommenderar att du inte använder DBFS och monterad molnobjektlagring för de flesta användningsfall i Unity Catalog-aktiverade Azure Databricks-arbetsytor. I den här artikeln beskrivs några scenarier där du bör använda monterad molnobjektlagring. Observera att Databricks inte rekommenderar att du använder DBFS-roten tillsammans med Unity Catalog, såvida du inte måste migrera filer eller data som lagras där till Unity Catalog.

Hur används DBFS i Unity Catalog-aktiverade arbetsytor?

Åtgärder som utförs mot tabeller i hive_metastore använder äldre dataåtkomstmönster, som kan omfatta data och autentiseringsuppgifter för lagring som hanteras av DBFS. Hanterade tabeller i arbetsytans hive_metastore omfattning lagras i DBFS-roten.

Hur fungerar DBFS i enanvändarläge?

Kluster som konfigurerats med enkel användaråtkomstläge har fullständig åtkomst till DBFS, inklusive alla filer i DBFS-roten och monterade data.

Hur fungerar DBFS i läget för delad åtkomst?

Läget för delad åtkomst kombinerar datastyrning i Unity Catalog med azure Databricks äldre tabell-ACL:er. Åtkomst till data i hive_metastore är endast tillgängligt för användare som har uttrycklig behörighet.

Om du vill interagera med filer direkt med HJÄLP av DBFS måste du ha ANY FILE behörigheter som beviljats. Eftersom ANY FILE tillåter användare att kringgå äldre tabeller aCL:er i hive_metastore och komma åt alla data som hanteras av DBFS rekommenderar Databricks försiktighet när du beviljar den här behörigheten.

Använd inte DBFS med externa platser i Unity Catalog

Unity Catalog skyddar åtkomsten till data på externa platser med hjälp av fullständiga moln-URI-sökvägar för att identifiera bidrag för lagringskataloger för hanterade objekt. DBFS-monteringar använder en helt annan dataåtkomstmodell som kringgår Unity Catalog helt och hållet. Databricks rekommenderar att du inte återanvänder lagringsvolymer för molnobjekt mellan DBFS-monteringar och externa UC-volymer, inklusive när du delar data mellan arbetsytor eller konton.

Skydda din Unity Catalog-hanterade lagring

Unity Catalog använder hanterade lagringsplatser för lagring av datafiler för hanterade tabeller och volymer.

Databricks rekommenderar följande för hanterade lagringsplatser:

• Använd nya lagringskonton eller bucketar.
• Definiera en anpassad identitetsprincip för Unity Catalog.
• Begränsa all åtkomst till Azure Databricks som hanteras av Unity Catalog.
• Begränsa all åtkomst till identitetsåtkomstprinciper som skapats för Unity Catalog.

Lägga till befintliga data på externa platser

Det går att läsa in befintliga lagringskonton i Unity Catalog med hjälp av externa platser. För största möjliga säkerhet rekommenderar Databricks att du bara läser in lagringskonton till externa platser när du har återkallat alla andra autentiseringsuppgifter för lagring och åtkomstmönster.

Du bör aldrig läsa in ett lagringskonto som används som en DBFS-rot som en extern plats i Unity Catalog.

Klusterkonfigurationer ignoreras av åtkomst till Unity Catalog-filsystem

Unity Catalog respekterar inte klusterkonfigurationer för filsysteminställningar. Det innebär att Hadoop-filsysteminställningar för att konfigurera anpassat beteende med lagring av molnobjekt inte fungerar vid åtkomst till data med hjälp av Unity Catalog.

Begränsning kring åtkomst till flera sökvägar

Du kan vanligtvis använda Unity Catalog och DBFS tillsammans, men sökvägar som är lika med eller delar en överordnad/underordnad relation kan inte refereras i samma kommando eller notebook-cell med olika åtkomstmetoder.

Om till exempel en extern tabell foo har definierats på hive_metastore platsen a/b/c och en extern plats definieras i Unity Catalog a/b/den , utlöser följande kod ett fel:

spark.read.table("foo").filter("id IS NOT NULL").write.mode("overwrite").save("a/b/c")

Det här felet skulle inte uppstå om den här logiken är uppdelad i två celler:

df = spark.read.table("foo").filter("id IS NOT NULL")

df.write.mode("overwrite").save("a/b/c")