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

Podes eliminar a tabela base de uma tabela gerida pelo Unity Catalog mesmo quando clones vivos e superficiais ainda a referenciam. Os clones continuam a ler até que os ficheiros de dados da tabela base sejam eliminados, o que os torna inutilizáveis. Pode restaurar a tabela base com UNDROP durante o respetivo período de recuperação, que, por predefinição, é de 7 dias, e esse período pode ser definido ao nível do catálogo ou do esquema para 0 (para desativar a recuperação) ou entre 7 e 30 dias. A configuração do período de recuperação é feita em Pré-visualização Pública. Se não restaurares a tabela, um processo de purga assíncrona apaga os ficheiros de dados dela após o fim do período de recuperação, para que os clones possam continuar a ler durante algum tempo depois de a tabela base deixar de ser recuperável. Para recuperar uma tabela base caída, usa UNDROP.

Limitations

• A clonagem superficial é 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.
• Não podes usar CREATE OR REPLACE para sobrescrever um clone superficial existente. Use DROP TABLE seguido de CREATE TABLE, ou use um novo nome de tabela.
• 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 externas, DROP TABLE não remove os ficheiros de dados subjacentes, pelo que clones superficiais não são afetados quando a tabela de origem é descartada.
• Para tabelas geridas no Databricks Runtime 13.3 LTS e superiores, clones superficiais de uma tabela de origem eliminada continuam a funcionar até que os ficheiros de dados de origem sejam eliminados. Consulte Eliminar a tabela base para um clone superficial.