Procesamiento de big data con Amazon EMR - Entornos de ejecución para Spark y Hive

Se presentan la ejecución de jobs de Spark y consultas de Hive en clústeres de EMR, cuándo usarlos frente a EMR Serverless y la optimización de costes mediante el escalado administrado.

Configuración de un clúster de EMR

Un clúster de EMR se compone de un nodo principal (administración del clúster y gestor de recursos de YARN), nodos core (almacenamiento de datos en HDFS y procesamiento de cómputo) y nodos task (solo procesamiento de cómputo). Como los nodos core almacenan datos de HDFS, existe riesgo de pérdida de datos al reducirlos, pero los nodos task no almacenan datos y, por eso, pueden escalar libremente. Cuando se usa S3 como almacenamiento principal, el HDFS de los nodos core se limita al almacenamiento temporal de datos intermedios y se reducen los costes aprovechando instancias Spot en los nodos task. Con las flotas de instancias de EC2, puede especificar varios tipos de instancia para aumentar la disponibilidad de Spot.

Ejecución de Spark y Hive

En Spark on EMR, los jobs se envían con el comando spark-submit o con la API EMR Steps. EMRFS es el sistema de archivos con el que EMR lee y escribe en S3 y, como S3 pasó de la consistencia eventual a la consistencia fuerte a partir de diciembre de 2020, la vista coherente de EMRFS ya no es necesaria. Si activa la asignación dinámica de recursos (Dynamic Resource Allocation) de Spark, el número de ejecutores se ajusta automáticamente según la carga del job. En Hive on EMR se puede configurar el Glue Data Catalog como metastore externo y compartir las definiciones de tablas con Athena y Redshift Spectrum. EMR Serverless no requiere aprovisionar clústeres, y los jobs se ejecutan especificando los recursos por aplicación.

EMR on EKS y escalado administrado

EMR on EKS ejecuta jobs de Spark en un clúster de EKS existente y aprovecha la gestión de recursos y la programación de Kubernetes. Se crea un clúster virtual, se asigna a un espacio de nombres de EKS y los jobs se envían con la API StartJobRun. El escalado administrado de EMR on EC2 añade / elimina automáticamente nodos core y nodos task según la carga de los jobs. Se configura el número mínimo / máximo de nodos para el escalado, y las decisiones de escalado se toman en función del uso de memoria de YARN. EMR Studio es un IDE basado en navegador que permite conectarse a clústeres de EMR desde notebooks de Jupyter y ejecutar análisis interactivos.

Optimización de costes de EMR

Los costes de EMR se componen de las tarifas de las instancias y las tarifas de EMR. Se puede adoptar una configuración en la que los nodos task usan instancias Spot y los nodos core funcionan bajo demanda para proteger los datos de HDFS. En una arquitectura EMRFS que usa S3 como almacenamiento principal, puede reducir al mínimo el HDFS de los nodos core y reducir el riesgo de interrupción de Spot. Con un diseño que inicia clústeres transitorios solo al ejecutar jobs y los termina automáticamente al completarse, se contiene el coste del tiempo inactivo. Las instancias Graviton (m6g, r6g) se pueden usar para ejecutar jobs de Spark.

Almacenamiento e integración con el data lake

La base para usar EMR de forma eficiente es separar el cómputo del almacenamiento. Si guarda los datos en S3 y lanza un clúster para leerlos solo cuando se necesita procesarlos, no tiene que mantener el clúster en funcionamiento permanente y puede contener los costes. Como los datos permanecen en S3 aunque se termine el clúster, varios procesos pueden reutilizar los mismos datos. Si registra las definiciones de tablas en un catálogo de datos, no solo EMR sino también otros servicios de análisis pueden consultar los mismos datos, y puede tratar todo el data lake de forma coherente. Un diseño que concentra el almacenamiento en S3, que es persistente, es una de las formas de construir una plataforma de big data.

Modos de ejecución del clúster

Los clústeres de EMR se usan de distinta forma según el propósito. El uso transitorio, en el que un clúster ejecuta un proceso determinado y se descarta al terminar, es adecuado para el procesamiento por lotes y permite evitar el funcionamiento innecesario. Para el análisis interactivo y el procesamiento continuo, se usa un clúster de funcionamiento permanente. También se puede definir el procesamiento como pasos y ejecutarlos en orden. Si elige un modo de ejecución serverless, la propia administración del clúster deja de ser necesaria y puede concentrarse solo en enviar jobs. Con un entorno de notebooks, los científicos de datos pueden avanzar en el análisis de forma interactiva. El modo de ejecución se elige según la naturaleza y la frecuencia del procesamiento.

Optimización del rendimiento y los costes

El coste y el rendimiento de EMR cambian según cómo se eligen las instancias. Si adopta una configuración que combina de forma flexible varios tipos de instancia, puede aprovechar las instancias Spot, que son económicas, y mantener a la vez la disponibilidad. Usar Spot para los procesos que toleran interrupciones permite contener los costes. Con un mecanismo que ajusta automáticamente el tamaño del clúster según la carga, puede aumentar y reducir los recursos al ritmo de las oscilaciones del volumen de procesamiento y contener el desperdicio. Si estima adecuadamente cómo dividir los datos y la cantidad de recursos que necesita el procesamiento, resulta más fácil contener el tiempo de procesamiento y los costes.

Seguridad y gobernanza

En una plataforma de big data, la protección de los datos que se manejan y la gestión del acceso son importantes. Se cifran los datos almacenados y las comunicaciones durante el procesamiento para proteger la información confidencial. El acceso a los datos se combina con un mecanismo de gestión de permisos detallada, y se controla el alcance que puede consultar cada usuario. Si restringe el acceso a nivel de columna o de fila, puede cambiar el alcance que se muestra a cada departamento incluso en el mismo conjunto de datos. Se registra quién procesó qué datos para que se pueda auditar. Precisamente porque es un entorno en el que muchos usuarios manejan grandes volúmenes de datos, establecer una gobernanza que combine cifrado / control de acceso / auditoría es la premisa de una plataforma de análisis segura.

Resumen

EMR proporciona un entorno de ejecución administrado para frameworks de big data como Spark y Hive. Con una arquitectura EMRFS que usa S3 como almacenamiento principal, se reduce el riesgo de interrupción de las instancias Spot, y el escalado administrado ajusta automáticamente el número de nodos según la carga de los jobs. Con EMR on EKS, también es posible la integración con entornos de Kubernetes existentes.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Compartir