Clone raso para tabelas Unity Catalog

info

Visualização

Esse recurso está em Prévia Pública.

importante

O suporte para clones rasos difere para tabelas gerenciadas do Unity Catalog e tabelas externas. Para tabelas gerenciadas, use o Databricks Runtime 13.3 e acima, e para tabelas externas, use o Databricks Runtime 14.2 e acima.

Só é possível clonar tabelas gerenciadas do Unity Catalog para tabelas gerenciadas do Unity Catalog, e tabelas externas do Unity Catalog para tabelas externas do Unity Catalog. VACUUM O comportamento difere entre tabelas gerenciadas e externas. Consulte Usar VACUUM com clones rasos do Unity Catalog.

É possível usar o clone raso para criar novas tabelas Unity Catalog a partir de tabelas Unity Catalog existentes. O suporte a clone raso para Unity Catalog permite criar tabelas com privilégios de controle de acesso independentemente de suas tabelas pai, sem a necessidade de copiar os arquivos de dados subjacentes.

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

Criar um clone raso gerenciado pelo Unity Catalog

Crie um clone raso de uma tabela gerenciada no 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 raso gerenciado no Unity Catalog, é preciso 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

Assim como ocorre com outras declarações de criação de tabela, o usuário que cria um clone raso é o proprietário da tabela de destino. O proprietário de uma tabela de destino clonada controla os direitos de acesso dessa tabela independentemente da tabela de origem. Isso significa que o proprietário de uma tabela clonada pode ser diferente do proprietário de uma tabela de origem.

Criar um clone raso externo do Unity Catalog

Crie um clone raso externo do Unity Catalog ao especificar 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 raso externo no Unity Catalog, é necessário ter os seguintes privilégios nos recursos de origem e 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
Localização externa de destino	CREATE EXTERNAL TABLE

Trabalhar com tabelas de clone raso 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 nos recursos que a contêm.

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

Você deve também ter MODIFY permissões no destino da operação de clonagem para concluir as seguintes ações.

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

Trabalhar com tabelas clonadas rasas em modo de acesso dedicado

Ao trabalhar com clones rasos do Unity Catalog no modo de acesso dedicado (anteriormente modo de acesso de usuário único), é preciso ter permissões nos recursos da origem da tabela clonada, assim como na tabela de destino.

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

A Databricks recomenda trabalhar com clones do Unity Catalog no compute com modo de acesso padrão, pois isso permite a evolução independente das permissões para destinos de clone raso do Unity Catalog e suas tabelas de origem.

Use VACUUM com clones rasos do Unity Catalog

Ao usar tabelas Unity Catalog para a origem e o destino de uma operação de clone raso, 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 um clone raso não danifica a tabela clonada.

Normalmente, quando VACUUM identifica arquivos válidos para um determinado limite de retenção, somente os metadados da tabela atual são considerados. No entanto, o suporte a clone raso para o Unity Catalog rastreia os relacionamentos entre todas as tabelas clonadas e os arquivos de dados de origem, portanto, os arquivos válidos são expandidos para incluir arquivos de dados necessários para retornar consultas para qualquer tabela clonada rasa, bem como a tabela de origem.

Isso significa que, para a semântica de clone raso VACUUM 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. Tabelas gerenciadas e tabelas externas têm semânticas ligeiramente diferentes.

Este acompanhamento aprimorado de metadados altera como as VACUUM operações impactam os arquivos de dados subjacentes para as tabelas do Delta Lake, com a seguinte semântica.

• Para tabelas gerenciadas, VACUUM operações contra a origem ou o destino de uma operação de clone superficial podem excluir arquivos de dados da tabela de origem.
• Para tabelas externas, as operações de VACUUM removem arquivos de dados da tabela de origem apenas quando executadas na tabela de origem.
• Apenas os arquivos de dados não considerados válidos para a tabela de origem ou para qualquer clone superficial da origem são removidos.
• Se várias clones rasas são definidas em relação a uma única tabela de origem, a execução de VACUUM em qualquer uma das tabelas clonadas não remove arquivos de dados válidos para outras tabelas clonadas.

nota

Databricks recomenda nunca executar VACUUM com uma configuração de retenção de menos de 7 dias para evitar corromper transações de execução longa em andamento. Se você precisar executar VACUUM com um limite de retenção mais baixo, certifique-se de entender como VACUUM em clones rasos 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 rasa seja descartada, poderá ser necessário SELECT acesso a essa tabela clonada rasa para executar VACUUM na tabela base. O Databricks lê o log Delta do clone raso para verificar quais arquivos de dados da tabela base o clone ainda referencia antes de executar o VACUUM neles. A Databricks mantém este link por 7 dias depois que uma tabela de clone raso é descartada para dar suporte à operação UNDROP. No modo de acesso padrão, no entanto, esta permissão não é necessária.

Descarte a tabela base para um clone raso

Se a tabela base de um clone raso for descartada, o clone se torna inutilizável. Por padrão, o Databricks impede a exclusão de uma tabela base se ela ainda tiver clones rasos fazendo referência a ela.

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

• A tabela base é excluída imediatamente.
• Todos os clones rasos referenciados tornam-se quebrados e:
  • Falhar 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.

Este comportamento aplica-se apenas a tabelas gerenciadas do Unity Catalog. Para obter mais informações, consulte DROP TABLE.

Limitações

• Clones rasos em tabelas externas devem ser tabelas externas. Clones rasos em tabelas gerenciadas devem ser tabelas gerenciadas.
• Não é possível usar REPLACE ou CREATE OR REPLACE para sobrescrever um clone raso existente. Em vez disso, DROP o clone raso e execute uma nova instrução CREATE.
• Não é possível compartilhar clones rasos usando o OpenSharing.
• Não é possível aninhar clones rasos, o que significa que não é possível criar um clone raso a partir de um clone raso.
• Para tabelas gerenciadas, descartar a tabela de origem invalida a tabela de destino para clones rasos. Os arquivos de dados subjacentes para tabelas externas não são removidos por DROP TABLE operações e, portanto, clones superficiais de tabelas externas não são impactados ao descartar a origem.
• O Unity Catalog permite que os usuários UNDROP tabelas gerenciadas por cerca de 7 dias após um comando DROP TABLE. No Databricks Runtime 13.3 LTS e acima, clones rasos gerenciados de uma tabela de origem descartada continuam a funcionar durante o período de 7 dias em que o Unity Catalog oferece suporte a UNDROP. Se a tabela de origem não for restaurada dentro daquele período, o clone superficial deixa de funcionar quando os arquivos de dados de origem forem excluídos durante a coleta de lixo.