Converta tabelas externas ou estrangeiras do Delta Lake em tabelas gerenciadas do Unity Catalog

info

Pré-lançamento público

A conversão de uma tabela externa em uma tabela gerenciada está disponível em geral.

A conversão de uma tabela externa para uma tabela gerenciada está em Prévia Pública. Somente tabelas externas federadas usando Hive metastore e Federação do Glue são compatíveis.

Para converter uma tabela Delta Lake externa ou estrangeira para uma tabela gerenciada do Unity Catalog no Databricks, use o comando ALTER TABLE ... SET MANAGED ou, para tabelas externas, o Catalog Explorer. A conversão mantém as configurações da tabela, incluindo nome, configurações, permissões e views, e mantém o histórico da tabela.

Para conversões de tabelas externas, SET MANAGED também:

• Minimiza o tempo de inatividade do leitor e do gravador.
• Lida com gravações concorrentes durante a conversão.
• Permite reverter uma tabela gerenciada convertida para uma tabela externa.
• Redireciona leituras e gravações baseadas em caminho para permitir que o código legado funcione após a conversão.

Embora você também possa usar CREATE TABLE AS SELECT (CTAS) para converter uma tabela externa, o Databricks recomenda SET MANAGED para estes benefícios.

Para conversões de tabelas externas, o Databricks define a otimização preditiva na tabela convertida para INHERIT em vez de habilitá-la automaticamente. Consulte Tabelas externas usando SQL.

Para converter tabelas estrangeiras em tabelas externas, consulte Converter uma tabela estrangeira em uma tabela externa do Unity Catalog.

Pré-requisitos

Tabelas externas

A conversão de tabelas externas em tabelas gerenciadas tem os seguintes pré-requisitos:

• Formato : A tabela deve usar o formato Delta Lake.

• Runtime : Você deve usar o Databricks Runtime 17.3 LTS ou acima ou compute serverless para usar SET MANAGED, UNSET MANAGED ou TRUNCATE UNIFORM HISTORY.

• Leitores e gravadores : os leitores e gravadores do Databricks para as suas tabelas de origem devem usar o Databricks Runtime 15.4 LTS ou acima. Se seus leitores ou gravadores usarem 14.3 LTS ou abaixo, consulte Leitores e gravadores legados.

• Clientes externos: Clientes externos (não-Databricks) devem dar suporte às leituras para tabelas gerenciadas do Unity Catalog. Consulte Acessar tabelas com clientes Delta.

  • Use o dashboard de percepções de acesso para ver se os leitores e gravadores que acessam suas tabelas são do Databricks Runtime ou externos não-Databricks.

• Compatibilidade de recursos: Se sua tabela minReaderVersion=2 minWriterVersion=7tiver,tableFeatures={..., columnMapping} e, o SET MANAGED comando falha com um DELTA_TRUNCATED_TRANSACTION_LOG erro. Verifique se sua tabela possui essas propriedades usando DESCRIBE DETAIL. Consulte compatibilidade e protocolos de recursos do Delta Lake.

Após a conversão, leituras e gravações baseadas em caminho são automaticamente redirecionadas para o novo local gerenciado com uma ligeira sobrecarga de desempenho. A Databricks recomenda migrar todo o acesso baseado em caminho para acesso baseado em nome para evitar a sobrecarga de desempenho. Consulte redirecionamento baseado em caminho.

importante

Para evitar conflitos, cancele quaisquer Jobs de comando OPTIMIZE existentes (clustering líquido, compactação, ZORDER) operando em sua tabela externa e não programe nenhum Job enquanto você converte suas tabelas externas em tabelas gerenciadas.

Tabelas externas

info

Pré-lançamento público

A conversão de uma tabela externa para uma tabela gerenciada está em Prévia Pública.

A conversão de tabelas externas para tabelas gerenciadas tem os seguintes pré-requisitos:

• Formato dos dados: A tabela estrangeira deve usar o formato Delta Lake. Para realizar uma conversão única para Parquet, consulte Converter para Delta Lake.
• Runtime : Databricks Runtime 17.3 ou acima.
• Tipo de tabela : O tipo de tabela do Hive metastore (HMS) deve ser uma tabela externa do HMS. O comando falha se a tabela for uma tabela HMS gerenciada.
• Permissões : permissões OWNER ou MANAGE na tabela e permissão CREATE em EXTERNAL LOCATION.

Tempo de inatividade e tempos de cópia de dados

O comando SET MANAGED minimiza ou elimina o tempo de inatividade em comparação com abordagens alternativas, como DEEP CLONE.

Tabelas externas

O processo de conversão para tabelas externas usa uma abordagem de duas etapas:

1. **Cópia inicial de dados (sem tempo de inatividade):** O comando copia dados da tabela e o log de transações Delta do local externo para o local gerenciado. Leitores e gravadores ativos para a tabela externa são executados sem interrupção.
2. Mudar para local gerenciado (breve tempo de inatividade): Commits feitos no local externo durante o primeiro passo são movidos para o local gerenciado, e os metadados da tabela são atualizados para registrar o novo local gerenciado. Durante este passo, todas as escritas no local externo são temporariamente bloqueadas, resultando em tempo de inatividade do escritor. Leitores em Databricks Runtime 16.4 LTS ou acima não experimentam tempo de inatividade, mas leitores em Databricks Runtime 15.4 LTS e abaixo podem experimentar tempo de inatividade.

A tabela a seguir mostra o tempo de inatividade estimado com base no tamanho da tabela de origem e em uma taxa de transferência estimada de 0,5-2 GB/núcleo de CPU/minuto:

Tamanho da tabela	Tamanho de cluster recomendado	Tempo estimado de cópia de dados	Tempo de inatividade estimado de leitor e gravador
100 GB ou menos	SQL warehouse X-Large de 32 núcleos	~6 minutos ou menos	~1-2 minutos ou menos
1 TB	SQL warehouse de 64 núcleos / 2X-Large	~30 min	~1-2 min
10 TB	SQL warehouse de 256 núcleos / 4X-Large	Aprox. 1,5 horas	~1-5 min

nota

O tempo de inatividade pode variar com base em fatores como tamanho do arquivo, número de arquivos e número de commits.

Tabelas externas

O tempo de inatividade da conversão de tabelas externas depende se você usar MOVE ou COPY:

• Para MOVE, pode ocorrer tempo de inatividade conforme descrito para tabelas externas. Consulte Tabelas externas.
• Para COPY, você é responsável por gerenciar o tempo de inatividade porque o processo de conversão copia a tabela de origem para o local de armazenamento gerenciado, criando duas cópias separadas dos dados. Você é responsável por desabilitar leituras e gravações na tabela de origem no catálogo externo e migrar cargas de trabalho para usar a nova tabela gerenciada.

Converter para uma tabela gerenciada

Converta uma tabela externa usando o Catalog Explorer ou SQL, ou converta uma tabela externa usando SQL.

Tabelas externas usando o Explorador de Catálogos (Beta)

info

Beta

A conversão de tabelas externas em gerenciadas usando o Catalog Explorer está em Beta.

Usando o Catalog Explorer, você pode converter uma ou mais tabelas externas em um esquema por vez.

1. Vá para a tabela ou o esquema que você deseja converter no Catalog Explorer.

2. Em Sobre esta tabela (página de detalhes da tabela) ou Sobre este esquema (página de detalhes do esquema), clique em Explorar otimizações .

3. Em Por que migrar para tabelas gerenciadas do Unity Catalog? caixa de diálogo, clique em **Continuar**.

   

4. Selecione as tabelas externas que você deseja converter. Se você abriu a caixa de diálogo a partir de uma página de detalhes da tabela, o Catalog Explorer pré-seleciona sua tabela. Use a barra de pesquisa para encontrar tabelas adicionais. Tabelas gerenciadas não são selecionáveis.

   

5. Clique em Criar notebook de conversão .

6. Opcionalmente, insira um nome para o Notebook. Por default, isso salva o Notebook na sua pasta home. Clique em **Navegar** para salvá-lo em um local diferente.

   

7. No notebook, analise as melhores práticas e verifique se você atende a todos os pré-requisitos.

8. Execute a célula SET MANAGED Queries .

Após a execução da célula, o tipo de tabela é exibido como **GERENCIADA** em vez de **EXTERNA** no Catalog Explorer. Refresh a página se o status não atualizar imediatamente.

Tabelas externas usando SQL

Dependendo se sua tabela externa tem leituras Apache Iceberg (UniForm) habilitadas, execute um dos seguintes comandos. Para verificar se sua tabela tem leituras Iceberg habilitadas, consulte Verifique se as leituras Iceberg estão habilitadas.

• Para tabelas externas do Unity Catalog sem leituras do Iceberg ativadas, execute o seguinte comando:

  SQL

  ALTER TABLE catalog.schema.my_external_table SET MANAGED;

  Após a conversão, você pode habilitar leituras do Iceberg em sua tabela gerenciada sem preocupações de compatibilidade.

• Para tabelas externas do Unity Catalog com leituras do Iceberg já habilitadas, execute o seguinte comando:

  SQL

  ALTER TABLE catalog.schema.my_external_table SET MANAGED TRUNCATE UNIFORM HISTORY;

  Inclua TRUNCATE UNIFORM HISTORY para manter o desempenho e a compatibilidade ideais da tabela. TRUNCATE UNIFORM HISTORY trunca apenas a história do UniForm Iceberg e não remove a história Delta. Este comando resulta em um curto tempo de inatividade de leitura e gravação para o Iceberg após o truncamento.

Após a conversão da tabela, as transmissões de leitura e gravação existentes falham. Reinicie as transmissões com as mesmas configurações para usar automaticamente o redirecionamento baseado em caminho. Verifique se seus leitores e gravadores funcionam com a tabela gerenciada. Consulte comportamento de transmissão.

A Otimização Preditiva é ativada automaticamente após a conversão, a menos que você a tenha desativado manualmente. Consulte Verificar se a Otimização Preditiva está habilitada.

O Databricks retém os dados em seu local externo do Unity Catalog por 14 dias para permitir a reversão. Consulte Reverter uma conversão de tabela gerenciada. Após 14 dias, com a otimização preditiva habilitada, o Databricks exclui automaticamente esses dados para recuperar o armazenamento e economizar custos. Se você desativar a otimização preditiva, execute VACUUM (requer Databricks Runtime 17.3 LTS ou superior ou compute serverless) na tabela gerenciada recém-convertida após 14 dias para recuperar o armazenamento por conta própria.

SQL

VACUUM my_converted_table

nota

Mesmo com a otimização preditiva ativada, os dados no seu local externo do Unity Catalog podem não ser excluídos após 14 dias. Por exemplo, isso pode ocorrer quando a tabela gerenciada é pouco usada ou pequena. Se os dados anteriores permanecerem, execute VACUUM manualmente para removê-lo.

O Databricks exclui apenas os dados no local externo. O log de transações do Delta e a referência à tabela no Unity Catalog são mantidos.

Tabelas externas usando SQL

info

Pré-lançamento público

A conversão de uma tabela externa para uma tabela gerenciada está em Prévia Pública.

Para converter sua tabela externa do Unity Catalog para ser gerenciada pelo Unity Catalog, execute o seguinte comando:

SQL

ALTER TABLE source_table SET MANAGED {MOVE | COPY}

• source_table

  Uma tabela externa existente federada no Unity Catalog.

• MOVE

  Converte a tabela em gerenciada e desabilita o acesso à tabela de origem no catálogo externo.

  • O acesso através do catálogo externo ou acesso baseado em caminho falha após a conversão da tabela. Todos os leitores e gravadores da tabela devem usar o namespace do Unity Catalog para acesso. Por exemplo:

    SQL

    SELECT * FROM catalog_name.schema_name.table_name;

  • O acesso baseado em caminho não é compatível e falha depois que a tabela é convertida. Por exemplo:

    SQL

    SELECT * FROM delta.`protocol://path/to/table`;

  • A versão do leitor/gravador e os requisitos de compatibilidade do cliente são os mesmos descritos em Pré-requisitos e Leitores e gravadores legados.

  • A otimização preditiva está definida como INHERIT, a menos que você a tenha configurado manualmente. Para verificar se a otimização preditiva está habilitada, consulte Verificar se a otimização preditiva está habilitada.

• COPY

  Converte a tabela para gerenciada sem modificar ou desabilitar o acesso à tabela de origem no catálogo externo.

  • Durante a conversão para gerenciada, o processo de conversão copia dados da tabela de origem para o local de armazenamento gerenciado definido para a tabela externa, criando duas cópias separadas: a nova tabela gerenciada e a tabela de origem no catálogo externo.
  • Diferente de MOVE, onde leituras e gravações falham, ao usar COPY, você é responsável por desabilitar corretamente leituras e gravações para a tabela de origem no catálogo externo e garantir que as cargas de trabalho tenham migrado para o novo catálogo.

Após a conversão da tabela, você deve reiniciar quaisquer jobs de transmissão (de leitura ou gravação) que usam a tabela externa e verificar se seus leitores e gravadores funcionam com a tabela gerenciada.

Antes da conversão, se você descartar a tabela de origem no catálogo externo, o Unity Catalog também descartará a tabela estrangeira. Depois de converter a tabela para gerenciada, descartar a tabela de origem no catálogo externo não afeta a tabela gerenciada do Unity Catalog.

Se o comando for interrompido durante a cópia dos dados, reinicie-o. O comando retoma de onde parou.

atenção

A Databricks recomenda que você evite executar vários comandos SET MANAGED concomitantemente na mesma tabela, o que pode levar a um estado de tabela inconsistente.

Verificar conversão

Para verificar se a sua tabela foi convertida para uma tabela gerenciada com sucesso, verifique se a tabela Type é MANAGED. Você pode fazer uma das seguintes opções:

• Abra uma nova tab e vá para o Catalog Explorer. Na tab **Detalhes**, em **Sobre esta tabela**, o **Tipo** da tabela aparece como **Gerenciado**.

• Verifique a tabela Type executando o seguinte comando SQL:

  SQL

  DESCRIBE EXTENDED catalog_name.schema_name.table_name

  Para verificar várias tabelas de uma vez ou criar um script de verificação, consulte information_schema.tables:

  SQL

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';

Leitores e gravadores legados

O Databricks recomenda atualizar todos os leitores e gravadores para o Databricks Runtime 15.4 LTS ou superior para usar todos os recursos de SET MANAGED, incluindo a retenção do histórico da tabela.

Ainda é possível usar SET MANAGED se houver leitores ou gravadores no Databricks Runtime 15.3 ou inferior. No entanto, após a conversão para uma tabela gerenciada, a viagem do tempo para commits históricos é possível apenas por versão, e não por carimbo de data/hora.

Se você reverter para uma tabela externa em até 14 dias, a viagem do tempo para commits históricos feitos antes da conversão será reativada. A viagem do tempo usando carimbos de data/hora não é compatível para commits feitos na tabela gerenciada convertida entre a conversão e a reversão. Consulte Reverter uma conversão de tabela gerenciada.

Gravar em uma tabela após a conversão com o Databricks Runtime 15.3 ou abaixo exige a exclusão do recurso inCommitTimestamp:

SQL

ALTER TABLE <table_name> DROP FEATURE inCommitTimestamp;

Redirecionamento baseado em caminho

info

Visualização

O redirecionamento baseado em caminho está em Pré-lançamento público. Para se inscrever, preencha este formulário.

No Databricks Runtime 18.1 e acima, depois que você converte uma tabela externa em uma tabela gerenciada do Unity Catalog, as leituras e gravações baseadas em caminho para o local externo anterior redirecionam automaticamente para o novo local gerenciado. Uma leitura baseada em caminho é um código como SELECT * FROM delta.`/path/to/my_table. O redirecionamento baseado em caminho reduz o tempo e o esforço necessários para migrar para tabelas gerenciadas, permitindo que o código legado que usa caminhos de armazenamento continue funcionando sem refatoração.

As conversões de tabelas externas não redirecionam o acesso baseado em caminho.

Para casos de uso de baixa latência, o Databricks recomenda que você migre o acesso baseado em caminho para o acesso baseado em nome. O redirecionamento baseado em caminho adiciona várias centenas de milissegundos de sobrecarga para cada leitura ou gravação baseada em caminho e exige que os logs Delta antigos permaneçam ativos em seu local externo do Unity Catalog. As leituras e gravações baseadas em nome não têm sobrecarga adicional de desempenho. Consulte Migrar código baseado em caminho para baseado em nome.

Migrar código baseado em caminho para baseado em nome

Se você decidir não usar o redirecionamento baseado em caminho, você pode migrar o código legado. Para migrar, substitua referências baseadas em caminho por referências baseadas em nome.

O exemplo de código a seguir contém uma referência de tabela baseada em caminho a arquivos:

SQL

SELECT * FROM delta.`/path/to/customers_table`;

Substitua a referência baseada em caminho por uma referência baseada em nome para uma tabela externa, como no código a seguir:

SQL

SELECT * FROM catalog_name.schema_name.customers_table;

Comportamento da Transmissão

A transmissão com redirecionamento baseado em caminho suporta leituras e gravações nas seguintes versões do Databricks Runtime:

• As leituras têm suporte no Databricks Runtime 18.1 e acima.
• Gravações têm suporte no Databricks Runtime 18.2 e acima.

Após a conversão, você deve reiniciar todos os jobs de transmissão para evitar leituras ou escritas no local da tabela anterior.

Leituras e gravações de transmissão baseadas em caminho falham e param no próximo ponto de verificação com uma mensagem de migração:

• Para leituras, a transmissão gera um erro: DELTA_STREAMING_INTERRUPTED_BY_MANAGED_TABLE_CONVERSION: The table at <path> has been converted to a Unity Catalog managed table. The stream has been stopped to ensure data consistency. Restart the stream and it will automatically resume from the last committed offset using the converted table.
• Para gravações, o primeiro micro-lote após a conversão gera um erro: Operation not allowed: STREAMING WRITE cannot be performed on a table with redirect feature. The no redirect rules are not satisfied [].

Para resolver erros, reinicie as transmissões com as mesmas configurações. O acesso baseado em caminho redireciona automaticamente para a tabela gerenciada.

Para limitações de redirecionamento baseado em caminho, consulte Limitações.

Solução de problemas de falhas de conversão

Esta seção descreve como resolver problemas comuns ao converter tabelas externas em tabelas gerenciadas pelo Unity Catalog usando SET MANAGED.

VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED

Se a conversão falhar, sempre tente novamente usando a mesma versão do Databricks Runtime. Metadados podem ser serializados de forma diferente entre versões, o que causa uma falha VERSIONED_CLONE_INTERNAL_ERROR.EXISTING_FILE_VALIDATION_FAILED se você tentar novamente uma conversão em uma versão diferente do Databricks Runtime.

Encerramento do cluster durante a conversão

Se o cluster for desligado durante a conversão, o comando pode falhar com DELTA_ALTER_TABLE_SET_MANAGED_INTERNAL_ERROR. Repita o comando para retomar a conversão.

Tabela externa corrompida

Se a tabela externa já estiver corrompida (por exemplo, estado de tabela inválido), a conversão pode falhar com erros como DELTA_TRUNCATED_TRANSACTION_LOG, DELTA_TXN_LOG_FAILED_INTEGRITY ou DELTA_STATE_RECOVER_ERRORS. Antes de tentar a conversão, verifique se você pode executar operações básicas na tabela externa, como DESCRIBE DETAIL.

Falha na validação de arquivo

O comando SET MANAGED valida que copiou todos os arquivos no snapshot mais recente da tabela para o novo local da tabela gerenciada. Se algum arquivo estiver faltando, o comando falha com um erro de DELTA_ALTER_TABLE_SET_MANAGED_FAILED.FILE_VALIDATION_FAILED.

Para resolver este problema:

1. Verifique seus logs do driver Spark para identificar quais arquivos não puderam ser migrados.
2. Verifique se esses arquivos existem no local da tabela externa de origem e estão acessíveis.
3. Tentar novamente o comando ALTER TABLE ... SET MANAGED.

Se o problema persistir, entre em contato com o suporte da Databricks.

Reverter uma conversão de tabela gerenciada

importante

Comandos de rollback exigem compute serverless ou Databricks Runtime 17.3 LTS e superior.

Tabela externa

Após converter uma tabela externa em uma tabela gerenciada, você pode reverter dentro de 14 dias usando o comando UNSET MANAGED. Isso atualiza os metadados da tabela para apontar de volta para o local externo original. Databricks preserva todas as gravações feitas no local gerenciado após a conversão.

Para reverter para uma tabela externa, execute o seguinte comando:

SQL

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED;

Tenha as seguintes informações em mente:

• Se o comando de rollback for interrompido ou falhar, execute-o novamente para tentar de novo.
• Você deve reiniciar seus Jobs de transmissão após reverter, semelhante à conversão.
• Commits feitos no local gerenciado entre a conversão e a reversão permitem a viagem do tempo por versão, mas não por carimbo de data/hora.
• Sete dias após o rollback, o Databricks excluirá automaticamente os dados no local gerenciado.

Tabela estrangeira: MOVE

atenção

VOCÊ DEVE EXECUTAR UNSET MANAGED antes de descartar a tabela gerenciada. Descartar a tabela sem executar UNSET MANAGED primeiro pode resultar em perda de dados ou inconsistências.

É possível reverter a migração da tabela e recuperar o acesso à tabela de origem no catálogo externo, usando o comando UNSET MANAGED. A reversão exige dois passos: primeiro, é necessário reverter a tabela para uma tabela externa e, em seguida, descartar a tabela externa para refederar a tabela como uma tabela estrangeira.

1. Para reverter para uma tabela externa, execute o seguinte comando:

SQL

ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED

1. Para refederar a tabela para uma tabela externa, descarte a tabela externa com o seguinte comando:

SQL

DROP TABLE catalog.schema.my_managed_table

A tabela externa está disponível após a próxima sincronização do catálogo.

Tenha as seguintes informações em mente:

• Para os commits que você fez no local externo entre a conversão e o rollback, você pode fazer viagem do tempo por versão, mas não por carimbo de data/hora.
• Sete dias após o rollback, o Databricks exclui os dados no local gerenciado.

Tabela estrangeira: COPY

Para reverter a migração da tabela, você não precisa executar o comando UNSET MANAGED porque a tabela de origem no catálogo externo não foi modificada. Descarte a tabela gerenciada e o Databricks a refedera como uma tabela estrangeira após a próxima sincronização do catálogo.

Verificar rollback

Verifique os rollbacks de forma diferente para tabelas externas e foreign.

Tabelas externas

Para verificar se sua tabela gerenciada foi revertida para uma tabela externa com sucesso, verifique se a tabela Type é EXTERNAL. Você pode fazer qualquer uma das seguintes opções:

• Abra uma nova tab e vá para o Catalog Explorer. Na tab **Detalhes**, em **Sobre esta tabela**, o **Tipo** da tabela é exibido como **Externa**.

• Verifique a tabela Type executando o seguinte comando SQL:

  SQL

  DESCRIBE EXTENDED catalog_name.schema_name.table_name

  Para verificar várias tabelas de uma vez ou criar um script de verificação, consulte information_schema.tables:

  SQL

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';

Tabelas externas

Para verificar se sua tabela gerenciada foi revertida para uma tabela externa com sucesso, verifique se a tabela Type é FOREIGN. Você pode fazer uma das seguintes opções:

• Abra uma nova tab e vá para o Catalog Explorer. Na tab Detalhes , em Sobre esta tabela , o Tipo de tabela é exibido como Foreign.

• Verifique o tipo da tabela executando o seguinte comando SQL:

  SQL

  SELECT table_type FROM system.information_schema.tables
  WHERE table_catalog = 'catalog_name' AND table_schema = 'schema_name' AND table_name = 'table_name';

  A coluna table_type é exibida como FOREIGN.

nota

Não use DESCRIBE EXTENDED para verificar conversões ou reversões de tabelas externas. A federação usa o comportamento do catálogo hive_metastore para este comando, então ela mostra a tabela Type como EXTERNAL, independentemente do estado real da tabela.

Tópicos avançados

Esta seção contém tópicos avançados para converter tabelas estrangeiras e externas em tabelas gerenciadas.

Converter no nível de esquema ou catálogo

Você tem as duas opções a seguir para automatizar a conversão de tabelas no nível do esquema ou do catálogo:

• Percorra as suas tabelas em seus esquemas para converter cada tabela individualmente.

• Use o projeto discoverx labs para converter esquemas ou catálogos inteiros de uma só vez:

  Python

  df = (dx.from_tables("prod.*.*")
  .with_sql("ALTER TABLE {full_table_name} SET MANAGED;")
  .apply())

Consulte Databricks Labs e discoverx.

Criar tabelas em um catálogo externo

Você pode criar tabelas externas ou gerenciadas em um catálogo estrangeiro. O comportamento depende da configuração do esquema:

• Para esquemas Glue ou eHMS , ou para esquemas com um local gerenciado definido no Unity Catalog : Se você executar CREATE TABLE foreign_catalog.schema.table, isso criará uma tabela gerenciada ou externa do Unity Catalog. O Databricks não envia nem sincroniza a tabela para o catálogo externo.
• Para esquemas de conexões internas do Hive metastore : se você tentar criar uma tabela em um esquema externo, ela ainda criará uma tabela externa e também criará uma tabela em hive_metastore.
• Para o Hive metastore de workspace legado : como ele tem federação de leitura e gravação, se você criar uma tabela no catálogo externo, ele também criará uma tabela no Hive metastore interno.

Tabelas externas baseadas em DBFS

Ao converter uma tabela com suporte DBFS, o Databricks armazena o mapeamento atual do caminho DBFS como o local do caminho de cloud da tabela externa.

Limitações

A conversão de tabelas externas ou estrangeiras em tabelas gerenciadas tem as seguintes limitações:

• O histórico da tabela para commits feitos após a conversão, mas antes da reversão, permite a viagem do tempo por versão, mas não por carimbo de data/hora.

• O OpenSharing não é totalmente compatível com o comando SET MANAGED. O Open OpenSharing é compatível, mas o compartilhamento Databricks-to-Databricks não atualiza automaticamente o local gerenciado da tabela do destinatário. O destinatário continua a ler do local antigo até que você compartilhe a tabela novamente. Para compartilhar a tabela novamente, execute os seguintes comandos:

  SQL

  ALTER SHARE <share_name> REMOVE TABLE <table_name>;
  ALTER SHARE <share_name> ADD TABLE <table_name> AS <table_share_name> WITH HISTORY;

• Se o local gerenciado default do seu metastore, catálogo ou esquema do Unity Catalog estiver em uma região de cloud diferente do local de armazenamento da tabela de origem, você pode incorrer em custos adicionais de transferência de dados entre regiões do seu provedor de cloud.

  Para verificar a localização do seu esquema e catálogo, execute os seguintes comandos:

  SQL

  DESC SCHEMA EXTENDED <catalog_name>.<schema_name>;
  
  DESC CATALOG EXTENDED <catalog_name>;

  Para verificar a localização do seu metastore, execute um dos seguintes comandos:

  SQL

  DESC METASTORE; -- Option 1
  SELECT * FROM system.information_schema.metastores; -- Option 2

Limitações de redirecionamento baseado em caminho:

• Você deve reiniciar quaisquer jobs de transmissão após a conversão. Consulte Comportamento de transmissão.
• O redirecionamento baseado em caminho tem apenas compatibilidade com versões anteriores para o processo de migração e não habilita novo acesso baseado em caminho a tabelas gerenciadas do Unity Catalog.

Limitações de tabela externa:

• Somente tabelas externas federadas usando Hive metastore e federação Glue são compatíveis com a conversão.