Melhores práticas para o DBFS e o Catálogo 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 melhores práticas sobre como trabalhar com locais externos e DBFS do Catálogo do Unity.
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 nos quais 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 credenciais de dados e 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 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 Catálogo do Unity com ACLs de tabela herdadas do Azure Databricks. O acesso aos dados no hive_metastore
está disponível somente para usuários que têm permissões explicitamente concedidas.
Para interagir com arquivos diretamente usando o DBFS, você deve ter permissões ANY FILE
concedidas. Como ANY FILE
permite que os usuários ignorem as ACLs de tabelas herdadas em 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. A Databricks recomenda que você não reutilize volumes de armazenamento de objetos em nuvem entre montagens DBFS e volumes externos UC, inclusive ao compartilhar dados entre espaços de trabalho ou contas.
Proteger o armazenamento gerenciado pelo catálogo do Unity
Catálogo do Unity usando locais de armazenamento gerenciados para armazenar arquivos de dados para tabelas e volumes gerenciados.
A 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 à 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, a Databricks recomenda apenas carregar contas de armazenamento para 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 em torno do acesso a vários caminhos
Embora você geralmente possa usar o Catálogo do Unity e o DBFS juntos, caminhos que são iguais ou compartilham uma relação pai/filho não podem ser referenciados na mesma célula de comando ou notebook usando métodos de acesso diferentes.
Por exemplo, se uma tabela foo
externa for definida no hive_metastore
local a/b/c
e um local externo for definido no Catálogo do Unity 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")
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")