Clone superficial para tabelas do Catálogo Unity

Você pode usar clones superficiais para criar novas tabelas do Catálogo Unity a partir de tabelas existentes do Catálogo Unity. O suporte a clones superficiais para o Unity Catalog permite que você crie tabelas com privilégios de controle de acesso independentes de suas tabelas pai sem a necessidade de copiar arquivos de dados subjacentes.

Para obter mais informações sobre clone Delta, consulte Clonar uma tabela no Azure Databricks.

Para obter mais informações sobre tabelas do Catálogo Unity, consulte O que são tabelas e exibições?.

Criar um clone superficial no Unity Catalog

Você pode criar um clone superficial no Unity Catalog usando a mesma sintaxe disponível para clones superficiais em todo o produto, conforme mostrado no exemplo de sintaxe a seguir:

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

Para criar um clone superficial no Unity Catalog, você deve ter privilégios suficientes nos recursos de origem e de destino, conforme detalhado na tabela a seguir:

Como outras instruções create table, o usuário que cria um clone superficial é o proprietário da tabela de destino. O proprietário de uma tabela clonada de destino pode controlar os direitos de acesso para essa tabela independentemente da tabela de origem.

Consultar ou modificar uma tabela clonada superficial no Unity Catalog

Para consultar um clone superficial no Unity Catalog, você deve ter privilégios suficientes na tabela e contendo recursos, conforme detalhado na tabela a seguir:

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

• Inserir registos
• Excluir registros
• Registos de atualizações
• MERGE
• CREATE OR REPLACE TABLE
• DROP TABLE

Vácuo e Unity Catálogo clones superficiais

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 da origem e do destino da operação de clone. A execução VACUUM na origem de um clone superficial não quebra a tabela clonada.

Normalmente, quando VACUUM identifica arquivos válidos para um determinado limite de retenção, apenas os metadados da tabela atual são considerados. O suporte a clones superficiais para o Unity Catalog rastreia as relações entre todas as tabelas clonadas e os arquivos de dados de origem, de modo que os arquivos válidos são expandidos para incluir arquivos de dados necessários para retornar consultas para qualquer tabela clonada superficial, bem como a tabela de origem.

Isso significa que, para a semântica de clone VACUUM superficial do Unity Catalog, um arquivo de dados válido é qualquer arquivo dentro do limite de retenção especificado para a tabela de origem ou qualquer tabela clonada. As tabelas gerenciadas e as tabelas externas têm semânticas ligeiramente diferentes.

Esse rastreamento aprimorado de metadados altera como VACUUM as operações afetam os arquivos de dados que dão suporte às tabelas Delta, com a seguinte semântica:

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

Trabalhar com tabelas clonadas superficiais no modo de acesso de usuário único

Ao trabalhar com clones superficiais do Unity Catalog no modo de acesso de usuário único, você deve ter permissões sobre os recursos para a origem da tabela clonada, bem como a tabela de destino.

Isso significa que, para consultas simples, além das permissões necessárias na tabela de destino, você deve ter USE permissões no catálogo de origem e esquema e SELECT permissões na tabela de origem. Para quaisquer consultas que atualizem ou insiram registros na tabela de destino, você também deve ter MODIFY permissões na tabela de origem.

O Databricks recomenda trabalhar com clones do Unity Catalog em computação com modo de acesso compartilhado, pois isso permite uma evolução independente das permissões para destinos de clone rasos do Unity Catalog e suas tabelas de origem.

Limitações

• Clones superficiais em tabelas externas devem ser tabelas externas. Clones superficiais em tabelas gerenciadas devem ser tabelas gerenciadas.
• Não é possível compartilhar clones superficiais usando o Delta Sharing.
• Você não pode aninhar clones superficiais, o que significa que você não pode fazer um clone superficial a partir de um clone raso.
• Para tabelas gerenciadas, descartar a tabela de origem quebra a tabela de destino para clones superficiais. Os arquivos de dados que dão suporte a tabelas externas não são removidos por DROP TABLE operações e, portanto, clones superficiais de tabelas externas não são afetados ao descartar a origem.
• O Unity Catalog permite que os usuários UNDROP gerenciem tabelas por cerca de 7 dias após um DROP TABLE comando. No Databricks Runtime 13.3 LTS e superior, clones superficiais gerenciados com base em uma tabela gerenciada descartada continuam a funcionar durante esse período de 7 dias. Se você não UNDROP fizer a tabela de origem nesta janela, o clone superficial para de funcionar quando os arquivos de dados da tabela de origem são coletados lixo.