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.

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

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

• A tabela base é descartada imediatamente.
• Todos os clones superficiais 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 superficiais ainda são visíveis em operações em 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 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 gerenciadas, remover a tabela de origem interrompe 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 pela remoção da origem.
• O Unity Catalog permite aos usuários UNDROP tabelas gerenciadas por cerca de 7 dias após um 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 no período em que o Catálogo do Unity 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.