Operações
JuniorPor que meu pipeline funciona no dev mas falha ou fica lento em produção?
Dev não mente exatamente — só responde uma pergunta diferente da que importa em produção: "isso funciona", não "isso funciona com 50x mais dados".
Isso é menos um bug único e mais uma categoria de bug, e quase toda instância dela se resume a uma de algumas formas específicas em que dev e produção divergem.
Volume de dados, obviamente — mas também formato dos dados
A diferença mais óbvia é volume: uma amostra de dev de 10.000 linhas não exercita spill de shuffle, skew ou pressão de memória como 500 milhões de linhas exercitam. Menos óbvio: o formato dos dados também difere — uma amostra de dev costuma ser tirada de forma uniforme ou recente, o que pode acidentalmente evitar justamente a distribuição de chave enviesada ou a coluna cheia de nulls que os dados de produção têm. Diferenças de volume aparecem como lentidão; diferenças de formato aparecem como jobs que falham direto em padrões de dados que o dev nunca continha.
Disputa de cluster que ambientes de dev não têm
Um cluster de dev geralmente é dedicado a uma pessoa rodando um job. Clusters de produção frequentemente são compartilhados, multi-tenant, ou sujeitos a efeitos de "vizinho barulhento" de outros jobs disputando os mesmos recursos. Um job que recebe alocação completa e sem disputa de executors no dev pode ver performance significativamente degradada em produção puramente por disputa de recursos, sem relação nenhuma com a lógica do próprio job.
Deriva de configuração entre ambientes
Memória do executor, shuffle partitions e número de instâncias frequentemente são ajustados manualmente uma vez para um teste em escala de dev, e nunca revisados para o deploy em escala de produção — ou o contrário, a configuração de produção é copiada desnecessariamente para o dev. De qualquer forma, a configuração que "funcionou" nunca foi de fato validada contra as características reais do outro ambiente.
Como realmente fechar essa lacuna antes de fazer deploy
A abordagem mais confiável: extrapolar, não adivinhar. Pegue métricas reais de uma execução de dev — duração de task, volume de shuffle, uso de memória por linha processada — e escale elas linearmente (ou com seus próprios fatores não lineares conhecidos, como o custo de shuffle escalando pior que linearmente com o número de linhas) para o volume estimado de produção, antes da primeira execução em produção. Isso transforma "vamos descobrir em produção" em uma previsão testável que você pode validar contra o que realmente acontece.
Vale ser direto sobre isso: esse fluxo específico de "extrapolar métricas de dev para escala de produção" não é algo que o opti-pipe faz hoje — ele analisa as métricas de uma execução que você já teve, dev real ou produção real, em vez de projetar para frente a partir de uma menor. É uma funcionalidade genuinamente útil que ainda não temos, não uma que estamos afirmando ter.
Veja como isso fica no seu próprio pipeline.
Envie um event log real do Spark, um run_results.json do dbt, ou uma exportação de métricas do Flink, e receba recomendações concretas para aprovar — não mais uma regra de bolso.