Clone superficial para tabelas do Unity Catalog

info

Visualização

Este recurso está em Pré-visualização Pública.

importante

O suporte para clonagem superficial difere entre o gerenciamento Unity Catalog e tabelas externas. Para gerenciar tabelas, utilize Databricks Runtime 13.3 ou superior, e para tabelas externas, utilize Databricks Runtime 14.2 ou superior.

Você só pode clonar tabelas Unity Catalog para tabelas Unity Catalog e tabelas externas Unity Catalog para tabelas externas Unity Catalog . O comportamento de VACUUM difere entre tabelas gerenciadas e externas. Consulte Usar VACUUM com clones superficiais Unity Catalog.

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.

Para obter informações sobre como clonar uma tabela, consulte Clonar uma tabela no Databricks.

Criar um Unity Catalog gerencie um clone superficial

Crie um clone superficial de uma tabela do Unity Catalog.

SQL

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

Para criar um clone superficial de gerenciamento no Unity Catalog, você precisa ter os seguintes privilégios no recurso de origem e no recurso de destino.

Recursos	Permissões necessárias
Esquema de origem	USE SCHEMA
Catálogo de origem	USE CATALOG
Esquema de destino	USE SCHEMA, CREATE TABLE
Catálogo de destino	USE CATALOG

Assim 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 de destino clonada controla os direitos de acesso a essa tabela independentemente da tabela de origem. Isso significa que o proprietário de uma tabela clonada pode ser diferente do proprietário da tabela de origem.

Criar um clone superficial externo Unity Catalog

Crie um clone externo superficial Unity Catalog especificando um local externo.

SQL

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>
LOCATION 's3://<bucket-name>/<path-name>/<target-table-name>'

Para criar um clone superficial externo no Unity Catalog, você precisa ter os seguintes privilégios nos recursos de origem e destino.

Recursos	Permissões necessárias
Esquema de origem	USE SCHEMA
Catálogo de origem	USE CATALOG
Esquema de destino	USE SCHEMA, CREATE TABLE
Catálogo de destino	USE CATALOG
Localização externa alvo	CREATE EXTERNAL TABLE

Trabalhar com tabelas clonadas superficiais no modo de acesso padrão

Para consultar um clone superficial no modo de acesso padrão (anteriormente modo de acesso compartilhado), você deve ter os seguintes privilégios na tabela e no recurso que a contém.

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

Você também deve ter 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

Trabalhe com tabelas clonadas superficiais no modo de acesso dedicado

Ao trabalhar com clones superficiais Unity Catalog no modo de acesso dedicado (anteriormente modo de acesso de usuário único), você deve ter permissões no recurso tanto para a tabela de origem clonada quanto 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 e esquema de origem 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.

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.

Use VACUUM com clones superficiais Unity Catalog

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 VACUUM identifica arquivos válidos para um determinado limite de retenção, apenas os metadados da tabela atual são considerados. No entanto, o suporte para clonagem superficial no 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 os arquivos de dados necessários para retornar consultas para qualquer tabela clonada superficialmente, bem como para a 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.

Este acompanhamento aprimorado de metadados altera a forma como as operações VACUUM impactam os arquivos de dados subjacentes para as 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 VACUUM com uma configuração de retenção inferior a 7 dias para evitar corromper transações de longa duração em andamento. Se você precisar executar VACUUM com um limite de retenção menor, certifique-se de entender como VACUUM em clones superficiais no Unity Catalog difere de como VACUUM interage com outras tabelas clonadas no Databricks. Para obter mais informações, consulte Clonar uma tabela no Databricks.

Além disso, mesmo que uma tabela clonada superficial seja descartada, você pode precisar de acesso SELECT a essa tabela clonada superficial para executar VACUUM na tabela base. O Databricks lê o log Delta do clone superficial para verificar quais arquivos de dados da tabela base o clone ainda referencia antes de realizar a limpeza (vacuum). Databricks mantém este link por 7 dias após uma tabela clonada superficial ser excluída para suportar as operações UNDROP . No modo de acesso padrão, porém, essa permissão não é necessária.

Elimine a tabela base para obter um clone superficial

Se a tabela base de um clone superficial for descartada, o clone se tornará inutilizável. Em default, Databricks impede que o senhor elimine uma tabela de base se ela ainda tiver clones rasos fazendo referência a ela.

Para substituir essa proteção, use a sintaxe DROP TABLE ... FORCE. Se você usar FORCE:

• A mesa base é descartada imediatamente.
• Todos os clones superficiais de referência são quebrados e:
  • Falha em operações que exigem a leitura de dados ou metadados (por exemplo, SELECT, INSERT, UPDATE, DESCRIBE HISTORY, CLONE).
  • Ainda são visíveis por meio de operações em nível de metadados (por exemplo, SHOW TABLES, DROP TABLE) para permitir a limpeza.

Esse comportamento se aplica somente às tabelas gerenciadas Unity Catalog . Para mais informações, veja DROP TABLE.

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 de clonagem superficial, excluir a tabela de origem quebra a tabela de destino. Os arquivos de dados subjacentes para tabelas externas não são removidos pelas operações DROP TABLE , portanto, clones superficiais de tabelas externas não são afetados pela remoção da origem.
• Unity Catalog permite que os usuários UNDROP gerenciem tabelas por cerca de 7 dias após um comando DROP TABLE . No Databricks Runtime 13.3 LTS e superior, gerenciar clones superficiais de uma tabela de origem excluída continua funcionando durante o período de 7 dias em que Unity Catalog oferece suporte UNDROP. Se a tabela de origem não for restaurada dentro desse período, o clone superficial para de funcionar quando os arquivos de dados de origem são excluídos durante a coleta de lixo.