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 |
|
Esquema de origem |
|
Catálogo de origem |
|
Esquema alvo |
|
Catálogo alvo |
|
Local externo de destino (somente tabelas externas) |
|
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 |
|
Esquema |
|
Mesa |
|
Você também deve ter permissões MODIFY
no destino das operações de clone para concluir as seguintes ações:
Inserir registros
Excluir registros
Atualizar registros
MERGE
CREATE OR REPLACE TABLE
DROP TABLE
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 umDROP 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ãoUNDROP
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.