← Voltar para Artigos

TL;DR — Na CERC, dezenas de engenheiros criam e evoluem jobs Databricks. Isso gerou um problema claro: muita telemetria, pouca decisão. Construímos o Jobs X-Ray para unir custo, performance, recursos e falhas em uma visão única. Adicionamos um motor de recomendação de cluster com regras práticas orientadas por dados. O resultado foi uma equipe que investiga menos depois do problema e age mais antes dele aparecer.

---

A CERC opera a infraestrutura do mercado financeiro para registro de recebíveis. Nossa plataforma de dados sustenta operações em alta escala, com exigência regulatória e impacto direto no negócio. Quando jobs falham, o custo não fica só na nuvem: cai na operação e no tempo de engenharia.

A gestão de jobs Databricks em escala exige mais do que painéis cheios de métricas. Exige sinal confiável, regra operacional e recomendação orientada por dados. Neste artigo, explicamos como construímos o Jobs X-Ray: o que unificamos, como mudamos a rotina das squads e qual motor de recomendação de cluster usamos para reduzir custo sem perder confiabilidade.

Boa leitura!

O problema que cresceu junto com o time

Quando a operação cresce, quase todo time de dados passa pela mesma fase: muita informação, pouca clareza. Nossa complexidade aumentou em duas frentes ao mesmo tempo — o time de engenharia de dados cresceu e outras áreas também passaram a criar e evoluir jobs. O que antes era trabalho de poucos virou rotina de dezenas de pessoas.

Isso foi ótimo para velocidade, mas trouxe um novo desafio para governança técnica. Os dados estavam lá; o trabalho era juntar peças demais para responder perguntas básicas. Qual job está caro sem entregar valor proporcional? Qual gargalo é de código e qual é de cluster? Qual configuração faz sentido para este job agora, e não para a média do mês?

A virada de chave

Na demo mensal, surgiu um ponto central: não faltava dashboard, faltava decisão orientada por sinal confiável. Esse foi o objetivo do Jobs X-Ray — sair de observação reativa e entrar em gestão operacional contínua, dando ferramentas para engenheiros decidirem melhor antes do custo aparecer.

O que o Jobs X-Ray consolidou na gestão de jobs

A primeira versão uniu em uma única visão cinco dimensões de observabilidade:

1. Custo por job em DBU e USD.
2. Duração, estado e frequência de runs.
3. Métricas de execução: spill, shuffle, cache e I/O.
4. Uso de CPU, memória e rede por task.
5. Outliers de duração e padrão de falhas.

Esse desenho reduziu o tempo de triagem e melhorou a qualidade das conversas técnicas. Também criou uma base comum para times diferentes decidirem com o mesmo critério. Quando dezenas de pessoas criam jobs, padrão compartilhado vira requisito, não detalhe.

O que mudou no dia a dia das squads

A principal mudança foi de rotina. Antes, o time investigava depois do alerta crítico. Agora, trabalha com um funil de cinco passos:

1. Overview para leitura rápida de saúde do workspace.
2. Cost Analysis quando há pressão de custo.
3. Performance e I/O para diagnóstico de lentidão.
4. Failures e Outliers para análise de instabilidade.
5. Resource Workers e Driver para sizing de cluster.

Essa ordem parece simples, mas ela evita análise profunda sem hipótese clara. A conversa sai de opinião individual e entra em leitura operacional padronizada — ponto central para reduzir assimetria entre times com níveis diferentes de experiência em Spark e Databricks.

Escala real: um espaço de decisão quase ilimitado

Conforme os jobs aumentam, cresce também o espaço de decisão: família de cluster, tamanho de máquina, perfil de memória, número de workers, estratégia de storage e padrão de execução. Na prática, a combinação possível é quase ilimitada.

Jobs têm sazonalidade. Um job que roda folgado em dias comuns pode saturar em fechamento, virada de mês ou janela regulatória — e o inverso também acontece: job superdimensionado em períodos de baixa. Sem leitura contínua de padrões, o time oscila entre overprovisioning caro e subprovisioning instável.

Seis sinais para transformar telemetria em diagnóstico de jobs

Telemetria só vira gestão quando existe regra operacional. As seis regras mais úteis nesta fase:

1. Spill alto aponta pressão de memória.
2. Shuffle alto aponta distribuição ruim de processamento.
3. Cache hit baixo aponta oportunidade de otimização de reuso.
4. Pruning baixo aponta filtro ou modelagem que precisam revisão.
5. SWAP acima de 5% indica degradação potencial.
6. Diferença alta de CPU entre workers indica skew de dados.

Com esses sinais, a discussão sai do achismo e entra em diagnóstico. Esse mesmo modelo guiou a migração e otimização das operações de BigQuery na CERC, com redução de 40% nos custos após aplicação sistemática de regras operacionais.

Motor de recomendação de cluster com pé no chão

A camada de recomendação de cluster foi o passo mais importante da V1. Ela cruza quatro fatores: utilização média de CPU, família de máquina em uso, compatibilidade com o ambiente GCP/Databricks e risco de saturação. Os exemplos práticos de saída:

1. CPU baixa em família cara: sugerir família mais econômica, com economia estimada em ~30%.
2. CPU alta perto de saturação: sugerir aumento de capacidade ou mais workers.
3. Uso estável: manter configuração atual.

Estimativa de economia não é verdade absoluta: a recomendação gera hipótese, e o ganho real precisa ser medido com comparação antes e depois. É aqui que a IA e a detecção de padrões entram com força — nosso objetivo não é só explicar o que já aconteceu, mas agir antes do erro de dimensionamento virar custo ou incidente.

Uma analogia ajuda: a IA funciona como curadoria de gôndola de supermercado. Existe uma prateleira enorme de opções possíveis, mas a recomendação precisa indicar a oferta certa para aquele contexto, aquele momento e aquele perfil de consumo. No nosso caso, o consumo é o comportamento do job; a oferta é a configuração que equilibra custo, performance e risco operacional.

Outlier como sinal de risco

Passamos a tratar duração fora do padrão como risco operacional, não curiosidade. A detecção estatística por quartis — IQR (Interquartile Range) × 1,5 — separa variação normal de anomalia real: quando um run foge da faixa esperada, a investigação começa com contexto técnico e de negócio. Esse cuidado reduz surpresa em janelas críticas e melhora o planejamento para sazonalidade, transformando variação histórica em insumo de decisão preventiva.

A jornada maior de IA na CERC

Este artigo não é só sobre um painel. Faz parte de uma jornada mais ampla: estamos combinando observabilidade, automação e agentes para decidir melhor com menos ruído. Você pode ver como esse mesmo princípio se aplica na orquestração de workflows Databricks com Apache Airflow e na ingestão de dados em escala com stack declarativa.

No mesmo ciclo, avançamos em eficiência estrutural na plataforma de dados. Um exemplo é a migração da camada raw para política de storage mais eficiente, com redução esperada de 70% a 80% de custo nessa frente. A lógica é única: melhorar custo sem perder confiabilidade, melhorar velocidade sem perder governança, melhorar escala sem aumentar fragilidade.

O que vem na próxima versão

Os próximos passos já estão claros:

1. Dar mais peso para memória no motor de recomendação.
2. Fechar o loop: medir economia observada após mudança aplicada.
3. Integrar recomendações com priorização de backlog técnico.
4. Incorporar sazonalidade como fator de recomendação.
5. Criar alertas preventivos de desvio antes da janela crítica.

A meta é sair de “acho que melhorou” para “provei que melhorou”. Se você está estruturando observabilidade de jobs Databricks e quer trocar experiência com nossa equipe, conheça as oportunidades abertas na CERC.