Práticas recomendadas para o Catálogo do DBFS e do Unity

O Catálogo do Unity apresenta uma série de novas configurações e conceitos que abordam a governança de dados totalmente diferente do DBFS. Este artigo descreve várias práticas recomendadas para trabalhar com locais externos do Unity Catalog e DBFS.

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

Como o DBFS é usado em workspaces habilitados para o Catálogo do Unity?

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 gerenciadas pelo DBFS. As tabelas gerenciadas no escopo do espaço de trabalho hive_metastore 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 dados montados.

Como o DBFS funciona no modo de acesso compartilhado?

O modo de acesso compartilhado combina a governança de dados do Unity Catalog com as ACLs de tabelas legadas do Azure Databricks. O acesso aos dados no hive_metastore só está disponível para usuários que têm permissões concedidas explicitamente.

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

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

O Catálogo do Unity protege o acesso aos dados em locais externos usando caminhos de URI de nuvem completos 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 Catálogo do Unity. O Databricks recomenda que você não reutilize volumes de armazenamento de objetos de nuvem entre montagens DBFS e volumes externos de UC, inclusive ao compartilhar dados entre workspaces ou contas.

Proteja o armazenamento gerenciado pelo Unity Catalog

O Unity Catalog utiliza locais de armazenamento gerenciado para armazenar arquivos de dados para tabelas e volumes gerenciados.

O Databricks recomenda o seguinte para locais de armazenamento gerenciado:

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

Adicionar dados existentes a locais externos

É possível carregar contas de armazenamento existentes no Catálogo do Unity usando locais externos. Para maior segurança, o Databricks recomenda carregar apenas 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 Catálogo do Unity.

As configurações de cluster são ignoradas pelo acesso ao sistema de arquivos do Catálogo do Unity

O Catálogo do Unity não respeita as configurações de cluster para 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 de nuvem não funcionam ao acessar dados usando o Catálogo do Unity.

Limitação ao acesso a vários caminhos

Embora você geralmente possa usar o Unity Catalog e o DBFS juntos, caminhos que são iguais ou que compartilham uma relação de pai e filho não podem ser referenciados na mesma célula de comando ou célula de notebook usando métodos de acesso diferentes.

Por exemplo, se uma tabela externa foo for definida no hive_metastore no local a/b/c e um local externo for definido no Catálogo do Unity 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")

Esse erro não surgiria se essa 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")