Ingestão de dados: batch, incremental e streaming

Antes do dashboard bonito, alguém precisa trazer o dado para dentro#

Toda conversa sobre analytics acaba esbarrando na mesma pergunta desconfortável: de quanto em quanto tempo o dado precisa estar atualizado? Essa pergunta parece simples, mas define arquitetura, custo e a dor de cabeça que você vai ter na madrugada. A ingestão de dados, o ato de trazer o dado da origem para a sua plataforma analítica, tem três padrões: batch, incremental e streaming. Escolher o padrão errado é o jeito mais rápido de gastar dinheiro à toa ou de entregar um relatório que já nasce desatualizado.

Neste artigo eu vou direto ao que interessa para quem decide: o que é cada um dos três padrões de ingestão de dados, quando cada um faz sentido, como implementar no Microsoft Fabric e o trade-off honesto entre frescor do dado, custo e complexidade. Vou dizer também onde cada padrão cobra o seu preço, porque essa parte quase ninguém conta na hora de vender.

Batch é a carga em lote agendada, e resolve a maioria dos casos#

A ingestão em batch é a mais antiga e a mais usada, por um bom motivo: ela funciona. O padrão é simples. Em um horário definido, tipicamente na madrugada, um processo lê um bloco de dados da origem e grava tudo de uma vez no destino. É a carga em lote agendada. Quando o time chega de manhã, os relatórios do dia anterior estão prontos.

O batch clássico carrega o conjunto inteiro. Se a sua tabela de vendas tem dois milhões de linhas, o processo lê os dois milhões, todo dia. Isso é chamado de carga full, ou carga completa. Parece desperdício, e em muitos casos é, mas para volumes pequenos e médios a carga full tem uma virtude enorme: ela é burra no bom sentido. Não guarda estado, não depende de saber o que mudou e não acumula erro ao longo do tempo. Se algo deu errado ontem, hoje o processo sobrescreve tudo e a base volta a ficar correta sozinha.

O que o batch entrega bem:

• Simplicidade de implementação e manutenção. Menos peças móveis, menos coisa para quebrar.
• Previsibilidade de custo. Você sabe quando roda e quanto processa.
• Recuperação fácil. Deu erro? Roda de novo. A carga full se corrige.

Onde o batch cobra o preço é no frescor. Se o dado só chega às 4h da manhã, qualquer decisão tomada às 15h olha para uma foto de até doze horas atrás. Para faturamento, fechamento contábil e a maioria dos relatórios gerenciais, isso é aceitável. Para fraude em tempo real ou estoque em um e-commerce em pico, não é. A honestidade aqui é: a maioria dos projetos de Power BI para empresas vive muito bem com batch diário, e tentar sofisticar isso sem necessidade só aumenta o custo.

Incremental traz só o que mudou, com watermark ou CDC#

Quando a carga full começa a doer, seja porque a tabela cresceu demais, seja porque a janela da madrugada ficou apertada, entra o padrão incremental. A ideia é elegante: em vez de reprocessar tudo, você traz apenas os registros que mudaram desde a última carga. Menos dado movimentado, processo mais rápido, janela de execução menor.

O problema é saber o que mudou. Existem duas técnicas principais para isso.

A primeira é a marca dágua, ou watermark. Você elege uma coluna que sempre cresce, tipicamente uma data de atualização (updated_at) ou um ID sequencial, e guarda o maior valor já carregado. Na próxima execução, você pede à origem apenas os registros com valor maior que a marca guardada. Se a última carga parou em 2026-10-13 23:59:59, a próxima traz só o que veio depois disso. Simples, barato e funciona na imensa maioria dos bancos relacionais.

A segunda é a captura de mudanças, ou CDC (Change Data Capture). Aqui o próprio banco de origem registra as operações de insert, update e delete em um log, e a ingestão lê esse log para reconstruir exatamente o que aconteceu. O CDC é mais poderoso que o watermark por um motivo específico: ele captura deleções que um watermark ingênuo perde, já que uma linha apagada não gera data de atualização nova.

Técnica incremental	Como detecta a mudança	Captura deleção?	Complexidade
Watermark (marca dágua)	Coluna de data ou ID que sempre cresce	Não, sem tratamento extra	Baixa
CDC (captura de mudanças)	Log de transações do banco de origem	Sim, nativamente	Média a alta

O incremental é o padrão que mais dá retorno quando bem feito, e o que mais gera bug quando mal feito. Os problemas clássicos são conhecidos: o relógio da origem e do destino fora de sincronia fazendo você perder registros na borda da janela, dados que chegam atrasados (late-arriving data) e ficam para trás da marca, e o temido drift, quando pequenos erros vão se acumulando carga após carga até a base ficar silenciosamente errada. Por isso, todo projeto incremental sério precisa de uma recarga completa periódica que zera o acúmulo de erro. Quem monta engenharia de dados de verdade sabe que incremental sem plano de reconciliação é uma bomba-relógio.

Vale um exemplo que talvez você já use sem saber: a atualização incremental do Power BI é exatamente um padrão incremental de ingestão. Você configura um período histórico que fica congelado e uma janela recente que é refrescada a cada atualização. Em vez de reprocessar cinco anos de dados toda vez, o Power BI só recarrega os últimos dias. É watermark aplicado ao refresh do modelo semântico, e uma das formas mais fáceis de aliviar relatórios pesados.

Streaming ingere eventos contínuos, em tempo quase real#

O terceiro padrão inverte a lógica. Em batch e incremental, você vai buscar o dado de tempos em tempos. No streaming, o dado vem até você continuamente, evento a evento, no instante em que acontece. Um clique no site, uma leitura de sensor de IoT, uma transação de cartão, uma mudança de status de pedido: cada acontecimento vira um evento ingerido na hora, sem esperar a próxima janela agendada.

O streaming trabalha com fluxos contínuos e não com lotes. Não existe "a carga das 3h". Existe um cano sempre aberto por onde os eventos passam. Isso muda a arquitetura, porque agora você precisa de uma peça que fique escutando o tempo todo, aguente picos de volume e não perca evento quando algo trava.

É aqui que muita gente se empolga e erra. Streaming é sedutor porque "tempo real" soa impressionante em reunião, mas é, de longe, o padrão mais caro e mais complexo dos três. Você paga por infraestrutura ligada continuamente e precisa lidar com ordenação de eventos, duplicidade e eventos que chegam fora de ordem. Antes de aprovar streaming, eu sempre pergunto ao cliente: alguém vai decidir diferente por ter o dado em segundos em vez de horas? Se a resposta é não, é dinheiro jogado fora.

Onde streaming se justifica de verdade:

• Detecção de fraude e anomalia, onde reagir em segundos evita prejuízo.
• Monitoramento de operações críticas e IoT, onde um sensor fora da faixa precisa gerar alerta imediato.
• Experiências em tempo real, como recomendação e personalização durante a navegação.

Como implementar a ingestão de dados no Microsoft Fabric#

No Microsoft Fabric os três padrões têm ferramentas próprias, e entender esse mapeamento evita escolha errada. Se você ainda está avaliando a plataforma como um todo, vale ler antes o nosso guia sobre o que é o Microsoft Fabric e se vale a pena em 2026.

Para batch e incremental, a peça é o Data Factory dentro do Fabric, com seus pipelines de orquestração e o Dataflow Gen2. Você monta a atividade de cópia, aponta origem e destino e agenda o gatilho. Para o incremental, combina a cópia com um parâmetro de watermark ou com as opções de CDC dos conectores que suportam, gravando no Lakehouse ou no Warehouse do OneLake.

Para streaming, a peça é o Eventstream, o recurso do Fabric para ingerir, transformar e rotear eventos contínuos em tempo real. Você conecta uma fonte de eventos, como um Azure Event Hubs, um tópico Kafka ou dados de mudança de um banco, e o Eventstream leva esse fluxo até um destino, tipicamente um Eventhouse com banco KQL, um Lakehouse ou direto para um relatório em tempo real. É a resposta nativa do Fabric para o padrão de eventos, sem você administrar a infraestrutura de streaming na mão.

Padrão	Frescor do dado	Ferramenta no Fabric	Destino típico
Batch	Horas (carga agendada)	Data Factory (pipeline, Dataflow Gen2)	Lakehouse, Warehouse
Incremental	Minutos a horas	Data Factory com watermark ou CDC	Lakehouse, Warehouse
Streaming	Segundos (contínuo)	Eventstream	Eventhouse (KQL), Lakehouse

Uma coisa importante e honesta sobre o Fabric: como ele cobra por capacidade (capacity), um Eventstream ligado o tempo todo consome recurso continuamente, enquanto um pipeline batch consome só quando roda. O custo do frescor não é abstrato, ele aparece na fatura da capacidade.

O trade-off é sempre entre frescor, custo e complexidade#

Se há uma frase para levar deste artigo é esta: frescor maior custa mais complexidade e mais dinheiro. Não existe padrão universalmente melhor, existe o padrão certo para a decisão que o dado precisa alimentar. Batch é barato e simples, mas o dado envelhece. Streaming é fresquíssimo, mas caro e complexo de operar. Incremental fica no meio e resolve boa parte dos casos onde o batch full ficou pesado.

Critério	Batch	Incremental	Streaming
Frescor do dado	Baixo (horas)	Médio (minutos a horas)	Alto (segundos)
Custo	Baixo	Médio	Alto
Complexidade de operar	Baixa	Média	Alta
Volume movimentado	Alto (recarrega tudo)	Baixo (só o que mudou)	Contínuo, evento a evento
Recuperação de erro	Fácil (roda de novo)	Exige reconciliação	Complexa (ordem, duplicidade)
Melhor cenário	Relatório gerencial, fechamento	Tabelas grandes, refresh frequente	Fraude, IoT, tempo real

Minha recomendação de consultor, sem enrolar: comece pelo batch. A maioria esmagadora das necessidades de BI é atendida por uma carga diária bem feita. Quando a janela da madrugada apertar ou o volume incomodar, evolua para incremental nas tabelas que justificam, sempre com um plano de recarga completa para matar o drift. Deixe o streaming para quando existir uma decisão real que dependa de segundos. Sofisticação sem necessidade não é engenharia, é vaidade técnica que aparece na conta no fim do mês. Se você quer estruturar isso com quem já montou dezenas dessas pipelines, conheça as nossas soluções de dados e analytics.

Perguntas frequentes#

Qual a diferença entre batch e incremental?

O batch clássico, na modalidade full, carrega o conjunto inteiro de dados a cada execução, reprocessando tudo. O incremental traz apenas os registros que mudaram desde a última carga, usando uma marca dágua (watermark) ou captura de mudanças (CDC). O incremental é mais rápido e movimenta menos dado, mas exige controlar estado e reconciliar periodicamente para não acumular erro.

O que é watermark na ingestão de dados?

Watermark, ou marca dágua, é o valor máximo já carregado de uma coluna que sempre cresce, tipicamente uma data de atualização ou um ID sequencial. A cada carga você pede à origem apenas os registros com valor maior que essa marca. É a forma mais simples e barata de fazer ingestão incremental, e funciona na maioria dos bancos relacionais.

Quando devo usar CDC em vez de watermark?

Use CDC quando precisar capturar deleções e updates com precisão, algo que um watermark ingênuo pode perder, já que uma linha apagada não gera uma data de atualização nova. O CDC lê o log de transações do banco e reconstrói exatamente insert, update e delete. Em troca, é mais complexo de configurar e depende de suporte do banco de origem.

A atualização incremental do Power BI é um padrão incremental?

Sim. A atualização incremental do Power BI é um exemplo clássico de ingestão incremental. Você congela um período histórico e refresca apenas uma janela recente a cada atualização, em vez de reprocessar todo o histórico. Na prática, é um watermark aplicado ao refresh do modelo semântico, e alivia bastante relatórios grandes.

Streaming sempre vale a pena por ser mais rápido?

Não. Streaming é o padrão mais caro e mais complexo dos três, porque exige infraestrutura ligada continuamente e tratamento de ordem e duplicidade de eventos. Só vale a pena quando existe uma decisão real que dependa de dados em segundos, como fraude, IoT ou personalização. Para relatório gerencial, batch resolve com muito menos custo.

Como faço streaming no Microsoft Fabric?

No Fabric, o recurso para streaming é o Eventstream. Ele ingere eventos contínuos de fontes como Azure Event Hubs, Kafka ou dados de mudança de bancos, aplica transformações e roteia o fluxo para destinos como um Eventhouse com banco KQL, um Lakehouse ou relatórios em tempo real. Batch e incremental, por sua vez, ficam com os pipelines do Data Factory dentro do Fabric.

Conclusão#

Os três padrões de ingestão de dados não competem, eles se complementam: batch como base barata, incremental quando o volume aperta e streaming quando a decisão depende de segundos. O erro caro é começar pelo mais sofisticado achando que frescor é sempre melhor, quando na prática ele custa mais complexidade e mais dinheiro. Se você quer definir o padrão de ingestão certo para o seu contexto, sem pagar por sofisticação que ninguém vai usar, fale com a gente.