Clone superficial para tabelas do Unity Catalog

Importante

O suporte a clones rasos para tabelas gerenciáveis do Unity Catalog está em Public Preview no Databricks Runtime 13.3 e acima. O suporte a clones rasos para a tabela externa Unity Catalog está em Public Preview em Databricks Runtime 14.2 e acima.

Você pode usar o clone superficial para criar novas tabelas do Unity Catalog a partir de tabelas existentes do Unity Catalog. O suporte de clone superficial para o Unity Catalog permite criar tabelas com privilégios de controle de acesso independentes de suas tabelas pai, sem a necessidade de copiar arquivos de dados subjacentes.

Importante

Você só pode clonar tabelas de gerenciamento do Unity Catalog para tabelas de gerenciamento do Unity Catalog e tabelas externas do Unity Catalog para tabelas externas do Unity Catalog. O comportamento de VACUUM difere entre o gerenciamento e as tabelas externas. Consulte Clones rasos do Vacuum and Unity Catalog.

Para saber mais sobre a clonagem Delta, consulte Clone a table on Databricks.

Para saber mais sobre as tabelas do site Unity Catalog, consulte O que são tabelas e visualizações?

Crie um clone raso 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 seguinte exemplo de sintaxe:

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 destino, conforme detalhado na tabela a seguir:

recurso	Permissões necessárias
Tabela de origem	`SELECT`
Esquema de origem	`USE SCHEMA`
Catálogo de origem	`USE CATALOG`
Esquema alvo	`USE SCHEMA`, `CREATE TABLE`
Catálogo alvo	`USE CATALOG`
Local externo de destino (somente tabelas externas)	`CREATE EXTERNAL TABLE`

Como outras instruções de criação de tabela, 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 dessa tabela independentemente da tabela de origem.

Observação

O proprietário de uma tabela clonada pode ser diferente do proprietário de uma tabela de origem.

Consulte ou modifique uma tabela clonada rasa no Unity Catalog

Importante

As instruções nesta seção descrevem os privilégios necessários para compute configurada com modo de acesso compartilhado. Para o modo de acesso de usuário único, consulte Trabalhar com tabelas clonadas rasas no modo de acesso de usuário único.

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

recurso	Permissões necessárias
Catálogo	`USE CATALOG`
Esquema	`USE SCHEMA`
Mesa	`SELECT`

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

Vacuum e clones rasos Unity Catalog

Importante

Esse comportamento está em Public Preview em Databricks Runtime 13.3 LTS e acima para tabelas gerenciar e Databricks Runtime 14.2 e acima para tabelas externas.

Ao usar tabelas do Unity Catalog para a origem e o destino de operações de clones superficiais, o Unity Catalog gerencia os arquivos de dados subjacentes para melhorar a confiabilidade da origem e do destino das operações de clones. A execução de 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 de clonagem rasa 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 sejam expandidos para incluir os arquivos de dados necessários para retornar query para qualquer tabela clonada rasa, bem como a tabela de origem.

Isso significa que para a semântica de clone superficial VACUUM 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. tabelas de gerenciamento e tabelas externas possuem semânticas ligeiramente diferentes.

Esse acompanhamento aprimorado de metadados altera como as operações VACUUM afetam os arquivos de dados que suportam as tabelas Delta, com a seguinte semântica:

Para gerenciar tabelas, 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 VACUUM removem apenas arquivos de dados da tabela de origem quando executadas na tabela de origem.
Apenas os arquivos de dados não considerados válidos para a tabela de origem ou qualquer clone raso da origem são removidos.
Se vários clones rasos forem definidos em uma única tabela de origem, a execução de VACUUM em qualquer uma das tabelas clonadas não removerá arquivos de dados válidos para outras tabelas clonadas.

Observação

Databricks recomenda nunca executar VACUUM com uma configuração de retenção de menos de 7 dias para evitar corromper transações de execução longa em andamento. Se você precisar executar VACUUM com um limite de retenção mais baixo, certifique-se de entender como VACUUM em clones rasos no Unity Catalog difere de como VACUUM interage com outras tabelas clonadas no Databricks. Consulte Clonar uma tabela no Databricks.

Trabalhe com tabelas clonadas rasas 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 nos 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 permissões USE no catálogo e esquema de origem e permissões SELECT na tabela de origem. Para qualquer query que atualize ou insira registros na tabela de destino, você também deve ter permissões MODIFY na tabela de origem.

Databricks recomenda trabalhar com clones Unity Catalog em compute com modo de acesso compartilhado, pois isso permite a evolução independente de permissões para destinos de clone superficial Unity Catalog e suas tabelas de origem.

Limitações

Clones superficiais em tabelas externas devem ser tabelas externas. Clones superficiais em tabelas de gerenciamento devem ser tabelas de gerenciamento.
Você não pode compartilhar clones rasos usando Delta compartilhamento.
Você não pode aninhar clones rasos, o que significa que não pode fazer um clone raso de um clone raso.
Para gerenciar tabelas, eliminar a tabela de origem quebra a tabela de destino para clones superficiais. Os arquivos de dados que suportam tabelas externas não são removidos pelas operações DROP TABLE e, portanto, clones superficiais de tabelas externas não são afetados pela eliminação da origem.
Unity Catalog permite que os usuários UNDROP gerenciem as mesas por cerca de 7 dias após um DROP TABLE comando. Em Databricks Runtime 13.3 LTS e acima, os clones rasos gerenciados com base em uma tabela gerenciada descartada continuam funcionando durante esse período de 7 dias. Se o senhor não UNDROP a tabela de origem nessa janela, o clone raso deixará de funcionar quando os arquivos de dados da tabela de origem forem coletados pelo lixo.