Práticas recomendadas 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 Unity Catalog locais externos 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 site DBFS é usado no espaço de trabalho habilitado para o 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 dedicado (antigo modo de acesso de usuário único)?
O recurso de computação configurado com o modo de acesso dedicado tem acesso total a DBFS, incluindo todos os arquivos no DBFS root e os dados montados.
Como o DBFS funciona no modo de acesso padrão (antigo modo de acesso compartilhado)?
O modo de acesso padrão combina a governança de dados do Unity Catalog com as ACLs de tabela herdadas do 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 os arquivos diretamente usando o DBFS, o senhor deve ter as permissões ANY FILE concedidas. Como o ANY FILE permite que os usuários contornem as ACLs das tabelas legadas no hive_metastore e acessem todos os dados gerenciados pelo DBFS, o Databricks recomenda cautela ao conceder esse privilégio.
Não use o DBFS com locais externos do Unity Catalog
Unity Catalog protege o acesso a dados em locais externos usando caminhos URI completos da 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 completamente o Unity Catalog. Databricks recomenda que o senhor não reutilize volumes de armazenamento de objetos na nuvem entre montagens de DBFS e volumes externos de UC, inclusive ao compartilhar dados entre espaços de trabalho ou contas.
Proteja seu armazenamento do 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.
Adicione 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.
O senhor nunca deve carregar um armazenamento account usado como DBFS root como um local externo em Unity Catalog.
As configurações de clustering são ignoradas pelo acesso ao sistema de arquivos 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 a vários caminhos
Embora, em geral, o senhor possa usar Unity Catalog e DBFS juntos, os 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 externa foo for definida no site 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")
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")