Atualizar o Apache Spark™ nunca foi fácil. Cada versão principal traz melhorias de desempenho, correções de bugs e novos recursos, mas chegar lá é doloroso. A maioria dos usuários do Spark conhece o procedimento. As cargas de trabalho são interrompidas, as APIs mudam e os desenvolvedores podem passar semanas consertando trabalhos apenas para se atualizarem. Isso resulta em novos recursos, melhorias de desempenho e correções de bugs e segurança que levam muito mais tempo para serem adotadas.
Na Databricks, queríamos remover totalmente esse atrito. O resultado é o Versionless Spark, uma nova maneira de executar o Spark que oferece atualizações contínuas, zero alterações de código e estabilidade incomparável. Nos últimos 18 meses, desde lançando notebooks e trabalhos sem servidoro Versionless Spark atualizou automaticamente mais de 2 bilhões de cargas de trabalho do Spark em 25 versões do Databricks Runtime, incluindo as principais versões do Spark, sem qualquer intervenção do usuário.
Neste weblog, compartilharemos como construímos o Spark sem versão, destacaremos os resultados que vimos e mostraremos onde encontrar mais detalhes em nosso artigo publicado recentemente Artigo SIGMOD 2025.
Um novo caminho a seguir: API pública estável por meio de cliente versionado
Para tornar as atualizações perfeitas e recuperar o tempo dos usuários do Databricks, precisávamos ter uma API Spark pública e estável para que pudéssemos atualizar o servidor perfeitamente. Conseguimos isso com uma API cliente estável e versionada, baseada em Faísca Conectarque desacopla o cliente do servidor Spark, permitindo que o Databricks atualize o servidor automaticamente.
A versão do ambiente Databricks serve como uma imagem base contendo pacotes de clientes como Spark Join, Python e dependências pip. O código do usuário e os pacotes adicionais são executados neste ambiente (por exemplo, aplicativo cliente1) e se comunicam com nosso serviço Spark sem servidor. A Databricks lança periodicamente novas versões de ambiente, cada uma com três anos de suporte – semelhante ao DBR LTS. Por padrão, as novas cargas de trabalho usam a versão mais recente, mas os usuários podem continuar executando em versões mais antigas e suportadas, se preferirem.
Ao usar notebooks sem servidor, os usuários podem escolher qualquer versão de ambiente compatível no painel Ambiente do pocket book (conforme mostrado na Figura 2). Para trabalhos sem servidor, a versão do ambiente é definida por meio do arquivo API de trabalho.
Atualizações automáticas e reversões com tecnologia de IA
Fornecer aos nossos usuários atualizações frequentes de segurança, confiabilidade e desempenho é basic ao executar cargas de trabalho automatizadas no Databricks. Isto deve ser feito automaticamente e sem comprometer a estabilidade, especialmente para tubulações de produção. Isso é feito por meio de nosso Launch Stability System (RSS), alimentado por IA, que combina a impressão digital exclusiva de uma carga de trabalho automatizada com metadados de execução, para detectar cargas de trabalho regredidas em novas versões de servidor e reverter automaticamente execuções subsequentes para a versão anterior do servidor. O RSS contém vários componentes:
- Cada carga de trabalho tem um impressão digital da carga de trabalho para identificar execuções repetidas da mesma carga de trabalho com base em um conjunto de propriedades
- Corridas históricas reter metadados sobre execuções anteriores
- Serviço de fixação monitora cargas de trabalho que se comportam de maneira diferente em duas versões de servidor diferentes
- Modelos de ML determinar a classificação de erros, fazer triagem de tíquetes e detectar anomalias na frota
- Detecção de anomalias gasodutos percorrem toda a frota
- Liberar saúde relatórios e alertas fornecem informações de integridade de lançamento em tempo actual para a equipe de engenharia do Databricks
As reversões automáticas garantem que as cargas de trabalho continuem funcionando com êxito após encontrarem regressões
Quando o RSS executa uma reversão em um trabalho automatizado, a carga de trabalho é automaticamente executada novamente em sua última versão conhecida, onde foi bem-sucedida anteriormente. Vamos ilustrar o RSS usando um exemplo actual: Um trabalho automatizado específico foi executado em 9 de abril usando o DBR versão 16.1.2 e apresentou um erro. As execuções históricas indicaram que a carga de trabalho foi bem-sucedida por vários dias consecutivos em 16.1.1. O modelo de ML descobriu que o erro provavelmente foi causado por um bug. Como resultado, uma entrada de fixação foi criada automaticamente no serviço de fixação. Quando a nova tentativa automática – neste caso – da carga de trabalho foi iniciada, ela encontrou a entrada do serviço de fixação e a carga de trabalho foi executada novamente em 16.1.1 e foi bem-sucedida. Isso resultou em um processo de triagem automático em que a engenharia do Databricks foi alertada, identificou o bug e emitiu uma correção. Nesse ínterim, as execuções subsequentes da carga de trabalho permaneceram fixadas em 16.1.1 até que a correção do bug foi implementada em 16.1.3 e a carga de trabalho foi finalmente liberada para 16.1.3 (caixa azul) e continuou a ser executada com sucesso.
Nesse caso, conseguimos detectar e corrigir rapidamente um bug muito sutil que afetou apenas um pequeno número de cargas de trabalho do cliente, sem qualquer impacto na confiabilidade do cliente. Examine isso com o modelo clássico de atualização do Spark, que depende da atualização guide do usuário e geralmente com um atraso significativo. O usuário realizaria a atualização, veria seu trabalho começar a falhar e, então, talvez fosse necessário registrar um tíquete de suporte para resolver o problema. Isto provavelmente levaria muito mais tempo para ser resolvido – exigindo, em última análise, mais envolvimento do cliente e com pior confiabilidade.
Conclusão
Usamos o Launch Stability System para atualizar mais de 2 bilhões de trabalhos, do DBR 14 para o DBR 17 – incluindo a transição para o Spark 4 – ao mesmo tempo em que fornecemos novos recursos como agrupamentootimização de junção de filtro Bloom e drivers JDBC. Desses, apenas 0,000006% dos trabalhos exigiam uma reversão automática, e cada reversão foi corrigida com uma correção e atualizada com sucesso para a versão mais recente em uma média de 12 dias. Essa conquista marca uma inovação no setor: atualizar bilhões de cargas de trabalho de produção do Spark automaticamente, sem nenhuma alteração de código por parte dos usuários.
Tornamos as atualizações do Spark completamente perfeitas, construindo uma nova arquitetura que combina controle de versão do ambiente, um servidor sem versão com atualização automática e o sistema de estabilidade de versão. Essa abordagem pioneira no setor permitiu que a Databricks fornecesse recursos e correções aos usuários com muito mais rapidez e maior estabilidade, permitindo que as equipes de dados se concentrassem mais em resultados de negócios de alto valor, em vez de na manutenção da infraestrutura.
Estamos apenas começando esta jornada e esperamos melhorar ainda mais a experiência do usuário.