Como fazer merge incremental de ficheiros Parquet em Azure Data Factory

João Barros 02 de November de 2026 4 min de leitura

Este tutorial explica como implementar um processo de merge incremental de ficheiros Parquet em Azure Data Factory (ADF) para manter um Lakehouse atualizado. É útil para evitar duplicados e aplicar actualizações ou eliminações em dados analíticos sem reconstruir tudo.

Pré-requisitos

Conta Azure com permissões para criar recursos.
Azure Data Factory v2 criado.
Azure Data Lake Storage Gen2 (ADLS Gen2) ou contentor com ficheiros Parquet de origem e destino.
Conhecimentos básicos de Parquet, SQL e actividade Copy/Data Flow no ADF.

Passo 1: Conceito e estratégia do merge incremental

Antes de criar o pipeline, definimos a estratégia: vamos identificar ficheiros Parquet de origem que representam novos registos ou actualizações, e aplicar um merge para actualizar a tabela destino armazenada como Parquet. O padrão comum é usar uma coluna de chave natural (id) e uma coluna de controlo de versão/updated_at.

Passo 2: Preparar folders e naming

Organiza os ficheiros no ADLS Gen2 em duas pastas: /bronze/incremental/ para ficheiros de input e /silver/tables/<nome>/ para o destino. Usa nomes com timestamp para facilidade de rastreio.

Passo 3: Criar Linked Services e Datasets no ADF

Configura um Linked Service para ADLS Gen2 com Managed Identity ou Service Principal. Depois cria dois Datasets Parquet: um para a origem incremental e outro para a tabela destino.

// Exemplo conceptual de JSON do dataset (simplificado)
{
  "name": "ParquetDatasetSource",
  "properties": {
    "linkedServiceName": { "referenceName": "LS_ADLSGen2", "type": "LinkedServiceReference" },
    "type": "Parquet",
    "typeProperties": { "location": { "type": "AzureBlobFSLocation", "fileSystem": "data", "folderPath": "bronze/incremental" } }
  }
}

Passo 4: Usar Mapping Data Flow para efectuar o merge

O componente mais prático é um Mapping Data Flow que lê origem incremental e destino e faz um join por chave para decidir inserir, actualizar ou manter. O Data Flow permite operações tipo MERGE usando transformações de conditional split e sink com update/insert.

// Fluxo simplificado de transformações no Data Flow
1. SourceA: leitor da origem incremental (Parquet)
2. SourceB: leitor da tabela destino (Parquet)
3. Join: left join SourceA.id == SourceB.id
4. DerivedColumn: calcular action = iif(isNull(SourceB.id), 'insert', iif(SourceA.updated_at > SourceB.updated_at, 'update', 'skip'))
5. FilterInsert: action == 'insert'
6. FilterUpdate: action == 'update'
7. SinkInsert: modo insert para destino Parquet (append)
8. SinkUpdate: modo update com chave id (modo upsert se suportado) ou escrever para staging e substituir

Passo 5: Configurar o Sink para upsert ou replace

Parquet não tem transacções nativas; para upsert recomendo duas opções: (A) usar um formato compatível com Upsert (ex.: Delta Lake) se disponível; (B) implementar padrão: escrever resultado completo actualizado para um directório temporário e depois substituir o directório destino. No ADF Data Flow podes escrever o ficheiro actualizado para /silver/tables/<nome>_tmp e, depois, um passo de copy/rename para substituir.

Passo 6: Pipeline ADF para orquestração

Cria um pipeline que orquestra: (1) validar ficheiros novos (Get Metadata ou Lookup), (2) executar o Mapping Data Flow, (3) mover ficheiros processados para archive e (4) substituir destino se necessário. Parametriza com datasetPath e runId para reutilização.

// Exemplo de sequência no pipeline (pseudocode)
- Get Metadata (folder bronze/incremental) -> outputs.list
- If length(outputs.list)>0 then
    - Data Flow activity (mergeFlow) with param sourcePath
    - If write to tmp, então Copy Activity para mover tmp -> silver e Remove antiga pasta
    - Move source files -> /archive/yyyyMMdd

Verificar o resultado

Confirmar que não existem duplicados: abre a pasta /silver/tables/<nome> e valida count por id (usar Notebook, Synapse ou Power BI). Verifica timestamps updated_at e compara alguns registos que deveriam ter sido actualizados. Confirma também que os ficheiros na pasta bronze foram movidos para archive.

Conclusão

Com este padrão de merge incremental em Azure Data Factory consegues manter um Lakehouse actualizado sem reconstruções completas. Próximos passos: adaptar para Delta Lake para upserts nativos, adicionar controlo de versões e alertas. Dica: testa com pequenos conjuntos e valida antes de aplicar em produção — qual o maior desafio que tens no teu cenário?