Clone Superficial para Tabelas do Unity Catalog

  • Artigo

Importante

O suporte de clone superficial para tabelas gerenciadas do Catálogo Unity está em Visualização Pública no Databricks Runtime 13.3 e superior. O suporte a clone superficial para tabela externa do Unity Catalog está em Visualização Pública no Databricks Runtime 14.2 e posteriores.

Agora você pode usar o clone superficial para criar novas tabelas gerenciadas do Unity Catalog nas tabelas existentes do Unity Catalog. O suporte de clone superficial para o Catálogo do Unity 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.

Importante

Você só pode clonar tabelas gerenciadas do Unity Catalog para tabelas gerenciadas do Unity Catalog e tabelas externas do Unity Catalog para tabelas externas do Unity Catalog. O comportamento do VACUUM é diferente entre tabelas gerenciadas e externas. Consulte Clones shallow do Vacuum e do Catálogo do Unity.

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

Para obter mais informações sobre tabelas do Unity Catalog, confira Criar tabelas no Catálogo do Unity.

Criar um clone superficial no Catálogo do Unity

Você pode criar um clone superficial no Catálogo do Unity 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 Catálogo do Unity, você deve ter privilégios suficientes nos recursos de origem e de 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 de destino USE SCHEMA, CREATE TABLE
Catálogo de destino USE CATALOG
Local externo de destino (somente tabelas externas) CREATE EXTERNAL TABLE

Como em 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 para essa 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.

Consultar ou modificar uma tabela clonada superficial no Catálogo do Unity

Importante

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

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

Recurso Permissões necessárias
Catálogo USE CATALOG
Esquema USE SCHEMA
Tabela SELECT

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

  • Inserir registros
  • Excluir registros
  • Registros de atualização
  • MERGE
  • CREATE OR REPLACE TABLE
  • DROP TABLE

Clones superficiais do Vacuum e do Catálogo do Unity

Importante

Esse comportamento está em Versão Prévia Pública no Databricks Runtime 13.3 LTS e superior para tabelas gerenciadas e no Databricks Runtime 14.2 e superior para tabelas externas.

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 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. O suporte de clone superficial para o Catálogo do Unity rastreia as relações entre todas as tabelas clonadas e os arquivos de dados de origem, portanto, 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 VACUUM de clone superficial do Catálogo do Unity, 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 gerenciadas e tabelas externas têm uma semântica um pouco diferente.

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

  • Para tabelas gerenciadas, as operações do VACUUM em relação à origem ou ao 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 os arquivos de dados não considerados válidos para a tabela de origem ou qualquer clone superficial na origem são removidos.
  • Se vários clones superficiais forem definidos em 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.

Observação

O Databricks recomenda nunca executar VACUUM com uma configuração de retenção de menos de 7 dias para evitar corromper transações de longa execução contínuas. Se você precisar executar VACUUM com um limite de retenção menor, certifique-se de entender como VACUUM nos clones superficiais no Catálogo do Unity diferem de como VACUUM interage com outras tabelas clonadas no Azure Databricks. Veja Clonar uma tabela no Azure Databricks.

Trabalhe com tabelas clonadas superficialmente no modo de acesso de usuário único

Ao trabalhar com clones superficiais do Catálogo do Unity no modo de acesso de Usuário Único, você deve ter permissões nos recursos para a origem da tabela clonada, bem como para 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 de origem e esquema e permissões SELECT na tabela de origem. Para qualquer consulta que atualize ou insira registros na tabela de destino, você também deve ter permissões MODIFY na tabela de origem.

O Databricks recomenda trabalhar com clones do Catálogo do Unity na computação com modo de acesso compartilhado, pois isso permite a evolução independente de permissões para destinos de clone superficial do Catálogo do Unity e suas tabelas de origem.

Limitações

  • 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 superficiais usando o Compartilhamento Delta.
  • 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 que fazem backup de tabelas externas não são removidos por operações do DROP TABLE e, portanto, os clones superficiais de tabelas externas não são afetados ao remover a 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 superior, os clones superficiais geridos com base numa tabela gerida eliminada continuam a funcionar durante este período de 7 dias. Se você não UNDROP a tabela de origem nessa janela, o clone superficial interromperá o funcionamento depois que os arquivos de dados da tabela de origem forem coletados como lixo.