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​

  • Um clone profundo é um clone que copia os dados da tabela de origem para o destino do clone, além dos metadados da tabela existente. Além disso, os metadados da transmissão também são clonados, de modo que uma transmissão que grava na tabela Delta pode ser interrompida em uma tabela de origem e continuada no destino de um clone de onde parou.
  • Um clone superficial é um clone que não copia os arquivos de dados para o destino do clone. Os metadados da tabela são equivalentes à fonte. Esses clones são mais baratos de criar.

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

importante

A tabela histórico Delta Lake não é copiada ao clonar uma tabela. As propriedades Unity Catalog não são copiadas, como as tags. Delta Lake Veja a história e da tags tabela .

Qual é a semântica das operações de clone Delta?​

Se o senhor estiver trabalhando com uma tabela Delta registrada no Hive metastore ou com uma coleção de arquivos não registrados como tabela, o clone tem a seguinte semântica:

importante

No Databricks Runtime 13.3 LTS e versões superiores, as tabelas gerenciadas Unity Catalog oferecem suporte a clones superficiais. A semântica de clonagem para tabelas do Unity Catalog difere da semântica de clonagem em outros ambientes. Consulte Clonagem superficial para tabelas Unity Catalog.

  • Qualquer alteração feita em clones profundos ou superficiais afeta somente os próprios clones e não a tabela de origem.
  • Clones superficiais fazem referência a arquivos de dados no diretório de origem. Se o senhor executar vacuum na tabela de origem, os clientes não poderão mais ler os arquivos de dados referenciados e um FileNotFoundException será lançado. Nesse caso, executar clone com replace sobre o clone superficial repara o clone. Se isso ocorrer com frequência, considere usar um clone profundo que não dependa da tabela de origem.
  • Os clones profundos não dependem da fonte da qual foram clonados, mas são caros de criar porque um clone profundo copia os dados e os metadados.
  • A clonagem com replace para um destino que já tenha uma tabela nesse caminho cria uma Delta log se não houver uma nesse caminho. Você pode limpar todos os dados existentes executando vacuum.
  • Para tabelas Delta existentes, é criado um novo commit que inclui os novos metadados e os novos dados da tabela de origem. Esse novo commit é incremental, o que significa que somente as novas alterações desde o último clone são confirmadas na tabela.
  • Clonar uma tabela não é o mesmo que Create Table As Select ou CTAS. Um clone copia os metadados da tabela de origem, além dos dados. A clonagem também tem uma sintaxe mais simples: você não precisa especificar particionamento, formato, invariantes, nulidade e assim por diante, pois eles são retirados da tabela de origem.
  • Uma tabela clonada tem um histórico independente de sua tabela de origem. As consultas de viagem do tempo em uma tabela clonada não funcionam com as mesmas entradas que funcionam em sua 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​

Se você criou um clone profundo, qualquer usuário que leia o clone profundo deverá ter acesso de leitura ao diretório do clone. Para fazer alterações no clone, os usuários devem ter acesso de gravação ao diretório do clone.

Se você criou um clone superficial, qualquer usuário que leia o clone superficial precisará de permissão para ler os arquivos na tabela original, pois os arquivos de dados permanecem na tabela de origem com clones superficiais, bem como no diretório do clone. Para fazer alterações no clone, os usuários precisarão ter acesso de gravação ao diretório do clone.

Exemplos​

Criar clones profundos ou superficiais​

Os exemplos de código a seguir demonstram a sintaxe para criar clones profundos e superficiais:

SQL
CREATE TABLE target_table CLONE source_table; -- Create a deep clone of source_table as target_table

CREATE OR REPLACE TABLE target_table CLONE source_table; -- Replace the target

CREATE TABLE IF NOT EXISTS target_table CLONE source_table; -- No-op if the target table exists

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; -- timestamp can be like “2019-01-01” or like date_sub(current_date(), 1)

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

Verifique os metadados copiados durante CLONE​

SQL
-- Test: Confirm which metadata is copied over during CLONE operations
-- Checks: TBLPROPERTIES, UC tags, and Delta history

-- Setup: create source table with a custom property my.custom.prop set to 'hello' and set delta.logRetentionDuration to '12 days' instead of default '30 days'. Insert data to generate table history
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');

-- Deep clone
CREATE OR REPLACE TABLE test_clone_deep
DEEP CLONE test_clone_source;

-- Shallow clone
CREATE OR REPLACE TABLE test_clone_shallow
SHALLOW CLONE test_clone_source;

-- Show that TBLPROPERTIES are copied to clones
SHOW TBLPROPERTIES test_clone_source;
SHOW TBLPROPERTIES test_clone_deep;
SHOW TBLPROPERTIES test_clone_shallow;

-- Show that UC tags not copied to clones
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';

-- Show that Delta history is not copied to clones
DESCRIBE HISTORY test_clone_source;
DESCRIBE HISTORY test_clone_deep;
DESCRIBE HISTORY test_clone_shallow;

-- Cleanup
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.

SQL
-- Every month run
CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

Reprodução de modelos deML​

Ao fazer aprendizado de máquina, o senhor pode querer arquivar uma determinada versão de uma tabela na qual treinou um modelo de ML. Modelos futuros podem ser testados usando esse conjunto de dados arquivado.

SQL
-- Trained model on version 15 of Delta table
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, o senhor pode criar facilmente um clone superficial. Isso permite que o senhor execute um fluxo de trabalho arbitrário na tabela clonada que contém todos os dados de produção, mas não afeta nenhuma carga de trabalho de produção.

SQL
-- Perform shallow clone
CREATE OR REPLACE TABLE my_test SHALLOW CLONE my_prod_table;

UPDATE my_test WHERE user_id is null SET invalid=true;
-- Run a bunch of validations. Once happy:

-- This should leverage the update information in the clone to prune to only
-- changed files in the clone if possible
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 *;

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:
SQL
-- For Delta tables
CREATE OR REPLACE TABLE archive_table CLONE prod.my_table
TBLPROPERTIES (
delta.logRetentionDuration = '3650 days',
delta.deletedFileRetentionDuration = '3650 days'
)

-- For Iceberg tables
CREATE OR REPLACE TABLE archive_table CLONE prod.my_table
TBLPROPERTIES (
iceberg.logRetentionDuration = '3650 days',
iceberg.deletedFileRetentionDuration = '3650 days'
)