Configurando um pipeline de ingestão de dados com processamento batch
A maioria dos times que eu vejo tenta fazer ingestion em tempo real quando o negócio só precisa de uma atualização diária. O resultado são sistemas complexos que quebram sem motivo, dashboards com dados stale porque o consumer não lida bem com latência, e operações gastando horas resolvendo jobs que já tinham sido processados.
O que é tecnologia e informação na prática
Não é o conceito abstrato de livros didáticos. É a infraestrutura que permite coletar dados de fontes heterogêneas, transformar, armazenar e entregar para quem precisa tomar decisão. No dia a dia, isso significa lidar com APIs que mudam sem aviso, arquivos CSV com encoding errado, e campos duplicados em tabelas que ninguém documentou. Eu configurei um sistema desses para uma empresa de logística há dois anos. Eles precisavam consolidar dados de 17 transportadoras diferentes em um único dataset para relatórios semanais. O problema que ninguém previa era que 9 dessas empresas enviavam timestamps no fuso horário delas, não UTC. Quando você soma tudo num data warehouse sem normalização, os KPIs de atraso de entrega ficam completamente errados, mostrando métricas que variam até 40% dependendo do transporte.
A solução foi criar uma camada de ingestão que roda todo dia às 3h da manhã, lê os arquivos de cada origem, converte os timestamps para UTC usando a biblioteca pytz com os fusos específicos de cada parceiro logístico, valida schemas contra um arquivo JSON de contrato (aqueles que o jurídico guarda mas ninguém lê), e só então escreve na tabela final. Esse pipeline levou cerca de 6 meses para ficar estável, dos primeiros 4 meses sendo debugging de edge cases que os contratos nem mencionavam.
Arquitetura recomendada para times pequenos
Se você tem menos de 50 fontes de dados e volume baixo a médio, esqueça Kafka e Flink. Usa Airflow ou Prefect para orquestração, Python com Pandas para transformação, PostgreSQL como data warehouse e dbt para modelagem. Isso reduz o custo operacional para quase zero e o tempo de setup de semanas para dias. O erro mais comum é começar pela ferramenta errada. People veem Airflow no site da Google e acham que precisam dele desde o início. Na prática, um simples script Python rodando em cron com logging pra S3 ou GCS resolve 80% dos casos. Só migre para orquestradores quando o número de jobs passar de 20 ou quando precisar de dependências complexas entre tasks.
Outra coisa que ninguém conta: validação de dados. A maioria dos pipelines falha porque alguém coloca um campo opcional como obrigatório no schema, ou uma API retorna formato diferente num dia de manutenção. Eu implemento uma camada de schema validation com Great Expectations ou Pandera antes de qualquer transformação. O overhead é de cerca de 10% no tempo de execução, mas evita que jobs inteiros falhem silenciosamente e gerem dashboards com dados errados.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Monitoramento e alertas práticos
Sensoriamento não precisa ser complexo. Configura um job que roda 5 minutos após cada pipeline terminar, checa se o número de linhas processadas está dentro do histórico (±2 desvios padrão), se não há NULLs em campos críticos, e se os timestamps mais recentes são coerentes. Se algo sair do esperado, dispara um alerta no Slack ou Telegram. Isso cobre 95% dos casos de falha que eu já vi. Alertas demais geram fadiga de alerta. Ninguém liga mais quando o Slack começa a piscar. Eu recomendo limitar alertas críticos para dados que impactam diretamente receita ou conformidade regulatória, e tratar o resto como warnings em logs que alguém revisa semanalmente.
Dicas técnicas específicas
Use particionamento temporal nos seus datasets final. Partition by dia ou mês no PostgreSQL ou BigQuery reduz drasticamente o tempo de query para relatórios históricos. Uma tabela de 50GB particionada por mês responde em 2 segundos, a mesma tabela sem particionamento pode levar minutos. Documentação técnica vive e morre com o código. Se você escrever documentação separada, ela vai desatualizar em 3 meses. A solução é docstrings em Python com formato estruturado e gerar documentação automática com Sphinx ou MkDocs. Adicione também um arquivo README em cada diretório de pipeline explicando o que cada job faz, fonte de dados, frequência, e dono. Isso parece bobo, mas quando o desenvolvedor que fez o código sai da empresa, é o único resgate que funciona.
Custos de ETL em nuvem somam rápido. Um job de transformação processando 100GB de dados em Spark AWS custa aproximadamente 2 dólares por execução. Se roda todo dia, são 60 dólares mensais só nisso. Omitir otimizações básicas como particionamento, compactação de dados e seleção de colunas pode quadruplicar essa conta sem necessidade.
Quando tudo dá errado
Eventualmente um job vai falhar no pior momento possível. O segredo não é evitar falhas, mas ter runbooks documentados e automação para recovery. Eu mantenho um arquivo de texto simples com procedimentos passo a passo para os 10 cenários de falha mais comuns que já encontrei. Quando algo quebra, o engenheiro de plantão gasta 5 minutos lendo ao invés de 45 minutos debugando. Backup de metadados é tão importante quanto backup de dados. Se seu airflow.cfg ou configuração de conexões perde, você pode levar dias para restaurar o estado do sistema mesmo tendo os dados íntegros. Versione configurações no Git e faça sync diário automático.
A complexidade aumenta naturalmente. Novas fontes de dados chegam, schemas mudam, requisitos de negócio se alteram. O sistema que funcionava para 5 fontes vai precisar de refatoração para 50. Planeje isso desde o início com modularização de código e abstração de fontes, senão o tempo de desenvolvimento escala linearmente com o número de integrações e você trava em manutenções eternas.
