Requisitos de hardware de Spark

Requisitos de hardware de Spark

Se estima que todos los desarrolladores de Spark están muy preocupados por los requisitos de hardware de Spark. La configuración adecuada del hardware requiere un análisis específico de situaciones específicas. Aquí se dan las siguientes sugerencias. Traducido principalmente del sitio web oficial

1. Sistema de almacenamiento

Debido a que la mayoría de los trabajos de Spark pueden necesitar leer datos de entrada de un sistema de almacenamiento externo (como el sistema de archivos Hadoop o HBase), Spark Es importante implementar lo más cerca posible del sistema de almacenamiento. Por lo tanto, aquí están las siguientes sugerencias:

1. Si es posible, ejecute Spark en el mismo nodo que HDFS. La forma más sencilla es instalar el clúster independiente de Spark y el clúster de Hadoop en el mismo nodo y configurar el uso de memoria de Spark y Hadoop al mismo tiempo para evitar interferencias mutuas (para Hadoop, el parámetro de configuración de memoria de cada tarea es mapred.child. java opts; mapreduce.tasktracker.map.tasks.maximum y mapreduce.tasktracker.reduce.tasks.maximum determinan el número de tareas). También puedes ejecutar hadoop y spark en el mismo administrador de clústeres, como mesos e hilo.

2. Si esto no es posible, ejecute Spark en un nodo diferente en la misma LAN que HDFS.

3. Para el almacenamiento de datos de baja latencia (como HBase), puede ser preferible ejecutar tareas informáticas en diferentes nodos del sistema de almacenamiento para evitar interferencias.

2. Disco local

Aunque Spark puede realizar una gran cantidad de cálculos en la memoria, todavía usa el disco local para almacenar datos que no caben en la RAM, así como entre etapas. Es decir, el resultado intermedio de la reproducción aleatoria. Se recomienda que cada nodo tenga al menos de 4 a 8 discos y no se requiere RAID, solo discos independientes colgados en los nodos. En Linux, monte el disco con la opción noatime para reducir escrituras innecesarias. En una tarea Spark, spark.local.dir se puede configurar con más de diez directorios de disco, separados por comas. Si se ejecuta en HDFS, ser coherente con HDFS está bien.

Montar el disco usando la opción noatime requiere que al montar el sistema de archivos, se pueda especificar la opción de instalación estándar de Linux (noatime), que deshabilitará las actualizaciones atime en el sistema de archivos. Comando de montaje del disco:

mount -t gfs BlockDevice MountPoint -onoatime

BlockDevice especifica el dispositivo de bloque donde reside el sistema de archivos GFS.

MountPoint especifica el directorio donde se debe instalar el sistema de archivos GFS.

Ejemplo:

mount -t gfs /dev/vg01/lvol0 /gfs1 -onoatime

3. Memoria

Spark de una sola máquina Puede funcionar bien con memorias que van desde 8 GB hasta cientos de GB. En todos los casos, se recomienda asignar hasta el 75 % de la memoria únicamente a Spark; dejar el resto para el sistema operativo y la memoria caché del búfer.

La cantidad de memoria necesaria depende de su aplicación. Para determinar cuánta memoria requiere el conjunto de datos específico de su aplicación, cargue una parte del conjunto de datos en la memoria y vea su huella de memoria en la interfaz de Almacenamiento de la interfaz de usuario de Spark.

Tenga en cuenta que el uso de la memoria se ve muy afectado por el nivel de almacenamiento y el formato de serialización; consulte el artículo de ajuste independiente para obtener consejos sobre cómo reducir el uso de la memoria.

Por último, tenga en cuenta que JAVA VM no siempre funciona bien en máquinas con más de 200 GB de memoria. Si compra una máquina con más de 200 GB de memoria, puede ejecutar varios trabajadores en un nodo. En el modo Spark Standalone, puede establecer el valor de SPARK_WORKER_INSTANCES en el archivo de configuración conf/spark-env.sh para establecer la cantidad de trabajadores de un solo nodo. También puede configurar el parámetro SPARK_WORKER_CORES para establecer la cantidad de CPU para cada trabajador.

4. Red

Según experiencias pasadas, si los datos están en la memoria, el cuello de botella de las aplicaciones Spark suele ser la red. Usar una red de 10 Gigabit o superior es la mejor manera de ejecutar aplicaciones Spark lo más rápido posible. Especialmente para aplicaciones de "reducción distribuida", como group-bys, reduce-bys y uniones sql, el rendimiento es aún más obvio. En cualquier aplicación determinada, puede ver cuántos datos ha transferido el proceso aleatorio de Spark a través de la red a través de la interfaz de usuario de Spark.

5. CPU

Para máquinas con docenas de CPU por máquina, Spark también puede escalar muy bien porque realiza un intercambio mínimo de CPU entre subprocesos. Cada máquina debe configurarse con al menos entre 8 y 16 núcleos. Dependiendo de la carga de la CPU, es posible que se necesite más CPU: una vez que los datos están en la memoria, el cuello de botella para la mayoría de las aplicaciones es la CPU y la red.

Lectura recomendada:

Conceptos básicos de la entrevista | Ajuste general de alto nivel de Spark

Encuesta de ejecución adaptativa de Spark

Configuración del hardware de Spark

Desde el surgimiento de MapReduce, ha surgido una idea: utilizar una gran cantidad de máquinas baratas para procesar datos masivos que antes requerían recursos costosos. Este enfoque es en realidad un modelo de arquitectura a escala horizontal, que realmente gana por volumen. Después de todo, a juzgar por el desarrollo actual del hardware, la cantidad de núcleos de CPU, la capacidad de memoria y los discos duros de almacenamiento masivo se están volviendo poco a poco más baratos y eficientes. Sin embargo, cuando se trata de extracción o análisis masivo de datos para aplicaciones comerciales, los costos del hardware siguen siendo una gran preocupación para los desarrolladores. Por supuesto, el mejor resultado es: el caballo puede correr más rápido y comer menos hierba.

\\

Spark se ejecuta mucho más rápido que MapReduce de Hadoop. Sin embargo, ¿el modelo informático en memoria de Spark tiene requisitos más altos en cuanto al consumo de recursos de hardware, especialmente recursos de memoria? No puedo encontrar tantas máquinas, ni puedo alquilar varias instancias virtuales. Si no puedo evaluarlo, solo necesito buscar el sitio web oficial de Spark o buscar en Google. Encontré algunos datos de respaldo sobre la configuración del hardware de Spark en el sitio web oficial de Spark, el discurso de Patrick Wendell de Databricks Company y el artículo de Spark de Matei Zaharia.

\\

Spark y el sistema de almacenamiento

\\

Si Spark usa HDFS como sistema de almacenamiento, Spark se puede usar de manera efectiva El clúster en modo independiente permite implementar Spark y HDFS en la misma máquina. Este modo es muy sencillo de implementar y proporciona un mayor rendimiento para leer archivos. Por supuesto, Spark tiene requisitos de uso de memoria y sus recursos con HDFS deben asignarse de manera razonable. Por lo tanto, es necesario configurar las variables de entorno de Spark y HDFS para asignar memoria y recursos de CPU a sus respectivas tareas para evitar la competencia de recursos entre sí.

\\

Si la máquina HDFS es lo suficientemente buena, se puede dar prioridad a este tipo de implementación. Si la eficiencia de ejecución del procesamiento de datos es muy alta, aún es necesario adoptar un modo de implementación separado, como la implementación en un clúster Hadoop YARN.

\\

Requisitos de disco de Spark

\\

Spark es una plataforma informática iterativa en memoria, por lo que es adecuada para The Los requisitos de disco no son altos. Spark recomienda oficialmente configurar de 4 a 8 discos para cada nodo y no es necesario configurarlo como RAID (es decir, el disco se usa como un punto de montaje separado). Luego, especifique la lista de discos configurando spark.local.dir.

\\

Requisitos de memoria de Spark

\\

Aunque Spark es una plataforma informática en memoria, según la información oficial Look , parece que los requisitos de memoria no son especialmente exigentes. El sitio web oficial solo requiere que la memoria sea superior a 8 GB (Impala requiere que la configuración de la máquina sea de 128 GB). Por supuesto, para un procesamiento eficiente, cuanto mayor sea la memoria, mejor. Si la memoria supera los 200 GB, debe tener cuidado porque la JVM tiene problemas para administrar la memoria que supera los 200 GB y requiere una configuración especial.

\\

Si la capacidad de memoria es lo suficientemente grande, se debe asignar a Spark. Spark recomienda que al menos el 75% del espacio de memoria se asigne a Spark y el espacio de memoria restante se asigne al sistema operativo y al caché del búfer. Esto requiere que la máquina donde se implementa Spark esté lo suficientemente limpia.

\\

Teniendo en cuenta el problema del consumo de memoria, si los datos que queremos procesar solo se procesan una vez y se descartan después de su uso, debemos evitar el uso de caché o persistir, reduciendo así la memoria. consumo de pérdidas. Si realmente necesita cargar datos en la memoria, pero la memoria no es suficiente, puede configurar el Nivel de almacenamiento. La versión 0.9 de Spark proporciona tres niveles de almacenamiento: MEMORY_ONLY (este es el valor predeterminado), MEMORY_AND_DISK y DISK_ONLY.

\\

Con respecto a la persistencia de datos, Spark persiste en la memoria de forma predeterminada. Pero también proporciona tres métodos de almacenamiento para RDD persistente:

\\

\\t

almacenamiento en memoria como objetos Java deserializados

\\t\\t

\\t

almacenamiento en memoria como datos serializados

\\t\\t

\\t

almacenamiento en disco

\\t\

El primer método de almacenamiento tiene el mejor rendimiento y el segundo método Se proporcionan extensiones para el método de presentación RDD (Representante), y el tercer método se utiliza cuando la memoria es insuficiente.

\\

Sin embargo, en la última versión de Spark (V1.0.2), se proporcionan más opciones de nivel de almacenamiento. Una opción que vale la pena destacar es OFF_HEAP, que almacena RDD en formato serializado en Tachyon. En comparación con MEMORY_ONLY_SER, esta opción puede reducir la ejecución de la recolección de basura, hacer que el ejecutor de Spark sea más pequeño y puede compartir completamente el grupo de memoria. Tachyon es un sistema de archivos distribuido basado en memoria cuyo rendimiento supera con creces a HDFS. Tachyon y Spark tienen el mismo origen y ambos llevan la marca de Berkeley AMPLab.

Actualmente, la versión de Tachyon es 0.5.0, la cual aún se encuentra en etapa experimental.

\\

Tenga en cuenta que los RDD son vagos al realizar operaciones de transformación como mapa y filtro, el trabajo no se enviará solo cuando se realicen operaciones de acción como recuento y primero. Sólo entonces se ejecutará el Trabajo y sólo entonces se cargarán los datos. Por supuesto, para algunas operaciones aleatorias, como reduceByKey, aunque es solo una operación de transformación, algunos datos intermedios persistirán durante la ejecución sin llamar explícitamente a la función persist(). Esto es para evitar volver a calcular grandes cantidades de datos cuando falla un nodo. Para calcular el tamaño del conjunto de datos cargado por Spark, puede utilizar la herramienta de monitoreo de la interfaz de usuario web proporcionada por Spark para ayudar a analizar y juzgar.

\\

El RDD de Spark tiene particiones y Spark no carga todo el RDD en la memoria a la vez. Spark proporciona una política de desalojo

para la partición. Esta política adopta el mecanismo LRU (menos utilizado recientemente). Cuando es necesario calcular una nueva partición RDD, si no hay espacio adecuado para el almacenamiento, la partición RDD a la que se accede al menos se expulsará de acuerdo con la política LRU, a menos que la nueva partición y la partición a la que se acceda menos pertenezcan al mismo RDD. Esto también facilita hasta cierto punto el consumo de memoria.

\\

El consumo de memoria de Spark se divide principalmente en tres partes:

\\

1. \\t

El tamaño de los objetos en el conjunto de datos;

\\t\\t

2. \\t

El consumo de memoria de acceder a estos objetos

\\t\\t

3. \\t

Recolección de basura Consumo de GC.

\\t\

Un método común de cálculo del consumo de memoria es: tamaño del consumo de memoria = datos nativos en el campo del objeto * (2~5). Esto se debe a que Spark se ejecuta en la JVM y los objetos Java que opera tienen "encabezados de objeto" definidos, y los propios objetos de estructura de datos (como Map, LinkedList) también necesitan ocupar espacio de memoria. Además, se requiere boxeo para los tipos básicos almacenados en estructuras de datos. Spark también proporciona algunos mecanismos de ajuste de memoria, como la serialización de objetos de ejecución, que pueden liberar parte del espacio de memoria. También puede marcar la cantidad de bytes almacenados configurando un indicador para la JVM (elija 4 bytes en lugar de 8 bytes). Bajo JDK 7, se pueden realizar más optimizaciones, como la configuración de codificación de caracteres. Estas configuraciones se pueden establecer en spark-env.sh.

\\

Requisitos de red de Spark

\\

Spark es un sistema vinculado a la red, por lo que se recomienda utilizar 10G y por encima del ancho de banda de la red.

\\

Requisitos de CPU de Spark

\\

Spark puede admitir una máquina para expandirse a docenas de CPU

core, que implementa un intercambio mínimo entre subprocesos. Si la memoria es lo suficientemente grande, el ancho de banda de la red y la cantidad de CPU limitarán el rendimiento informático.

\\

Los funcionarios de Spark realizaron una evaluación comparativa de Spark utilizando el entorno Amazon EC2.

Por ejemplo, para realizar minería de datos en modo interactivo (Interactive Data Mining), alquile 100 instancias de Amazon EC2, configuradas con 8 núcleos y 68 GB de memoria. Realizar extracción de datos en 1 TB de registros de revisión de páginas de Wikipedia (dos años de datos de Wikipedia). Al realizar una consulta, un escaneo completo de todos los datos de entrada solo toma entre 5 y 7 segundos. Como se muestra en la siguiente figura:

Algunos casos reales de uso de Spark también se dan en el artículo Spark de Matei Zaharia. La empresa de procesamiento de vídeo Conviva utiliza Spark para cargar subconjuntos de datos en RDD. El informe indica que las operaciones de consulta y agregación se realizaron en 200 GB de datos comprimidos y se ejecutaron en dos máquinas Spark, ocupando 96 GB de memoria. Se tardaron unos 30 minutos en realizar todas las operaciones. Año tras año, Hadoop tarda 20 horas. Nota: La razón por la que 200 GB de datos comprimidos solo ocupan 96 GB de memoria es porque la forma en que se procesa el RDD nos permite cargar solo las filas y columnas que coinciden con el filtro del cliente, en lugar de todos los datos comprimidos. `

Recomendaciones de configuración de hardware del clúster Spark

Computación y almacenamiento:

La mayoría de los trabajos de Spark pueden requerir datos de un sistema de almacenamiento externo (por ejemplo: Cassandra, archivo Hadoop system o HBase) lee los datos de entrada, por lo que el motor informático Spark debe colocarse lo más cerca posible de la capa de persistencia de datos. Si utiliza HDFS como clúster de almacenamiento de datos, puede implementar un clúster Spark en el mismo clúster y configurar el uso de memoria y CPU de Spark y Hadoop para evitar interferencias. Nuestro almacenamiento de producción utiliza un clúster de Cassandra. El servicio maestro Spark

se implementa por separado y otros nodos se implementan al mismo tiempo: Cassandra

Spark Worker, lo que garantiza Spark

nodos trabajadores Los datos se pueden leer rápidamente localmente para realizar cálculos y resúmenes.

Disco:

Aunque Spark puede realizar una gran cantidad de cálculos en la memoria, aún puede usar el disco local para almacenar datos que no son adecuados para la RAM. Se recomienda configurar 4. por nodo -8 discos, no es necesario configurar RAID (matriz de discos), los costos de los discos son cada vez más bajos, puede considerar configurar un disco duro SSD, lo que puede mejorar enormemente el rendimiento. Además, en Linux, utilice la opción noatime para montar el disco y reducir operaciones de escritura innecesarias. En Spark, puede configurar la variable spark.local.dir para las direcciones de varios discos locales, separados por comas.

Memoria

Se recomienda que la capacidad de memoria asignada a Spark no sea superior al 75% de la capacidad de memoria total de la máquina; asegúrese de dejar suficiente memoria para el sistema operativo; y amortiguadores. Evalúe cuánta memoria se necesita en función de las características comerciales. Tenga en cuenta que el rendimiento de la máquina virtual Java será inestable cuando la capacidad de la memoria supere los 200 GB. Si compra más de 200 GB de RAM, puede ejecutar varias JVM de trabajo por nodo. En el modo independiente de Spark, puede establecer la cantidad de procesos de trabajo que se ejecutan en cada nodo a través de la variable SPARK_WORKER_INSTANCES en conf/spark-env.sh, y la cantidad de núcleos de CPU disponibles para cada trabajador a través de la variable SPARK_WORKER_CORES.

Red

Cuando los datos ya están almacenados en la memoria, el cuello de botella en el rendimiento de muchas aplicaciones Spark es la velocidad de transmisión de la red. Se recomienda utilizar una red mínima de 10G.

CPU

Spark ejecuta muchas tareas de cálculo resumidas. Se recomienda configurar más núcleos de CPU. La mejora del rendimiento aún es obvia. Se recomienda configurar cada máquina con. menos 8-16 núcleos.

Se pueden realizar ajustes de configuración en función de la carga de CPU del trabajo Spark. Una vez que los datos ya están en la memoria, el cuello de botella en el rendimiento para la mayoría de las aplicaciones reside en la CPU y la red.

Documentación de referencia

http://spark.apache.org/docs/latest/hardware-provisioning.html