Amazon EMR Serverless
Servicio de procesamiento de big data sin servidor que ejecuta trabajos de Apache Spark y Hive sin gestión de clústeres, cobrando únicamente por el tiempo de vCPU y memoria utilizados
Descripción general
Amazon EMR Serverless es un servicio de procesamiento de big data que ejecuta trabajos de Apache Spark y Hive de forma serverless. No requiere construcción, escalado ni aplicación de parches en clústeres; simplemente se envía el trabajo y los recursos necesarios se aprovisionan automáticamente. Tras completar el procesamiento, los recursos se liberan y solo se cobra por el tiempo de vCPU y memoria realmente utilizados. EMR Runtime for Apache Spark proporciona hasta 3.5 veces más velocidad que la versión OSS de Spark sin costo adicional.
Ciclo de vida de aplicaciones y ejecución de trabajos
En EMR Serverless, primero se crea una aplicación. La aplicación es un contenedor que define el entorno de ejecución de Spark o Hive, especificando la versión de release de EMR (emr-6.x, emr-7.x). Las aplicaciones tienen tres estados: CREATED, STARTED y STOPPED, aceptando trabajos en estado STARTED. Los trabajos se envían mediante la API StartJobRun, especificando para Spark la ruta S3 del archivo JAR o script Python y el punto de entrada. Cuando se envía un trabajo, EMR Serverless aprovisiona automáticamente los workers e inicia el procesamiento. El tiempo de inicio de los workers es normalmente de 15-30 segundos, pero configurando Pre-initialized Workers se puede reducir prácticamente a cero. Tras completar el trabajo, los workers se liberan automáticamente. Habilitando la función de auto-stop, la aplicación transiciona a estado STOPPED cuando no hay trabajos durante un período determinado, eliminando completamente los costos de espera.
Configuración de workers y control de costos
Los workers de EMR Serverless se definen por combinaciones de vCPU y memoria, personalizables según las características del trabajo. Por defecto, se asignan 4 vCPU / 16 GB al driver de Spark y 4 vCPU / 16 GB a los executors, pero para procesamiento intensivo en memoria se puede ajustar a 4 vCPU / 30 GB. Estableciendo el número máximo de workers se limita el consumo de recursos por trabajo. La clave del control de costos es la configuración de recursos máximos a nivel de aplicación. Con maxCapacity se especifican límites de vCPU y memoria, controlando que el total de recursos de todos los trabajos no exceda este límite. El precio es aproximadamente 0.052 USD por hora de vCPU y 0.0057 USD por hora de GB de memoria. Aunque el precio unitario es mayor comparado con EMR on EC2 On-Demand, al no tener costos de tiempo inactivo, el costo total suele ser menor para procesamiento por lotes y análisis ad-hoc. Los logs de ejecución se exportan automáticamente a S3, y la Spark UI puede reconstruirse desde los logs en S3 para su consulta.
Patrones de integración con data lake en S3
La arquitectura típica de EMR Serverless es ejecutar procesamiento ETL con trabajos Spark usando S3 como data lake. Los datos de entrada son archivos Parquet, ORC, CSV o JSON en S3, utilizando Glue Data Catalog como metastore. Se pueden referenciar directamente las tablas de Glue Data Catalog con Spark SQL, aplicándose automáticamente partition pruning y predicate pushdown. También soporta lectura y escritura en tablas Apache Iceberg, permitiendo construir pipelines de datos robustos con transacciones ACID, evolución de esquema y consultas de viaje en el tiempo. La combinación con Step Functions para orquestar pipelines ETL diarios es ampliamente utilizada en la práctica. Se invoca la API StartJobRun desde un estado de tarea de Step Functions, esperando la finalización del trabajo antes de avanzar al siguiente paso. Configurando un trigger diario con EventBridge Scheduler, se completa un pipeline de procesamiento por lotes periódico completamente serverless.