Cópia superficial para tabelas do Unity Catalog

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.

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.

Assim como outras instruções de criação de tabela, o utilizador que cria um clone raso é dono da tabela de destino. O proprietário de uma tabela alvo clonada controla os direitos de acesso dessa tabela independentemente da tabela de origem. Isto significa que 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 associados.

Também deve ter MODIFY permissões sobre o alvo da operação de clonagem para completar as ações seguintes.

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

Trabalhar com tabelas clonadas superficiais no modo de acesso dedicado

Ao trabalhar com clones superficiais do Unity Catalog no modo de acesso dedicado (anteriormente conhecido como modo de acesso de utilizador único), deve ter permissões nos recursos tanto para a fonte da tabela clonada quanto para a tabela de destino.

Isto significa que, para consultas simples, além das permissões necessárias na tabela de destino, deve ter USE permissões no catálogo e esquema de origem e SELECT permissões na tabela de código-fonte. Para quaisquer consultas que atualizem ou insiram registros na tabela de destino, você também deve ter MODIFY permissões na tabela de origem.

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

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. A execução de 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 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 para qualquer tabela clonada superficial, bem como para 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.

Este acompanhamento melhorado dos metadados altera a forma como VACUUM as operações afetam os ficheiros de dados subjacentes para as tabelas Delta, com a seguinte semântica.

• Para tabelas geridas, VACUUM as operações realizadas na fonte 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 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.

Além disso, mesmo que uma tabela clonada superficial seja descartada, podes precisar SELECT de acesso a essa tabela clonada superficial para correr VACUUM na tabela 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. A Databricks mantém esta ligação durante 7 dias após uma tabela clonada superficial ser eliminada para suportar a operação de UNDROP. No modo de acesso padrão, no entanto, esta permissão não é necessária.

Remova a tabela base para um clone superficial

Se a tabela base de um clone superficial for descartada, o clone se tornará 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:
  • Falha em operações que exigem leitura de dados ou metadados (por exemplo, SELECT, , INSERT, UPDATEDESCRIBE HISTORY, CLONE).
  • Ainda são visíveis por meio de operações no nível de metadados (por exemplo, SHOW TABLES, DROP TABLE) para permitir a limpeza.

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

Limitações

• Clones superficiais em tabelas externas devem ser tabelas externas. Clones superficiais em tabelas gerenciadas devem ser tabelas gerenciadas.
• Não é possível usar REPLACE ou CREATE OR REPLACE para sobrescrever um clone superficial existente. Em vez disso, DROP o clone superficial e execute uma nova instrução CREATE.
• Não é possível compartilhar clones superficiais usando Delta Sharing.
• 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.