Clonagem rasa para tabelas do Catálogo Unity

Use o clone superficial para criar tabelas do Unity Catalog com privilégios de controlo de acesso independentes das suas tabelas fonte, sem copiar os ficheiros de dados subjacentes. A clonagem superficial no Unity Catalog é suportada apenas para tabelas Delta Lake. Não podes criar um clone raso de uma tabela Iceberg ou de qualquer outra tabela não Delta.

Para informações sobre clonagem de uma tabela, veja Clonar uma tabela no Azure Databricks.

Criar um clone superficial gerido pelo Unity Catalog

Crie um clone superficial de uma tabela gerida no Unity Catalog.

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

Para criar um clone superficial gerido no Unity Catalog, é necessário possuir os seguintes privilégios nos recursos de origem e de destino.

Tal como outras instruções create table, quando executas SHALLOW CLONE, és o dono da tabela alvo. O proprietário de uma tabela alvo clonada controla os direitos de acesso dessa tabela independentemente da tabela de origem. O proprietário de uma tabela clonada pode ser diferente do proprietário de uma tabela de origem.

Criar um clone superficial externo do Unity Catalog

Crie um clone externo superficial do Unity Catalog especificando uma localização externa.

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 externo raso no Unity Catalog, deve ter os seguintes direitos sobre os recursos de origem e destino.

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

Para consultar um clone superficial no modo de acesso padrão (anteriormente modo de acesso partilhado), deve ter os seguintes privilégios na tabela e nos recursos que a contêm:

Tem também de ter permissões MODIFY no destino da operação de clonagem para executar as seguintes operações:

• INSERT
• DELETE
• UPDATE
• MERGE
• CREATE TABLE
• DROP TABLE

Trabalhar com tabelas clonadas superficiais no modo de acesso dedicado

Ao trabalhar com clones superficiais do Unity Catalog em modo de acesso dedicado (anteriormente modo de acesso de utilizador único), deve ter permissões sobre os recursos tanto para a tabela de origem clonada como para a tabela de destino.

Para consultas simples, além de ter as permissões necessárias na tabela de destino, deve ter permissões USE no catálogo e no esquema de origem e permissões SELECT na tabela de origem. Para qualquer consulta que atualize ou insira registos na tabela de destino, deve também ter permissões de MODIFY na tabela de origem.

A Databricks recomenda usar clones do Unity Catalog em computação com modo de acesso padrão, pois isto permite alterações independentes de permissões para os alvos de clones superficiais do Unity Catalog e as suas tabelas de fonte.

Utilização VACUUM com clones superficiais do Unity Catalog

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. Executar VACUUM na origem de uma clonagem superficial não danifica 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 a clones superficiais para o Unity Catalog acompanha as relações entre todas as tabelas clonadas e os ficheiros de dados de origem, pelo que os ficheiros válidos são expandidos para incluir ficheiros de dados necessários para devolver consultas tanto para tabelas clonadas superficiais como para a tabela de origem.

Para VACUUM num clone superficial do Unity Catalog, um ficheiro de dados válido é qualquer ficheiro dentro do período de retenção especificado para a tabela de origem ou para qualquer tabela clonada. Tabelas geridas e tabelas externas têm comportamentos ligeiramente diferentes.

Este acompanhamento melhorado dos metadados altera a forma como VACUUM as operações afetam os ficheiros de dados subjacentes para as tabelas Delta Lake, com o seguinte comportamento:

• Para tabelas geridas, as operações VACUUM quer na origem quer no destino de uma operação de clonagem superficial podem eliminar ficheiros 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 contra uma única tabela de origem, executar VACUUM em qualquer uma das tabelas clonadas não removerá arquivos de dados válidos para as outras tabelas clonadas.

Mesmo que elimines uma tabela de clone superficial, poderás precisar de acesso SELECT a essa tabela de clone superficial para executar VACUUM na tabela de base. O Databricks lê o log Delta do clone superficial para verificar quais são os ficheiros de dados da tabela base que o clone ainda refere antes de os remover. O Databricks mantém esta ligação durante 7 dias após lançar uma tabela clonada superficial para suportar a UNDROP operação. No modo de acesso padrão, no entanto, esta permissão não é necessária.

Remova a tabela base para um clone superficial

Se eliminares a tabela base de um clone superficial, o clone torna-se inutilizável. Por padrão, o Databricks impede que você elimine uma tabela base se ela ainda tiver clones superficiais fazendo referência a ela.

Para substituir essa proteção, use a DROP TABLE ... FORCE sintaxe. Caso utilize FORCE:

• A tabela base é descartada imediatamente.
• Todos os clones superficiais de referência ficam quebrados e:
  • Clones superficiais falham em operações que exigem leitura de dados ou metadados (por exemplo, SELECT, INSERT, UPDATE, DESCRIBE HISTORY, CLONE).
  • Para permitir a limpeza, os clones superficiais continuam visíveis em operações de nível de metadados (por exemplo, SHOW TABLES, DROP TABLE).

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

Limitations

• A clonagem superficial é suportada apenas para tabelas Delta Lake. Não podes criar um clone superficial de uma tabela Iceberg ou de qualquer outra tabela não Delta.
• Clones superficiais em tabelas externas devem ser tabelas externas. Clones superficiais em tabelas gerenciadas devem ser tabelas gerenciadas.
• Não podes partilhar clones superficiais usando o OpenSharing.
• Você não pode encadear clones superficiais, o que significa que você não pode criar um clone superficial a partir de outro clone superficial.
• Para tabelas gerenciadas, descartar a tabela de origem quebra a tabela de destino para clones superficiais. Os ficheiros de dados subjacentes para tabelas externas não são removidos pelas operações de DROP TABLE, pelo que clones superficiais de tabelas externas não são afetados pela remoção da fonte.
• O Unity Catalog permite que os usuários UNDROP gerenciem tabelas por cerca de 7 dias após um DROP TABLE comando. Nas versões do Databricks Runtime 13.3 LTS e superiores, clones superficiais geridos de uma tabela de origem removida continuam a funcionar durante o período de 7 dias em que o Unity Catalog suporta UNDROP. Se a tabela de origem não for restaurada dentro dessa janela, o clone superficial deixa de funcionar quando os ficheiros de dados de origem são eliminados durante a recolha de lixo.