Práticas recomendadas para DBFS e Unity Catalog

O Unity Catalog introduz uma série de novas configurações e conceitos que abordam a governança de dados de forma totalmente diferente do DBFS. Este artigo descreve várias práticas recomendadas sobre como trabalhar com os locais externos do Unity Catalog e o DBFS.

O Databricks recomenda não usar DBFS e armazenamento de objetos em nuvem montado para a maioria dos casos de uso em espaços de trabalho do Azure Databricks habilitados para Unity Catalog. Este artigo descreve alguns cenários nos quais você deve usar o armazenamento de objetos na nuvem montado. Observe que o Databricks não recomenda o uso da raiz DBFS em conjunto com o Unity Catalog, a menos que você precise migrar arquivos ou dados armazenados lá para o Unity Catalog.

Como o DBFS é usado em espaços de trabalho habilitados para Unity Catalog?

As ações executadas contra tables no hive_metastore usam padrões de acesso a dados herdados, que podem incluir dados e armazenamento credentials gerenciados pelo DBFS. Os tables gerenciados no hive_metastore com escopo de espaço de trabalho são armazenados na raiz do DBFS.

Como o DBFS funciona no modo de acesso de usuário único?

Os clusters configurados com o modo de acesso de usuário único têm acesso total ao DBFS, incluindo todos os arquivos na raiz do DBFS e os dados montados.

Como funciona o DBFS no modo de acesso compartilhado?

O modo de acesso partilhado combina a governança de dados do Unity Catalog com as ACLs herdadas do Azure Databricks table. O acesso aos dados no hive_metastore só está disponível para usuários que tenham permissões concedidas explicitamente.

Para interagir com arquivos diretamente usando DBFS, você deve ter ANY FILE permissões concedidas. Como ANY FILE permite que os usuários ignorem ACLs de tables herdadas no hive_metastore e acessem todos os dados gerenciados pelo DBFS, o Databricks recomenda cuidado ao conceder esse privilégio.

Não use DBFS com locais externos do Unity Catalog

O Unity Catalog protege o acesso a dados em locais externos usando caminhos URI completos na nuvem para identificar concessões em diretórios de armazenamento de objetos gerenciados. As montagens DBFS usam um modelo de acesso a dados totalmente diferente que ignora totalmente o Unity Catalog. O Databricks recomenda que você não reutilize volumes de armazenamento de objetos em nuvem entre montagens DBFS e volumesexternas de UC, inclusive ao compartilhar dados entre espaços de trabalho ou contas.

Proteja seu armazenamento gerenciado pelo Unity Catalog

Unity Catalog usando locais de armazenamento gerenciados para armazenar arquivos de dados para tables gerenciados e volumes.

O Databricks recomenda o seguinte para locais de armazenamento gerenciados:

• Use novas contas de armazenamento ou buckets.
• Defina uma política de identidade personalizada para o Unity Catalog.
• Restrinja todo o acesso ao Azure Databricks gerenciado pelo Unity Catalog.
• Restrinja todo o acesso às políticas de acesso de identidade criadas para o Unity Catalog.

Adicionar dados existentes a locais externos

É possível carregar contas de armazenamento existentes no Unity Catalog usando locais externos. Para maior segurança, o Databricks recomenda apenas carregar contas de armazenamento em locais externos depois de revogar todos os outros credentials de armazenamento e padrões de acesso.

Você nunca deve carregar uma conta de armazenamento usada como uma raiz DBFS como um local externo no Unity Catalog.

As configurações de cluster são ignoradas pelo acesso ao sistema de arquivos Unity Catalog

O Unity Catalog não respeita as configurações de cluster para as configurações do sistema de arquivos. Isso significa que as configurações do sistema de arquivos Hadoop para configurar o comportamento personalizado com o armazenamento de objetos na nuvem não funcionam ao acessar dados usando o Unity Catalog.

Limitação no acesso a vários caminhos

Embora você geralmente possa usar o Unity Catalog e o DBFS juntos, os caminhos que são iguais ou compartilham uma relação pai/filho não podem ser referenciados no mesmo comando ou célula do bloco de anotações usando métodos de acesso diferentes.

Por exemplo, se um tablefoo externo for definido no hive_metastore no local a/b/c e um local externo for definido no Unity Catalog no a/b/, o código a seguir gerará um erro:

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

Este erro não surgiria se esta lógica é dividida em duas células:

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

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