Resolver conflitos de caminho de armazenamento

Um conflito de caminho de armazenamento ocorre quando um local externo se sobrepõe ao caminho interno que o Databricks utiliza para o seu workspace's default Unity Catalog armazenamento. Essa sobreposição interfere na forma como o Unity Catalog utiliza o armazenamento default do workspace para processamento interno em determinados recursos e requer que você atualize sua configuração de localização externa.

Como o conflito acontece

Um conflito ocorre quando você cria um local externo com um caminho que se sobrepõe ao caminho de armazenamento default Unity Catalog do seu workspace. O armazenamento workspace default é especificado no momento da criação do workspace, quando você cria o objeto de configuração de armazenamento seguindo o guia de criação workspace. Por exemplo:

• Caminho padrão de armazenamento workspace utilizado para criar workspace: s3://<your-bucket>/<region>/
• Localização externa sobreposta (conflito): s3://<your-bucket>/

Essa sobreposição impede que Unity Catalog utilize o local de armazenamento workspace default para processamento interno, e certas funcionalidades em Unity Catalog são bloqueadas. Isso também enfraquece a governança de dados, pois a localização externa expõe os dados internos da workspace dentro da localização. Como resultado, os caminhos de localização externos não devem se sobrepor aos caminhos de armazenamento workspace default Unity Catalog . A criação de um local externo em caminhos mais específicos em workspace default , como o localDBFS root, continua a ser permitida, porque o local DBFS root é um irmão do caminho de armazenamento interno workspace e não causa conflito.

Identifique seu cenário

Verifique seus locais externos no Catalog Explorer na interface do usuário do Databricks para verificar se o caminho do local externo inclui ou é mais amplo do que o caminho de armazenamento default do seu workspace.
Exemplo:

• Localização externa: s3://<your-bucket>/
• caminho de armazenamento do default do espaço de trabalho: s3://<your-bucket>/<region>/

Considere os cenários a seguir para ajudá-lo a determinar como proceder.

Cenário A: atualizações de localização externa sem mover dados

Defina um local externo em um caminho amplo (como s3://<customer-bucket>/), mas acesse os dados em uma pasta irmã mais específica, como dados legados do Databricks Filesystem armazenados em s3://<customer-bucket>/<region>/<workspace-id>/.

Ação: (Recomendado) Atualize sua localização externa existente para o caminho mais específico. Essa alteração resolve o conflito e continua permitindo o acesso a todos os dados. Por exemplo, você atualizaria o caminho de s3://<your-bucket>/ para s3://<your-bucket>/<region>/<workspace-id>/. Isso também evita o vazamento acidental de dados internos d workspace.

Cenário B: gerenciar tabelas armazenadas no local do bucket raiz

Defina um local externo na raiz do seu bucket (por exemplo, s3://<your-bucket>/) e crie tabelas gerenciar diretamente abaixo dele, como s3://<your-bucket>/__unity_storage/catalogs/<catalog_id>/tables/<table_id>.

Nesse caso, atualizar o caminho não é possível e você deve mover os dados.

Ação: Abra um ticket de suporte com o Suporte da Databricks. A equipe de suporte pode auxiliá-lo a migrar seus dados gerenciados para um novo local e restaurar seu metastore para um estado sem conflitos.