Repensando Sistemas Distribuídos para Desempenho e Confiabilidade Serverless

Criar computação verdadeiramente serverless para Apache Spark exigiu a solução de desafios arquitetônicos fundamentais que existem desde o início do Spark. A complexidade vai muito além de simplesmente criar pools aquecidos de máquinas ou implementar escalonamento automático básico. Foi necessário repensar as premissas centrais de como os sistemas de computação distribuída devem operar.

Implantações tradicionais de Spark expõem a infraestrutura diretamente aos usuários, criando um acoplamento estreito entre aplicações e computação. Cargas de trabalho competem por recursos compartilhados, pequenas ineficiências podem se cascatear em falhas, e os usuários são forçados a equilibrar manualmente desempenho, custo e confiabilidade. À medida que a demanda muda, os sistemas lutam para manter tanto a alta utilização quanto o desempenho previsível.

A computação serverless adota uma abordagem diferente ao gerenciar totalmente a infraestrutura para que o usuário possa se concentrar nos dados e insights. A estabilidade se torna uma propriedade do sistema em vez de uma responsabilidade do usuário, possibilitada por arquiteturas que isolam cargas de trabalho, as posicionam de forma inteligente e adaptam recursos dinamicamente.

A computação serverless foi projetada para melhorar a estabilidade, o desempenho e a simplicidade operacional. Três sistemas centrais tornam isso possível:

1. Spark Connect, que separa aplicações do usuário da infraestrutura de computação
2. O Serverless Gateway, que roteia cargas de trabalho de forma inteligente entre recursos de computação
3. Um autoscaler adaptativo, que otimiza continuamente o tamanho do cluster para desempenho e custo

Juntos, esses sistemas possibilitam um modelo onde o desempenho é alcançado garantindo primeiro a estabilidade em todo o sistema.

Spark Connect: Estabilidade Através do Isolamento

Spark Connect representa a transformação arquitetônica mais significativa na história do Spark, um afastamento completo do design monolítico que definiu a computação distribuída por mais de uma década. Em arquiteturas tradicionais, aplicações do usuário rodam diretamente na mesma máquina que o driver Spark, criando um acoplamento estreito que introduz limitações críticas. Quando múltiplas aplicações competem por recursos no mesmo cluster ou quando o código do usuário consome memória ou CPU excessivas, o sistema se torna instável, levando a falhas que podem se cascatear entre as cargas de trabalho.

O Spark Connect introduz uma arquitetura cliente-servidor na qual as aplicações se comunicam com o driver Spark via gRPC, e o driver executa consultas em nome do cliente em vez de rodar processos do usuário diretamente. Isso muda a unidade de execução de processos de aplicação para consultas e permite uma separação limpa entre aplicações do usuário e infraestrutura.

Esse desacoplamento melhora significativamente a confiabilidade e permite que a plataforma gerencie drivers independentemente das cargas de trabalho do usuário. Ao isolar aplicações da computação, o Spark Connect cria a base necessária para execução estável multi-tenant e permite um gerenciamento de recursos mais avançado em todo o sistema.

Essa arquitetura permite que a Databricks entregue mais de 25 atualizações principais de runtime Spark por ano com uma taxa de sucesso de 99,998% em mais de 4,5 bilhões de cargas de trabalho, sem a necessidade de ação do usuário.¹

O Gateway: Equilibrando Eficiência e Previsibilidade

Sistemas distribuídos há muito tempo enfrentam uma tensão fundamental entre eficiência e previsibilidade. Maximizar a utilização muitas vezes leva à contenção de recursos, enquanto isolar cargas de trabalho pode resultar em capacidade subutilizada. Modelos de cluster tradicionais forçam os usuários a navegar por esse trade-off manualmente, muitas vezes resultando em desempenho imprevisível ou execução não confiável à medida que as cargas de trabalho mudam.

Considere o que acontece quando dezenas de consultas chegam simultaneamente: algumas pequenas explorações rodando contra dados de amostra, outras grandes jobs de ETL processando centenas de gigabytes. Um roteador ingênuo as trata de forma idêntica, forçando jobs grandes a esperar atrás de jobs pequenos ou permitindo que cargas de trabalho compitam pelo mesmo cluster, levando a uma degradação imprevisível do desempenho. Essa dinâmica torna difícil entregar alta utilização e desempenho consistente em ambientes compartilhados.

O gateway Databricks roteia cada carga de trabalho avaliando três sinais em tempo real: tamanho estimado da consulta (derivado do plano lógico), utilização atual em todo o pool de clusters e perfil de latência: se uma sessão é interativa e sensível à latência ou um job em batch otimizado para throughput. Uma pequena consulta exploratória é roteada para um cluster com pouca carga que pode responder em segundos; um job de ETL pesado é direcionado para um cluster com capacidade disponível para seu volume de dados, ou o autoscaler é sinalizado para provisionar um. Quando as condições mudam (um cluster enche, um job de longa duração termina, um novo cluster entra online), o gateway reavalia continuamente os posicionamentos e corrige o roteamento sem intervenção do usuário. O resultado: cargas de trabalho são isoladas umas das outras. Uma consulta descontrolada em um cluster não atrasa consultas em outro, e o sistema mantém alta utilização sem sacrificar a previsibilidade.

Autoscaling: Otimizando a Curva de Custo-Desempenho

O dimensionamento dinâmico de clusters é o principal mecanismo para otimizar o custo-desempenho em sistemas distribuídos, mas determinar a quantidade ideal de computação é inerentemente complexo. A configuração ideal depende das características da carga de trabalho, do tamanho dos dados e da importância relativa da latência versus custo, sem uma única configuração funcionar em todos os cenários. A computação serverless da Databricks oferece dois modos para atender a diferentes necessidades: Standard, que usa menos computação para reduzir custos, e Performance-Optimized, que oferece inicialização e execução mais rápidas para cargas de trabalho sensíveis ao tempo.

A inicialização é uma prioridade para nós, e os Notebooks e Workflows serverless fizeram uma enorme diferença. A computação serverless para notebooks facilita com apenas um clique. — Chiranjeevi Katta, Engenheiro de Dados na Airbus

A Databricks nos ajudou a migrar para computação serverless, eliminando fluxos de trabalho redundantes. Essas eficiências nos colocaram em posição de reduzir os custos operacionais em 25%. Pipelines em nossa infraestrutura legada levavam horas para processar. Agora, eles rodam de 2 a 5 vezes mais rápido. — Evan Cherney, Gerente Sênior de Ciência de Dados na Unilever

Abordagens tradicionais de autoscaling dependem de regras estáticas e limiares reativos, que frequentemente falham em capturar essas nuances. Como resultado, os clusters são frequentemente sub ou superprovisionados, levando a ineficiência, instabilidade ou ambos.

O autoscaling serverless adota uma abordagem mais adaptativa. Ao analisar continuamente os padrões de carga de trabalho e sinais de todo o sistema, o autoscaler posiciona cada carga de trabalho na curva de custo-desempenho ideal, onde a maioria dos clusters configurados manualmente falha, entregando pior desempenho e custo mais alto devido à dificuldade de dimensionar corretamente sistemas distribuídos. Ele ajusta dinamicamente a capacidade de computação escalando horizontal e verticalmente conforme necessário, prevenindo falhas de falta de memória e mantendo a estabilidade à medida que as cargas de trabalho crescem. Quando uma tarefa encontra um erro de falta de memória, o autoscaler o detecta automaticamente, reinicia a tarefa em uma VM maior e continua o job sem intervenção manual ou falha do job.

O impacto é mensurável. A CKDelta relatou jobs concluindo em 20 minutos que antes rodavam por 4–5 horas. A Unilever viu pipelines rodando 2–5x mais rápido com custos operacionais reduzidos em 25%. A HP obteve economias na nuvem de mais de 32% e reduziu o tempo de execução combinado dos jobs em 36%.

Juntos, o Spark Connect, o gateway e o autoscaler possibilitam um modelo operacional fundamentalmente diferente para o Spark. As cargas de trabalho são isoladas, posicionadas de forma inteligente e com recursos dinâmicos sem intervenção do usuário. Ao abordar a estabilidade no nível arquitetônico, a computação serverless pode entregar forte desempenho mantendo a confiabilidade, permitindo que os usuários se concentrem na construção de cargas de trabalho de dados e IA em vez de gerenciar infraestrutura.

¹ Justin Breese et al., "Blink Twice: Automatic Workload Pinning and Regression Detection for Versionless Apache Spark using Retries," SIGMOD/PODS '25, pp. 103–106. https://doi.org/10.1145/3722212.3725084

Comece Sua Jornada Serverless Hoje

• Cadastre-se em uma conta Databricks Serverless
• Computação Serverless para Notebooks, Jobs Lakeflow e Pipelines Declarativas Spark
• Guia do Praticante para Computação Serverless

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original