Um desafio no dia a dia de engenharia de dados pode ser lidar com a criação repetitiva de pipelines. Muitas vezes, diferentes análises
[caption id="attachment_6248" align="alignright" width="219"]
Escrito por Bryan Bora, Engenheiro de Dados da Onetopia[/caption]
precisam dos mesmos dados de origem, seguindo a mesma estrutura de tabelas e as mesmas regras de transformação. Ainda assim, cada novo pipeline tradicionalmente exige que alguém escreva manualmente DAGs no Airflow, queries SQL para bronze, silver e gold, além de toda a configuração necessária.
Isso consome tempo, gera retrabalho e aumenta o risco de inconsistências entre projetos.
Diante desse cenário, exploramos uma forma de automatizar ao máximo esse processo. A solução uniu três peças principais:
- Airflow no Cloud Composer (GCP) para orquestração,
- arquivos YAML como ponto único de configuração,
- e, mais tarde, uma interface em Streamlit, que democratizou a criação dos pipelines.
O contexto: por que automatizar?
No início, a necessidade era clara:
- sempre que surgia uma nova análise baseada na mesma origem,
- era preciso criar DAGs semelhantes no Airflow,
- que seguiam exatamente o mesmo padrão de camadas (raw, bronze, silver e gold).
Ou seja, o trabalho era repetitivo, previsível e sujeito a erro humano.
Ao identificar isso, buscamos responder a uma pergunta simples:
se a estrutura já é conhecida, por que não automatizar a criação dos pipelines?
O Airflow no GCP como base
A escolha do Cloud Composer foi natural, já que ele oferece uma versão gerenciada do Apache Airflow dentro do Google Cloud. Isso nos permitiu evitar a sobrecarga de manter a infraestrutura do Airflow manualmente, ganhando benefícios como:
- Escalabilidade automática: os recursos de execução cresciam ou diminuíam conforme a demanda.
- Monitoramento centralizado: logs e alertas acessíveis na própria interface do GCP.
- Gestão de dependências simplificada: sem dores de cabeça com bibliotecas conflitantes.
- Integração nativa: BigQuery, Cloud Storage e outros serviços estavam a apenas um operador de distância.
Essa base sólida tornou possível focar na lógica de automação, sem perder tempo com camadas de infraestrutura.
O papel dos sensores
Dentro do Airflow, um recurso foi crucial: os sensores.
Eles permitem que uma tarefa fique em “espera” até que uma condição seja atendida. Entre os vários tipos disponíveis, o que mais utilizamos foi o ExternalTaskSensor, que nos permitia:
- garantir que a DAG de ingestão estivesse finalizada antes de iniciar a DAG de transformação,
- assegurar a sequência correta entre as camadas bronze → silver → gold,
- e criar pipelines encadeados sem precisar de gambiarras ou dependências manuais.
Esse tipo de mecanismo trouxe confiabilidade ao processo, essencial quando se está lidando com múltiplos fluxos simultâneos.
Automação via YAML
O passo seguinte foi transformar a criação dos pipelines em algo parametrizável.
Em vez de escrever DAGs manualmente, criávamos um YAML base, contendo:
- a origem e credenciais de acesso,
- a estrutura da tabela de destino,
- e as camadas a serem geradas.
Uma função consumia esse YAML e automaticamente:
- publicava DAGs no Airflow,
- gerava queries SQL padronizadas,
- e estruturava todo o fluxo até a camada gold.
Na prática, bastava um arquivo de configuração para ter um pipeline completo — da ingestão bruta até as métricas analíticas.
As funções SQL seguiam sempre o mesmo padrão:
- bronze: ingestão bruta dos dados,
- silver: deduplicação e normalização,
- gold: agregações e métricas para análise.
Esse modelo nos trouxe eficiência imediata:
- velocidade de entrega — novos pipelines podiam ser criados em minutos;
- padronização — todas as tabelas seguiam a mesma lógica;
- redução de erros — menos código manual significava menos inconsistência;
- replicabilidade — um mesmo processo podia ser repetido entre times e projetos sem esforço extra.
Evolução: da configuração técnica para a interface
Apesar do avanço, havia uma limitação: os YAMLs ainda precisavam ser montados por um engenheiro de dados. Para quem não dominava a linguagem ou não estava acostumado com a estrutura, isso ainda era uma barreira.
Foi então que demos um passo além: construímos uma interface em Streamlit, hospedada no App Engine.
Essa interface permitia que usuários menos técnicos preenchessem parâmetros em uma tela amigável, como:
- nome da extração,
- origem dos dados,
- destino no data lake,
- periodicidade de execução.
- credenciais de acesso
A partir dessas informações, o sistema gerava automaticamente o YAML correspondente e disparava o deploy no Airflow.
Na prática, analistas e outros perfis fora da engenharia puderam criar seus próprios pipelines, sem abrir mão da padronização e da governança.
Foi um avanço significativo em democratização do acesso e em redução da dependência do time de engenharia.
Onde essa estratégia faz sentido
Essa abordagem se mostrou extremamente eficaz em cenários de padronização:
- quando a origem de dados é a mesma,
- a estrutura é previsível,
- e as análises seguem um padrão.
Por outro lado, não é uma solução universal.
- Casos que exigem lógica customizada ou regras muito específicas ainda precisam de pipelines feitos sob medida.
- A automação cobre o “grosso” do trabalho repetitivo, mas não substitui a flexibilidade necessária em contextos complexos.
Conclusão
A combinação de Airflow no GCP, sensores para orquestração confiável e automação via YAML provou ser uma solução poderosa para acelerar entregas e reduzir erros.
Ao adicionar uma camada de interface com Streamlit + App Engine, demos o próximo passo: levamos a criação de pipelines para um público mais amplo, sem abrir mão da qualidade e da governança.
Esse modelo não resolve tudo, mas quando aplicado no contexto certo, transforma a forma como pipelines são criados e mantidos. Mais do que ganho técnico, é uma forma de escalar a capacidade do time e liberar engenheiros para se dedicarem a desafios mais estratégicos.
