Converter uma tabela externa em uma tabela gerenciar Unity Catalog
Visualização
Este recurso está em Visualização Pública.
Esta página descreve como usar o comando ALTER TABLE ... SET MANAGED
para converter uma tabela externa em uma tabela Unity Catalog gerenciar em Databricks.
Visão geral doSET MANAGED
Use o recurso SET MANAGED
para converter uma tabela externa em uma tabela de gerenciamento Unity Catalog no Databricks. SET MANAGED
oferece os seguintes benefícios:
- Minimizando o tempo de inatividade do leitor e do escritor.
- Tratamento de gravações concorrente durante a conversão.
- História da mesa de retenção.
- Manter as mesmas configurações de tabela, incluindo o mesmo nome, configurações, permissões e visualização.
- Capacidade de reverter uma tabela gerenciar convertida para uma tabela externa.
Pré-requisitos
Para utilizar o recurso de conversão de tabelas, é necessário ter:
-
Todos os leitores e gravadores das tabelas externas devem usar o acesso baseado em nomes. Por exemplo:
SQLSELECT * FROM catalog_name.schema_name.table_name;
O acesso baseado em caminho não é suportado e falhará após a conversão da tabela. Por exemplo:
SQLSELECT * FROM delta.`protocol://path/to/table`;
-
Você deve usar Databricks Runtime 17.0 ou acima para usar
SET MANAGED
ouUNSET MANAGED
. -
Para converter tabelas Unity Catalog com leituras Iceberg (UniForm) já habilitadas, você deve usar Databricks Runtime 17.2 ou acima para usar
TRUNCATE UNIFORM HISTORY
. -
Databricks Os leitores e escritores devem usar o site Databricks Runtime 15.4 LTS ou acima. Se seus leitores ou redatores usarem a versão 14.3 LTS ou abaixo, consulte Opção alternativa para leitores e redatores em Databricks Runtime 14.3 LTS ou abaixo.
-
Os clientes externos (nãoDatabricks) devem suportar leituras em tabelas gerenciais Unity Catalog. Consulte Ler tabelas com clientes Delta.
- Utilize o painel de percepções do Access para verificar se os leitores e escritores que acessam suas tabelas são usuários internos ( Databricks Runtime ) ou externos (non-Databricks).
Para evitar conflitos, cancele qualquer trabalho de comando OPTIMIZE
existente (líquido clustering, compactação, ZORDER
) que esteja operando na sua tabela e não programe nenhum trabalho enquanto o senhor converte as tabelas externas em tabelas gerenciáveis.
Converter de tabela externa para gerenciar
O SET MANAGED
comando está disponível em Databricks Runtime 17.0 ou acima.
O comando TRUNCATE UNIFORM HISTORY
está disponível no Databricks Runtime 17.2 ou superior.
execute um dos seguintes comandos para converter sua tabela externa Unity Catalog em uma tabela de gerenciamento Unity Catalog .
-
Para tabelas externas do Unity Catalog sem leituras do Apache Iceberg (UniForm) habilitadas:
SQLALTER TABLE catalog.schema.my_external_table SET MANAGED;
Após a conversão, você pode habilitar leituras Iceberg na sua tabela gerencial sem problemas de compatibilidade.
-
Para tabelas externas do Unity Catalog com leituras Iceberg (UniForm) já habilitadas:
SQLALTER TABLE catalog.schema.my_external_table SET MANAGED TRUNCATE UNIFORM HISTORY;
Neste caso, inclua
TRUNCATE UNIFORM HISTORY
para manter o desempenho e a compatibilidade ideais da tabela.TRUNCATE UNIFORM HISTORY
trunca apenas UniForm Iceberg história e não remove Delta história. Este comando resulta em um curto tempo de inatividade de leitura e gravação para o Iceberg após o truncamento, mas elimina a necessidade de desabilitar e reabilitar manualmente as leituras do Iceberg antes e depois da conversão.
Se o comando for interrompido durante a cópia de dados, o senhor pode reiniciá-lo e ele continuará de onde parou.
Databricks recomenda não executar vários SET MANAGED
comandos simultaneamente na mesma tabela, o que pode levar a um estado inconsistente da tabela.
Após a conversão da tabela, você deve:
- Habilite o UniForm na sua tabela caso você o tenha desabilitado anteriormente.
- Reiniciar qualquer trabalho de transmissão (leitura ou gravação) usando a tabela externa.
- Certifique-se de que seus leitores e redatores trabalhem com a tabela gerenciar.
A otimização preditiva é ativada automaticamente, exceto se você a desativou manualmente. Consulte Verificar se a otimização preditiva está habilitada.
Com a otimização preditiva habilitada, Databricks exclui automaticamente os dados no seu local externo Unity Catalog após 14 dias. Se a otimização preditiva estiver desabilitada, você poderá executar VACUUM
(requer Databricks Runtime 17.0) na tabela de gerenciamento recém-convertida. Isso instrui Databricks a limpar os dados no local original da tabela externa Unity Catalog após 14 dias:
VACUUM my_converted_table
Em alguns casos, os dados no local externo do seu Unity Catalog podem não ser excluídos após 14 dias, mesmo com a otimização preditiva ativada. Por exemplo, se sua tabela de gerenciamento Unity Catalog não for usada com frequência ou for muito pequena, a exclusão automática pode não ocorrer. Nesses casos, após 14 dias, execute manualmente VACUUM
(requer Databricks Runtime 17.0) na tabela de gerenciamento recém-convertida para remover os dados antigos.
O Databricks exclui apenas os dados no local externo. O log de transações Delta e a referência à tabela no Unity Catalog são mantidos.
Verifique a conversão
O senhor pode confirmar que sua tabela externa foi convertida em uma tabela gerenciar:
DESCRIBE EXTENDED catalog_name.schema_name.table_name
Se a tabela tiver sido convertida, o Type
abaixo de col_name
será exibido como MANAGED
abaixo de data_type
.
Opção alternativa para leitores e escritores em Databricks Runtime 14.3 LTS ou abaixo
Databricks recomenda que o senhor atualize todos os leitores e gravadores para Databricks Runtime 15.4 LTS ou superior para aproveitar as vantagens do comando SET MANAGED
, inclusive a capacidade de reter o histórico da tabela.
O senhor ainda pode usar o SET MANAGED
comando se tiver leitores ou escritores com Databricks Runtime 14.3 ou abaixo. No entanto, após a conversão para uma tabela gerenciar, o senhor não pode viajar do tempo para o commit histórico por carimbo de data/hora. Você só pode fazer isso por versão. Se o senhor reverter para uma tabela externa na janela de 14 dias, a viagem do tempo para o commit histórico feito antes da conversão será reativada.
Em todos os casos (independentemente da versão do DBR), a reversão para UC externo por carimbo de data/hora não funciona para nenhum commit feito na tabela gerenciar UC convertida, entre o momento em que o senhor terminou a conversão e antes de tentar reverter.
Para gravar em uma tabela após a conversão com Databricks Runtime 15.4 LTS ou abaixo, é necessário remover o recurso inCommitTimestamp
:
ALTER TABLE <table_name> DROP FEATURE inCommitTimestamp;
Voltar para uma mesa externa
O UNSET MANAGED
comando está disponível em Databricks Runtime 17.0 ou acima.
Depois de converter uma tabela externa em uma tabela gerenciar, o senhor pode reverter dentro de 14 dias.
Se o senhor fizer uma reversão, o commit feito no local externo entre a conversão e a reversão poderá viajar no tempo pela versão, mas não pelo carimbo de data/hora. Sete dias após a reversão, os dados no local gerenciado serão excluídos.
Para reverter para uma tabela externa, execute o seguinte comando:
ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED
Se o comando rollback for interrompido, o senhor poderá executá-lo novamente para tentar de novo, de forma semelhante ao comando SET gerenciar.
Verifique a reversão
Você pode confirmar que sua conversão foi revertida:
DESCRIBE EXTENDED catalog_name.schema_name.table_name
Se a tabela tiver sido convertida, o Type
abaixo de col_name
será exibido como EXTERNAL
abaixo de data_type
.
O senhor também deve reiniciar o Job de transmissão depois de reverter para uma tabela externa, de forma semelhante à conversão.
Tempo de inatividade e tempos de cópia de dados
O tempo de inatividade pode ocorrer quando leitores ou escritores acessam a tabela durante a conversão. No entanto, em comparação com o comando “DEEP CLONE”, o comando “ SET MANAGED
” minimiza ou elimina o tempo de inatividade para leitores e gravadores. Os usuários do Databricks Runtime 16.1 ou superior não enfrentam tempo de inatividade. Os leitores e escritores não são afetados durante a primeira etapa, quando os dados da tabela e o log delta são copiados.
Durante a segunda etapa, as gravações no local externo Unity Catalog são bloqueadas e o commit feito no local externo durante a primeira cópia de dados será transferido. Essa segunda etapa de cópia de dados acarretará tempo de inatividade para os gravadores e leitores em Databricks Runtime 15.4 LTS ou abaixo.
Depois disso, os leitores e gravadores são transferidos para o local gerenciar Unity Catalog e o novo local da tabela gerenciar é registrado em Unity Catalog. Os leitores com Databricks Runtime 16.1 ou acima terão uma experiência equivalente a nenhum tempo de inatividade.
O tempo de inatividade estimado é:
Tamanho da tabela | Tamanho recomendado do clustering | Hora da cópia dos dados | Tempo de inatividade do leitor e do escritor |
---|---|---|---|
100 GB ou menos | 32 núcleos//DBSQL pequeno | ~6min ou menos | ~1-2min ou menos |
1 TB | mídia de 64 núcleos/DBSQL | ~30 minutos | ~1-2min |
10 TB | 256 núcleos//DBSQL x-large | ~1,5 horas | ~1-5min |
As estimativas pressupõem uma taxa de transferência de 0,5-2 GB/núcleo da CPU/minuto.
O tempo de inatividade pode variar. O desempenho da conversão depende de fatores como o tamanho do arquivo, o número de arquivos e o número de commits.
Limitações conhecidas
A conversão de tabelas externas para gerenciar tem as seguintes limitações:
-
Clientes de transmissão : É necessário reiniciar qualquer tarefa de transmissão após a conversão.
-
Restrições do histórico da tabela após a reversão : Para os leitores/gravadores em Databricks Runtime 15.4 LTS ou acima, a história da tabela para o commit feito após a conversão, mas antes da reversão, será passível de viagem no tempo por versão, mas não por carimbo de data/hora.
-
Várias regiões de nuvem : Se o local de default gerenciar seu metastore, catálogo ou esquema Unity Catalog estiver em uma região de nuvem diferente do local de armazenamento da tabela externa que está sendo convertida, o senhor poderá incorrer em custos adicionais de transferência de dados entre regiões. O provedor de nuvem impõe essas cobranças fora do controle da Databricks.
Para verificar os locais do esquema, do catálogo e do metastore, o senhor pode usar o seguinte comando:
SQLDESC SCHEMA EXTENDED <catalog_name>.<schema_name>;
DESC CATALOG EXTENDED <catalog_name>;
SELECT * FROM system.information_schema.metastores;