Clone raso para Tabelas do Unity Catalog

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. A clonagem superficial no Unity Catalog é 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 Unity Catalog, você deve ter os seguintes privilégios 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 externo superficial do Unity Catalog

Crie uma cópia superficial externa do Unity Catalog especificando uma localização externa.

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 Unity Catalog, é necessário ter os seguintes privilégios nos recursos de origem e destino.

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

Para consultar um clone raso no modo de acesso padrão (anteriormente 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 operações a seguir:

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

Trabalhar com tabelas de clonagem superficial 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 USE permissões no catálogo e no esquema de origem e SELECT permissões 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 rasos do Catálogo do Unity

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. Executar VACUUM na fonte de um clone superficial não corrompe 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, 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, 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 quais arquivos de dados da tabela base 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 raso.

Se você excluir a tabela base de um clone raso, o clone ficará inutilizável. Por padrão, o Databricks impede que você descarte uma tabela base se ainda tiver clones rasos referenciando-a.

Para substituir essa proteção, use a DROP TABLE ... FORCE sintaxe. Se você usar FORCE:

• A tabela base é descartada imediatamente.
• Todos os clones rasos de referência são interrompidos e:
  • Clones rasos falham em operações que exigem a leitura de dados ou metadados (por exemplo, , SELECT, INSERT, UPDATE, DESCRIBE HISTORY, ). CLONE
  • Para permitir a limpeza, clones rasos ainda são visíveis em operações no nível de metadados (por exemplo, SHOW TABLES, DROP TABLE).

Esse comportamento se aplica somente às tabelas gerenciadas do Catálogo do Unity. Para obter mais informações, consulte DROP TABLE.

Limitações

• A clonagem superficial é 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.
• 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, ou seja, não é possível fazer um clone superficial de um clone superficial.
• Para tabelas gerenciadas, a exclusão da tabela de origem quebra a tabela de destino para clones superficiais. Os arquivos de dados subjacentes para tabelas externas não são removidos por operações DROP TABLE, e, portanto, clones superficiais de tabelas externas não são afetados por remover a origem.
• O Unity Catalog permite aos usuários UNDROP as tabelas gerenciadas por cerca de 7 dias após o comando DROP TABLE. No Databricks Runtime 13.3 LTS e posteriores, clones superficiais gerenciados de uma tabela de origem removida continuam a funcionar por até 7 dias durante o período em que o Unity Catalog oferece suporte UNDROP. Se a tabela de origem não for restaurada dentro dessa janela, o clone superficial interromperá o funcionamento quando os arquivos de dados de origem forem excluídos durante a coleta de lixo.