LQRS: Learned Query Re-optimization Framework for Spark SQL

El artículo presenta LQRS, un marco de reoptimización de consultas aprendido para Spark SQL que utiliza observaciones en tiempo de ejecución y aprendizaje por refuerzo para refinar dinámicamente los planes de consulta, logrando reducir el tiempo de ejecución hasta en un 90% en comparación con otros métodos.

Lo esencial

Imagina que tienes un chef experto (el optimizador de consultas) en una cocina muy grande y compleja (la base de datos Spark SQL). Su trabajo es decidir el mejor orden para preparar un plato gigante que tiene muchos ingredientes (tablas de datos).

El Problema: El Chef que no puede improvisar

En el pasado, y con la mayoría de los sistemas actuales, el chef lee la receta y decide el orden de los pasos antes de encender el fuego.

• El error: A veces, la receta dice "corta 100 cebollas", pero cuando el chef empieza a cortar, se da cuenta de que en realidad solo hay 1 cebolla en la despensa. Sin embargo, como ya decidió el plan, sigue cortando las 100 cebollas imaginarias, desperdiciando tiempo y energía.
• Los "chefs aprendices" (Optimizadores tradicionales): Intentan adivinar cuántas cebollas hay basándose en recetas viejas, pero a menudo se equivocan.
• Los "chefs inteligentes" (Optimizadores aprendidos o LQO): Son sistemas de Inteligencia Artificial que han estudiado miles de recetas. Son mejores adivinando, pero siguen atados a su plan inicial. Si el plan dice "hacer la salsa primero", lo hacen aunque vean que la sartén está fría. No pueden cambiar de opinión a mitad de la cocción.

La Solución: LQRS (El Chef que improvisa en tiempo real)

Los autores de este paper, de la Universidad Renmin de China, crearon LQRS. Imagina a LQRS como un chef maestro que tiene un asistente mágico que le susurra al oído lo que está pasando mientras cocina.

Aquí está la analogía de cómo funciona:

1. La Cocina Inteligente (Spark AQE)

Spark SQL ya tiene una característica llamada "Ejecución Adaptativa". Es como si la cocina tuviera sensores que le dicen al chef: "Oye, la cebolla que cortaste pesa solo 1 gramo, no 1 kilo".

• El problema de Spark: El sensor le dice la verdad, pero el chef (el planificador) es terco y sigue el plan original. Solo cambia la técnica (por ejemplo, cambiar de cuchillo), pero no el orden de los ingredientes.

2. El Asistente Mágico (LQRS)

LQRS se conecta a esos sensores y actúa como un entrenador de IA que toma decisiones en tiempo real.

• Observa: "¡Espera! La tabla 't' solo tiene 1 fila de datos. ¡Es minúscula!"
• Actúa: En lugar de seguir el plan original, LQRS le dice al sistema: "Cambia el orden. Pon esa tabla pequeña primero, únela con la otra ahora mismo".
• Resultado: El chef reordena los pasos sobre la marcha. En lugar de cocinar una sopa gigante y luego filtrarla, filtra los ingredientes pequeños primero, ahorrando una cantidad enorme de esfuerzo.

¿Cómo aprende este sistema? (El Gimnasio de la Cocina)

Para que LQRS sea bueno, necesita entrenarse. Los autores usaron una técnica llamada Aprendizaje por Refuerzo (como entrenar a un perro o a un jugador de videojuegos):

1. El Actor (El Chef): Toma decisiones (¿Cambio el orden? ¿Uso un método diferente?).
2. El Crítico (El Juez): Observa lo que hizo el Chef.
   • Si el Chef cambió el orden y la sopa quedó rica y rápida: ¡Puntos! (Recompensa).
   • Si el Chef cambió el orden y tuvo que tirar toda la sopa a la basura porque se mezcló mal: ¡Penalización! (Castigo).
3. Curriculum Learning (Entrenamiento Progresivo): Al principio, el sistema solo le permite al Chef hacer cambios simples (como elegir entre dos recetas básicas). Poco a poco, le permite hacer cambios más complejos (cambiar el orden de 5 ingredientes a la vez). Esto evita que el sistema se abrume y aprenda mejor.

La Magia de "Re-optimizar"

La gran innovación de LQRS es que no espera a que termine la comida para aprender.

• Si el Chef se equivoca en el paso 1, LQRS lo corrige en el paso 2.
• Si el Chef aprende que "la tabla X siempre es pequeña", guarda ese conocimiento para la próxima vez que empiece a cocinar (antes de encender el fuego).

¿Por qué es tan rápido?

En las pruebas, LQRS fue capaz de reducir el tiempo de ejecución hasta un 90% en comparación con otros sistemas.

• Imagina: Tienes que recorrer un laberinto.
  • Spark normal: Te da un mapa estático. Si hay un muro nuevo, chocas contra él.
  • Otros sistemas de IA: Te dan un mapa mejorado, pero si chocas contra un muro, sigues caminando contra él hasta que te cansas.
  • LQRS: Tiene un mapa en tiempo real. Si ves un muro, giras inmediatamente. Además, si ves un atajo, lo tomas al instante.

En resumen

LQRS es un sistema que convierte a la base de datos de un "robot que sigue instrucciones ciegamente" en un "chef experto que improvisa". Utiliza lo que está pasando ahora mismo (datos reales) para corregir sus errores al instante, haciendo que las consultas de datos sean mucho más rápidas y eficientes, ahorrando tiempo y energía en el proceso.

Resumen técnico

Resumen Técnico: LQRS (Marco de Re-optimización de Consultas Aprendido para Spark SQL)

1. El Problema

Los optimizadores de consultas tradicionales basados en costos (CBO) y los optimizadores aprendidos (LQO) recientes (como Lero o AutoSteer) comparten una limitación fundamental: operan bajo el paradigma "optimizar luego ejecutar".

• Inexactitud de las estimaciones: Los modelos de costos tradicionales y los modelos aprendidos se basan en estadísticas estimadas antes de la ejecución. Estas estimaciones a menudo son inexactas debido a distribuciones de datos desconocidas o selectividades complejas.
• Planos estáticos: Una vez que se selecciona un plan de ejecución, este se mantiene fijo durante toda la consulta.
• Pérdida de información en tiempo de ejecución: Durante la ejecución, el sistema genera observaciones valiosas (como cardinalidades reales de resultados intermedios), pero los optimizadores existentes no pueden utilizar esta información para re-optimizar dinámicamente el plan en curso.
• Limitaciones de Spark AQE: Aunque Spark SQL 3.0 introdujo la Ejecución de Consulta Adaptativa (AQE) para ajustar estrategias de unión (Join) en tiempo de ejecución, esta se limita a umbrales configurados manualmente y no puede cambiar el orden de las uniones una vez que la ejecución ha comenzado, perdiendo oportunidades de optimización crítica.

2. Metodología: LQRS

LQRS es un marco de re-optimización de consultas aprendida que integra el aprendizaje por refuerzo (RL) dentro del motor de ejecución de Spark SQL, permitiendo que las decisiones de optimización se pospongan hasta el tiempo de ejecución y se guíen por observaciones reales.

Componentes Clave:

1. Extensión del Planificador (Planner Extension):

   • Se construye sobre las interfaces de extensibilidad de Spark AQE.
   • Actúa como un intermediario que intercepta el plan de ejecución en puntos de sincronización naturales (finalización de "stages" o etapas de consulta).
   • Extrae el plan parcialmente ejecutado y las estadísticas en tiempo real (cardinalidades reales, tamaños en bytes).
   • Aplica las acciones de optimización devueltas por el modelo de decisión directamente al plan en ejecución sin reiniciar la consulta.

2. Modelo de Decisión (Actor-Critic con RL):

   • Arquitectura: Utiliza una red neuronal basada en TreeCNN (Red Neuronal Convolucional en Árboles) para codificar la estructura del plan de consulta como un árbol vectorizado.
   • Estado ($s_t$): Compuesto por el plan parcialmente ejecutado y las estadísticas reales de las etapas completadas.
   • Espacio de Acciones: El modelo puede realizar cinco tipos de acciones:
     • init: Seleccionar la estrategia de inicialización del plan.
     • swap: Intercambiar nodos hoja (reordenar uniones).
     • lead: Promover una tabla específica para que se una primero.
     • broadcast: Forzar una unión por difusión (broadcast) en un nodo específico.
     • no-op: No realizar ninguna acción (esperar más información).
   • Recompensa: Diseñada para maximizar el tiempo de ejecución total, penalizando las operaciones de "reshuffle" (reasignación de datos) innecesarias y recompensando la reducción del tiempo de ejecución.
   • Estrategia de Aprendizaje (Curriculum Learning): El entrenamiento comienza con decisiones simples (solo inicialización) y aumenta gradualmente la complejidad (permitiendo reordenamientos y ajustes en tiempo de ejecución) para estabilizar el aprendizaje.

Flujo de Trabajo:

1. Spark ejecuta una etapa de consulta.
2. La extensión del planificador extrae el estado actual y lo envía al modelo.
3. El modelo (Actor) predice una acción (ej. cambiar el orden de unión).
4. La extensión aplica la transformación al plan restante (ej. convertir una unión lineal en una arbórea).
5. Spark reanuda la ejecución con el nuevo plan.
6. Al finalizar la consulta, el modelo (Critic) evalúa las acciones tomadas para actualizar la política.

3. Contribuciones Clave

• Unificación de Optimización: LQRS es el primer optimizador aprendido en Spark SQL que soporta simultáneamente la optimización previa a la ejecución y la optimización durante la ejecución, unificando la optimización aprendida con el procesamiento adaptativo.
• Re-optimización Dinámica: Permite corregir decisiones tomadas antes de la ejecución (como un mal orden de uniones) basándose en observaciones reales de cardinalidad, algo que los optimizadores estáticos no pueden hacer.
• Arquitectura Plug-and-Play: La extensión del planificador se integra en las interfaces existentes de Spark SQL, permitiendo la modificación en línea de planes sin necesidad de reiniciar la consulta o invalidar etapas completadas.
• Señales de Retroalimentación Densas: A diferencia de los métodos que solo reciben retroalimentación al final de la consulta, LQRS recibe señales densas (por etapa de consulta), lo que acelera la convergencia del aprendizaje.

4. Resultados Experimentales

Los experimentos se realizaron sobre cuatro benchmarks estándar (JOB, ExtJOB, STACK, TPC-H) en Spark SQL.

• Rendimiento General: LQRS redujo el tiempo de ejecución de extremo a extremo en un 90% en comparación con otros optimizadores aprendidos y métodos de re-optimización.
• Comparativa con Baselines:
  • Superó consistentemente a Spark SQL (con AQE nativo), Lero, AutoSteer y SSA (QuerySplit).
  • En el benchmark JOB, LQRS redujo el tiempo total de 5821s (Spark SQL) a 3069s, mientras que Lero tardó 33211s.
• Análisis de Casos:
  • LQRS logró transformar planes de unión lineales en estructuras arbóreas (bushy joins) dinámicamente, algo que AQE nativo no permite.
  • En consultas donde una tabla producía muy pocas filas (ej. 1 tupla), LQRS reordenó las uniones para procesar esa tabla primero, reduciendo drásticamente los datos intermedios y permitiendo que AQE cambiara estrategias de unión (de Sort-Merge a Broadcast) de manera más eficiente.
• Robustez: LQRS demostró ser robusto ante cambios en la distribución de datos y cargas de trabajo, aunque mostró cierta degradación en entornos de ejecución muy diferentes a los de entrenamiento en comparación con Lero (debido a la exploración de acciones no vistas).
• Sobrecarga (Overhead): LQRS tiene la sobrecarga de optimización más baja entre los métodos aprendidos (ej. 33.3s en JOB vs 30098s de Lero), ya que toma decisiones en tiempo de ejecución basadas en datos reales y evita la enumeración exhaustiva de planes antes de ejecutar.

5. Significado e Impacto

El trabajo de LQRS representa un avance significativo en la gestión de bases de datos modernas al cerrar la brecha entre la optimización basada en aprendizaje y la ejecución adaptativa.

• Cambio de Paradigma: Demuestra que las decisiones de optimización no deben ser estáticas; deferirlas al tiempo de ejecución y guiarlas con datos reales supera las limitaciones inherentes de las estimaciones de costos.
• Viabilidad Práctica: Al integrarse directamente en Spark SQL mediante una extensión del planificador, LQRS ofrece una solución práctica y escalable que no requiere cambiar el núcleo del motor, sino extenderlo inteligentemente.
• Futuro de los Optimizadores: Establece un precedente para que los futuros optimizadores aprendidos no solo "aprendan a elegir" un plan, sino que "aprendan a ajustar" el plan mientras se ejecuta, maximizando el rendimiento en entornos de datos dinámicos y complejos.