Melhores práticas 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 locais externos do Unity Catalog e DBFS.

O Databricks recomenda não usar DBFS e armazenamento de objetos na 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 em relação a tabelas usam hive_metastore padrões de acesso a dados herdados, que podem incluir credenciais de dados e armazenamento gerenciadas pelo DBFS. As tabelas gerenciadas no escopo hive_metastore do espaço de trabalho são armazenadas 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 compartilhado combina a governança de dados do Catálogo Unity com ACLs de tabela herdada do Azure Databricks. 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 tabelas herdadas e acessem todos os dados gerenciados pelo DBFS, o hive_metastore Databricks recomenda cuidado ao conceder esse privilégio.

Não use DBFS com locais externos do Catálogo Unity

O Unity Catalog protege o acesso aos dados em locais externos usando caminhos de URI na nuvem completa 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 na nuvem entre montagens DBFS e volumes externos de UC, inclusive ao compartilhar dados entre espaços de trabalho ou contas.

Proteja seu armazenamento gerenciado pelo catálogo Unity

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

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 todas as outras credenciais 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 do 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 em torno do 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 uma tabela foo externa for definida no hive_metastore local a/b/c at e um local externo for definido no Unity Catalog on 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")