Spark: número de rendimiento incoherente en el número de núcleos de escala

Estoy haciendo una prueba de escalado simple en Spark utilizando un punto de referencia de clasificación: de 1 núcleo, hasta 8 núcleos. Noté que 8 núcleos son más lentos 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.

Limitaciones teóricas

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

enter image description here

dónde

  • s – es la aceleración de la parte paralela.
  • p – es la fracción del progtwig 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:

enter image description here

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

Efectivamente, esto establece un límite teórico de la rapidez con la que puede obtener. Puedes esperar que p sea ​​relativamente alto en caso de trabajos vergonzosamente 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 funcionar en hardware básico en la escala del centro de datos. Su diseño central se centra en hacer que un sistema completo sea robusto e inmune a fallas de hardware. Es una gran característica cuando se trabaja con cientos de nodos y se ejecutan trabajos de larga ejecución, pero no se escala 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 total de IO mediante la distribución de operaciones de IO entre nodos múltiples.
  • Aumento de la cantidad de memoria disponible sin boost el costo por unidad.

que son problemas fundamentales para sistemas intensivos de datos a gran escala.

El parallel processing es más un efecto secundario de la solución particular que el objective principal. Spark se distribuye primero, segundo paralelo. El punto principal es mantener el tiempo de procesamiento constante a medida que aumenta la cantidad de datos al escalar, sin acelerar los cálculos existentes.

Con coprocesadores modernos y GPGPU 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 de datos debido a IO y limitaciones de memoria. 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 mulithreading en una sola máquina.
  • Es poco probable que el aumento del paralelismo en una sola máquina produzca mejoras y, en general, reducirá el rendimiento debido a la sobrecarga de los componentes.

En este contexto :

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