Ejecución serverless de trabajos Spark con Amazon EMR Serverless - Procesamiento de big data sin gestión de clústeres
Explicamos la ejecución de trabajos Spark/Hive con EMR Serverless, el diseño de ejecuciones de trabajos y la optimización de costos.
Descripción general de EMR Serverless
EMR Serverless es un servicio de procesamiento de big data que ejecuta trabajos Spark y Hive de forma serverless, que escala automáticamente los workers dentro de la capacidad máxima configurada para la aplicación. A diferencia de EMR on EC2 que requiere configurar tipos de instancia, cantidad de nodos y Auto Scaling, EMR Serverless aprovisiona recursos automáticamente al enviar un trabajo. No se requiere parcheo de clústeres ni actualizaciones de versión, permitiendo concentrar el esfuerzo operativo en el desarrollo de trabajos.
Auto-escalado y modelo de pago por uso
De forma predeterminada, una aplicación de EMR Serverless se inicia automáticamente al enviar un trabajo y se detiene automáticamente tras 15 minutos de inactividad. Al enviar un trabajo, se especifican límites de vCPU y memoria para drivers y executors, pero durante la ejecución el número de executors aumenta y disminuye según el volumen de datos. La facturación depende de la cantidad de recursos, como vCPU y memoria, que usan los trabajos. Este mecanismo elimina el desperdicio de mantener clústeres ejecutándose para trabajos ETL batch que se ejecutan solo una vez al día, lo que facilita contener los costos en cargas de trabajo de baja utilización comparado con mantener clústeres permanentes con EMR on EC2.
Diseño de aplicaciones e integración con Hive
Las aplicaciones EMR Serverless se crean seleccionando un runtime de Spark o Hive. Las aplicaciones Spark colocan scripts PySpark en S3 y los ejecutan mediante job runs. Las aplicaciones Hive escriben procesamiento ETL en scripts HiveQL usando Glue Data Catalog como metastore. Configurar workers pre-inicializados evita arranques en frío al inicio del trabajo. Se pueden especificar individualmente vCPU y memoria para drivers y executors del job run, permitiendo asignación de recursos adaptada a las características del trabajo. Almacenar datos en S3 en formato Parquet con particionamiento puede reducir la cantidad de datos que leen las consultas.
Elección entre EMR on EC2 y Glue
Opciones similares a EMR Serverless incluyen EMR on EC2 y Glue, y la elección depende de las características de la carga de trabajo. EMR on EC2 es ventajoso cuando se necesitan funciones no soportadas por Serverless (instancias GPU, clústeres Presto/Trino) o cuando la utilización del clúster es alta para aprovechar descuentos de Reserved Instances. Glue ETL permite construir pipelines ETL con un editor visual y destaca en la integración con Data Catalog y job bookmarks (capacidad de reanudación), pero ofrece acceso limitado a parámetros de ajuste de Spark. Como guía: use EMR Serverless cuando los trabajos se completan con funciones estándar de Spark/Hive y la utilización del clúster es baja; use EMR on EC2 cuando se necesitan frameworks distintos a Spark (Flink, HBase); elija Glue cuando el ETL visual sin código sea la prioridad.
Mejores prácticas de diseño y trampas
Tres puntos clave de diseño aseguran una operación estable con EMR Serverless. Primero, establezca la capacidad máxima de la aplicación para prevenir aumentos de costos por un escalado inesperado. Sin una capacidad máxima para la aplicación, un trabajo que genera executors masivos debido a data skew puede resultar en cargos inesperados. Segundo, los workers pre-inicializados son adecuados cuando la frecuencia de trabajos es alta. La capacidad pre-inicializada se libera cuando la aplicación se detiene. Tercero, planifique una estrategia de compactación cuando use tablas Iceberg. Los archivos pequeños acumulados aumentan la cantidad de tareas Spark y alargan el inicio de los trabajos. Incorporar compactaciones periódicas en los pipelines de trabajos mantiene el rendimiento de consultas.
Precios de EMR Serverless
EMR Serverless cobra según la cantidad de recursos utilizados. Para el procesamiento batch esporádico, facilita contener los costos frente a los clústeres permanentes de EMR on EC2. Los workers pre-inicializados incurren en cargos incluso inactivos, así que habilítelos o deshabilítelos según la frecuencia de trabajos. Establezca límites de recursos en job runs para controlar costos de trabajos descontrolados y use timeouts para terminación automática.
Resumen
EMR Serverless es un servicio que ejecuta trabajos Spark y Hive sin gestión de clústeres. El precio de pago por uso y la detención automática en inactividad contienen los costos, y los workers pre-inicializados evitan arranques en frío. Usando Glue Data Catalog como metastore, permite procesamiento ETL sobre datos Parquet en S3. Establecer límites de recursos y gestionar los workers pre-inicializados son los puntos principales para contener los costos.
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.
- Amazon EMR Serverless (página oficial)
- Amazon S3 (página oficial)
- AWS Glue (página oficial)
- Documentación de AWS (oficial)
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.