Pular para o conteúdo principal
Última atualização em

Resolver conflitos de caminho de armazenamento

Ocorre um conflito de caminho de armazenamento quando um local externo se sobrepõe ao caminho de armazenamento default Unity Catalog de qualquer workspace em sua account Databricks . Essa sobreposição interfere no processamento interno de certos recursos Unity Catalog . Se a sua account apresentar um conflito de caminho de armazenamento, você deverá atualizar a configuração de localização externa.

Unity Catalog valida locais externos em relação a todas as configurações de armazenamento registradas em sua account Databricks , e não apenas no workspace onde o local foi criado. Consequentemente, pode surgir um conflito se vários espaços de trabalho na mesma account compartilharem o mesmo bucket.

Como o conflito acontece​

Ocorre um conflito quando você cria ou atualiza um local externo que se sobrepõe ao caminho de armazenamento default Unity Catalog de qualquer workspace em sua account. Este caminho default é configurado usando o objeto de configuração de armazenamento durante a implantação workspace clássico. Consulte Criar uma configuração de armazenamento. 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 para processamento interno e bloqueia certas funcionalidades Unity Catalog . A sobreposição de dados também enfraquece a governança de dados, pois os dados internos workspace podem ser expostos pela localização externa. Consequentemente, os caminhos de localização externos não devem se sobrepor a nenhum caminho de armazenamento default Unity Catalog do seu workspace account

No entanto, você pode criar um local externo em caminhos mais específicos dentro de um caminho de armazenamento default workspace , como o localDBFS root. Isso ocorre porque o local DBFS root é um diretório irmão do caminho de armazenamento interno do workspace e não cria um 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​

Você define um local externo em um caminho amplo (como s3://<customer-bucket>/), mas acessa dados em uma pasta irmã mais específica, como dados do Sistema de Arquivos Databricks legados 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>.

Neste caso, a atualização do caminho não é possível. Migre suas tabelas gerenciadas para um novo local.

importante

Os passos seguintes são um procedimento sugerido, não um plano de migração completo ou garantido. Eles não levam em conta todos os tipos de objeto (por exemplo, volumes ou modelos registrados) ou todos os padrões de carga de trabalho. Use o seu próprio critério para planejar e validar a migração, e trabalhe com a sua equipe de conta Databricks em quaisquer problemas específicos ao seu ambiente.

**Ação:** Conclua os passos seguintes para resolver o conflito:

  1. Identifique todas as tabelas gerenciadas afetadas. Como administrador do metastore, query system.information_schema.tables para obter uma lista completa de tabelas gerenciadas em todos os catálogos:

    SQL
    SELECT table_catalog, table_schema, table_name
    FROM system.information_schema.tables
    WHERE table_type = 'MANAGED';

  2. Escolha um novo subdiretório raiz do metastore. Selecione um caminho que não seja principal de quaisquer caminhos de armazenamento internos existentes (caminhos contendo __unity_storage). Por exemplo: s3://<your-bucket>/uc-root/.

  3. Atualize o local de armazenamento gerenciado do metastore. Consulte Adicionar armazenamento gerenciado a um metastore existente. Novas tabelas gerenciadas são armazenadas no novo local após esta atualização. As tabelas gerenciadas existentes não são movidas automaticamente.

  4. Faça backup das concessões de privilégios em cada tabela afetada antes de migrar. Execute isso como o proprietário da tabela ou um administrador do metastore para que todas as concessões sejam visíveis:

    SQL
    SHOW GRANTS ON TABLE <catalog>.<schema>.<table_name>;

  5. Pare todas as cargas de trabalho que leem ou escrevem nas tabelas afetadas, e certifique-se de que nenhuma carga de trabalho ou administrador modifique concessões nelas pela duração da migração. Gravações ou alterações de concessão que ocorrem depois que você clona as tabelas não são capturadas e podem resultar em perda de dados.

  6. Recrie cada tabela afetada no novo local de armazenamento gerenciado. Use DEEP CLONE para preservar o histórico da tabela Delta Lake:

    SQL
    -- Recommended: deep clone preserves Delta history
    CREATE TABLE <catalog>.<schema>.<table_name>
    DEEP CLONE <old_catalog>.<schema>.<table_name>;

  7. Reaplique todas as concessões às tabelas recriadas:

    SQL
    GRANT <privilege> ON TABLE <catalog>.<schema>.<table_name> TO <principal>;

  8. Atualize todas as cargas de trabalho downstream (jobs, notebooks, painéis) para fazer referência às tabelas recriadas. Use Linhagem de dados para identificar cargas de trabalho dependentes antes de fazer a transição. Retome as cargas de trabalho somente depois que elas apontarem para as tabelas recriadas.

  9. Verifique as tabelas recriadas e, em seguida, descarte as tabelas antigas.

  10. Atualize a localização externa para um caminho não conflitante mais específico, conforme descrito em Cenário A.

Nesta página