performance - Spark: número de rendimiento inconsistente en la escala del número de núcleos

apache-spark hadoop

Question

Estoy haciendo una prueba de escala simple en Spark usando benchmark de clasificación: desde 1 núcleo, hasta 8 núcleos. Noto que 8 núcleos es más lento que 1 núcleo.

//run spark using 1 core
spark-submit --master local[1] --class john.sort sort.jar data_800MB.txt data_800MB_output
//run spark using 8 cores
spark-submit --master local[8] --class john.sort sort.jar data_800MB.txt data_800MB_output

Los directorios de entrada y salida en cada caso, están en HDFS.

1 núcleo: 80 segundos

8 núcleos: 160 segundos

Esperaría que el rendimiento de 8 núcleos tenga x cantidad de aceleración.

Answer 1

Limitaciones teóricas

Supongo que conoce la ley de Amdahl, pero aquí hay un recordatorio rápido. La aceleración teórica se define de la siguiente manera:

dónde :

• s - es la aceleración de la parte paralela.
• p - es una fracción del programa que se puede paralelizar.

En la práctica, la aceleración teórica siempre está limitada por la parte que no se puede paralelizar e incluso si p es relativamente alta (0,95) el límite teórico es bastante bajo:

( Este archivo está licenciado bajo la licencia Creative Commons Reconocimiento-Compartir Igual 3.0 Unported.
Atribución: Daniels220 de Wikipedia en inglés )

Efectivamente, esto establece un límite teórico de lo rápido que puede llegar. Puede esperar que p sea ​​relativamente alto en caso de trabajos embarazosamente paralelos, pero no soñaría con nada cercano a 0.95 o superior. Esto es porque

Spark es una abstracción de alto costo

Spark está diseñado para trabajar en hardware básico a escala de centro de datos. Su diseño central se centra en hacer que todo un sistema sea robusto e inmune a fallas de hardware. Es una gran característica cuando trabaja con cientos de nodos y ejecuta trabajos de larga ejecución, pero no se reduce muy bien.

Spark no está enfocado en computación paralela

En la práctica, Spark y sistemas similares se centran en dos problemas:

• Reducir la latencia general de E / S mediante la distribución de operaciones de E / S entre múltiples nodos.
• Cantidad creciente de memoria disponible sin aumentar el costo por unidad.

que son problemas fundamentales para los sistemas a gran escala que requieren muchos datos.

El procesamiento paralelo es más un efecto secundario de la solución particular que el objetivo principal. Spark se distribuye primero, paralelo segundo. El punto principal es mantener constante el tiempo de procesamiento con una cantidad creciente de datos escalando, sin acelerar los cálculos existentes.

Con los coprocesadores y GPGPU modernos, puede lograr un paralelismo mucho mayor en una sola máquina que un clúster Spark típico, pero no necesariamente ayuda en trabajos intensivos en datos debido a las limitaciones de memoria y E / S. El problema es cómo cargar datos lo suficientemente rápido, no cómo procesarlos.

Implicaciones prácticas

• Spark no es un reemplazo para multiprocesamiento o multihilo en una sola máquina.
• Es poco probable que el aumento del paralelismo en una sola máquina traiga mejoras y generalmente disminuirá el rendimiento debido a la sobrecarga de los componentes.

En este contexto :

Suponiendo que la clase y el jar son significativos y de hecho es un tipo, es más barato leer datos (una sola partición, una sola partición) y ordenar en la memoria en una sola partición que ejecutar toda una maquinaria de clasificación de Spark con archivos y datos aleatorios intercambiar.