Blog de Amazon Web Services (AWS)

Parte 2: Ejecución de un ETL basado en Spark SQL con Amazon EMR en Amazon EKS

Melody Yang, Arquitecta de Soluciones especialista de AWS,
Shiva Achari, Arquitecto Senior de laboratorio de datos de AWS,
Igor Izotov,Arquitecto de Soluciones empresariales de AWS,
Daniel Maldonado, Arquitecto de Soluciones de AWS.

 

Introducción

Cada vez más, el éxito de una empresa depende de su agilidad para transformar los datos en información procesable, lo que requiere procesos de datos eficientes y automatizados. En el blog Parte 1: Crear un ETL basado en SQL con Apache Spark en Amazon EKS, describimos un problema de productividad común en una arquitectura de datos moderna. Para abordar el desafío, explicamos y demostramos cómo utilizar el enfoque declarativo como el habilitador clave para mejorar la eficiencia, lo que resultó en un tiempo de respuesta más rápido para las empresas.

En términos generales, la administración de aplicaciones mediante declaración en Kubernetes es un procedimiento recomendado ampliamente adoptado. Hemos visto a los clientes que utilizan el mismo enfoque para crear e implementar sus aplicaciones Spark con marcos de compilación de código abierto o internos para lograr el mismo objetivo de productividad.

Como ejemplo, aprovecharemos el marco de código abierto data processing framework – Arc, abstraído de Apache Spark, para transformar una canalización de datos normal en un trabajo de «ETL como definición». Significa que todos los pasos de la canalización de datos simplemente se expresarán en un archivo de definición declarativa (JSON) con scripts SQL de lenguaje declarativo incrustados.

La definición de trabajo en Arc Jupyter Notebook tiene este aspecto:

 

 

Esta representación hace que ETL sea mucho más fácil para una gama más amplia de personas: analistas, científicos de datos y cualquier autor de SQL que pueda expresar completamente sus flujos de trabajo de datos sin la necesidad de escribir código en un lenguaje de programación como Python.

En este blog, exploraremos algunas ventajas clave de la última opción de implementación de EMR: Amazon EMR en Amazon EKS para ejecutar aplicaciones Spark, explicaremos su principal diferencia con respecto al comúnmente usado administrador de recursos de Spark – YARN y, por último, demostraremos cómo programar el trabajo de ETL declarativo anterior con Amazon EMR en EKS. Construir y probar el trabajo en un “Arc Jupyter kernel” personalizado está fuera de alcance. Puede encontrar más tutoriales en el sitio web de Arc.

 

Por qué elegir Amazon EMR en Amazon EKS

Arquitectura simplificada mediante la unificación de cargas de trabajo: EMR en EKS nos permite ejecutar cargas de trabajo de Apache Spark en Amazon Elastic Kubernetes Service (EKS) sin aprovisionar clústeres de EMR dedicados. Si tiene un entorno de EKS existente en su organización, tiene sentido unificar las cargas de trabajo analíticas con otras aplicaciones basadas en Kubernetes en el mismo clúster de Amazon EKS. Mejora la utilización de los recursos y simplifica significativamente la administración de la infraestructura.

Más recursos para compartir con una menor plantilla de JVM: Una diferencia importante en esta opción de implementación es el cambio del gestor de recursos de YARN basado en JVM a Kubernetes, de un gestor de clústers de Hadoop a un orquestador de aplicaciones en contenedores genérico. Como se muestra a continuación, cada ejecutor de Spark se ejecuta como un contenedor yarn (unidad de proceso) en Hadoop. En términos generales, YARN crea una JVM en cada contenedor solicitado por las aplicaciones de Hadoop, como Apache Hive. Mientras que cuando ejecuta Spark en Kubernetes, mantiene su plantilla de JVM mínima, de modo que el clúster de EKS pueda acomodar más aplicaciones, incluidos los trabajos de JVM y no JVM, lo que resulta en más recursos de sobra para sus cargas de trabajo analíticas.

 

 

Uso compartido eficiente de recursos que conduce a reducción de costos: Con el administrador de clústers de YARN, si desea reutilizar el mismo clúster de EMR para trabajos simultáneos de Spark a fin de reducir los costos, tendrá que poner en peligro el aislamiento de recursos. Además, tiene que pagar por los recursos de proceso que no se utilizan completamente, como el nodo principal, porque estos recursos informáticos no utilizados pueden ser aprovechados únicamente por EMR. Con EMR en EKS, puede disfrutar de la característica de asignación de recursos optimizada, al compartirlos en todas sus aplicaciones, lo que resulta en una reducción de costos.

Tiempo de ejecución de EMR más rápido para Spark: Una de las ventajas clave de ejecutar Spark con EMR en EKS es el  tiempo de ejecución de EMR más rápido para Spark. El tiempo de ejecución es un entorno optimizado para el rendimiento, que está disponible y activado de forma predeterminada en Amazon EMR versión 5.28.0 y posteriores. En nuestras pruebas de rendimiento con consultas de referencia de TPC-DS a escala de 3 TB, descubrimos que el tiempo de ejecución de EMR para Apache Spark 3.0 proporciona una mejora de rendimiento de 1.7 veces en promedio y un rendimiento mejorado de hasta 8 veces para consultas individuales a través de Apache Spark 3.0.0 de código abierto. Esto significa que puede ejecutar sus aplicaciones Apache Spark más rápido y más barato sin necesidad de realizar ningún cambio en sus aplicaciones.

Configuración cero para admitir múltiples inquilinos: Sin ninguna configuración de infraestructura, puede usar un solo clúster de EKS para ejecutar aplicaciones que requieren diferentes versiones y configuraciones de Apache Spark, al tiempo que aprovecha la asignación dinámica de recursos de Spark, el escalado automático de EKS, la alta disponibilidad con varias zonas de disponibilidad y el aislamiento de la carga de trabajo para casos de uso multiinquilino, etc.

 

Rentabilidad

Los precios de Amazon EMR on EKS se calculan en función de los vCPU’s y los recursos de memoria utilizados desde el momento en que comienza a descargar la imagen de la aplicación EMR hasta que el pod de Amazon EKS termina, redondeado al segundo más cercano. Vea el ejemplo siguiente:

 

Ejemplo: costo en la región de Virginia del Norte (us-east-1)

 

El precio de Amazon EMR anterior se suma a los precios de Amazon EKS y a cualquier otro servicio utilizado con EKS. Paga $0.10 USD por hora por cada clúster de EKS que use. Sin embargo, puede aprovechar un único clúster de Amazon EKS para ejecutar varias aplicaciones aprovechando los Kubernetes namespaces y las políticas de seguridad de IAM.

Durante el tiempo de ejecución de la aplicación, la funcionalidad de escalado automático  de EKS asigna y elimina automáticamente los recursos para eliminar el aprovisionamiento excesivo o la infrautilización de estos recursos. Le permite reducir los costos, ya que solo paga por los recursos que utiliza.

Para reducir aún más el costo de ejecución de los trabajos que no son críticos, uno de los patrones comunes es programar ejecutores de Spark en instancias de spot para ahorrar hasta un 90% más que el precio bajo demanda y ejecutar el controlador en una instancia bajo demanda confiable. Porque el controlador es responsable de solicitar nuevos ejecutores para reemplazar los fallidos cuando ocurre un evento inesperado. Si el controlador falla, todos los componentes y ejecutores vinculados se descartarán.

Kubernetes viene con una especificación YAML denominada plantilla de pod que puede usar para configurar pods. Para reducir el costo y satisfacer la necesidad de confiabilidad anterior, definimos reglas­­ ­­nodeSelector en plantillas de pod cargadas en S3, con el fin de ejecutar pods de controlador/ejecutor de Spark en un tipo específico de nodos EKS (instancias de proceso), que no es compatible con las configuraciones de Spark. Por último, en el envío del trabajo, especifique dos propiedades de Spark spark.kubernetes.driver.podTemplateFile  y  spark.kubernetes.executor.podTemplateFile  para que apunten a las plantillas de pod en S3.

 

por ejemplo:

executor_pod_template.yaml:

apiVersion: v1

kind: Pod

spec:

nodeSelector:

eks.amazonaws.com/capacityType: SPOT

 

driver_pod_template.yaml:

apiVersion: v1

kind: Pod

spec:

nodeSelector:

eks.amazonaws.com/capacityType: ON_DEMAND

Envío de trabajos de Spark:

aws emr-containers start-job-run \
--virtual-cluster-id ${EMR_EKS_CLUSTER_ID} \
--name spark-pi-pod-template \
--execution-role-arn ${EMR_EKS_ROLE_ARN} \
--release-label emr-5.33.0-latest \
--job-driver '{
    "sparkSubmitJobDriver": {
        "entryPoint": "s3://'${s3DemoBucket}'/someAppCode.py",
        "sparkSubmitParameters": "--conf spark.kubernetes.driver.podTemplateFile=\"s3://'${s3DemoBucket}'/pod_templates/driver_pod_template.yaml\" --conf spark.kubernetes.executor.podTemplateFile=\"s3://'${s3DemoBucket}'/pod_templates/executor_pod_template.yaml\" --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2"
	}
    }

 

Con las versiones 5.33.0 y posteriores de Amazon EMR, EMR en EKS admite la característica de plantilla de pod basada en S3. Si está utilizando una versión EMR no compatible, también es posible aprovechar la misma función sin soporte S3. Asegúrese de que su versión de Spark sea 3.0 o posterior y copie los archivos de plantilla en su imagen de Docker personalizada. La secuencia de comandos de envío de trabajos será cambiada por esto:

"—conf
spark.kubernetes.driver.podTemplateFile=/local/path/to/driver_pod_template.
yaml"
"—conf
spark.kubernetes.executor.podTemplateFile=/local/path/to/executor_pod_templ
ate.yaml"

 

Opciones de computación flexibles

Sin servidor: Fargate

La solución de ejemplo se ejecutará en un clúster de EKS con AWS Fargate. Fargate es un motor informático sin servidor para contenedores que se ejecutan en Amazon Elastic Kubernetes Service (EKS). Facilita el enfoque en la creación de aplicaciones, ya que elimina la necesidad de aprovisionar y administrar servidores. Fargate ejecuta cada tarea/pod en su propio kernel, proporcionando su propio entorno informático aislado. Esto permite que la aplicación tenga aislamiento de recursos y seguridad mejorada por diseño.

Con AWS Fargate, no es necesario ser un experto en operaciones de Kubernetes. Asigna automáticamente la cantidad correcta de procesos, lo que elimina la necesidad de elegir instancias y escalar la capacidad del clúster, por lo que el  escalador automático de clústers de Kubernetes ya no es necesario para ajustar el nodo del clúster de EKS.

En nuestro caso, cada ejecutor o controlador de Spark se aprovisiona mediante un pod de Fargate independiente, para formar un clúster de Spark dedicado a una canalización de ETL. Solo necesita especificar y pagar por los recursos necesarios para ejecutar la aplicación, sin más preocupaciones sobre la administración de clústeres complejos, las colas y las compensaciones de aislamiento.

Otras opciones de EC2

Además de la opción sin servidor, EMR en EKS puede funcionar en todos los tipos de clústers de EKS. Por ejemplo, grupos de nodos administrados de Amazon EKS con instancias EC2 bajo demanda y de tipo spot.

Anteriormente, mencionamos la colocación del pod de controlador de Spark en una instancia bajo demanda para reducir el riesgo de interrupción. Para mejorar aún más la estabilidad del clúster, es importante comprender las características de directiva de alta disponibilidad y reinicio de Kubernetes. Estos permiten nuevas y emocionantes posibilidades, no solo en computo multi-inquilino, sino también en la capacidad de auto-recuperación de aplicaciones, por ejemplo, relanzar Spark Driver en instancias Spot u On-Demand. Revisa el ejemplo  en nuestro blog anterior para obtener más detalles.

Cuando escribimos este blog, el resultado de nuestra prueba mostro que un controlador de Spark aún no se puede reiniciar en caso de error con el tipo de implementación de EMR en EKS. Por lo tanto, tenga en cuenta al diseñar una aplicación Spark con el tiempo de inactividad mínimo necesario, especialmente para tareas críticas. Las recomendaciones son:

Diversifique sus solicitudes de spot

Al igual que la flota de instancias de EMR, EMR en EKS le permite implementar una sola aplicación en varios tipos de instancias para mejorar aún más la disponibilidad. Aprovechando las prácticas recomendadas de spot de AWS EC2, como el reequilibrio de capacidad, puede diversificar la solicitud de spot en varios tipos de instancias dentro de cada zona de disponibilidad. Esto limita el impacto de las interrupciones de spot en la carga de trabajo si EC2 reclama una instancia de spot. Para obtener más información, consulte el blog:  Ejecución de cargas de trabajo de Spark optimizadas en costos en Kubernetes mediante instancias de spot de EC2

Aumentar la resiliencia

Reiniciar repetidamente un clúster de Spark comprometerá el rendimiento de la aplicación o la duración de los trabajos, especialmente para los procesos de datos sensibles en el tiempo. Se recomienda usar las siguientes mejores practicas para aumentar la resistencia de la aplicación:

  1. Asegúrese de que su trabajo no tiene estado para que pueda recuperarse sin esperar a una dependencia.
  2. Si se requiere un punto de control, por ejemplo, un ETL de streaming de Spark con estado, asegúrese de que el almacenamiento del punto de control está desacoplado del recurso de cómputo EKS, que se puede desasociar y adjuntar al clúster de Kubernetes a través de los persistent volume claims (PVC’s), o simplemente use S3 Cloud Storage.
  3. Ejecute el controlador spark en una instancia bajo demanda definida por una plantilla de pod. Esto agrega una capa adicional de resistencia a la aplicación Spark con EMR en EKS.

 

Seguridad

Amazon EMR en EKS hereda la característica de seguridad específica IAM roles for service accounts, IRSA en resumen, proporcionada por Amazon EKS. Esto significa que el control de acceso a datos ya no está en el nivel de instancia de proceso, sino que es tan granular como el nivel de contenedor/pod controlado por un rol de IAM. El enfoque de autenticación basada en tokens nos permite aprovechar uno de los proveedores de credenciales predeterminados de AWS  WebIdentityTokenCredentialsProvider  para intercambiar el token emitido por Kubernetes por credenciales de rol de IAM. Esto garantiza que nuestras aplicaciones implementadas con EMR en EKS puedan comunicarse con otros servicios de AWS en un canal seguro y privado, sin necesidad de almacenar el par de credenciales de AWS de larga vida como un secreto de Kubernetes.

Para obtener más información sobre los detalles de implementación, consulte el ejemplo en nuestro repositorio git aws-sample.

 

Tutorial: Ejecución de un ETL declarativo con Amazon EMR en EKS

En este ejemplo, presentamos un diseño con reconocimiento de calidad, un marco de procesamiento de datos declarativo de código abierto Arc framework  para abstraer la tecnología Spark lejos de usted. Esto hace que sea fácil para usted centrarse en los resultados empresariales, no en las tecnologías.

Le guiaremos a través de los pasos para ejecutar un trabajo de Arc ETL predefinido con el enfoque de EMR en EKS.   Para obtener más información, visite la solución en  aws-sample git repository.

Visión general

La solución de ejemplo lanzará un clúster de EKS sin servidor, cargará los registros TLC green taxi trip records desde un bucket de S3 público, aplicará el esquema del conjunto de datos, agregará los datos, y finalmente se generará en un bucket de S3 como formato de archivo Parquet. La aplicación Spark de ejemplo se define como un Jupyter Notebook  green_taxi_load.ipynb con tecnología Arc,  y la información de metadatos se define en green_taxi_schema.json.

 

Diagrama 1:ETL de Spark basado en SQL con EMR en EKS

Introducción (lanzamiento de EKS)

  1. Abra AWS CloudShell en la región us-east-1:  enlace a AWS CloudShell
  2. Ejecute el siguiente comando para aprovisionar un nuevo clúster de EKS eks-cluster,  respaldado por Fargate. A continuación, cree un clúster de EMR virtual  emr-on-eks-cluster.

curl https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/provision.sh  | bash

 

Implemente el trabajo ETL de ejemplo

  1. Después de aprox. 20 minutos cuando se realiza el aprovisionamiento, envíe el trabajo de ETL de ejemplo a EMR en EKS con un clúster virtual sin servidor denominado «emr-on-eks-cluster»:

curl https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/submit_arc_job.sh | bash

 

 

Básicamente, esto ejecuta el siguiente comando de AWS:

aws emr-containers start-job-run \
--virtual-cluster-id $EMRCLUSTERID  \
--name arc-job \
--execution-role-arn $ROLEARN \
--release-label emr-6.2.0-latest \
--job-driver '{
"sparkSubmitJobDriver": {

"entryPoint": "https://repo1.maven.org/maven2/ai/tripl/arc_2.12/3.6.2/arc_2.12-3.6.2.jar", "entryPointArguments":["--etl.config.uri=https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/green_taxi_load.ipynb "], 

"sparkSubmitParameters": "--packages com.typesafe:config:1.4.0 --class ai.tripl.arc.ARC --conf spark.executor.instances=10 --conf spark.executor.memory=4G --conf spark.driver.memory=2G --conf spark.executor.cores=2 –conf spark.kubernetes.driverEnv.ETL_CONF_ENV=test --conf spark.kubernetes.driverEnv.OUTPUT=s3://'$OUTPUTS3BUCKET'/output/ --conf spark.kubernetes.driverEnv.SCHEMA=https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/green_taxi_schema.json "}}' \

--configuration-overrides '{
 "monitoringConfiguration": {"cloudWatchMonitoringConfiguration": {"logGroupName": "/aws/eks/'$EKSCLUSTERNAME'/jobs", "logStreamNamePrefix": "arc-job"}
 }
}'
  1. Ejecute estos comandos para comprobar el progreso y el estado de escalado automático:

kubectl get pod -n emr
kubectl get node --label-columns=topology.kubernetes.io/zone

  1. Como solicitó 10 ejecutores por el trabajo, automáticamente escala el clúster Spark de 0 a 10 pods / ejecutores en el clúster EKS. El clúster de Spark finalizará automáticamente una vez que se complete el trabajo.

 

 

  1. Vaya a la consola de EMR para ver el estado del trabajo en Spark History Server:

 

 

5. O revise los logs en AWS Cloudshell, tan pronto como el Spark Driver este corriendo:

driver_name=$(kubectl get pod -n emr | grep "driver" | awk '{print $1}')

kubectl logs ${driver_name} -n emr -c spark-kubernetes-driver | grep 'event'

Limpiar los recursos

Para limpiar los recursos de AWS creados anteriormente, ejecute:

curl https://raw.githubusercontent.com/aws-samples/sql-based-etl-on-amazon-eks/main/emr-on-eks/deprovision.sh | bash

 

Soporte Regional

En el momento de publicar este blog, Amazon EMR en Amazon EKS está disponible en las regiones EE.UU. Este (Virginia Norte), Ee.UU. Oeste (Oregón), EE.UU. Oeste (Norte de California), EE.UU. Este (Ohio), Canadá (Centro), Europa (Irlanda, Fráncfort y Londres) y Asia Pacífico (Mumbai, Seúl, Singapur, Sídney y Tokio). Si desea utilizar EMR en EKS en una región que aún no está disponible, consulte la alternativa de spark on EKS de código abierto que se muestra en el blog de la Parte 1. La solución de ejemplo se puede implementar en su región, siempre que Amazon EKS esté disponible. La migración de una carga de trabajo de Spark en EKS al EMR totalmente administrado en EKS es fácil y directa con cambios mínimos requeridos. Dado que la aplicación Spark autocontenida sigue siendo la misma, solo el despliegue de la implementación difiere.

 

Conclusión

Esta publicación proporciona una introducción a Amazon EMR en EKS y un recorrido por una solución de ejemplo para demostrar el concepto «ETL como definición». Al tener un marco de procesamiento de datos declarativo, permite a los clientes crear e implementar sus cargas de trabajo de Spark con una eficiencia mejorada. Al aprovechar Amazon EMR en Amazon EKS, la ejecución de aplicaciones basadas en un marco declarativo maximiza la productividad, el rendimiento, la fiabilidad y la disponibilidad de los procesos de datos a escala. Este patrón abstrae la tecnología Spark de usted y le ayuda a centrarse en los productos que optimizan los resultados empresariales. Debido a la facilidad de uso, que combina las optimizaciones integradas proporcionadas por nuestro servicio totalmente administrado Amazon EMR en Amazon EKS, el público objetivo no son solo los ingenieros de datos con habilidades analíticas, sino también los analistas, científicos de datos y cualquier autor de SQL que pueda expresar completamente sus flujos de trabajo de datos mediante declaración en Spark SQL. Este patrón de arquitectura podría usarse para impulsar el cambio de propiedad de los datos en su organización, de TI a partes interesadas que no son de TI y que tienen una mejor comprensión de las operaciones y necesidades del negocio.

Sobre los autores

Melody Yang es una arquitecta de soluciones especialista de AWS con experiencia en tecnologías de Big Data. Es una líder de analíticos que trabaja con los clientes de AWS para brindar orientación sobre las mejores prácticas y asesoramiento técnico para ayudarlos a tener éxito en la transformación de datos. Sus áreas de interés son los marcos de código abierto y la automatización, la ingeniería de datos y DataOps.

 

 

 

 

Shiva Achari es un arquitecto senior de laboratorio de datos de Amazon Web Services. Ayuda a los clientes de AWS a diseñar y crear prototipos de datos y análisis a través del AWS Data Lab Engagement. Tiene más de 14 años de experiencia trabajando con clientes empresariales y startups principalmente en el espacio de Datos y análisis de Big Data.

 

 

 

 

Igor Izotov es un arquitecto de soluciones empresariales de AWS y trabaja en estrecha colaboración con las organizaciones de servicios financieros más grandes de Australia. Antes de AWS, Igor ocupó puestos de arquitectura e ingeniería de soluciones con consultores de nivel 1 y proveedores de software. Igor es un apasionado de todo lo relacionado con los datos y la ingeniería de software moderna. Fuera del trabajo, le gusta escribir e interpretar música, un buen audiolibro o trotar, a menudo combinando los dos últimos.

 

 

 

 

Daniel Maldonado es un Arquitecto de Soluciones de AWS, especialista en cargas de trabajo Microsoft y tecnologías de Big Data, enfocado a ayudar a los clientes a migrar sus aplicaciones y datos a AWS. Daniel tiene mas de 12 años de experiencia trabajando con Tecnologías de la Información y disfruta de ayudar a los clientes a obtener los beneficios de correr sus cargas de trabajo en la nube.