Eliminar ou substituir uma tabela Delta

Databricks oferece suporte ao comando DDL padrão SQL para descartar e substituir tabelas registradas no Unity Catalog ou no Hive metastore. 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 descartar 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ântica diferente dependendo do tipo de tabela e se a tabela está registrada no Unity Catalog ou no Hive metastore.

Tipo de tabela	metastore	Comportamento
Gerenciadas	Unity Catalog	A tabela é removida do metastore e os dados subjacentes são marcados para exclusão. Você pode UNDROP dados no Unity Catalog gerenciar tabelas por 7 dias.
Gerenciadas	Hive	A tabela é removida do metastore e os dados subjacentes são excluídos.
Externo	Unity Catalog	A tabela é removida do metastore, mas os dados subjacentes permanecem. Os privilégios de acesso ao URI agora são controlados pelo local externo que contém os dados.
Externo	Hive	A tabela é removida do metastore, mas os dados subjacentes permanecem. Quaisquer privilégios de acesso ao URI permanecem inalterados.

DROP TABLE a semântica difere entre os tipos de tabela, e o Unity Catalog mantém uma história de tabelas Delta usando um ID de tabela interno. Porém, todas as tabelas compartilham o resultado comum de que após a conclusão das operações, o nome da tabela previamente cadastrado não possui mais um link ativo para os dados e a história da tabela do metastore.

Veja DROP TABLE.

Observação

A Databricks não recomenda o padrão de eliminar e depois recriar uma tabela usando o mesmo nome para pipeline 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 mesa

A Databricks recomenda usar instruções CREATE OR REPLACE TABLE para casos de uso em que você deseja substituir totalmente a tabela de destino por novos dados. Por exemplo, para substituir uma tabela Delta com todos os dados de um diretório Parquet, você poderia 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. A seguir estão vantagens importantes de CREATE OR REPLACE TABLE:

• O conteúdo da tabela é substituído, mas a identidade da tabela é mantida.

• A tabela história é mantida e você pode reverter a tabela para uma versão anterior com o comando RESTORE .

• As operações são uma transação única, portanto nunca há um momento em que a tabela não exista.

• consultas simultâneas lendo da tabela podem continuar sem interrupção. Como a versão antes e depois da substituição ainda existe na tabela história, consultas simultâneas podem fazer referência a qualquer versão da tabela, conforme necessário.

Consulte CREATE TABLE [USING].

Substitua dados por operações simultâneas

Sempre que desejar realizar uma substituição completa de dados de uma tabela que possa ser utilizada em operações simultâneas, deverá utilizar CREATE OR REPLACE TABLE.

O seguinte antipadrã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 esta recomendação variam dependendo se você está usando tabelas gerenciadas ou externas e se você está usando o Unity Catalog, mas em todos os tipos de tabela Delta usar esse padrão pode resultar em erro, registros descartados ou resultados corrompidos.

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

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

Como a tabela história é mantida 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 as transações simultâneas conforme necessário, sem introduzir comportamento ou resultados inesperados.