El tiempo de ejecución de Amazon EMR para Apache Spark es un tiempo de ejecución de rendimiento optimizado para Apache Spark que es 100 % appropriate con API con Apache Spark de código abierto. Con EMR de Amazon versión 6.9.0, el tiempo de ejecución de EMR para Apache Spark admite la versión equivalente de Spark 3.3.0.
Con Amazon EMR 6.9.0, ahora puede ejecutar sus aplicaciones Apache Spark 3.x más rápido y a menor costo sin necesidad de realizar ningún cambio en sus aplicaciones. En nuestras pruebas comparativas de rendimiento, derivadas de las pruebas de rendimiento de TPC-DS a una escala de 3 TB, encontramos que el tiempo de ejecución de EMR para Apache Spark 3.3.0 proporciona una mejora del rendimiento de 3,5 veces (usando el tiempo de ejecución whole) en promedio sobre Apache Spark 3.3 de código abierto. 0.
En esta publicación, analizamos los resultados de nuestras pruebas comparativas que ejecutan una aplicación TPC-DS en Apache Spark de código abierto y luego en Amazon EMR 6.9, que viene con un tiempo de ejecución de Spark optimizado que es appropriate con Spark de código abierto. Realizamos un análisis de costos detallado y finalmente proporcionamos instrucciones paso a paso para ejecutar el punto de referencia.
Resultados observados
Para evaluar las mejoras de rendimiento, utilizamos una utilidad de prueba de rendimiento Spark de código abierto que se deriva del equipment de herramientas de prueba de rendimiento TPC-DS. Ejecutamos las pruebas en un clúster de EMR c5d.9xlarge de siete nodos (seis nodos centrales y un nodo principal) con el tiempo de ejecución de EMR para Apache Spark, y un segundo clúster autogestionado de siete nodos en Nube informática elástica de Amazon (Amazon EC2) con la versión equivalente de código abierto de Spark. Ejecutamos ambas pruebas con datos en Servicio de almacenamiento easy de Amazon (Amazon S3).
La asignación dinámica de recursos (DRA) es una característica excelente para usar con diferentes cargas de trabajo. Sin embargo, para un ejercicio de evaluación comparativa en el que comparamos dos plataformas únicamente en función del rendimiento y los volúmenes de datos de prueba no cambian (3 TB en nuestro caso), creemos que es mejor evitar la variabilidad para realizar una comparación de manzanas con manzanas. En nuestras pruebas tanto en Spark de código abierto como en Amazon EMR, deshabilitamos DRA mientras ejecutamos la aplicación de evaluación comparativa.
La siguiente tabla muestra el tiempo de ejecución whole del trabajo para todas las consultas (en segundos) en el conjunto de datos de consulta de 3 TB entre Amazon EMR versión 6.9.0 y Spark de código abierto versión 3.3.0. Observamos que nuestras pruebas de TPC-DS tenían un tiempo de ejecución whole del trabajo en Amazon EMR en Amazon EC2 que period 3,5 veces más rápido que el que usaba un clúster Spark de código abierto con la misma configuración.
La aceleración por consulta en Amazon EMR 6.9 con y sin el tiempo de ejecución de EMR para Apache Spark se ilustra en el siguiente gráfico. El eje horizontal muestra cada consulta en el banco de pruebas de 3 TB. El eje vertical muestra la aceleración de cada consulta debido al tiempo de ejecución de EMR. Las mejoras de rendimiento notables son más de 10 veces más rápidas para las consultas TPC-DS 24b, 72, 95 y 96.
Análisis de costos
Las mejoras de rendimiento del tiempo de ejecución de EMR para Apache Spark se traducen directamente en menores costos. Pudimos obtener un ahorro de costos del 67 % al ejecutar la aplicación de referencia en Amazon EMR en comparación con el costo incurrido para ejecutar la misma aplicación en Spark de código abierto en Amazon EC2 con el mismo tamaño de clúster debido a la reducción de horas de Amazon EMR y Amazon. Uso de EC2. El precio de Amazon EMR es para aplicaciones de EMR que se ejecutan en clústeres de EMR con instancias EC2. El precio de Amazon EMR se agrega a los precios de procesamiento y almacenamiento subyacentes, como el precio de la instancia EC2 y Tienda de bloques elásticos de Amazon (Amazon EBS) costo (si se adjuntan volúmenes de EBS). En common, el costo de referencia estimado en la región EE. UU. Este (Norte de Virginia) es de $27,01 por ejecución para Spark de código abierto en Amazon EC2 y de $8,82 por ejecución para Amazon EMR.
| trabajo de referencia | Tiempo de ejecución (hora) | Costo estimado | Instancia EC2 whole | CPU virtuales totales | Memoria whole (GiB) | Dispositivo raíz (Amazon EBS) |
|
Spark de código abierto en Amazon EC2 (1 nodo principal y 6 principales) |
2.23 | $27.01 | 7 | 252 | 504 | 20 GiB gp2 |
|
Amazon EMR en Amazon EC2 (1 nodo principal y 6 principales) |
0,63 | $8.82 | 7 | 252 | 504 | 20 GiB gp2 |
Desglose de los costos
El siguiente es el desglose de costos del trabajo de código abierto Spark en Amazon EC2 ($27,01):
- Costo whole de Amazon EC2 – (7 * $ 1,728 * 2,23) = (número de instancias * c5d.9x tarifa por hora grande * tiempo de ejecución del trabajo en horas) = $ 26,97
- Costo de Amazon EBS – ($0.1/730 * 20 * 7 * 2.23) = (Amazon EBS por GB-tarifa por hora * tamaño de EBS raíz * número de instancias * tiempo de ejecución del trabajo en horas) = $0.042
El siguiente es el desglose de costos del trabajo de Amazon EMR en Amazon EC2 ($8,82):
- Costo whole de Amazon EMR – (7 * 0,27 USD * 0,63) = ((número de nodos principales + número de nodos principales)* c5d.9xlarge Precio de Amazon EMR * tiempo de ejecución del trabajo en horas) = 1,19 USD
- Costo whole de Amazon EC2 – (7 * $1,728 * 0,63) = ((número de nodos principales + número de nodos principales)* c5d.9xprecio de instancia grande * tiempo de ejecución del trabajo en horas) = $7,62
- Costo de Amazon EBS – ($0,1/730 * 20 GiB * 7 * 0,63) = (tarifa por hora de Amazon EBS por GB * tamaño de EBS * número de instancias * tiempo de ejecución del trabajo en horas) = $0,012
Configurar la evaluación comparativa de OSS Spark
En las siguientes secciones, proporcionamos un breve resumen de los pasos involucrados en la configuración de la evaluación comparativa. Para obtener instrucciones detalladas con ejemplos, consulte el repositorio de GitHub.
Para nuestra evaluación comparativa de OSS Spark, utilizamos la herramienta de código abierto pedernal para lanzar nuestro Amazon EC2 basado chispa apache grupo. Flintrock proporciona una forma rápida de lanzar un clúster de Apache Spark en Amazon EC2 mediante la línea de comandos.
requisitos previos
Full los siguientes pasos de requisitos previos:
- Tener Python 3.7.x o superior.
- Tener Pip3 22.2.2 o superior.
- Agregue el directorio bin de Python a la ruta de su entorno. El binario Flintrock se instalará en esta ruta.
- Correr
aws configurepara configurar tu Interfaz de línea de comandos de AWS (AWS CLI) shell para apuntar a la cuenta de evaluación comparativa. Referirse a Configuración rápida con aws configure para instrucciones. - Tener un Par de claves con permisos de archivo restrictivos para acceder al nodo principal de OSS Spark.
- Cree un nuevo depósito S3 en su cuenta de prueba si es necesario.
- Copie los datos de origen de TPC-DS como entrada a su depósito S3.
- Cree la aplicación de referencia siguiendo los pasos proporcionados en Pasos para crear una aplicación de ensamblaje de referencia de chispa. Alternativamente, puede descargar un preconstruido chispa-benchmark-ensamblaje-3.3.0.jar si desea una aplicación basada en Spark 3.3.0.
Implemente el clúster de Spark y ejecute el trabajo de referencia
Full los siguientes pasos:
- Instale la herramienta Flintrock a través de pip como se muestra en Pasos para configurar OSS Spark Benchmarking.
- Ejecute el comando flintrock configure, que muestra un archivo de configuración predeterminado.
- Modificar el valor predeterminado
config.yamlarchivo basado en sus necesidades. Alternativamente, copie y pegue el archivo config.yaml contenido al archivo de configuración predeterminado. Luego guarde el archivo donde estaba. - Finalmente, lance el clúster Spark de 7 nodos en Amazon EC2 a través de Flintrock.
Esto debería crear un clúster de Spark con un nodo principal y seis nodos de trabajo. Si ve algún mensaje de error, vuelva a verificar los valores del archivo de configuración, especialmente las versiones de Spark y Hadoop y los atributos de la fuente de descarga y la AMI.
El clúster de OSS Spark no incluye el administrador de recursos de YARN. Para habilitarlo, necesitamos configurar el clúster.
- Descargar el hilo-sitio.xml y enable-yarn.sh archivos del repositorio de GitHub.
- Reemplace
con la dirección IP del nodo principal en su clúster de Flintrock.
Puede recuperar la dirección IP desde la consola de Amazon EC2.
- Cargue los archivos en todos los nodos del clúster de Spark.
- Ejecute el script enable-yarn.
- Habilite la compatibilidad con Snappy en Hadoop (el trabajo de referencia lee los datos comprimidos de Snappy).
- Descargue el archivo JAR de la aplicación de utilidad de referencia chispa-benchmark-ensamblaje-3.3.0.jar a su máquina native.
- Copie este archivo en el clúster.
- Inicie sesión en el nodo principal e inicie YARN.
- Envíe el trabajo de referencia en el clúster de Spark de código abierto como se muestra en Enviar el trabajo de referencia.
Resumir los resultados
Descargue el archivo de resultados de la prueba del depósito S3 de salida s3://$YOUR_S3_BUCKET/EC2_TPCDS-TEST-3T-RESULT/timestamp=xxxx/abstract.csv/xxx.csv. (Reemplazar $YOUR_S3_BUCKET con el nombre de su depósito de S3). Puede usar la consola de Amazon S3 y navegar a la ubicación de salida de S3 o usar la CLI de AWS.
La aplicación de referencia Spark crea una carpeta de marca de tiempo y escribe un archivo de resumen dentro de un prefijo abstract.csv. Su marca de tiempo y nombre de archivo serán diferentes a los que se muestran en el ejemplo anterior.
Los archivos CSV de salida tienen cuatro columnas sin nombres de encabezado. Son:
- Nombre de la consulta
- tiempo medio
- tiempo minimo
- Tiempo máximo
La siguiente captura de pantalla muestra una salida de muestra. Hemos agregado nombres de columna manualmente. La forma en que calculamos la media geográfica y el tiempo whole de ejecución del trabajo se basa en medias aritméticas. Primero tomamos la media de los valores med, min y max usando la fórmula PROMEDIO (B2: D2). Luego tomamos una media geométrica de la columna Promedio usando la fórmula MEDIAGEOM(E2:E105).
Configurar la evaluación comparativa de Amazon EMR
Para obtener instrucciones detalladas, consulte Pasos para configurar EMR Benchmarking.
requisitos previos
Full los siguientes pasos de requisitos previos:
- Correr
aws configurepara configurar su shell de AWS CLI para que apunte a la cuenta de evaluación comparativa. Referirse a Configuración rápida con aws configure para instrucciones. - Cargue la aplicación de referencia en Amazon S3.
Implemente el clúster de EMR y ejecute el trabajo de referencia
Full los siguientes pasos:
- Inicie Amazon EMR en su shell de AWS CLI usando la línea de comando como se muestra en Implemente el clúster de EMR y ejecute el trabajo de referencia.
- Configure Amazon EMR con un nodo principal (c5d.9xlarge) y seis núcleos (c5d.9xlarge). Referirse a crear-cluster para obtener una descripción detallada de las opciones de la CLI de AWS.
- Almacene el ID de clúster de la respuesta. Necesitas esto en el siguiente paso.
- Envíe el trabajo de referencia en Amazon EMR utilizando pasos adicionales en la CLI de AWS.
Resumir los resultados
Resumir los resultados del cubo de salida s3://$YOUR_S3_BUCKET/weblog/EMRONEC2_TPCDS-TEST-3T-RESULT de la misma manera que lo hicimos para los resultados de OSS y examine.
Limpiar
Para evitar incurrir en cargos futuros, elimine los recursos que creó siguiendo las instrucciones en el Sección de limpieza del repositorio de GitHub.
- Detenga los clústeres de EMR y OSS Spark. También puede eliminarlos si no desea conservar el contenido. Puede eliminar estos recursos ejecutando el script cleanup-benchmark-env.sh desde una terminal en su entorno de referencia.
- si usaste Nube de AWS9 como su IDE para construir el archivo JAR de la aplicación de referencia utilizando Pasos para crear una aplicación de ensamblaje de referencia de chispaes posible que también desee eliminar el entorno.
Conclusión
Puede ejecutar sus cargas de trabajo de Apache Spark 3,5 veces (según el tiempo de ejecución whole) más rápido y a menor costo sin realizar ningún cambio en sus aplicaciones mediante el uso de Amazon EMR 6.9.0.
Para mantenerse actualizado, suscríbase al Huge Knowledge Weblog’s RSS Feed para obtener más información sobre el tiempo de ejecución de EMR para Apache Spark, las mejores prácticas de configuración y los consejos de ajuste.
Para pruebas comparativas anteriores, consulte Ejecute cargas de trabajo de Apache Spark 3.0 1,7 veces más rápido con el tiempo de ejecución de Amazon EMR para Apache Spark. Tenga en cuenta que el resultado de referencia anterior de 1,7 veces el rendimiento se basó en la media geométrica. Según la media geométrica, el rendimiento en Amazon EMR 6.9 fue dos veces más rápido.
Sobre los autores
Sekar Srinivasan es un Arquitecto de Soluciones Especialista Sr. en AWS centrado en Huge Knowledge y Analytics. Sekar tiene más de 20 años de experiencia trabajando con datos. Le apasiona ayudar a los clientes a crear soluciones escalables que modernicen su arquitectura y generen información a partir de sus datos. En su tiempo libre le gusta trabajar en proyectos sin fines de lucro, especialmente aquellos enfocados en la educación de niños desfavorecidos.
Prabu Ravichandran es Arquitecto de datos sénior en Amazon Internet Companies, centrado en análisis, arquitectura e implementación de lagos de datos. Ayuda a los clientes a diseñar y crear soluciones sólidas y escalables mediante los servicios de AWS. En su tiempo libre, a Prabu le gusta viajar y pasar tiempo con su familia.
