Partilhar via

Soltar ou substituir uma tabela Delta

  • Artigo

O Azure Databricks dá suporte a comandos DDL padrão do SQL para descartar e substituir tabelas registradas no Catálogo Unity ou no metastore do Hive. Este artigo fornece exemplos de eliminação e substituição de tabelas Delta e recomendações de sintaxe, dependendo do ambiente configurado e do resultado desejado.

Quando largar uma mesa

Você deve usar DROP TABLE para remover uma tabela do metastore quando quiser excluir permanentemente a tabela e não tiver intenção de criar uma nova tabela no mesmo local. Por exemplo:

DROP TABLE table_name

DROP TABLE tem semânticas diferentes, dependendo do tipo de tabela e se a tabela está registrada no Unity Catalog ou no metastore herdado do Hive.

Tipo de tabela Metastore Comportamento
Não gerido Catálogo do Unity A tabela é removida do metastore e os dados subjacentes são marcados para exclusão. Você pode UNDROP obter dados em tabelas gerenciadas do Unity Catalog por 7 dias.
Não gerido Ramo de registo A tabela é removida do metastore e os dados subjacentes são excluídos.
Externa Catálogo do Unity A tabela é removida do metastore, mas os dados subjacentes permanecem. Os privilégios de acesso URI agora são governados pelo local externo que contém os dados.
Externa Ramo de registo A tabela é removida do metastore, mas os dados subjacentes permanecem. Todos os privilégios de acesso URI permanecem inalterados.

DROP TABLE semântica difere entre tipos de tabela, e Unity Catalog mantém um histórico de tabelas Delta usando um ID de tabela interna. No entanto, todas as tabelas compartilham o resultado comum de que, após a conclusão da operação, o nome da tabela registrada anteriormente não tem mais um link ativo para dados e histórico de tabelas do metastore.

Consulte DROP TABLE.

Nota

O Databricks não recomenda o padrão de descartar e, em seguida, recriar uma tabela usando o mesmo nome para pipelines ou sistemas de produção, pois esse padrão pode resultar em resultados inesperados para operações simultâneas. Consulte Substituir dados por operações simultâneas.

Quando substituir uma tabela

O Databricks recomenda o uso CREATE OR REPLACE TABLE de instruções para casos de uso em que você deseja substituir totalmente a tabela de destino por novos dados. Por exemplo, para substituir uma tabela Delta por todos os dados de um diretório Parquet, você pode executar o seguinte comando:

CREATE OR REPLACE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`

CREATE OR REPLACE TABLE tem a mesma semântica, independentemente do tipo de tabela ou metastore em uso. As seguintes são vantagens importantes de CREATE OR REPLACE TABLE:

  • O conteúdo da tabela é substituído, mas a identidade da tabela é mantida.
  • O histórico da tabela é mantido e você pode reverter a tabela para uma versão anterior com o RESTORE comando.
  • A operação é uma única transação, portanto, nunca há um momento em que a tabela não exista.
  • A leitura simultânea de consultas da tabela pode continuar sem interrupção. Como a versão antes e depois da substituição ainda existe no histórico da tabela, consultas simultâneas podem fazer referência a qualquer versão da tabela, conforme necessário.

Consulte CREATE TABLE [USING].

Substituir dados por operações simultâneas

Sempre que desejar executar uma substituição completa de dados em uma tabela que possa ser usada em operações simultâneas, você deverá usar CREATE OR REPLACE TABLE.

O seguinte anti-padrão não deve ser usado:

-- This is an anti-pattern. Avoid doing this!
DROP TABLE IF EXISTS table_name;

CREATE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`;

Os motivos para essa recomendação variam dependendo se você está usando tabelas gerenciadas ou externas e se está usando o Unity Catalog, mas em todos os tipos de tabela Delta usar esse padrão pode resultar em um erro, registros descartados ou resultados corrompidos.

Em vez disso, o Databricks recomenda sempre usar CREATE OR REPLACE TABLEo , como no exemplo a seguir:

CREATE OR REPLACE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`

Como o histórico da tabela é mantido durante a substituição de dados atômicos, as transações simultâneas podem validar a versão da tabela de origem referenciada e, portanto, falhar ou reconciliar transações simultâneas conforme necessário sem introduzir comportamento ou resultados inesperados.