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 LTS e acima, e para tabelas externas, use o Databricks Runtime 14.3 LTS 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.

Use o clone raso para criar tabelas do Unity Catalog com privilégios de controle de acesso independentes de suas tabelas de origem, sem copiar os arquivos de dados subjacentes. O clone raso no Unity Catalog é compatível apenas com tabelas Delta Lake. Não é possível criar um clone raso de uma tabela Iceberg ou outra que não seja Delta.

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

Como outras instruções de criação de tabela, ao realizar a execução de SHALLOW CLONE, você se torna 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. 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 raso em modo de acesso padrão (antigo modo de acesso compartilhado), é preciso 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

É preciso também ter permissões MODIFY no destino da operação de clonagem para a execução das seguintes operações:

• INSERT
• DELETE
• UPDATE
• 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 (antigo modo de acesso de usuário único), você deve ter permissões nos recursos para a fonte da tabela clonada e para a tabela de destino.

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

A Databricks recomenda usar clones do Unity Catalog em compute com modo de acesso padrão, visto que isso permite alterações independentes de 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. A execução de VACUUM na origem de um clone raso não quebra 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, assim, os arquivos válidos são expandidos para incluir os arquivos de dados necessários para retornar consultas para as tabelas clonadas rasas e para a tabela de origem.

Para VACUUM em um clone raso 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 comportamentos ligeiramente diferentes.

Este acompanhamento aprimorado de metadados altera como as operações VACUUM afetam os arquivos de dados subjacentes para as tabelas Delta Lake, com o seguinte comportamento:

• Para tabelas gerenciadas, VACUUM operações na origem ou no destino de uma operação de clone raso 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

O Databricks recomenda que você nunca execute 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 de um limite de retenção mais baixo, considere como VACUUM em clones rasos no Unity Catalog difere de como VACUUM afeta outras tabelas clonadas no Databricks. Para obter mais informações, consulte Clonar uma tabela no Databricks.

Mesmo que você descarte uma tabela de clone raso, você pode exigir acesso SELECT a essa tabela de clone raso para a execução de 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. O Databricks mantém este link por 7 dias após descartar uma tabela de clone raso para oferecer 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 você descartar a tabela base de um clone raso, 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:
  • Clones rasos falham em operações que exigem a leitura de dados ou metadados (por exemplo, SELECT, INSERT, UPDATE, DESCRIBE HISTORY, CLONE).
  • Para permitir a limpeza, os clones rasos ainda são visíveis por meio de operações em nível de metadados (por exemplo, SHOW TABLES, DROP TABLE).

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

Limitações

• Clone raso tem suporte somente para tabelas do Delta Lake. Não é possível criar um clone superficial de uma tabela Iceberg ou de outra tabela que não seja Delta.
• Clones rasos em tabelas externas devem ser tabelas externas. Clones rasos em tabelas gerenciadas devem ser tabelas gerenciadas.
• 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.