Solución:
En general, es difícil decir si Presto es definitivamente más rápido o más lento que Spark SQL. Realmente depende del tipo de consulta que esté ejecutando, el entorno y los parámetros de ajuste del motor. Sin embargo, lo que veo en la industria (ejemplos de Uber, Neflix) Presto se usa como análisis SQL ad-hock mientras que Spark para tuberías ETL / ML.
Una posible explicación, no hay muchos gastos generales para programar una consulta para Presto. El coordinador de Presto siempre está despierto y espera una consulta. Por otro lado, Spark está haciendo un enfoque vago. El controlador necesita tiempo para negociar con el administrador del clúster los recursos, copiar los archivos jar y comenzar a procesar.
Otro que Presto arquitectura bastante sencillo. Tiene un coordinador que hace análisis, planificación, programación de SQL y un conjunto de trabajadores que ejecutan un plan físico.
Por otro lado, Spark Core tiene muchas más capas intermedias. Además de las etapas que tiene Presto, Spark SQL tiene que hacer frente a una construcción de resiliencia en RDD, gestionar los recursos y negociar los trabajos.
Tenga en cuenta también que Spark SQL tiene un Optimizador basado en costos que funciona mejor en consultas complejas. Mientras que Presto (0.199) tiene un optimizador basado en reglas heredado. Hay un esfuerzo continuo para llevar CBO a Presto, lo que potencialmente podría superar el rendimiento de Spark SQL.
Creo que la diferencia clave es que la arquitectura de Presto es muy similar a un motor MPP SQL. Eso significa que está altamente optimizado solo para la ejecución de consultas SQL frente a Spark, que es un marco de ejecución de propósito general que puede ejecutar múltiples cargas de trabajo diferentes, como ETL, Machine Learning, etc.
Además, una compensación que hace Presto para lograr una latencia más baja para las consultas SQL es no preocuparse por la tolerancia a fallas a mitad de la consulta. Si uno de los nodos de trabajo de Presto experimenta una falla (por ejemplo, se apaga), en la mayoría de los casos, las consultas que están en progreso se abortarán y deberán reiniciarse. Spark, por otro lado, es compatible con la tolerancia a fallas a mitad de la consulta y puede recuperarse de tal situación, pero para hacer eso, necesita hacer una contabilidad adicional y esencialmente “planificar para fallas”. Esa sobrecarga da como resultado un rendimiento más lento cuando su clúster no experimenta fallas.
Posición: Presto énfasis en la consulta, sin embargo, enciende el énfasis en el cálculo.
Almacenamiento de memoria: ambos son almacenamiento de memoria y cálculos, Spark escribirá los datos en el disco cuando no pueda obtener suficiente memoria, pero presto conducirá a OOM.
Tareas, recursos: la chispa compromete tareas y solicita recursos en tiempo real en cada etapa (esta estrategia puede resultar en una velocidad de procesamiento ligeramente más lenta en comparación con el presto); Presto solicita todos los recursos necesarios y compromete todas las tareas una vez.
Procesamiento de datos: en Spark, los datos deben procesarse por completo antes de pasar a la siguiente etapa. Presto es un modo de procesamiento de canalización por lotes (página). Siempre que la página esté terminada, se puede enviar a la siguiente tarea (este enfoque reduce en gran medida el tiempo de respuesta de un extremo a otro de varias consultas).
Tolerancia a fallas de datos: si la chispa falla o pierde datos, se volverán a calcular en función del parentesco. Pero presto resultará en un error de consulta.