Partilhar via

Clone superficial para tabelas do Catálogo Unity

  • Artigo

Importante

O suporte a clones rasos para tabelas gerenciadas do Unity Catalog está em Visualização Pública no Databricks Runtime 13.3 e superior. O suporte a clones rasos para a tabela externa do Unity Catalog está em Visualização Pública no Databricks Runtime 14.2 e superior.

Você pode usar clones superficiais para criar novas tabelas do Catálogo Unity a partir de tabelas existentes do Catálogo Unity. O suporte a clones superficiais para o Unity Catalog 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. VACUUM O comportamento difere entre tabelas gerenciadas e externas. Consulte clones superficiais do Vacuum e do Unity Catalog.

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

Para obter mais informações sobre tabelas do Catálogo Unity, consulte O que são tabelas e exibições?.

Criar um clone superficial 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 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 Unity Catalog, 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 fontes 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 outras instruções create table, 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.

Nota

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 Unity Catalog

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 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
Tabela SELECT

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

  • Inserir registos
  • Excluir registros
  • Registos de atualizações
  • MERGE
  • CREATE OR REPLACE TABLE
  • DROP TABLE

Vácuo e Unity Catálogo clones superficiais

Importante

Esse comportamento está em Visualização Pública no Databricks Runtime 13.3 LTS e superior para tabelas gerenciadas e 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 da origem e do destino da operação de clone. A execução 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 a clones superficiais 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 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 de clone VACUUM superficial 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. As tabelas gerenciadas e as tabelas externas têm semânticas ligeiramente diferentes.

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

  • 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, VACUUM as operações só removem arquivos de dados da tabela de origem quando executadas em relação à tabela de origem.
  • Somente os arquivos de dados não considerados válidos para a tabela de origem ou qualquer clone superficial em relação à origem são removidos.
  • Se vários clones superficiais forem definidos em relação a 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.

Nota

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

Trabalhar com tabelas clonadas superficiais 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 sobre os 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 USE permissões no catálogo de origem e esquema e SELECT permissões na tabela de origem. Para quaisquer consultas que atualizem ou insiram registros na tabela de destino, você também deve ter MODIFY permissões na tabela de origem.

O Databricks recomenda trabalhar com clones do Unity Catalog em computação com modo de acesso compartilhado, pois isso permite uma evolução independente das permissões para destinos de clone rasos do Unity Catalog e suas tabelas de origem.

Limitações

  • Clones superficiais em tabelas externas devem ser tabelas externas. Clones superficiais em tabelas gerenciadas devem ser tabelas gerenciadas.
  • Não é possível compartilhar clones superficiais usando o Delta Sharing.
  • Você não pode aninhar clones superficiais, o que significa que você não pode fazer um clone superficial a partir de um clone raso.
  • Para tabelas gerenciadas, descartar a tabela de origem quebra a tabela de destino para clones superficiais. Os arquivos de dados que dão suporte a tabelas externas não são removidos por DROP TABLE operações e, portanto, clones superficiais de tabelas externas não são afetados ao descartar a origem.
  • O Unity Catalog permite que os usuários UNDROP gerenciem tabelas por cerca de 7 dias após um DROP TABLE comando. No Databricks Runtime 13.3 LTS e superior, clones superficiais gerenciados com base em uma tabela gerenciada descartada continuam a funcionar durante esse período de 7 dias. Se você não UNDROP fizer a tabela de origem nesta janela, o clone superficial para de funcionar quando os arquivos de dados da tabela de origem são coletados lixo.