Melhores práticas para DBFS e Unity Catalog

O Unity Catalog apresenta 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 para trabalhar com locais externos do Unity Catalog e DBFS.

Databricks não recomenda o uso de DBFS e armazenamento de objeto cloud montado para a maioria dos casos de uso no workspace Databricks habilitado para Unity Catalog. Este artigo descreve alguns cenários nos quais você deve usar o armazenamento de objeto em cloud montado. Observe que o Databricks não recomenda o uso da DBFS root em conjunto com o Unity Catalog, a menos que você deva 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 em tabelas no hive_metastore usam padrões de acesso a dados herdados, que podem incluir dados e credenciais de armazenamento gerenciados por DBFS. Gerenciar tabelas no workspace-scoped hive_metastore são armazenadas no DBFS root.

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

clusters configurados com o modo de acesso de usuário único têm acesso total a DBFS, incluindo todos os arquivos em DBFS root e dados montados.

Como o DBFS funciona no modo de acesso compartilhado?

O modo de acesso compartilhado combina a governança de dados Unity Catalog com ACLs de tabela herdada do Databricks. O acesso aos dados no hive_metastore está disponível apenas para usuários com permissões explicitamente concedidas.

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

Não use DBFS com locais externos do Unity Catalog

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

Proteja seu armazenamento Unity Catalog-gerenciar

Unity Catalog usar locais de armazenamento gerenciar para armazenar arquivos de dados para tabelas e volumes gerenciar.

Databricks recomenda o seguinte para gerenciar os locais de armazenamento:

  • Usar uma nova conta de armazenamento ou buckets.

  • Defina uma política de identidade personalizada para o Unity Catalog.

  • Restringir todo o acesso a Databricks gerenciar por Unity Catalog.

  • Restringir todo o acesso às políticas de acesso à identidade criadas para o Unity Catalog.

Adicionar dados existentes a locais externos

É possível carregar a conta de armazenamento existente em Unity Catalog usando locais externos. Para maior segurança, o site Databricks recomenda carregar a conta de armazenamento em locais externos somente depois de revogar todas as outras credenciais de armazenamento e padrões de acesso.

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

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

O Unity Catalog não respeita as configurações clusters 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 armazenamento de objetos cloud não funcionam ao acessar o uso de dados do Unity Catalog.

Limitação em torno do acesso de vários caminhos

Embora geralmente você possa usar Unity Catalog e o DBFS juntos, os caminhos que são iguais ou compartilham um relacionamento pai/filho não podem ser referenciados no mesmo comando ou célula Notebook usando métodos de acesso diferentes.

Por exemplo, se uma tabela externa foo for definida em hive_metastore no local a/b/c e um local externo for definido no Unity Catalog em 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 fosse dividida em duas células:

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

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