Clonar uma tabela no Databricks

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

O Databricks também suporta a clonagem de tabelas Parquet e Iceberg. Consulte Clonar incrementalmente as tabelas Parquet e Iceberg para Delta Lake.

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

Observação

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 clone

  • 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 transmitidos também são clonados de forma que uma transmissão que grava na tabela Delta possa ser interrompida em uma tabela de origem e continuada no destino de um clone de onde parou.

  • Um clone raso é 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 que são clonados incluem: esquema, informação de particionamento, invariantes, nulidade. 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 commit definidos pelo usuário.

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

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

Importante

Em Databricks Runtime 13.3 LTS e acima, as tabelas de gerenciar Unity Catalog têm suporte para clones rasos. A semântica de clone para tabelas do Unity Catalog difere significativamente da semântica de clone do Delta Lake em outros ambientes. Consulte Shallow clone para tabelas do Unity Catalog.

  • Quaisquer alterações feitas em clones profundos ou rasos afetam apenas os próprios clones e não a tabela de origem.

  • Os clones superficiais fazem referência a arquivos de dados 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 clone com replace sobre o clone raso 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, bem como os metadados.

  • A clonagem com replace para um destino que já possui uma tabela nesse caminho cria logs Delta se não existir um nesse caminho. Você pode limpar todos os dados existentes executando vacuum.

  • Para tabelas Delta existentes, é criada uma nova commit que inclui os novos metadados e os novos dados da tabela de origem. Este novo commit é incremental, o que significa que apenas as novas alterações desde o último clone são commitna 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 possui uma sintaxe mais simples: você não precisa especificar particionamento, formato, invariantes, nulidade e assim por diante, pois eles são obtidos da tabela de origem.

  • Uma tabela clonada possui uma história independente de sua tabela de origem. query viagem do tempo em uma tabela clonada não funciona com os mesmos inputs que trabalha em sua tabela de origem.

Exemplo de sintaxe de clone

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

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)

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)

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 obter detalhes de sintaxe, consulte CREATE TABLE CLONE.

Clonar métricas

CLONE relata as seguintes métricas como um DataFrame de linha única após a conclusão das operações:

  • 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 rasos).

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

Clonar exemplo de métricas

Permissões

Você deve configurar permissões para Databricks access control da tabela e seu provedor cloud .

controle de acesso da tabela

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

  • SELECT permissão na tabela de origem.

  • Se você estiver usando CLONE para criar uma nova tabela, CREATE permissão no banco de dados no qual você está criando a tabela.

  • Se você estiver usando CLONE para substituir uma tabela, deverá ter permissão MODIFY na tabela.

Permissões do provedor de nuvem

Se você criou um clone profundo, qualquer usuário que lê o clone profundo deve 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 precisa de permissão para ler os arquivos na tabela original, pois os arquivos de dados permanecem na tabela de origem com os clones superficiais, assim como o diretório do clone. Para fazer alterações no clone, os usuários precisarão de acesso de gravação ao diretório do clone.

Usar clone para arquivamento de dados

Você pode usar clone profundo para preservar o estado de uma tabela em um determinado ponto no tempo 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.

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

Usar clone para reprodução de modelo de ML

Ao fazer machine learning, talvez você queira arquivar uma determinada versão de uma tabela na qual treinou um modelo de ML. Modelos futuros podem ser testados usando este conjunto de dados arquivados.

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

Use o clone para 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, você pode criar facilmente um clone superficial. Isso permite executar 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.

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

Use o clone para substituir as propriedades da tabela

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

  • tabelas anotar com informações do proprietário ou do usuário ao compartilhar dados com diferentes unidades de negócios.

  • O arquivamento das tabelas Delta e da tabela história ou viagem do tempo é obrigatório. Você pode especificar os períodos de retenção de dados e logs de forma independente para a tabela de arquivo. Por exemplo:

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

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)

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)