Amazon EMR
Plataforma de big data que ejecuta frameworks de código abierto como Apache Spark, Hive y Presto de forma gestionada para procesamiento y análisis de datos a escala de petabytes
Descripción general
Amazon EMR (Elastic MapReduce) es un servicio de procesamiento de big data que ejecuta de forma totalmente gestionada frameworks de código abierto como Apache Spark, Hadoop, Hive, Presto y HBase. Además del modelo tradicional de construir clústeres sobre instancias EC2, ofrece tres opciones de despliegue: EMR on EKS para ejecución sobre EKS, y EMR Serverless para ejecución sin servidor. Utilizando S3 como data lake y separando cómputo y almacenamiento, permite minimizar costos terminando el clúster una vez finalizado el procesamiento.
Tres modelos de despliegue y criterios de selección
EMR on EC2 es la opción más flexible, permitiendo un control detallado sobre tipos de instancia, configuración del clúster y acciones de bootstrap. Es adecuado cuando se necesita especificar versiones de Spark o Hive, usar AMIs personalizadas o aprovechar almacenamiento local con HDFS. EMR on EKS ejecuta trabajos Spark sobre un clúster EKS existente, aprovechando la gestión de recursos y capacidades multi-tenant de Kubernetes. Es ideal para operaciones donde múltiples equipos comparten el mismo clúster mientras aíslan trabajos por namespace. EMR Serverless es la opción más reciente, disponible en GA desde 2022, que elimina completamente la necesidad de construir y gestionar clústeres. Solo se envía el trabajo y los recursos necesarios se aprovisionan automáticamente, liberándose tras completar el procesamiento. Para cargas de trabajo que no requieren ejecución continua, como ETL por lotes y análisis ad-hoc, ofrece la mayor eficiencia de costos. Como guía de selección: EC2 cuando se necesita ajuste fino, EKS cuando se requiere integración con Kubernetes, y Serverless cuando se quiere minimizar la carga operativa.
Optimización de trabajos Spark y control de costos
Al ejecutar Spark en EMR, lo que más impacta en rendimiento y costos es la configuración de instancias y el diseño de particiones. La práctica básica es asignar instancias tipo r (orientadas a memoria) para el nodo driver e instancias tipo m (orientadas a costo) para los nodos worker. Usando instancias Spot para los workers se puede lograr una reducción de costos del 60-90% respecto a On-Demand, pero es necesario especificar múltiples tipos de instancia en una flota de instancias para prepararse ante interrupciones. El número de particiones de shuffle de Spark (spark.sql.shuffle.partitions) debe ajustarse desde el valor predeterminado de 200 según el volumen de datos. Como referencia, configurar aproximadamente 128-256 MB por partición logra un buen equilibrio entre eficiencia de memoria y paralelismo de tareas. Para lecturas desde S3, es importante usar formatos columnares como Parquet u ORC y particionar los datos por fecha o categoría para que el partition pruning sea efectivo. EMR Runtime for Apache Spark logra hasta 3.5 veces más velocidad que la versión OSS de Spark, disponible sin costo adicional.
Arquitectura de data lake y diferenciación con Glue
Tanto EMR como Glue pueden ejecutar procesamiento ETL basado en Spark, pero tienen posicionamientos diferentes. Glue es serverless con baja carga operativa, e integra Glue Data Catalog para gestión de metadatos y crawlers para detección automática de esquemas. Es adecuado para pipelines ETL estándar y casos donde la integración con el catálogo de datos es importante. Por otro lado, EMR puede ejecutar diversos frameworks además de Spark (Hive, Presto, HBase, Flink) y ofrece mayor libertad en la configuración del clúster, siendo ideal para procesamiento analítico complejo y consultas interactivas. En la práctica, es común procesar ETL diario estándar con Glue y ejecutar análisis a gran escala ad-hoc o preprocesamiento de machine learning con EMR. Para construir un data lake, el patrón estándar es almacenar datos crudos en S3, detectar esquemas con Glue Crawler, registrarlos en Data Catalog y consultarlos desde EMR o Athena. Usando formatos de tabla como Apache Iceberg o Delta Lake sobre EMR, también se pueden lograr transacciones ACID y consultas de viaje en el tiempo.