Pipelines de Engenharia de Dados

Este projeto de engenharia de dados implementa um pipeline de atribuição fechada para Google Ads: eventos de conversão web (compras com GCLIDs) armazenados no PostgreSQL são transformados por um modelo dbt e enviados de volta ao Google Ads via API de Upload de Conversões, permitindo que a plataforma de anúncios veja quais cliques geraram compras reais. Dois DAGs do Airflow rodam em cronogramas separados — o dbt atualiza de hora em hora, o job de upload roda diariamente.

As campanhas do Google Ads otimizam para cliques por padrão. Sem dados de conversão enviados de volta à plataforma, os algoritmos de lance não têm sinal sobre quais cliques realmente geram receita. O desafio de engenharia era construir um pipeline confiável que: (1) mapeie corretamente dados de eventos internos para o schema de conversão do Google Ads; (2) lide com autenticação OAuth2 em ambiente containerizado; (3) separe transformação de upload para que cada um possa falhar e tentar novamente independentemente.

Construir um pipeline ETL pronto para produção que: (1) extraia eventos de compra do PostgreSQL; (2) transforme-os no formato de conversão do Google Ads usando dbt; (3) faça upload para a API de Conversão do Google Ads diariamente; (4) orquestre com Airflow em cronogramas separados para transformação vs. upload; (5) rode de forma reproduzível no Docker com DAGs validados por pytest.

• ◈Engenheiro de dados solo — arquitetura do pipeline, modelagem dbt, criação de DAGs Airflow, deploy Docker

1. 01Cronogramas separados para dbt (horário) e upload (diário) — transformação e upload têm frequências ótimas diferentes. O dbt roda de hora em hora para manter a VIEW atualizada. O upload do Google Ads roda diariamente para fazer lotes eficientes e respeitar os limites de cota da API. Separar os dois significa que uma falha do dbt não bloqueia o upload.
2. 02Modelo dbt materializado como VIEW em vez de TABLE — o modelo purchase_clicks é um SELECT com filtro WHERE event_name = 'purchase'. Materializar como VIEW não tem overhead de armazenamento e a VIEW reflete automaticamente mudanças nos dados de origem sem executar refresh explicitamente.
3. 03BashOperator para invocação dbt em vez de DbtOperator — dá controle total sobre os flags do dbt e permite fazer source do ambiente virtual explicitamente. A estrutura do comando é mais portável que um operador customizado e mais fácil de depurar.
4. 04InstalledAppFlow OAuth2 para auth do Google Ads em container — credenciais copiadas para o container em tempo de build e seus caminhos definidos como variáveis de ambiente. Evita fluxos OAuth interativos em runtime mantendo credenciais fora do código do DAG.
5. 05Astronomer Runtime 10.6.0 como imagem base — o runtime pré-construído do Astronomer inclui providers do Airflow, dbt-core e dependências comuns. Usá-lo como base reduz o Dockerfile a ~10 linhas e garante que o ambiente de dev local corresponda exatamente ao de produção.
6. 06Validação de DAG com pytest como gate de CI — três invariantes aplicados: sem erros de import, tags presentes, retries ≥ 2. Roda no CI antes de qualquer DAG ser implantado.

• →A separação de responsabilidades entre DAGs de transformação e carregamento é essencial para confiabilidade — um DAG monolítico que roda dbt depois faz upload falha atomicamente quando qualquer etapa tem um erro transitório. DAGs separados com políticas de retry independentes significam que um 429 da API do Google Ads não re-executa a transformação dbt.
• →A atribuição baseada em GCLID requer gerenciamento cuidadoso de frescor dos dados — GCLIDs expiram após 90 dias. Fazer upload de conversões mais antigas que 90 dias falha silenciosamente na API do Google Ads sem resposta de erro.
• →O Astro CLI do Astronomer reduz significativamente a complexidade de configuração local do Airflow — astro dev start inicializa 4 containers com um único comando. Sem ele, uma configuração docker-compose vanilla para Airflow requer 20+ configurações de variáveis de ambiente.
• →A validação de DAG com pytest captura erros de import que de outra forma só apareceriam em produção — um DAG tinha um erro de digitação em um caminho de import que só aparecia quando o Airflow tentava analisar o arquivo em runtime.

Funcional — pipeline ETL para atribuição de conversões no Google Ads