Retirar ou substituir uma mesa

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. O comportamento de eliminação e recriação varia consoante o tipo de tabela e o metastore. Escolha o comando certo para evitar perda de dados ou falhas simultâneas nas operações.

Quando eliminar uma tabela

O Databricks recomenda que use DROP TABLE para remover uma tabela da metastore quando quiser apagar 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 apresenta comportamentos diferentes dependendo do tipo de tabela e se a tabela está registada no Unity Catalog ou na antiga metastore Hive.

Tipo de tabela Metastore Comportamento
Managed Catálogo Unity A tabela é removida do metastore e os dados subjacentes são marcados para exclusão. Podes UNDROP criar uma tabela gerida dentro do período de recuperação configurado (por defeito 7 dias). Veja Eliminar uma tabela gerida.
Managed Hive A tabela é removida do metastore e os dados subjacentes são excluídos.
Externo Catálogo 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.
Externo Hive A tabela é removida do metastore, mas os dados subjacentes permanecem. Todos os privilégios de acesso URI permanecem inalterados.

O Unity Catalog mantém um histórico de tabelas usando um ID de tabela interno. Para todos os tipos de tabela, após a conclusão da operação de remoção, o nome da tabela anteriormente registado deixa de ter uma ligação ativa aos dados e ao histórico da tabela no metastore.

Consulte DROP TABLE.

Note

O Databricks não recomenda que descarte e depois recrie uma tabela com o mesmo nome para pipelines ou sistemas de produção, pois isso pode resultar em resultados inesperados para operações concorrentes. Consulte Substituir dados por operações simultâneas.

Quando substituir uma tabela

O Databricks recomenda o uso de 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 sobrescrever uma tabela com todos os dados de um diretório Parquet, execute 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 comando RESTORE.
  • 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.
  • Se a tabela original incluísse máscaras de coluna, essas máscaras seriam mantidas para quaisquer colunas que ainda existissem na nova tabela. Isso garante que as políticas de acesso aos dados sejam preservadas.

Ver CREATE TABLE [UTILIZANDO].

Substituir dados por operações simultâneas

Quando quiser realizar uma substituição completa de dados numa tabela que possam ser usados em operações concorrentes, deve usar CREATE OR REPLACE TABLE.

Não deve utilizar o seguinte anti-padrão:

DROP TABLE IF EXISTS table_name;

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

Para todos os tipos de tabelas, esteja ou não a usar o Unity Catalog, usar este padrão pode resultar em erro, registos perdidos 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 substituição atómica preserva o histórico da tabela, as transações concorrentes podem validar a versão da tabela de origem que referenciam e falhar ou reconciliar transações concorrentes sem comportamentos inesperados.

  • Last updated on