Pular para o conteúdo principal
Última atualização em

Clonar uma tabela no Databricks

Crie uma cópia de uma tabela existente no Databricks em uma versão específica usando o comando clone . Os clones podem ser profundos ou superficiais.

O Databricks também oferece suporte à clonagem de tabelas Parquet e Apache Iceberg. Consulte Clonagem incremental de tabelas Parquet e Apache Iceberg para o Delta Lake.

Para obter detalhes sobre o uso do clone com o Unity Catalog, consulte Clone superficial para tabelas do Unity Catalog.

nota

A Databricks recomenda o uso do Delta Sharing para fornecer acesso somente leitura a tabelas em diferentes organizações. Consulte O que é Delta Sharing?

Tipos de clones​

Os seguintes tipos de clone estão disponíveis:

Tipo

Sintaxe SQL

Descrição

Clone profundo

CLONE

Copia tanto os dados quanto os metadados da tabela de origem para o destino do clone, incluindo metadados de transmissão. Uma transmissão que grava na tabela de origem pode ser parada e continuada no destino clonado de onde parou.

Clone raso

SHALLOW CLONE

Copia apenas os metadados da tabela de origem para o destino clonado. Arquivos de dados não são copiados. Clones rasos são mais baratos de criar, porque a operação usa menos recursos de compute e espaço de armazenamento.

Metadados clonados incluem: esquema, informações de particionamento, invariantes, anulabilidade e TBLPROPERTIES. Apenas para clones profundos, metadados de transmissão e de COPY INTO também são clonados. Metadados não clonados são a descrição da tabela e metadados de confirmação definidos pelo usuário.

importante

Clones não copiam a história de tabelas do Delta Lake ou propriedades do Unity Catalog, como tags. Consulte Trabalhar com o histórico de tabelas e Aplicar tags a objetos protegíveis do Unity Catalog.

nota

Tabelas de transmissão e views materializadas não oferecem suporte a CLONE. Não é possível usar uma tabela de transmissão ou view materializada como origem ou destino de um clone profundo ou raso. Consulte Limitações e Limitações.

Comportamento da operação de clonagem para o Hive metastore​

importante

No Databricks Runtime 13.3 LTS e acima, as tabelas gerenciadas do Unity Catalog têm suporte para clones rasos. A semântica de clone para tabelas do Unity Catalog difere da semântica de clone em outros ambientes. Consulte Clone raso para tabelas Unity Catalog.

Para uma tabela Delta Lake registrada no Hive metastore ou uma coleção de arquivos não registrados como uma tabela, o clone apresenta os seguintes comportamentos:

  • Alterações em clones profundos ou rasos não afetam a tabela de origem.
  • Clones rasos fazem referência a arquivos de dados no diretório de origem. Se VACUUM for executado na tabela de origem, os clientes não poderão mais ler esses arquivos de dados e isso gerará um FileNotFoundException. Para reparar, execute o clone com replace no clone raso. Se isso ocorrer com frequência, considere usar um clone profundo, que não depende da tabela de origem.
  • Clones profundos não dependem da tabela de origem, mas são caros para criar porque copiam tanto os dados quanto os metadados.
  • A clonagem com replace para um destino que já possui uma tabela nesse caminho cria um log Delta se um não existir. Execute VACUUM para limpar quaisquer dados existentes.
  • Para tabelas Delta existentes, a clonagem cria um novo commit incremental que inclui apenas novos metadados e dados da tabela de origem desde o último clone.
  • Clonar uma tabela difere de Create Table As Select (CTAS). Um clone copia os metadados da tabela de origem além dos dados. Não é necessário especificar particionamento, formato, invariantes, anulabilidade ou outras configurações.
  • Uma tabela clonada tem um histórico independente de sua tabela de origem. Consultas de viagem do tempo em uma tabela clonada não funcionam com as mesmas entradas que na tabela de origem.

Clonar métricas​

CLONE informa as seguintes métricas como um DataFrame de uma única linha quando a operação é concluída:

  • source_table_size: tamanho da tabela de origem que está sendo clonada em bytes.
  • source_num_of_files: o número de arquivos na tabela de origem.
  • num_removed_files: se a tabela estiver sendo substituída, quantos arquivos serão removidos da tabela atual.
  • num_copied_files: número de arquivos que foram copiados da origem (0 para clones superficiais).
  • removed_files_size: tamanho em bytes dos arquivos que estão sendo removidos da tabela atual.
  • copied_files_size: tamanho em bytes dos arquivos copiados para a tabela.

Exemplo de métricas de clone

Permissões​

O senhor deve configurar as permissões para Databricks o controle de acesso da tabela e do seu provedor de nuvem.

controle de acesso da tabela​

As seguintes permissões são necessárias para clones profundos e superficiais:

  • SELECT permissão na tabela de origem.
  • Se você estiver usando CLONE para criar uma nova tabela, permissão CREATE no banco de dados no qual você está criando a tabela.
  • Se você estiver usando CLONE para substituir uma tabela, você deve ter a permissão MODIFY na tabela.

Permissões do provedor de nuvem​

Leitores de um clone profundo precisam de acesso de leitura ao diretório do clone. Gravadores precisam de acesso de gravação ao diretório do clone.

Leitores de um clone raso precisam de acesso de leitura tanto aos arquivos de dados da tabela de origem quanto ao diretório do clone, porque os arquivos de dados permanecem na origem. Gravadores precisam de acesso de gravação ao diretório do clone.

Exemplos​

Criar clones profundos ou superficiais​

Os seguintes exemplos de código demonstram como criar clones profundos e rasos:

Crie um clone profundo:

SQL
CREATE TABLE target_table CLONE source_table;

Substitua um alvo existente:

SQL
CREATE OR REPLACE TABLE target_table CLONE source_table;

Criar um clone profundo, ou ignorar se o destino já existir.

SQL
CREATE TABLE IF NOT EXISTS target_table CLONE source_table;

Criar um clone raso na versão mais recente, em uma versão específica ou em um carimbo de data/hora específico. O carimbo de data/hora pode ser uma string de data como '2019-01-01' ou uma expressão como date_sub(current_date(), 1).

SQL
CREATE TABLE target_table SHALLOW CLONE source_table;

CREATE TABLE target_table SHALLOW CLONE source_table VERSION AS OF version;

CREATE TABLE target_table SHALLOW CLONE source_table TIMESTAMP AS OF timestamp_expression;

Para obter detalhes sobre a sintaxe, consulte CREATE TABLE CLONE.

Verifique os metadados copiados durante CLONE​

Este exemplo confirma quais metadados são copiados durante as CLONE operações, especificamente TBLPROPERTIES, tags do Unity Catalog e o histórico do Delta Lake.

Configure uma tabela de origem com uma propriedade personalizada e uma duração de retenção de log não-padrão, então insira dados para gerar o histórico da tabela:

SQL
CREATE OR REPLACE TABLE test_clone_source (id INT, val STRING)
TBLPROPERTIES ('my.custom.prop' = 'hello', 'delta.logRetentionDuration' = '12 days');

ALTER TABLE test_clone_source SET TAGS ('team' = 'data-eng', 'env' = 'prod');
INSERT INTO test_clone_source VALUES (1, 'a');
INSERT INTO test_clone_source VALUES (2, 'b');

Crie um clone profundo e um clone raso:

SQL
CREATE OR REPLACE TABLE test_clone_deep DEEP CLONE test_clone_source;

CREATE OR REPLACE TABLE test_clone_shallow SHALLOW CLONE test_clone_source;

Confirme que TBLPROPERTIES são copiados para ambos os clones:

SQL
SHOW TBLPROPERTIES test_clone_source;
SHOW TBLPROPERTIES test_clone_deep;
SHOW TBLPROPERTIES test_clone_shallow;

Confirmar que as tags do Unity Catalog não são copiadas para clones:

SQL
SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_source';
SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_deep';
SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_shallow';

Confirme que o histórico do Delta Lake não é copiado para clones:

SQL
DESCRIBE HISTORY test_clone_source;
DESCRIBE HISTORY test_clone_deep;
DESCRIBE HISTORY test_clone_shallow;

Limpar:

SQL
DROP TABLE IF EXISTS test_clone_shallow;
DROP TABLE IF EXISTS test_clone_source;
DROP TABLE IF EXISTS test_clone_deep;

Arquivamento de dados​

Você pode usar o clone profundo para preservar o estado de uma tabela em um determinado momento para fins de arquivamento. Você pode sincronizar clones profundos de forma incremental para manter um estado atualizado de uma tabela de origem para recuperação de desastres.

Execute o seguinte comando uma vez por mês para sincronizar o arquivo:

SQL
CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

Reprodução de modelos deML​

Para casos de uso de machine learning, pode ser interessante arquivar uma versão de uma tabela que foi usada para ensinar um modelo de ML. Modelos futuros podem ser testados usando este dataset arquivado. Para arquivar uma versão do dataset com CLONE, proceda da seguinte forma:

Por exemplo, para arquivar a versão de uma tabela usada para ensinar um modelo na versão 15:

SQL
CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Experimentos de curto prazo em uma mesa de produção​

Para testar um fluxo de trabalho em uma tabela de produção sem corromper a tabela, crie um clone raso. Clones rasos permitem executar cargas de trabalho na tabela clonada, que contém todos os dados de produção, mas não afeta nenhuma carga de trabalho de produção.

Exemplo​

Crie um clone raso da tabela de produção:

SQL
CREATE OR REPLACE TABLE my_test SHALLOW CLONE my_prod_table;

Execute atualizações e validações no clone:

SQL
UPDATE my_test WHERE user_id is null SET invalid=true;

Quando estiver pronto, merge as alterações de volta. O merge usa informações de atualização no clone para remover apenas os arquivos alterados, sempre que possível:

SQL
MERGE INTO my_prod_table
USING my_test
ON my_test.user_id <=> my_prod_table.user_id
WHEN MATCHED AND my_test.user_id is null THEN UPDATE *;

Descartar o clone quando terminar:

SQL
DROP TABLE my_test;

Substituir propriedades da tabela​

As substituições de propriedades de tabela são particularmente úteis para:

  • anotar tabelas com informações do proprietário ou do usuário ao compartilhar dados com diferentes unidades de negócios.
  • É necessário arquivar as tabelas Delta e o histórico de tabelas ou a viagem do tempo. O senhor pode especificar os períodos de retenção de dados e de log de forma independente para a tabela de arquivos. Por exemplo:

Para uma tabela Delta Lake:

SQL
CREATE OR REPLACE TABLE archive_table CLONE prod.my_table
TBLPROPERTIES (
delta.logRetentionDuration = '3650 days',
delta.deletedFileRetentionDuration = '3650 days'
)

Para uma tabela Iceberg:

SQL
CREATE OR REPLACE TABLE archive_table CLONE prod.my_table
TBLPROPERTIES (
iceberg.logRetentionDuration = '3650 days',
iceberg.deletedFileRetentionDuration = '3650 days'
)
Nesta página