Clone incrementalmente as mesas Parquet e Iceberg para o Lago Delta

Você pode usar a funcionalidade de clonagem do Azure Databricks para converter incrementalmente dados de fontes de dados Parquet ou Iceberg em tabelas Delta gerenciadas ou externas.

O clone do Azure Databricks para Parquet e Iceberg combina a funcionalidade usada para clonar tabelas Delta e converter tabelas em Delta Lake. Este artigo descreve casos de uso e limitações para esse recurso e fornece exemplos.

Importante

Esta funcionalidade está em Pré-visualização Pública.

Nota

Esse recurso requer o Databricks Runtime 11.3 ou superior.

Quando usar clone para ingestão incremental de dados de Parquet ou Iceberg

O Azure Databricks fornece várias opções para ingerir dados na casa do lago. A Databricks recomenda o uso de clones para ingerir dados de Parquet ou Iceberg nas seguintes situações:

Nota

O termo tabela de origem refere-se à tabela e aos arquivos de dados a serem clonados, enquanto a tabela de destino refere-se à tabela Delta criada ou atualizada pela operação.

  • Você está realizando uma migração de Parquet ou Iceberg para Delta Lake, mas precisa continuar usando tabelas de origem.
  • Você precisa manter uma sincronização somente de ingestão entre uma tabela de destino e uma tabela de origem de produção que recebe acréscimos, atualizações e exclusões.
  • Você deseja criar um instantâneo compatível com ACID de dados de origem para relatórios, aprendizado de máquina ou ETL em lote.

Qual é a sintaxe para clone?

Clone for Parquet e Iceberg usa a mesma sintaxe básica usada para clonar tabelas Delta, com suporte para clones rasos e profundos. Para obter mais informações, consulte Tipos de clones.

O Databricks recomenda o uso incremental do clone para a maioria das cargas de trabalho. O suporte de clonagem para Parquet e Iceberg usa sintaxe SQL.

Nota

Clone para Parquet e Iceberg tem requisitos e garantias diferentes de clonar ou converter para Delta. Consulte Requisitos e limitações para clonagem de tabelas Parquet e Iceberg.

Para clonar profundamente uma tabela Parquet ou Iceberg usando um caminho de arquivo, use a seguinte sintaxe:

CREATE OR REPLACE TABLE <target-table-name> CLONE parquet.`/path/to/data`;

CREATE OR REPLACE TABLE <target-table-name> CLONE iceberg.`/path/to/data`;

Para clonar superficialmente uma tabela Parquet ou Iceberg usando um caminho de arquivo, use a seguinte sintaxe:

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE parquet.`/path/to/data`;

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE iceberg.`/path/to/data`;

Você também pode criar clones profundos ou superficiais para tabelas do Parquet registradas no metastore, conforme mostrado nos exemplos a seguir:

CREATE OR REPLACE TABLE <target-table-name> CLONE <source-table-name>;

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE <source-table-name>;

Requisitos e limitações para clonagem de tabelas Parquet e Iceberg

Seja usando clones profundos ou superficiais, as alterações aplicadas à tabela de destino após a ocorrência do clone não podem ser sincronizadas de volta com a tabela de origem. A sincronização incremental com clone é unidirecional, permitindo que as alterações nas tabelas de origem sejam aplicadas automaticamente às tabelas Delta de destino.

As seguintes limitações adicionais se aplicam ao usar clone com tabelas Parquet e Iceberg:

  • Você deve registrar tabelas do Parquet com partições em um catálogo, como o metastore do Hive, antes de clonar e usar o nome da tabela para identificar a tabela de origem. Não é possível usar sintaxe de clone baseada em caminho para tabelas Parquet com partições.
  • Não é possível clonar tabelas Iceberg que tenham experimentado evolução de partição.
  • Não é possível clonar tabelas de mesclagem em leitura do Iceberg que tenham sofrido atualizações, exclusões ou mesclagens.
  • A seguir estão as limitações para clonar tabelas Iceberg com partições definidas em colunas truncadas:
    • No Databricks Runtime 12.2 LTS e inferior, o único tipo de coluna truncada suportado é string.
    • No Databricks Runtime 13.3 LTS e superior, você pode trabalhar com colunas truncadas dos tipos string, longou int.
    • O Azure Databricks não suporta trabalhar com colunas truncadas do tipo decimal.
  • O clone incremental sincroniza as alterações de esquema e as propriedades da tabela de origem. Todas as alterações de esquema e arquivos de dados gravados diretamente na tabela clonada são substituídos.
  • O Unity Catalog não suporta clones superficiais para tabelas Parquet ou Iceberg.
  • Não é possível usar padrões glob ao definir um caminho.

Nota

No Databricks Runtime 11.3, essa operação não coleta estatísticas no nível de arquivo. Como tal, as tabelas de destino não se beneficiam do salto de dados do Delta Lake. As estatísticas de nível de arquivo são coletadas no Databricks Runtime 12.2 LTS e superior.