Compartilhar via

Clonar uma tabela no Azure Databricks

  • Artigo

Você pode criar uma cópia de uma tabela do Delta Lake no Azure Databricks em uma versão específica usando o comando clone. Os clones podem ser profundos ou superficiais.

O Azure Databricks também dá suporte à clonagem de tabelas Parquet e Iceberg. Consulte Clonar incrementalmente tabelas Parquet e Iceberg no Delta Lake.

Para obter detalhes sobre como usar o clone com o Catálogo do Unity, confira Clone superficial para tabelas do Catálogo do Unity.

Observação

O Databricks recomenda usar o Compartilhamento Delta para fornecer acesso somente leitura a tabelas em diferentes organizações. Confira O que é o Compartilhamento Delta?.

Tipos de clone

  • Clone profundo é um clone que copia os dados da tabela de origem para o destino do clone, bem como os metadados da tabela. Além disso, os metadados de fluxo também são clonados de modo que um fluxo que grava na tabela do Delta seja interrompido na uma tabela de origem e continue de onde parou no destino do clone.
  • Clone superficial é um clone que não copia os arquivos de dados para o destino do clone. Os metadados da tabela são equivalentes à origem. O custo para criar esses clones é inferior.

Os metadados clonados incluem: esquema, informações de particionamento, invariáveis e nulidade. Somente no caso de clones profundos, o fluxo e os metadados 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.

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

Se você tiver trabalhado com uma tabela Delta registrada no metastore do Hive ou uma coleção de arquivos não registrados como uma tabela, o clone terá a seguinte semântica:

Importante

No Databricks Runtime 13.3 LTS e superior, as tabelas gerenciadas do Catálogo do Unity têm suporte para clones rasos. A semântica de clone para tabelas do Catálogo do Unity difere significativamente da semântica de clone do Delta Lake em outros ambientes. Confira Clone superficial para tabelas do Catálogo do Unity.

  • As alterações feitas em clones profundos ou superficiais afetam apenas os clones propriamente ditos e não a tabela de origem.
  • Os clones superficiais são arquivos de dados de referência no diretório de origem. Se você 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 o clone com substituição sobre o clone superficial repara o clone. Se isso acontecer com frequência, use um clone profundo, que não depende da tabela de origem.
  • Clones profundos não dependem da origem da qual foram clonados, mas são caros de criar porque copiam os dados e os metadados.
  • A clonagem com replace para um destino que já tem uma tabela nesse caminho cria um log Delta (se já não existir um nesse caminho). Você pode limpar todos os dados executando vacuum.
  • Para tabelas Delta existentes, é criado um novo commit que inclui os novos metadados e novos dados da tabela de origem. Esse novo commit é incremental. Portanto, apenas 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. O clone copia os metadados da tabela de origem, bem como os dados. A clonagem também tem uma sintaxe mais simples: não é preciso especificar particionamento, formato, invariáveis, nulidade etc. porque essas informações são retiradas da tabela de origem.
  • O histórico de tabelas clonadas é independente do histórico das tabelas de origem. As consultas de viagem no tempo em uma tabela clonada não funcionam com as mesmas entradas que funcionam em sua tabela de origem.

Sintaxe de clone de exemplo

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

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)

Python

from delta.tables import *

deltaTable = DeltaTable.forName(spark, "source_table")

deltaTable.clone(target="target_table", isShallow=True, replace=False) # clone the source at latest version

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=True, replace=False) # clone the source at a specific version

# clone the source at a specific timestamp such as timestamp="2019-01-01"
deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=True, replace=False)

Scala

import io.delta.tables._

val deltaTable = DeltaTable.forName(spark, "source_table")

deltaTable.clone(target="target_table", isShallow=true, replace=false) // clone the source at latest version

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=true, replace=false) // clone the source at a specific version

deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=true, replace=false) // clone the source at a specific timestamp

Para mais informações sobre sintaxe, confira CRIAR UMA TABELA CLONADA.

Métricas de clonagem

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

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

Exemplo de clonagem de métricas

Permissões

Configure permissões de controle de acesso à tabela no Azure Databricks e o provedor de nuvem.

Controle de acesso de tabela

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

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

Permissões do provedor de nuvem

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

Se você criou um clone superficial, os usuários que leem esse clone precisam 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 o diretório do clone. Para fazer alterações no clone, os usuários precisam ter acesso de gravação no diretório do clone.

Usar clone para arquivamento de dados

Você pode criar um clone profundo para preservar o estado de uma tabela em um determinado momento para arquivamento. Você pode sincronizar clones profundos incrementalmente para manter um estado atualizado de uma tabela de origem para recuperação de desastre.

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

Usar clones para reprodução de modelo de ML

No aprendizado de máquina, o ideal é arquivar uma determinada versão de uma tabela em que você treinou um modelo de ML. Você pode testar os próximos modelos com esse conjunto de dados arquivados.

-- Trained model on version 15 of Delta table
CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Usar experimentos de curto prazo em uma tabela de produção

Para testar um fluxo de trabalho em uma tabela de produção sem corromper a tabela, você pode criar facilmente um clone superficial. Isso permite executar fluxos de trabalho arbitrários na tabela clonada que contém todos os dados de produção, mas não afeta nenhuma carga de trabalho de produção.

-- 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;

Usar clone para substituir as propriedades da tabela

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

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

SQL

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

Python

dt = DeltaTable.forName(spark, "prod.my_table")
tblProps = {
"delta.logRetentionDuration": "3650 days",
"delta.deletedFileRetentionDuration": "3650 days"
}
dt.clone(target="archive_table", isShallow=False, replace=True, tblProps)

Scala

val dt = DeltaTable.forName(spark, "prod.my_table")
val tblProps = Map(
"delta.logRetentionDuration" -> "3650 days",
"delta.deletedFileRetentionDuration" -> "3650 days"
)
dt.clone(target="archive_table", isShallow = false, replace = true, properties = tblProps)