Expedia utiliza LLMs para analisar planos do Spark SQL e acelerar depuração de jobs

A Expedia não está apenas usando LLMs como assistentes genéricos para ler planos do Spark SQL. Ela construiu um fluxo de trabalho operacional com três pilares técnicos concretos: (1) integração com o MCP (Model Context Protocol) Server, ferramenta de código aberto da Kubeflow que extrai metadados estruturados diretamente do Spark History Server; (2) engenharia de prompt baseada em antipadrões com limiares métricos objetivos, por exemplo, skew é declarado quando uma partição ultrapassa 5 GB *e* é 5× maior que a média; (3) validação cruzada com dados reais de execução, como volumes de shuffle, spill em disco e leitura bruta de tabelas (ex.: 23,5 TB lidos sem filtro em Vrbo). Isso transforma a análise de planos físicos de um exercício manual de adivinhação em um diagnóstico automatizado com critérios de engenharia de dados.

O sistema opera sobre o plano físico gerado pelo Catalyst Optimizer, mas vai além dele: correlaciona cada operador com métricas de tempo real coletadas no cluster, como tamanho de partição, bytes escritos em shuffle, e latência de tarefa. Não é só 'explicar o plano', é mapear cada linha do EXPLAIN ANALYZE em um risco mensurável de custo ou desempenho.

Em abril de 2026, o Service Telemetry Analyzer já usava LLMs com telemetria do Datadog, mas focava em serviços REST e incidentes de API. Agora, em julho de 2026, a Expedia estendeu a mesma filosofia de IA-assistida para o nível mais baixo da infraestrutura de dados: o plano de execução do Spark. A mudança não é só de escopo, mas de granularidade técnica. Antes, a IA interpretava logs e métricas agregadas. Agora, ela analisa DAGs de tarefas, estatísticas de stage, e até o conteúdo de partições, com regras de detecção codificadas (não heurísticas), como 'transmissão > 1 GB' ou 'explosão de linhas > 2×'. Isso representa uma migração de IA como 'analista de sintomas' para IA como 'engenheiro de performance de execução distribuída'.

Jobs do Spark que demoram horas não são só um problema de tempo: são um problema de governança de custo. Um único job mal otimizado pode consumir centenas de dólares em recursos computacionais por execução. Ao automatizar a detecção de antipadrões com limiares objetivos, e não com interpretações subjetivas, a Expedia converte diagnóstico técnico em ação operacional imediata: ajuste de broadcast join, reescrita de filtro de partição, redistribuição de dados. Isso reduz o tempo médio de resolução de falhas de horas para minutos e corta custos em até 90% por job. Para equipes que operam milhares de pipelines diários, essa não é uma melhoria incremental, é a diferença entre manter ou descartar um pipeline crítico por inviabilidade econômica.