Procedure consigliate per DBFS e il catalogo Unity

Unity Catalog introduce diverse nuove configurazioni e concetti che variano completamente a seconda della governance dei dati rispetto a DBFS. Questo articolo illustra diverse procedure consigliate per l'uso di posizioni esterne del catalogo Unity e DBFS.

Databricks consiglia di usare DBFS e l'archiviazione di oggetti cloud montati per la maggior parte dei casi d'uso nelle aree di lavoro di Azure Databricks abilitate per Unity. Questo articolo descrive alcuni scenari in cui è consigliabile usare l'archiviazione di oggetti cloud montata. Si noti che Databricks non consiglia di usare la radice DBFS in combinazione con Unity Catalog, a meno che non sia necessario eseguire la migrazione di file o dati archiviati in Unity Catalog.

Come viene usato DBFS nelle aree di lavoro abilitate per Il catalogo Unity?

Le azioni eseguite sulle tabelle in hive_metastore usano modelli di accesso ai dati legacy, che possono includere dati e credenziali di archiviazione gestite da DBFS. Le tabelle gestite nell'ambito dell'area hive_metastore di lavoro vengono archiviate nella radice DBFS.

Come funziona DBFS in modalità accesso utente singolo?

I cluster configurati con la modalità di accesso utente singolo hanno accesso completo a DBFS, inclusi tutti i file nella radice DBFS e i dati montati.

Come funziona DBFS in modalità di accesso condiviso?

La modalità di accesso condiviso combina la governance dei dati di Unity Catalog con gli ACL della tabella legacy di Azure Databricks. L'accesso hive_metastore ai dati in è disponibile solo per gli utenti che dispongono di autorizzazioni concesse in modo esplicito.

Per interagire con i file direttamente tramite DBFS, è necessario disporre ANY FILE delle autorizzazioni concesse. Poiché ANY FILE consente agli utenti di ignorare gli ACL delle tabelle legacy in hive_metastore e di accedere a tutti i dati gestiti da DBFS, Databricks consiglia di prestare attenzione quando si concede questo privilegio.

Non usare DBFS con percorsi esterni del catalogo Unity

Il catalogo unity protegge l'accesso ai dati in posizioni esterne usando percorsi URI cloud completi per identificare le concessioni nelle directory di archiviazione degli oggetti gestiti. I montaggi DBFS usano un modello di accesso ai dati completamente diverso che ignora completamente Unity Catalog. Databricks consiglia di non riutilizzare i volumi di archiviazione di oggetti cloud tra i montaggi DBFS e i volumi esterni UC, incluso quando si condividono dati tra aree di lavoro o account.

Proteggere l'archiviazione gestita dal catalogo unity

Catalogo unity che usa percorsi di archiviazione gestiti per l'archiviazione di file di dati per tabelle e volumi gestiti.

Databricks consiglia quanto segue per le posizioni di archiviazione gestite:

• Usare nuovi account di archiviazione o bucket.
• Definire un criterio di identità personalizzato per il catalogo unity.
• Limitare l'accesso a Azure Databricks gestito dal catalogo unity.
• Limitare tutti gli accessi ai criteri di accesso alle identità creati per Il catalogo unity.

Aggiungere dati esistenti a percorsi esterni

È possibile caricare gli account di archiviazione esistenti nel catalogo Unity usando posizioni esterne. Per una maggiore sicurezza, Databricks consiglia di caricare solo gli account di archiviazione in posizioni esterne dopo aver revocato tutte le altre credenziali di archiviazione e i modelli di accesso.

Non caricare mai un account di archiviazione usato come radice DBFS come posizione esterna nel catalogo Unity.

Le configurazioni del cluster vengono ignorate dall'accesso al file system del catalogo Unity

Il catalogo unity non rispetta le configurazioni del cluster per le impostazioni del file system. Ciò significa che le impostazioni del file system Hadoop per la configurazione del comportamento personalizzato con l'archiviazione oggetti cloud non funzionano quando si accede ai dati usando Unity Catalog.

Limitazione dell'accesso a più percorsi

Anche se in genere è possibile usare insieme Unity Catalog e DBFS, non è possibile fare riferimento ai percorsi uguali o condivisi con una relazione padre/figlio nella stessa cella del comando o del notebook usando metodi di accesso diversi.

Ad esempio, se una tabella foo esterna è definita nella hive_metastore posizione a/b/c e una posizione esterna è definita nel catalogo Unity in a/b/, il codice seguente genererà un errore:

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

Questo errore non si verifica se questa logica è suddivisa in due celle:

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

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