Clone superficial para tabelas do Unity Catalog

important

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.

O senhor pode usar o shallow clone para criar novas tabelas do Unity Catalog a partir de tabelas existentes do Unity Catalog. O suporte a clones rasos para o Unity Catalog permite que o senhor crie tabelas com privilégios de controle de acesso independentes de suas tabelas pai sem precisar copiar arquivos de dados subjacentes.

important

O senhor só pode clonar tabelas gerenciar Unity Catalog para tabelas gerenciar Unity Catalog e tabelas externas Unity Catalog para tabelas externas Unity Catalog. VACUUM O comportamento difere entre tabelas gerenciais e externas. Consulte vacuum e Unity Catalog clones rasos.

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

Para saber mais sobre as tabelas do Unity Catalog, consulte O que é uma tabela?

Criar um clone superficial no Unity Catalog

O senhor pode criar um clone raso no Unity Catalog usando a mesma sintaxe disponível para clones rasos em todo o produto, conforme mostrado no exemplo de sintaxe a seguir:

SQL

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name> SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>

Para criar um shallow clone em Unity Catalog, o senhor deve ter privilégios suficientes no recurso de origem e no recurso de destino, conforme detalhado na tabela a seguir:

Recursos	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

Assim 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.

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

important

As instruções desta seção descrevem os privilégios necessários para compute configurado com o modo de acesso padrão (antigo modo de acesso compartilhado). Para o modo de acesso dedicado (antigo modo de acesso de usuário único), consulte Trabalhar com tabelas clonadas superficiais no modo de acesso dedicado.

Para consultar um shallow clone em Unity Catalog, o senhor deve ter privilégios suficientes na tabela e no recurso que a contém, conforme detalhado na tabela a seguir:

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

O senhor também deve ter as permissões MODIFY no destino das operações de clonagem para concluir as seguintes ações:

• Inserir registros
• Excluir registros
• Atualizar registros
• MERGE
• CREATE TABLE
• DROP TABLE

vacuum e clones rasos Unity Catalog

important

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.

Quando o senhor usa tabelas Unity Catalog para a origem e o destino de uma operação de clone superficial, Unity Catalog gerencia os arquivos de dados subjacentes para aumentar a confiabilidade da origem e do destino das operações de clone. Executar VACUUM na origem de um clone superficial não quebra a tabela clonada.

Normalmente, quando o site 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 rasos para o Unity Catalog rastreia os relacionamentos entre todas as tabelas clonadas e os arquivos de dados de origem, de modo que os arquivos válidos são expandidos para incluir os arquivos de dados necessários para retornar consultas de qualquer tabela clonada rasa, bem como da tabela de origem.

Isso significa que, para a semântica do Unity Catalog shallow clone VACUUM, 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 gerenciais e as tabelas externas têm uma semântica ligeiramente diferente.

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

• Para gerenciar tabelas, VACUUM operações contra a origem ou o destino de uma operação de clone raso podem excluir arquivos de dados da tabela de origem.
• Para tabelas externas, VACUUM operações só removem arquivos de dados da tabela de origem quando executadas contra a tabela de origem.
• Somente arquivos de dados não considerados válidos para a tabela de origem ou qualquer clone superficial da fonte são removidos.
• Se vários clones superficiais forem definidos em uma única tabela de origem, a execução de VACUUM em qualquer uma das tabelas clonadas não removerá os arquivos de dados válidos de outras tabelas clonadas.

nota

A Databricks recomenda nunca executar o site VACUUM com uma configuração de retenção inferior a 7 dias para evitar a corrupção de transações em andamento de longa duração. Se o senhor precisar executar VACUUM com um limite de retenção mais baixo, certifique-se de entender como VACUUM em clones rasos em Unity Catalog difere de como VACUUM interage com outras tabelas clonadas em Databricks. Consulte Clonar uma tabela em Databricks.

Trabalhe com tabelas clonadas superficiais no modo de acesso dedicado

Ao trabalhar com Unity Catalog shallow clones no modo de acesso dedicado, o senhor deve ter permissões no recurso 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 as permissões USE no catálogo e no esquema de origem e as permissões SELECT na tabela de origem. Para qualquer consulta que atualize ou insira registros na tabela de destino, você também deve ter as permissões MODIFY na tabela de origem.

Databricks recomenda trabalhar com clones Unity Catalog em compute com o modo de acesso padrão, pois isso permite a evolução independente das permissões para alvos de clones rasos Unity Catalog e suas tabelas de origem.

Limitações

• Clones superficiais em tabelas externas devem ser tabelas externas. Os clones rasos em tabelas gerenciar devem ser tabelas gerenciar.
• Você não pode usar REPLACE ou CREATE OR REPLACE para substituir um clone superficial existente. Em vez disso, DROP o shallow clone e executa uma nova declaração CREATE.
• O senhor não pode compartilhar clones rasos usando o Delta Sharing.
• Você não pode aninhar clones superficiais, o que significa que você não pode criar um clone superficial a partir de um clone superficial.
• Para tabelas gerenciáveis, a eliminação da tabela de origem quebra a tabela de destino para clones rasos. Os arquivos de dados que fazem o backup de tabelas externas não são removidos pelas operações do site DROP TABLE e, portanto, os clones rasos de tabelas externas não são afetados pela eliminação da fonte.
• 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 sete dias. Se você não usar UNDROP na tabela de origem nessa janela, o clone superficial deixará de funcionar quando os arquivos de dados da tabela de origem forem coletados como lixo.