Clone superficial das tabelas do Catálogo do Unity

Use um clone superficial para criar tabelas do Catálogo do Unity com privilégios de controle de acesso independentes de suas tabelas de origem, sem copiar os arquivos de dados subjacentes. O clone superficial no Catálogo do Unity é compatível apenas com tabelas Delta Lake. Você não pode criar um clone superficial de uma tabela Iceberg ou de qualquer outra tabela que não seja Delta.

Para obter informações sobre como clonar uma tabela, consulte Clonar uma tabela no Azure Databricks.

Criar um clone superficial gerenciado do Catálogo do Unity

Crie um clone superficial de uma tabela gerenciada no Catálogo do Unity.

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>

Para criar um clone superficial gerenciado no Catálogo do Unity, você deve ter os privilégios a seguir nos recursos de destino e origem.

Como outras instruções de criação de tabela, quando você executa SHALLOW CLONE, você possui a tabela de destino. O proprietário de uma tabela de destino clonada controla os direitos de acesso para essa tabela independentemente da tabela de origem. O proprietário de uma tabela clonada pode ser diferente do proprietário de uma tabela de origem.

Criar um clone superficial externo do Catálogo do Unity

Crie um clone superficial externo do Catálogo do Unity especificando um local externo.

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>
LOCATION 's3://<bucket-name>/<path-name>/<target-table-name>'

Para criar um clone superficial externo no Catálogo do Unity, você deve ter os privilégios a seguir nos recursos de destino e origem.

Trabalhar com tabelas clonadas superficiais no modo de acesso padrão

Para consultar um clone superficial no modo de acesso padrão (antes chamado de modo de acesso compartilhado), você deve ter os seguintes privilégios na tabela e nos recursos que a contêm:

Você também deve ter permissões de MODIFY no destino da operação de clone para executar as seguintes operações:

• INSERT
• DELETE
• UPDATE
• MERGE
• CREATE TABLE
• DROP TABLE

Trabalhar com tabelas clonadas superficiais no modo de acesso dedicado

Ao trabalhar com clonagens rasas do Unity Catalog no modo de acesso dedicado (anteriormente chamado de modo de acesso de usuário único), você deve ter permissões sobre os recursos tanto da tabela de origem da clonagem quanto da tabela de destino.

Para consultas simples, além das permissões necessárias na tabela de destino, você deve ter permissões USE no catálogo e no esquema de origem e permissões SELECT na tabela de origem. Para todas as consultas que atualizam ou inserem registros na tabela de destino, você também deve ter MODIFY permissões na tabela de origem.

A Databricks recomenda usar clones do Unity Catalog em computação com modo de acesso padrão, pois isso permite alterações independentes nas permissões dos destinos de clones rasos do Unity Catalog e de suas tabelas de origem.

Usar VACUUM com clones superficiais do Unity Catalog

Quando você usa tabelas do Unity Catalog para a origem e o destino de uma operação de clone superficial, o Unity Catalog gerencia os arquivos de dados subjacentes para melhorar a confiabilidade para a origem e o destino da operação de clone. A execução de VACUUM na origem de um clone superficial não interrompe a tabela clonada.

Normalmente, quando VACUUM identifica arquivos válidos para um determinado limite de retenção, somente os metadados da tabela atual são considerados. No entanto, o suporte a clone superficial no Unity Catalog rastreia as relações entre todas as tabelas clonadas e os arquivos de dados de origem, de modo que o conjunto de arquivos válidos é ampliado para incluir os arquivos de dados necessários para atender às consultas tanto das tabelas clonadas superficialmente quanto da tabela de origem.

Para VACUUM em um clone superficial do Unity Catalog, um arquivo de dados válido é qualquer arquivo dentro do período de retenção especificado para a tabela de origem ou qualquer tabela clonada. Tabelas gerenciadas e tabelas externas têm comportamentos ligeiramente diferentes.

Esse acompanhamento aprimorado das mudanças nos metadados altera a forma como as operações VACUUM afetam os arquivos de dados subjacentes das tabelas do Delta Lake, com o seguinte comportamento:

• Para tabelas gerenciadas, as operações VACUUM na origem ou no destino de uma operação de clone superficial podem excluir arquivos de dados da tabela de origem.
• Para tabelas externas, as operações do VACUUM apenas removem os arquivos de dados da tabela de origem quando executados na tabela de origem.
• Somente arquivos de dados não considerados válidos para a tabela de origem ou qualquer clone superficial em relação à tabela de origem são removidos.
• Se vários clones rasos forem definidos contra uma única tabela de origem, executar VACUUM em qualquer uma das tabelas clonadas não removerá arquivos de dados válidos de outras tabelas clonadas.

Mesmo que você exclua uma tabela clonada de forma superficial, talvez precise de acesso SELECT a essa tabela clonada de forma superficial para executar VACUUM na tabela base. O Databricks lê o log Delta do clone superficial para verificar os arquivos de dados da tabela base que o clone ainda referencia antes de removê-los. O Databricks mantém esse link por 7 dias após excluir uma tabela de clone superficial para dar suporte à operação UNDROP. No modo de acesso padrão, no entanto, essa permissão não é necessária.

Remova a tabela base para um clone superficial.

Você pode excluir a tabela base de uma tabela gerenciada do Unity Catalog mesmo quando clones rasos ativos ainda fazem referência a ela. Os clones continuam lendo até que os arquivos de dados da tabela base sejam deletados, o que os torna inutilizáveis. Você pode restaurar a tabela base com UNDROP durante o período de recuperação, que, por padrão, é de 7 dias e pode ser configurado no nível do catálogo ou do esquema para 0 (para desabilitar a recuperação) ou de 7 a 30 dias. A configuração do período de recuperação é feita em Prévia Pública. Se você não restaurar a tabela, um processo de purga assíncrono apaga seus arquivos de dados após o término do período de recuperação, para que os clones possam continuar lendo por um tempo depois que a tabela base não for mais recuperável. Para recuperar uma tabela base caída, use UNDROP.

Limitações

• A clonagem superficial é compatível somente com tabelas do Delta Lake. Você não pode criar um clone superficial de uma tabela Iceberg ou de qualquer outra tabela que não seja Delta.
• Você não pode usar CREATE OR REPLACE para substituir um clone raso existente. Use DROP TABLE seguido por CREATE TABLE, ou use um novo nome de tabela.
• Os clones superficiais nas tabelas externas devem ser tabelas externas. Os clones superficiais nas tabelas gerenciadas devem ser tabelas gerenciadas.
• Não é possível compartilhar clones rasos usando o OpenSharing.
• Você não pode aninhar clones superficiais, o que significa que você não pode fazer um clone superficial de um clone superficial.
• Para tabelas externas, DROP TABLE não remove os arquivos de dados subjacentes, então clones superficiais não são afetados quando a tabela de origem é descartada.
• Para tabelas gerenciadas no Databricks Runtime 13.3 LTS e superiores, clones superficiais de uma tabela de origem abandonada continuam funcionando até que os arquivos de dados de origem sejam deletados. Consulte Soltar a tabela base para um clone superficial.