← Voltar para Artigos

---

O Problema de Escala que Ninguém Te Avisa

Dois anos atrás, o problema não era fazer os jobs rodarem. Era descobrir, rápido o bastante, por que eles tinham parado, quem seria afetado e quanto tempo de engenharia seria drenado até a plataforma voltar ao normal.

Em dias ruins, a sustentação consumia uma parte desproporcional da atenção dos engenheiros mais experientes do time. O trabalho não era resolver um bug claro. Era reconstruir contexto: correlacionar logs, entender dependências implícitas, descobrir se a falha era transitória, identificar impacto downstream e decidir quem precisava agir. O custo real não aparecia só na infraestrutura. Aparecia no tempo de engenharia que deixava de ser investido em evolução de plataforma.

Isso ficava ainda mais crítico por causa da escala em que operamos. A CERC mantém a infraestrutura do mercado financeiro brasileiro para registro de ativos financeiros — um sistema que já registrou mais de R$5 trilhões em ativos financeiros e processa mais de 500 milhões de transações por dia. Nosso DataLake possui mais de 3 PB de dados, distribuídos em mais de 15 sistemas de registro e mais de 8.000 tabelas transacionais, com milhões de novos registros chegando todos os dias.

Centenas de jobs Databricks já deployados, espalhados por múltiplos times, ingerem, transformam e servem esses dados para consumidores que vão de modelos internos de risco a relatórios regulatórios.

Antes de tudo, vale esclarecer a topologia da solução: os workloads de dados já existiam como jobs deployados no Databricks. O problema que precisávamos resolver não era reescrever esses jobs, mas construir uma camada de orquestração confiável para dispará-los, encadear dependências, aplicar governança e operar tudo isso em escala.

Nessa escala, orquestração não é encanamento. É o sistema nervoso de toda a plataforma. E o nosso estava com falhas.

A ferramenta terceirizada que utilizávamos havia sido suficiente quando a plataforma era menor. Quando o volume cresceu e mais times passaram a depender dela, o que antes era tolerável virou um passivo operacional diário. As principais dores se concentravam em quatro frentes:

Não eram dores de crescimento para tolerar. Eram sinais arquiteturais: a camada de orquestração havia se tornado um passivo.

---

Por que Airflow — E Por que Não Outra Coisa

Antes de falar da solução, vale deixar claro o critério de decisão. Não precisávamos apenas trocar de ferramenta. Precisávamos de uma camada de orquestração que o time pudesse programar, versionar, operar e evoluir com autonomia.

Avaliamos três alternativas:

Ferramenta	Por que foi considerada	Por que foi descartada
Manter o fornecedor atual	Familiar, sem custo de migração	Causa raiz do problema; corrigir não era viável
Databricks Workflows (nativo)	Integração nativa, sem infra extra	Sem grafo de dependências entre jobs; limitado a workloads Databricks
Prefect / Dagster	API moderna, boa observabilidade	Ecossistema menor, menos referências em produção na nossa escala; curva de aprendizado mais íngreme
Apache Airflow no Cloud Composer	✅ Python-nativo, padrão amplamente consolidado, integração madura com Databricks, infra gerenciada	—

O Apache Airflow venceu por três critérios decisivos. Primeiro, ele trata pipelines como código: DAGs são Python, versionadas e revisáveis. Segundo, o recurso Airflow Datasets (introduzido na versão 2.4) nos deu uma forma explícita de modelar dependências de dados sem gambiarras de polling. Terceiro, o Google Cloud Composer entregou o que queríamos operacionalmente: um ambiente Airflow gerenciado e pronto para produção, sem transformar a operação do próprio orquestrador em mais um problema para o time.

A variável restante era capital humano. Tínhamos um engenheiro sênior com profundo conhecimento em Airflow e um mandato claro para decidir rápido. Era suficiente para sair da comparação e entrar em execução.

---

A Arquitetura: Convenção Acima de Configuração em Escala

A filosofia de design do novo sistema pode ser resumida em uma frase: tornar a coisa certa a coisa fácil. Essa ideia guiou tudo o que veio depois. Em vez de confiar que cada engenheiro repetiria manualmente o padrão correto, desenhamos a plataforma para aplicar esse padrão por construção.

A DAG Factory: YAML Entra, DAGs Validadas Saem

O mecanismo central dessa virada foi a DAG Factory: uma camada de geração de código que converte especificações YAML legíveis por humanos em DAGs Airflow validadas e estruturalmente consistentes.

Antes dela, criar um novo pipeline significava escrever uma DAG Python do zero, reinterpretar convenções da plataforma e torcer para que o resultado final estivesse alinhado com expectativas de operação, retry, observabilidade e acesso. Em qualquer time de tamanho relevante, isso inevitavelmente gera variações demais. A factory inverte a equação: o engenheiro declara o que quer executar, e a plataforma define como aquilo será executado.

Uma especificação de pipeline na prática segue este padrão — o nome da DAG é a chave raiz, e o schema expressa o contexto de negócio, as dependências e as regras de disparo:

# 1) Extração da fonte transacional — dispara por cron
landing-nome-do-workflow-no-databricks-1:
  folder_application: pasta-que-faz-sentido-esse-workflow-pertencer
  folder_sub_application: ''
  date_start: '2025-03-01'
  owner: time-responsavel
  schedule_america_sp: 30 3 * * *   # fuso horário America/Sao_Paulo
  tags:
    - transient
    - {source}
    - etc
  access:
    - grupo-que-precisa-ver-esse-workflow

# 2) Camada bronze/silver — dispara por dataset (quando o transiente acima conclui)
bronze-silver-nome-do-workflow-no-databricks-2:
  folder_application: pasta-que-faz-sentido-esse-workflow-pertencer
  folder_sub_application: ''
  date_start: '2025-03-01'
  owner: time-responsavel
  dependencies:
    - nome-do-workflow-no-databricks-1
  tags:
    - bronze
    - silver
    - {sistema}
    - {domínio}
    - etc
  access:
    - grupo-que-precisa-ver-esse-workflow

# 3) Camada gold — depende de múltiplos upstreams e dispara stages paralelos
gold-nome-do-workflow-no-databricks-3:
  folder_application: pasta-que-faz-sentido-esse-workflow-pertencer
  folder_sub_application: ''
  date_start: '2025-03-01'
  owner: time-responsavel
  dependencies:
    - bronze-silver-nome-do-workflow-no-databricks-2
    - outro-workflow-no-databricks
  tags:
    - gold
    - registro
    - {sistema}
    - {domínio}
    - etc
  access:
    - grupo-que-precisa-ver-esse-workflow

O ponto importante é que não há Python de orquestração para cada time escrever. Antes de qualquer DAG ser gerada, uma camada de validação com Pydantic verifica schema, campos obrigatórios e restrições de valores. Specs inválidas morrem no CI, não durante uma janela crítica de operação.

Toda DAG que sai da factory compartilha o mesmo esqueleto estrutural: nomenclatura padronizada de tasks, políticas de retry da plataforma, hooks de alerta e convenções de acesso. O custo cognitivo de “fazer certo” caiu drasticamente.

Mais importante: a plataforma deixou de depender de disciplina manual para permanecer consistente.

Agendamento: Baseado em Cron e Orientado a Eventos

Uma tensão fundamental em qualquer grande plataforma de dados é que nem todos os pipelines deveriam rodar em um relógio. O agendamento baseado em tempo assume que os dados upstream estarão prontos em um horário previsível — uma premissa que quebra sob atrasos upstream, retries ou falhas de SLA. O job downstream roda mesmo assim, consumindo compute para produzir dados desatualizados ou incorretos.

Nossa arquitetura suporta dois modelos de agendamento, selecionáveis por pipeline:

1. Agendamento por cron — para pipelines com fontes genuinamente dependentes de tempo
2. Airflow Datasets — para pipelines que devem rodar somente após a conclusão do upstream (até porque se o upstream ainda está rodando, o downstream não tem como produzir algo correto)

O Airflow Datasets fornece um primitivo de dependência de dados de primeira classe. Quando uma DAG produtora conclui e marca seu Dataset de saída como atualizado, todas as DAGs consumidoras registradas disparam automaticamente. As dependências são declaradas em código, versionadas e auditáveis — não inferidas por intervalos de tempo entre expressões cron.

O efeito prático foi simples e poderoso: pipelines passaram a iniciar quando os dados estão prontos, não quando um cron dispara na esperança de que tudo já tenha dado certo.

Execução Confiável: Um Operador Próprio para Databricks

A integração nativa do Airflow com Databricks é robusta, mas não cobre todas as nuances operacionais da nossa plataforma. Construímos o CercDatabricksRunNowOperator — um operador que estende o operador padrão do provider Databricks e adiciona as camadas que nossa plataforma exige:

• Execução deferível: usa o modelo assíncrono do Airflow (deferrable=True), liberando o worker enquanto aguarda o job no Databricks. Em escala, isso reduz significativamente o consumo de slots de worker.
• Idempotência garantida: gera um token MD5 a partir de dag_id | task_id | run_id e o passa como parâmetro ao job Databricks, evitando execuções duplicadas em caso de retry do Airflow.
• Contexto rico de execução: injeta automaticamente nos notebook_params do job o dag_id, task_id, owner, schedule, URL do run no Airflow e ambiente (stg/prd) — disponíveis para logging e rastreabilidade dentro do próprio notebook.
• Métricas de observabilidade: envia séries ao Google Cloud Monitoring ao final de cada execução, registrando se houve repairs automáticos — base para alertas e dashboards de saúde da plataforma.
• Callback integrado: o CercCallbackHandler aciona notificação no Slack e abertura de ticket no JiraOps em caso de falha (apenas em produção), garantindo que toda falha gere um rastro formal e acionável.

Esse operador foi o ponto em que a integração deixou de ser apenas funcional e passou a ser operacionalmente confiável em escala.

Política de Retry: Menos é Mais

Uma das decisões com maior impacto operacional foi simplificar — deliberadamente — a política de repair.

A maioria das plataformas faz o contrário: retry automático em qualquer falha, com backoff agressivo, na esperança de que o problema se resolva sozinho. O resultado previsível é um Databricks sobrecarregado de clusters reiniciando em cima de erros que não vão desaparecer com tentativas, e uma fila de alertas que ninguém mais leva a sério.

Invertemos a lógica: por padrão, não há retry automático. O operador mantém uma lista explícita de erros conhecidos — catalogada e mantida pelo time de plataforma — que autoriza repair automático via API do Databricks. Tudo fora da lista falha imediatamente e cria um ticket no JiraOps.

Essa abordagem contraintuitiva — menos automação em retries — foi uma das que mais reduziram a carga operacional diária. Em vez de mascarar sintomas, ela forçou a plataforma a distinguir falhas recuperáveis de falhas que exigiam intervenção real.

---

Observabilidade: Da Falha ao Contexto em Segundos

Falha sem contexto é só ruído. Em uma plataforma com centenas de workflows, saber que um job quebrou é o mínimo; o que importa é encurtar o caminho entre falha, entendimento e ação.

Esse foi um ponto de virada importante do projeto. Em vez de tratar observabilidade como acabamento, tratamos como parte da arquitetura desde o início. O objetivo era simples: a pessoa certa precisava receber o contexto certo, sem triagem manual.

Camada 1: Incidentes Estruturados, Não Ruído de Alertas

Nossa camada de observabilidade integra diretamente com o JiraOps para criar tickets de incidente estruturados quando falhas de pipeline ultrapassam limites de severidade. Cada ticket é preenchido automaticamente com:

• A DAG e o identificador de task com falha, com links diretos para os logs do Airflow
• A URL do run do job Databricks e o ID do cluster para debugging imediato
• Os datasets downstream com anotação de impacto potencial
• O responsável de plantão resolvido a partir dos metadados do time

Isso transforma alertas em itens de trabalho com escopo e responsabilidade definidos. Além disso, dashboards personalizados agregam taxas de falha, cumprimento de SLA e utilização de cluster em todos os ~1.800 workflows, dando aos líderes de time uma visão única da saúde da plataforma sem alternar entre Airflow, Databricks e consoles de cloud.

Camada 2: Observabilidade Cirúrgica Onde o Genérico Não Basta

A observabilidade automatizada cobre bem o caso mais comum: o job falhou, o alerta disparou. Mas há uma classe de problemas que não é capturada por callbacks de falha — jobs que completam com sucesso, mas demoram muito mais do que deveriam.

Um workflow que normalmente roda em 40 minutos e começou a demorar 18 horas não vai gerar um ticket no JiraOps. Vai bloquear pipelines downstream, consumir cluster por tempo indeterminado e só ser percebido quando alguém olhar o Airflow no momento certo.

Para esses casos, construímos DAGs de monitoramento escritas manualmente — fora da DAG Factory, deliberadamente. A DAG Factory é excelente para padronização em larga escala, mas certos workflows críticos merecem lógica de monitoramento personalizada: limiares específicos de duração, janelas de tolerância ajustadas ao comportamento histórico daquele job, alertas segmentados por severidade de atraso.

Uma DAG de monitoramento típica consulta o histórico de execução via API do Airflow, calcula o tempo de execução corrente e aciona o fluxo de notificação quando o job excede seu limiar — por exemplo, mais de 18 horas para workflows que historicamente terminam em até 2 horas. O alerta chega com contexto: duração atual vs. média histórica, número de tentativas, link direto para o run no Databricks.

Além disso temos outros tipos de monitoramento específicos para certos cenários. É Python.

Essa combinação fechou uma lacuna importante: falhas explícitas deixaram de ser o único evento observável. Anormalidades silenciosas também passaram a gerar contexto e ação.

Camada 3: Diagnóstico Acelerado com IA Generativa

Saber que um job falhou e ter um ticket no JiraOps é um grande passo. Mas há um passo além: chegar ao erro com uma hipótese de diagnóstico antes mesmo de abrir o log.

Integramos o Google Gemini ao fluxo de observabilidade para exatamente isso. Quando um erro ocorre em um pipeline, o callback de falha — além de criar o ticket no JiraOps — aciona o Google Gemini, que analisa a mensagem de erro e envia uma resposta automatizada no Slack, junto à notificação de falha.

A resposta do Google Gemini inclui:

• Interpretação da mensagem de erro em linguagem natural
• Hipóteses mais prováveis de causa raiz
• Sugestões de ações de remediação

O resultado prático é que o engenheiro que chega no alerta já parte de uma hipótese, em vez de começar do zero. Em uma plataforma com dezenas de falhas semanais, isso reduz significativamente o tempo de diagnóstico.

---

Governança e Autonomia dos Times

Quando a operação ficou mais previsível, apareceu o próximo requisito natural: devolver autonomia aos times sem abrir mão de governança.

Controle de Acessos por Time

Com ~1.800 workflows espalhados por múltiplos times com domínios distintos de dados, um desafio operacional natural surge: como dar autonomia para que cada time gerencie seus próprios pipelines sem abrir acesso irrestrito ao ambiente de orquestração?

Construímos um modelo de controle de acessos baseado em grupos de DAGs, configurado via access_dag_groups.json. Cada time tem visibilidade e permissão de ação somente nas DAGs do seu domínio. A DAG Factory respeita essas configurações ao gerar os artefatos de deploy, garantindo que o isolamento de acesso seja declarativo, versionado e auditável — não dependente de configurações manuais na interface do Airflow.

Essa separação permitiu que times de diferentes domínios — ingestão, transformação, serviço de dados — operassem com independência real, sem criar um novo gargalo no time de plataforma.

Deploy: Simplicidade Como Princípio

O pipeline de deploy foi desenhado para ser tão simples quanto possível — e essa simplicidade não é acidental, é uma decisão de arquitetura.

O Google Cloud Composer gerencia toda a infraestrutura do Airflow: workers, scheduler, webserver, banco de metadados. Do nosso lado, o deploy se resume a uma única operação: sincronizar os diretórios dags/ e plugins/ com um bucket no Google Cloud Storage. O Google Cloud Composer detecta as mudanças e as aplica automaticamente. Não há restart de serviços, não há janela de manutenção, não há procedimento manual.

O processo de CD é executado via Azure Pipelines e funciona assim:

1. Um PR é aprovado e mergeado no repositório principal
2. O pipeline de CI valida as specs YAML via Pydantic e executa a DAG Factory, gerando os arquivos .py das DAGs
3. O pipeline de CD faz o rsync entre o repositório e o bucket do Google Storage
4. O Google Cloud Composer detecta as mudanças e sincroniza — as novas DAGs aparecem na interface em segundos

O repositório Git é a fonte da verdade. Qualquer DAG que existe no Google Cloud Composer precisa existir no repositório. Qualquer mudança passa pelo pipeline — não há edição manual de DAGs em produção. Essa restrição eliminou uma classe inteira de problemas que antes consumia energia demais: deploys inconsistentes, divergências entre ambientes e a pergunta recorrente “qual versão está rodando em produção?”.

Launcher Inteligente de Workflows no Databricks

Já rodou um workflow, deu sucesso e os dados não foram atualizados? O job rodou contra uma tabela transacional que não havia sido atualizada naquele dia — e ninguém ficou sabendo até olhar os dados downstream. Isso é desperdício de compute e risco de produzir resultados desatualizados silenciosamente.

O launcher com consciência de data-freshness é uma task no template da DAG que funciona como um gate de pré-voo antes de todo acionamento de job Databricks. Ele avalia a recência dos dados em relação a um threshold configurável e pula o job se os dados transacionais não foram atualizados dentro da janela esperada.

Esse padrão evita inicializações desnecessárias de clusters em toda a plataforma. Em uma carga de ~1.800 jobs, mesmo uma fração modesta de execuções puladas se multiplica em economia mensal relevante. Consciência de custos na camada de execução, onde a decisão realmente acontece, gera impacto imediato.

Documentação Contínua a partir do Código

A dívida de documentação é endêmica em plataformas de dados. Quando o comportamento de um pipeline está finalmente documentado com precisão, o código já evoluiu. Nossa arquitetura elimina esse problema de forma estrutural: a documentação é gerada a partir da mesma especificação YAML que define o pipeline, tornando impossível que as duas divirjam.

Cada spec YAML inclui metadados estruturados — responsável, descrição, datasets upstream, expectativas de SLA, consumidores downstream — que o motor de documentação da plataforma renderiza em um catálogo de dados navegável. Esse catálogo é regenerado a cada deploy, refletindo sempre o estado atual da plataforma.

Além disso, integramos um assistente de documentação baseado em LLM que enriquece as entradas do catálogo geradas por máquina com resumos em linguagem natural e orientações de uso. O resultado é uma documentação que é ao mesmo tempo tecnicamente precisa (porque deriva do código) e legível por humanos (porque é aprimorada por modelos de linguagem).

---

Os Resultados: Quando a Plataforma Fica Previsível

Toda decisão descrita até aqui tinha o mesmo objetivo: tirar a plataforma do modo reativo e colocá-la em um regime previsível de operação. Os números abaixo são a evidência de que isso funcionou:

Métrica	Antes	Depois
Suporte operacional diário	~16h (2 engenheiros sêniores)	~30 min (1 engenheiro júnior)
Custo de orquestração (YoY)	Baseline	~50% de redução (+ 2 ambientes - staging e homologação)
Workflows sob governança	Fragmentado, inconsistente	~1.800 (modelo unificado)
Consistência de deploy	Variável por time	Padronizado via DAG Factory
Rastreabilidade de falhas	Manual, lento, tribal	Automatizado via JiraOps
Modelo de dependência de dados	Implícito (premissas de timing)	Explícito (Airflow Datasets)
Frescor da documentação	Sempre desatualizada	Regenerada a cada deploy

A métrica mais reveladora é a carga de suporte. Cair de 16 horas de cobertura diária de engenheiros sêniores para 30 minutos gerenciados por um engenheiro júnior não significa que a plataforma ficou mais simples. Significa que ficou previsível. Um sistema previsível é aquele em que as falhas seguem padrões conhecidos, os alertas contêm a informação necessária para agir, e o comportamento da plataforma corresponde à sua especificação. Isso é operável. Caos não é.

E a nossa missão é reduzir para zero a carga de suporte operacional — não porque queremos eliminar o trabalho de engenharia, mas porque queremos que os engenheiros gastem seu tempo construindo coisas novas, não apagando incêndios antigos e conhecidos. Automatizar a sustentação é o caminho para a inovação contínua e uma plataforma que realmente capacita os times de dados a entregar valor, em vez de apenas manter as luzes acesas.

---

O que Erramos (E o que Aprendemos)

Não contamos essa história como um sucesso limpo. A arquitetura funcionou, mas a migração cobrou pedágio técnico e organizacional. Estas são as lições honestas:

Subestimamos a superfície de migração do YAML. Traduzir ~1.800 definições de workflow existentes para especificações YAML foi a fase mais longa do projeto — não a engenharia. A governança e a qualidade dos dados das specs de entrada importam tanto quanto a qualidade do motor de geração. Investimos tempo mapeando quais workflows eram candidatos menos críticos para a migração inicial, e isso acelerou o processo. Realizamos a migração em ondas, com muitos PRs e rollback fácil. Alguns erros chegaram a produção — normal para uma migração dessa escala — mas foram rapidamente corrigidos.

Opiniões fortes exigem adesão organizacional, não apenas aplicação técnica. A DAG Factory funciona porque os times a adotaram. Fazer os times abandonarem seus padrões customizados de DAG exigiu mais gestão de stakeholders do que antecipávamos. O design técnico foi a parte fácil.

A adoção de Airflow Datasets é uma jornada, não uma virada de chave. Migramos primeiro os pipelines mais críticos para o agendamento baseado em Dataset. Muitos pipelines ainda rodam em cron. A deprecação das premissas implícitas de timing é um trabalho em andamento — não uma migração concluída.

Construa observabilidade primeiro, mesmo que seja entregue por último. Projetamos a integração com JiraOps e os dashboards na arquitetura desde a primeira semana, mas foram os últimos componentes a se estabilizar totalmente em produção. Em retrospecto, deveríamos ter usado um mecanismo mais simples de incidentes como caminho rápido enquanto o sistema completo maturava.

---

Lições para Times de Plataforma

Destilados à sua forma mais portável, estes são os princípios que levaríamos para o próximo projeto de plataforma:

1. Convenção acima de configuração escala; liberdade, não. Padronizar pela DAG Factory reduziu a sobrecarga cognitiva para cada time que usa a plataforma;
2. Declare dependências ou pague pelo custo das premissas. Cada lacuna implícita de timing em um pipeline é um bug latente. Os Airflow Datasets fornecem o vocabulário para eliminá-los;
3. Consciência de custos pertence à camada de execução. Gates de frescor embutidos no operador, não em uma revisão mensal, mudam a trajetória de custos desde o início;
4. Um especialista, mandato claro, quatro semanas. Velocidade vem de indivíduos empoderados tomando decisões — não de times grandes construindo consenso. Confie nos seus engenheiros mais experientes para se moverem rápido;
5. Observabilidade é arquitetura, não uma feature. Uma plataforma sem tratamento estruturado de falhas e roteamento automático de incidentes vai rotear essas falhas para as agendas dos seus engenheiros sêniores;

---

O que Vem a Seguir

O sistema descrito aqui está em produção desde março de 2025, governando ~1.800 workflows Databricks. A plataforma está estável. Nossos próximos investimentos:

• Agente de otimização de custos baseado em LLM: identificando padrões de desperdício de compute em todo o catálogo de workflows, gerando recomendações proativas de right-sizing de clusters;
• Adoção mais ampla de Airflow Datasets: eliminando os pipelines baseados em cron remanescentes que ainda dependem de premissas de timing;
• Provisionamento self-service: permitindo que times de dados façam deploy de novos workflows de ponta a ponta sem envolvimento do time de plataforma, usando a DAG Factory como interface self-service;

A fundação é sólida. A arquitetura está provada em escala. Mais importante: ela devolveu tempo de engenharia para construir, não apenas sustentar. Esse é o sinal mais claro de que a plataforma saiu do caos e entrou em um regime de previsibilidade.

---

Tecnologias

Camada	Tecnologia
Compute	Databricks (Jobs, Workflows, Clusters)
Orquestração	Apache Airflow 2.x (Datasets, Callbacks, Operadores Customizados)
Infraestrutura Gerenciada	Google Cloud Composer
Validação	Python + Pydantic
Especificação de Pipeline	YAML
Gestão de Incidentes	JiraOps
CI/CD	Pipeline automatizado de validação e deploy de DAGs
LLM (Google Gemini)	Análise de erros com diagnóstico no Slack, geração de documentação do catálogo

---

A CERC opera a infraestrutura do mercado financeiro brasileiro para registro de recebíveis — um sistema onde correção, escala e confiabilidade não são opcionais. Construímos a plataforma de dados sobre a qual o sistema financeiro roda. Se você quer trabalhar em problemas como este — escala real, consequências reais e autonomia para projetar a solução certa — estamos contratando.

---

Este post foi escrito pelo time de Engenharia de Dados da CERC: Davi Campos, André Tayer e Guilherme Oliveira.