Aanbevolen procedures voor DBFS en Unity Catalog
Unity Catalog introduceert een aantal nieuwe configuraties en concepten die gegevensbeheer volledig anders benaderen dan DBFS. In dit artikel worden verschillende aanbevolen procedures beschreven voor het werken met externe locaties van Unity Catalog en DBFS.
Databricks raadt het gebruik van DBFS en gekoppelde cloudobjectopslag af voor de meeste gebruiksscenario's in Azure Databricks-werkruimten met Unity Catalog. In dit artikel worden enkele scenario's beschreven waarin u gekoppelde cloudobjectopslag moet gebruiken. Databricks raadt het gebruik van de DBFS-hoofdmap niet aan in combinatie met Unity Catalog, tenzij u bestanden of gegevens die daar zijn opgeslagen, moet migreren naar Unity Catalog.
Hoe wordt DBFS gebruikt in werkruimten met Unity Catalog?
Acties die worden uitgevoerd op tabellen in de hive_metastore
gebruikmaken van verouderde gegevenstoegangspatronen, waaronder mogelijk gegevens- en opslagreferenties die worden beheerd door DBFS. Beheerde tabellen in het werkgebied met scope hive_metastore
worden opgeslagen in de hoofdmap van DBFS.
Hoe werkt DBFS in de modus voor toegang tot één gebruiker?
Clusters die zijn geconfigureerd met de modus voor toegang van één gebruiker, hebben volledige toegang tot DBFS, inclusief alle bestanden in de DBFS-hoofdmap en gekoppelde gegevens.
Hoe werkt DBFS in de modus voor gedeelde toegang?
De modus voor gedeelde toegang combineert Unity Catalog-gegevensbeheer met verouderde Azure Databricks-tabel-ACL's. Toegang tot gegevens in de hive_metastore
is alleen beschikbaar voor gebruikers die expliciet machtigingen hebben.
Als u rechtstreeks met bestanden wilt werken via DBFS, moet u ANY FILE
machtigingen hebben gekregen. Omdat ANY FILE
gebruikers in staat stelt verouderde tabellen ACL's te omzeilen in de hive_metastore
en toegang te krijgen tot alle gegevens die worden beheerd door DBFS, raadt Databricks voorzichtigheid aan bij het verlenen van deze bevoegdheid.
DBFS niet gebruiken met externe locaties van Unity Catalog
Unity Catalog beveiligt de toegang tot gegevens in externe locaties door gebruik te maken van volledige cloud-URI-paden om toegangsrechten op beheerde objectopslagmappen te identificeren. DBFS-koppelingen maken gebruik van een volledig ander gegevenstoegangsmodel waarmee Unity Catalog volledig wordt overgeslagen. Databricks raadt aan om cloudobjectopslagvolumes niet opnieuw te gebruiken tussen DBFS-mounts en externe UC-volumes, inclusief bij het delen van gegevens tussen werkruimten of accounts.
Uw door de Unity-catalogus beheerde opslag beveiligen
Unity Catalog met beheerde opslaglocaties voor het opslaan van gegevensbestanden voor beheerde tabellen en volumes.
Databricks raadt het volgende aan voor beheerde opslaglocaties:
- Gebruik nieuwe opslagaccounts of buckets.
- Definieer een aangepast identiteitsbeleid voor Unity Catalog.
- Beperk alle toegang tot Azure Databricks die wordt beheerd door Unity Catalog.
- Alle toegang tot identiteitstoegangsbeleid beperken dat is gemaakt voor Unity Catalog.
Bestaande gegevens toevoegen aan externe locaties
Het is mogelijk om bestaande opslagaccounts in Unity Catalog te laden met behulp van externe locaties. Voor de grootste beveiliging raadt Databricks aan om opslagaccounts alleen naar externe locaties te laden nadat alle andere opslagreferenties en toegangspatronen zijn ingetrokken.
Je moet nooit een opslagaccount laden dat wordt gebruikt als DBFS-hoofdmap als een externe locatie in Unity Catalog.
Clusterconfiguraties worden genegeerd door toegang tot het Bestandssysteem van Unity Catalog
Unity Catalog respecteert geen clusterconfiguraties voor bestandssysteeminstellingen. Dit betekent dat Hadoop-bestandssysteeminstellingen voor het configureren van aangepast gedrag met cloudobjectopslag niet werken bij het openen van gegevens met behulp van Unity Catalog.
Beperking rond toegang tot meerdere paden
Hoewel u over het algemeen Unity Catalog en DBFS samen kunt gebruiken, kunnen paden die gelijk zijn of een bovenliggende/onderliggende relatie delen niet in dezelfde opdracht of notebookcel worden gerefereerd met gebruik van verschillende toegangsmethoden.
Als bijvoorbeeld een externe tabel foo
is gedefinieerd in de hive_metastore
op locatie a/b/c
en een externe locatie is gedefinieerd in Unity Catalog op a/b/
, zou de volgende code een fout veroorzaken:
spark.read.table("foo").filter("id IS NOT NULL").write.mode("overwrite").save("a/b/c")
Deze fout treedt niet op als deze logica in twee cellen is onderverdeeld:
df = spark.read.table("foo").filter("id IS NOT NULL")
df.write.mode("overwrite").save("a/b/c")