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

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:

1. Airflow no Cloud Composer (GCP) para orquestração,
2. arquivos YAML como ponto único de configuração,
3. 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.