DP-700: cargas incrementais com watermark em Fabric

João Barros 21 de July de 2026 6 min de leitura

Vou ensinar como implementar cargas incrementais (incremental loads) usando uma coluna watermark em pipelines de ingestão no Microsoft Fabric. Esta competência é frequente no exame DP-700 e, na prática, reduz custos e tempo de processamento ao evitar recarregar toda a tabela. Aplicando este padrão, podes passar de processar dezenas ou centenas de gigabytes por execução para apenas alguns megabytes ou alguns milhares de registos, dependendo da taxa de alteração dos dados.

O que precisas de saber

Uma carga incremental carrega apenas os registos novos ou alterados desde a última execução. A técnica mais comum usa uma coluna temporal ou numérica (o «watermark") que identifica até que ponto os dados já foram lidos. Em Fabric isso aplica‑se quando usas Power Query ou Dataflows para filtrar linhas antes de escrever para um Lakehouse/table.

Tipos de watermark e quando os usar: colunas DateTime (TransactionDate) são preferíveis quando os registos têm carimbos temporais fiáveis; identificadores sequenciais (ID crescente) são úteis em streams ordenados. Para grandes volumes (por exemplo 100M de registos diários), uma carga incremental pode reduzir o trabalho em >95% se apenas 5M forem novos.

Cuidados práticos: define a granularidade (segundos, minutos, dias), toma atenção a timezones (UTC versus locais) e converte tipos explicitamente para evitar falhas. Decide também uma janela de tolerância para late arriving data (por exemplo 3–7 dias), pois reenvios e backfills são comuns num ecossistema real.

Na prática: passo-a-passo

Segue estes passos práticos para implementar um padrão de carga incremental, com exemplos concretos.

Escolher a coluna watermark: preferência por colunas de carimbo temporal (DateTime) ou um identificador crescente (ID sequencial). Evita usar a data de modificação do ficheiro se os dados internos têm datas próprias.
Criar uma tabela de controlo (control table): persiste o last watermark num pequeno table no Lakehouse ou num ficheiro de metadados em OneLake. Exemplo de esquema: (datasource_id STRING, last_watermark DATETIME, last_max_id BIGINT NULL, updated_at DATETIME, run_id STRING). Para 50 fontes diferentes, a tabela terá 50 linhas; para um único fluxo, uma única linha basta.
Criar o Dataflow/Power Query: adiciona um parâmetro (por exemplo LastWatermark) e aplica um filtro na query para apenas selecionar linhas onde TransactionDate > LastWatermark. Isto diminui drasticamente os dados lidos e transforma IO e CPU em proporções lineares com a taxa de mudança.

let
  Source = Csv.Document(File.Contents("/path/to/file.csv"),[Delimiter=",", Columns=5, Encoding=65001, QuoteStyle=QuoteStyle.Csv]),
  ToTable = Table.FromRows(Source, {"TransactionID","TransactionDate","Amount","Customer"}),
  ParsedDate = Table.TransformColumnTypes(ToTable, {{"TransactionDate", type datetime}}),
  Filtered = Table.SelectRows(ParsedDate, each [TransactionDate] > DateTime.FromText(Parameters[LastWatermark]))
in
  Filtered

Nota: em Power Query usado no Fabric, o parâmetro Parameters[LastWatermark] vem do pipeline que executa o Dataflow. Podes também parametrizar por datasource_id para multi‑fonte.

Gravar os dados no Lakehouse com lógica de upsert: se precisares de manter a tabela actualizada (actualizações e eliminações), usa a operação de MERGE/Upsert suportada pelo Lakehouse ou escreve para uma tabela staging e executa um MERGE SQL/Delta posteriormente. Exemplo: inserir 200k registos novos e 5k actualizações por execução é típico num cenário médio.
Atualizar o watermark: após sucesso da carga, calcula o novo last watermark (por exemplo SELECT MAX(TransactionDate) dos dados carregados) e grava-o na tabela de controlo. Se processaste 1M registos com máximo 2026-07-20T12:34:56Z, escreve esse carimbo como novo watermark. Usa transacção ou operação atómica para evitar condições de corrida.
Agendar e monitorizar: configura o pipeline para correr com a frequência desejada (diária, horária). Para dados de telemetria podes agendar a cada 15 minutos; para vendas talvez uma vez por hora ou por dia. Adiciona alertas para falhas e métricas (registos processados, tempo de execução, percentagem incremental) para garantir observabilidade.

Erros comuns

Usar a data do ficheiro em vez da data do registo: a data de criação do ficheiro pode não refletir quando os registos foram gerados. Isso causa duplicação ou perda de dados quando ficheiros são reenviados.
Não tratar dados atrasados (late arriving data): se tiveres registos com TransactionDate anterior ao last watermark, vais perdê‑los. Soluções: janela de tolerância (p.ex. reprocessar últimos 7 dias), chave de deduplicação com MERGE e logs de auditing para identificar perdas. Em percentagens concretas, um sistema com 0,5–2% de registos tardios pode representar valores financeiros significativos se não for tratado.
Não gerir schema drift: adicionar ou renomear colunas sem alteração da lógica pode quebrar a pipeline; seleciona explicitamente as colunas necessárias, valida o esquema no início da execução e aplica transformações defensivas.
Condições de concorrência: várias execuções paralelas podem ler e actualizar a tabela de controlo simultaneamente; usa mecanismos de locking, run_id e testes de idempotência para prevenir corridas.

Como praticar

Pratica este padrão com uma conta trial do Microsoft Fabric e um pequeno conjunto de ficheiros CSV em OneLake ou Blob Storage. Cria 30 ficheiros diários com 1k–10k registos cada, simula late arrivals reenviando alguns ficheiros e observa como o workload muda quando aplicas o filtro por watermark. Implementa a pipeline em três componentes: Dataflow (Power Query) que filtra por watermark, uma tabela de controlo no Lakehouse para guardar o last watermark e uma tarefa de MERGE/upsert para aplicar alterações.

Para preparar o DP-700, utiliza o Practice Assessment oficial da Microsoft (gratuito) e a Study Guide oficial da Microsoft Learn (gratuita). Esses recursos ajudam a validar a tua compreensão das skills medidas e a praticar cenários sem recorrer a materiais não autorizados.

Em resumo

Cargas incrementais com watermark reduzem tempo e custos ao ingestarem apenas novos/alterados registos — muitas vezes com ganhos de desempenho na ordem dos 80–99% em I/O e CPU, consoante a taxa de alteração.
Precisas de uma coluna de watermark, uma tabela de controlo para o last watermark e pipelines que apliquem filtros antes de escrever no Lakehouse.
Trata late arriving data, actualizações (upsert/merge), schema drift e concorrência para garantir fiabilidade.
Pratica no Fabric com Dataflows/Power Query, Lakehouse e a tabela de controlo; usa os recursos oficiais da Microsoft para estudo e validação.