Repensando sistemas distribuidos para rendimiento y confiabilidad sin servidor

Construir cómputo verdaderamente serverless para Apache Spark requirió resolver desafíos arquitectónicos fundamentales que han existido desde el inicio de Spark. La complejidad va mucho más allá de simplemente crear grupos de máquinas calientes o implementar escalado automático básico. Requirió repensar las suposiciones centrales sobre cómo deberían operar los sistemas de cómputo distribuido.

Las implementaciones tradicionales de Spark exponen la infraestructura directamente a los usuarios, creando un acoplamiento estrecho entre las aplicaciones y el cómputo. Las cargas de trabajo compiten por recursos compartidos, las pequeñas ineficiencias pueden convertirse en fallos, y los usuarios se ven obligados a equilibrar manualmente el rendimiento, el costo y la confiabilidad. A medida que la demanda cambia, los sistemas luchan por mantener tanto una alta utilización como un rendimiento predecible.

El cómputo serverless adopta un enfoque diferente al gestionar completamente la infraestructura para que el usuario pueda centrarse en los datos y los insights. La estabilidad se convierte en una propiedad del sistema en lugar de una responsabilidad del usuario, habilitada por arquitecturas que aíslan las cargas de trabajo, las colocan inteligentemente y adaptan dinámicamente los recursos.

El cómputo serverless está diseñado para mejorar la estabilidad, el rendimiento y la simplicidad operativa. Tres sistemas centrales lo hacen posible:

1. Spark Connect, que separa las aplicaciones de usuario de la infraestructura de cómputo
2. La Serverless Gateway, que enruta inteligentemente las cargas de trabajo a través de los recursos de cómputo
3. Un autoscaler adaptativo, que optimiza continuamente el tamaño del clúster para el rendimiento y el costo

Juntos, estos sistemas permiten un modelo donde el rendimiento se logra asegurando primero la estabilidad en todo el sistema.

Spark Connect: Estabilidad a través del Aislamiento

Spark Connect representa la transformación arquitectónica más significativa en la historia de Spark, una desviación completa del diseño monolítico que ha definido la computación distribuida durante más de una década. En las arquitecturas tradicionales, las aplicaciones de usuario se ejecutan directamente en la misma máquina que el driver de Spark, creando un acoplamiento estrecho que introduce limitaciones críticas. Cuando múltiples aplicaciones compiten por recursos en el mismo clúster o cuando el código del usuario consume memoria o CPU excesivas, el sistema se vuelve inestable, lo que lleva a fallos que pueden propagarse a través de las cargas de trabajo.

Spark Connect introduce una arquitectura cliente-servidor en la que las aplicaciones se comunican con el driver de Spark a través de gRPC, y el driver ejecuta consultas en nombre del cliente en lugar de ejecutar procesos de usuario directamente. Esto cambia la unidad de ejecución de procesos de aplicación a consultas y permite una separación limpia entre las aplicaciones de usuario y la infraestructura.

Este desacoplamiento mejora significativamente la confiabilidad y permite que la plataforma gestione los drivers de forma independiente de las cargas de trabajo del usuario. Al aislar las aplicaciones del cómputo, Spark Connect crea la base requerida para una ejecución multi-inquilino estable y permite una gestión de recursos más avanzada en todo el sistema.

Esta arquitectura permite a Databricks ofrecer más de 25 actualizaciones importantes del runtime de Spark al año con una tasa de éxito del 99.998% en más de 4.5 mil millones de cargas de trabajo, sin requerir ninguna acción del usuario.¹

La Gateway: Equilibrando Eficiencia y Previsibilidad

Los sistemas distribuidos han enfrentado durante mucho tiempo una tensión fundamental entre eficiencia y previsibilidad. Maximizar la utilización a menudo conduce a la contención de recursos, mientras que aislar las cargas de trabajo puede resultar en capacidad infrautilizada. Los modelos de clústeres tradicionales obligan a los usuarios a navegar por esta compensación manualmente, lo que a menudo resulta en un rendimiento impredecible o una ejecución poco confiable a medida que cambian las cargas de trabajo.

Considere lo que sucede cuando docenas de consultas llegan simultáneamente: algunos pequeños escaneos exploratorios ejecutándose contra datos de muestra, otros trabajos ETL de producción grandes procesando cientos de gigabytes. Un enrutador ingenuo los trata de manera idéntica, obligando a los trabajos grandes a esperar detrás de los pequeños o permitiendo que las cargas de trabajo compitan por el mismo clúster, lo que lleva a una degradación impredecible del rendimiento. Esta dinámica hace que sea difícil ofrecer tanto alta utilización como rendimiento consistente en entornos compartidos.

La gateway de Databricks enruta cada carga de trabajo evaluando tres señales en tiempo real: tamaño estimado de la consulta (derivado del plan lógico), utilización actual en el pool de clústeres y perfil de latencia: si una sesión es interactiva y sensible a la latencia o un trabajo por lotes optimizado para el rendimiento. Una pequeña consulta exploratoria se enruta a un clúster poco cargado que puede responder en segundos; un trabajo ETL pesado se dirige a un clúster con capacidad disponible para su volumen de datos, o se señala al autoscaler para que aprovisione uno. Cuando las condiciones cambian (un clúster se llena, un trabajo de larga duración termina, un nuevo clúster se activa), la gateway reevalúa continuamente las colocaciones y corrige el enrutamiento sin intervención del usuario. El resultado: las cargas de trabajo están aisladas entre sí. Una consulta descontrolada en un clúster no retrasa las consultas en otro, y el sistema mantiene una alta utilización sin sacrificar la previsibilidad.

Autoscaling: Optimizando la Curva de Costo-Rendimiento

El dimensionamiento dinámico de clústeres es el mecanismo principal para optimizar el precio-rendimiento en sistemas distribuidos, pero determinar la cantidad óptima de cómputo es intrínsecamente complejo. La configuración óptima depende de las características de la carga de trabajo, el tamaño de los datos y la importancia relativa de la latencia frente al costo, sin que una única configuración funcione en todos los escenarios. Databricks serverless ofrece dos modos para adaptarse a diferentes necesidades: Estándar, que utiliza menos cómputo para reducir costos, y Optimizado para Rendimiento, que ofrece un inicio y ejecución más rápidos para cargas de trabajo sensibles al tiempo.

El inicio es una prioridad para nosotros, y los Notebooks y Workflows serverless han marcado una gran diferencia. El cómputo serverless para notebooks lo hace fácil con un solo clic. — Chiranjeevi Katta, Ingeniero de Datos en Airbus

Databricks nos ayudó a pasar a cómputo serverless, eliminando flujos de trabajo redundantes. Estas eficiencias nos pusieron en posición de reducir los costos operativos en un 25%. Los pipelines en nuestra infraestructura heredada solían tardar horas en procesarse. Ahora, se ejecutan de 2 a 5 veces más rápido. — Evan Cherney, Gerente Senior de Ciencia de Datos en Unilever

Los enfoques tradicionales de escalado automático se basan en reglas estáticas y umbrales reactivos, que a menudo no capturan estos matices. Como resultado, los clústeres a menudo se aprovisionan en exceso o en defecto, lo que genera ineficiencia, inestabilidad o ambas cosas.

El escalado automático serverless adopta un enfoque más adaptativo. Al analizar continuamente los patrones de carga de trabajo y las señales de todo el sistema, el autoscaler posiciona cada carga de trabajo en la curva de costo-rendimiento óptima, donde la mayoría de los clústeres configurados manualmente se quedan cortos, ofreciendo un rendimiento peor y un costo mayor debido a la dificultad de dimensionar correctamente los sistemas distribuidos. Ajusta dinámicamente la capacidad de cómputo escalando horizontal y verticalmente según sea necesario, previniendo fallos de falta de memoria y manteniendo la estabilidad a medida que crecen las cargas de trabajo. Cuando una tarea encuentra un error de falta de memoria, el autoscaler lo detecta automáticamente, reinicia la tarea en una VM más grande y continúa el trabajo sin intervención manual ni fallo del trabajo.

El impacto es medible. CKDelta reportó trabajos completados en 20 minutos que antes se ejecutaban durante 4–5 horas. Unilever vio pipelines ejecutándose 2–5 veces más rápido con costos operativos reducidos en un 25%. HP logró ahorros en la nube de más del 32% y redujo el tiempo de ejecución combinado de los trabajos en un 36%.

Juntos, Spark Connect, la gateway y el autoscaler permiten un modelo operativo fundamentalmente diferente para Spark. Las cargas de trabajo se aíslan, se colocan inteligentemente y se les asignan recursos dinámicamente sin intervención del usuario. Al abordar la estabilidad a nivel arquitectónico, el cómputo serverless puede ofrecer un rendimiento sólido manteniendo la confiabilidad, permitiendo a los usuarios centrarse en la creación de cargas de trabajo de datos e IA en lugar de gestionar la infraestructura.

¹ 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

Comienza Tu Viaje Serverless Hoy

• Regístrate en una cuenta de Databricks Serverless
• Cómputo Serverless para Notebooks, Trabajos de Lakeflow y Pipelines Declarativas de Spark
• Guía del Practicante para Cómputo Serverless

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original