Clone raso para tabelas Unity Catalog
Visualização
Esse recurso está em Prévia Pública.
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.
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 |
|
Catálogo de origem |
|
Esquema de destino |
|
Catálogo de destino |
|
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.
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 |
|
Catálogo de origem |
|
Esquema de destino |
|
Catálogo de destino |
|
Localização externa de destino |
|
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 |
|
Esquema |
|
Tabela |
|
É preciso também ter permissões MODIFY no destino da operação de clonagem para a execução das seguintes operações:
INSERTDELETEUPDATEMERGECREATE TABLEDROP 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,
VACUUMoperaçõ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
VACUUMremovem 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
VACUUMem qualquer uma das tabelas clonadas não remove arquivos de dados válidos para outras tabelas clonadas.
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
Você pode excluir a tabela base de uma tabela gerenciada do Unity Catalog mesmo quando clones rasos ativos ainda fizerem referência a ela. Os clones continuam fazendo leituras até que os arquivos de dados da tabela base sejam excluídos, o que os torna inutilizáveis. Você pode restaurar a tabela base com UNDROP durante o período de recuperação, que tem o default de 7 dias e pode ser definido no nível de catálogo ou de esquema como 0 (para desativar a recuperação) ou de 7 a 30 dias. A configuração do período de recuperação está em Pré-lançamento público. Se você não restaurar a tabela, um processo de limpeza assíncrono excluirá os arquivos de dados após o término do período de recuperação, para que os clones possam continuar fazendo a leitura por um tempo após a tabela base não ser mais recuperável. Para recuperar uma tabela base removida, use UNDROP.
Some workspaces enforce drop-time protection for base tables that have shallow clones. If DROP TABLE on such a base table fails with the CANNOT_DROP_BASE_TABLE_REFERENCED_BY_SHALLOW_CLONE error, your workspace enforces this protection. To drop the base table anyway, use DROP TABLE ... FORCE. Dropping the base table with FORCE breaks the referencing shallow clones. As falhas ocorrem em operações que leem dados ou metadados (por exemplo, SELECT, INSERT, UPDATE, DESCRIBE HISTORY, CLONE), mas os clones continuam visíveis para operações no nível de metadados (por exemplo, SHOW TABLES, DROP TABLE) para que você possa limpá-los. This protection applies only to Unity Catalog managed tables.
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.
- Não é possível usar
CREATE OR REPLACEpara substituir um clone raso existente. UseDROP TABLEseguido porCREATE TABLEou use um novo nome de tabela. - 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.
- For external tables,
DROP TABLEdoes not remove the underlying data files, so shallow clones are not affected when the source table is dropped. - Para tabelas gerenciadas no Databricks Runtime 13.3 LTS e acima, os clones rasos de uma tabela de origem descartada continuam funcionando até que os arquivos de dados de origem sejam excluídos. Consulte Descartar a tabela base para um clone raso.