Soltar ou substituir uma tabela

A Databricks oferece suporte a comandos DDL padrão SQL para descartar e substituir tabelas registradas no Unity Catalog ou no Hive metastore. O comportamento de descarte e substituição difere por tipo de tabela e metastore. Escolha o comando certo para evitar perda de dados ou falhas de operações concorrentes.

Quando descartar uma tabela

O Databricks recomenda que você use DROP TABLE para remover uma tabela do metastore quando quiser excluir permanentemente a tabela e não tiver a intenção de criar uma nova tabela no mesmo local. Por exemplo:

SQL

DROP TABLE table_name

DROP TABLE apresenta diferentes comportamentos, dependendo do tipo de tabela e se a tabela está registrada no Unity Catalog ou no Hive metastore herdado.

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 uma tabela gerenciada dentro do período de recuperação configurado (default 7 dias). Consulte Remover uma tabela gerenciada.
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 a URI são agora regidos 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 a URIs permanecem inalterados.

O Unity Catalog mantém uma história de tabelas usando um ID de tabela interno. Para todos os tipos de tabela, após a conclusão das operações de remoção, o nome da tabela registrado anteriormente não tem mais um link ativo para os dados e a história da tabela do metastore.

See DROP TABLE.

nota

A Databricks não recomenda excluir e, em seguida, recriar uma tabela usando o mesmo nome para pipelines ou sistemas de produção, pois isso pode resultar em resultados inesperados para operações concorrentes. Consulte Substituir dados com operações concorrentes.

Quando substituir uma tabela

O Databricks recomenda o uso de instruções CREATE OR REPLACE TABLE para casos de uso em que se deseja substituir completamente a tabela de destino com dados novos. Por exemplo, para sobrescrever uma tabela com todos os dados de um diretório Parquet, faça a execução do 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 do metastore em uso. A seguir, estão as importantes vantagens de CREATE OR REPLACE TABLE:

• O conteúdo da tabela é substituído, mas a identidade da tabela é mantida.
• O histórico da tabela é retido, e você pode reverter a tabela para uma versão anterior com o comando RESTORE.
• A operação é uma transação única, então nunca há um momento em que a tabela não exista.
• Consultas concorrentes lendo a tabela podem continuar sem interrupção. Porque a versão anterior e posterior à substituição ainda existe na história da tabela, consultas concorrentes podem fazer referência a qualquer uma das versões da tabela, conforme necessário.
• Se a tabela original incluía máscaras de coluna, essas máscaras são retidas para quaisquer colunas que ainda existam na nova tabela. Isso garante que as políticas de acesso a dados sejam preservadas.

Consulte CREATE TABLE [USING].

Substituir dados com operações concorrentes

Quando você deseja realizar uma substituição completa de dados em uma tabela que pode ser usada em operações concorrentes, você deve usar CREATE OR REPLACE TABLE.

Você não deve usar o seguinte antipadrão:

SQL

DROP TABLE IF EXISTS table_name;

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

Para todos os tipos de tabela, esteja você usando o Unity Catalog ou não, o uso desse padrão pode resultar em um 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 a substituição atômica preserva a história da tabela, as transações concorrentes podem validar a versão da tabela de origem que elas referenciam e falhar ou conciliar transações concorrentes sem comportamento inesperado.