Metodtips 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 innehålla data och autentiseringsuppgifter för lagring som hanteras av DBFS. Hanterade tabeller inom arbetsytans omfång hive_metastore lagras på roten av DBFS.

Hur fungerar DBFS i enanvändarläge?

Kluster som konfigurerats med läge för enanvändaråtkomst har fullständig åtkomst till DBFS, inklusive alla filer i DBFS:s rot och den monterade datan.

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änglig för användare som uttryckligen har behörighet.

Om du vill interagera med filer direkt med DBFS måste du ha ANY FILE behörigheter som beviljats. Eftersom ANY FILE tillåter användare att kringgå äldre tabellers ACL:er i hive_metastore och komma åt alla data som hanteras av DBFS rekommenderar Databricks försiktighet när de 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 tillstånd för kataloger för hanterad objektlagring. 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 ladda ett lagringskonto som används som en DBFS-root 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 eller har en förälder/barn-relation kan inte refereras i samma kommando eller notebook-cell med olika åtkomstmetoder.

Om till exempel en extern tabell foo definieras i hive_metastore på plats a/b/c och en extern plats definieras i Unity Catalog på a/b/skulle följande kod utlösa 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")