Derrubar ou substituir uma mesa Delta

Databricks suporta o comando DDL padrão SQL para descartar e substituir tabelas registradas com Unity Catalog ou 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 derrubar uma mesa

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

SQL

DROP TABLE table_name

DROP TABLE tem semântica diferente, dependendo do tipo de tabela e se a tabela está registrada em Unity Catalog ou no legado Hive metastore.

Tipo de mesa	Metastore	Comportamento
Gerenciadas	Unity Catalog	A tabela é removida do metastore e os dados subjacentes são marcados para exclusão. O senhor pode UNDROP dados em 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 regidos pelo local externo que contém os dados.
Externo	Hive	A tabela é removida do metastore, mas os dados subjacentes permanecem. Todos os privilégios de acesso ao URI permanecem inalterados.

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

Consulte DROP TABLE.

nota

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 concorrentes. Consulte Substituir dados por operações concorrentes.

Quando substituir uma mesa

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

SQL

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 as vantagens importantes do CREATE OR REPLACE TABLE:

• O conteúdo da tabela é substituído, mas a identidade da tabela é mantida.
• O histórico da tabela é mantido, e o senhor pode reverter a tabela para uma versão anterior com o comando RESTORE.
• As operações são uma única transação, portanto, nunca há um momento em que a tabela não exista.
• As consultas concorrente de leitura da tabela podem continuar sem interrupção. Como a versão anterior e posterior à substituição ainda existe no histórico da tabela, as consultas concorrente podem fazer referência a qualquer versão da tabela, conforme necessário.

Consulte CREATE TABLE [USING].

Substituir dados por operações concorrentes

Sempre que quiser fazer uma substituição completa dos dados em uma tabela que possa ser usada em operações concorrentes, o senhor deve usar o site CREATE OR REPLACE TABLE.

O seguinte antipadrão não deve ser usado:

SQL

-- 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 o senhor está usando tabelas gerenciar ou externas e se está usando Unity Catalog, mas em todos os tipos de tabela Delta o uso desse padrão pode resultar em erro, registros descartados ou resultados corrompidos.

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

SQL

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

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