Apache Spark en Amazon EMR - Diseño de clústeres para procesamiento de big data y optimización de costos
Explicamos la construcción de clústeres Spark con EMR, la diferenciación con EMR Serverless y la optimización de costos mediante el uso de instancias Spot.
Descripción general de EMR
EMR es un servicio que ejecuta más de 20 frameworks de big data, incluyendo Apache Spark, Hive, Presto y Flink, en clústeres gestionados. Los clústeres se componen de nodos maestro, core y task, y EMR gestiona automáticamente el aprovisionamiento, configuración y aplicación de parches. EMR Serverless, que alcanzó disponibilidad general en 2022, elimina completamente la gestión de clústeres. Solo se envían los trabajos de Spark y los recursos necesarios se aprovisionan automáticamente. La arquitectura de "separación de cómputo y almacenamiento" usando S3 como almacenamiento es el estándar, permitiendo detener y recrear clústeres sin dependencia de HDFS para una gestión de ciclo de vida flexible.
Optimización de costos
La optimización de costos en EMR depende del diseño de la configuración de instancias. Se usan instancias bajo demanda para nodos maestro y core para asegurar estabilidad, e instancias Spot para nodos task. Como los nodos task no almacenan datos, no hay riesgo de pérdida de datos por interrupciones de Spot. Se especifican múltiples tipos de instancias con instance fleets para mejorar la disponibilidad de Spot. EMR Serverless es ideal para trabajos intermitentes, cobrando solo durante la ejecución del trabajo. Los precios de EMR on EC2 incluyen los costos de instancias EC2 más una tarifa de gestión de EMR (aproximadamente 25% de los costos EC2), por lo que aplicar Savings Plans es efectivo para clústeres de larga duración.
Ajuste de Spark y formatos de datos
El rendimiento de los trabajos Spark depende significativamente del número de particiones, la configuración de executors y la selección del formato de datos. Se ajusta spark.sql.shuffle.partitions según el volumen de datos, cambiando el valor predeterminado de 200 a un valor apropiado. El formato Parquet usa almacenamiento columnar que lee solo las columnas necesarias, reduciendo drásticamente el volumen de escaneo y el tiempo de procesamiento comparado con CSV. Habilitar Adaptive Query Execution (AQE) optimiza automáticamente el número de particiones shuffle y las estrategias de join basándose en estadísticas de ejecución. Los formatos de tabla como Delta Lake y Apache Iceberg habilitan transacciones ACID, viajes en el tiempo y evolución de esquemas en data lakes. Desde Spark 3.x, Dynamic Partition Pruning (DPP) optimiza automáticamente los joins con tablas particionadas, eliminando lecturas innecesarias de particiones. Para conocimientos prácticos sobre EMR, también vale la pena consultar libros relacionados en Amazon.
Gestión de costos del clúster EMR
Instance fleets permiten especificar múltiples tipos de instancias para maximizar la disponibilidad de Spot. Se establece una proporción mixta de instancias bajo demanda y Spot, asegurando una línea base con bajo demanda mientras se complementa la capacidad adicional con Spot. EMR Serverless no requiere gestión de clúster y cobra solo por el tiempo de ejecución del trabajo, siendo ideal para procesamiento batch esporádico. Para clústeres de larga duración, se aplican Savings Plans para aprovechar descuentos por compromiso. Se monitoriza la utilización de recursos YARN con métricas de CloudWatch para detectar y ajustar clústeres sobre-aprovisionados. Habilitar Managed Scaling escala automáticamente los nodos task según las métricas de YARN, agregando recursos solo durante picos y reduciendo durante períodos inactivos.
Elección entre EMR on EC2, EMR Serverless y EMR on EKS
EMR ofrece tres opciones de despliegue, seleccionadas según las características de la carga de trabajo. EMR on EC2 es el modo de clúster tradicional, adecuado para personalización detallada de configuración Spark, instalación de bibliotecas y cargas de trabajo que requieren HDFS. EMR Serverless no requiere aprovisionamiento de clúster y es ideal para cargas de trabajo de tipo "enviar y esperar" como batches diarios o trabajos ETL esporádicos. Tiene una sobrecarga de inicio de decenas de segundos, haciéndolo inadecuado para consultas interactivas de baja latencia. EMR on EKS ejecuta trabajos Spark en clústeres Kubernetes, elegido cuando los equipos ya operan EKS y quieren unificar la infraestructura o compartir recursos con otras cargas de trabajo de contenedores. En cuanto a costos, EMR Serverless tiende a tener costos por GB más bajos para trabajos de corta duración, mientras que los clústeres EC2 logran costos más bajos para trabajos de larga duración mediante instancias Spot combinadas con Savings Plans.
Errores de diseño y consideraciones operativas
Hay varios problemas comunes al ejecutar Spark en EMR. Primero, el Small File Problem (acumulación masiva de archivos pequeños) aumenta la sobrecarga de procesamiento de metadatos e infla los costos de solicitudes GET de S3. Se controla el número de archivos de salida con coalesce o repartition de Spark, o se fusionan periódicamente archivos pequeños usando la función de compaction de Iceberg. Segundo, como mitigación de interrupciones de instancias Spot, se habilita spark.speculation para ejecutar especulativamente tareas retrasadas, reduciendo el tiempo de recuperación de tareas interrumpidas. El sesgo de datos (data skew) es otro problema frecuente: cuando los datos se concentran en claves de partición específicas, los shuffles causan agotamiento de memoria o desequilibrio en tiempos de procesamiento. Se aborda con la optimización de skew join de AQE o técnicas de salting (agregar sufijos aleatorios a las claves para distribuir). Finalmente, respecto al acceso a S3 a través de EMRFS de EMR, S3 cambió a consistencia fuerte en diciembre de 2020, por lo que las preocupaciones históricas de consistencia ya no aplican.
Resumen
EMR es un servicio para ejecutar frameworks de big data en un entorno gestionado. Adaptive Query Execution optimiza automáticamente el rendimiento de trabajos Spark, mientras que el formato Parquet y un diseño de particiones adecuado mejoran la eficiencia de consultas. Instance fleets maximizan la disponibilidad de Spot, y EMR Serverless mejora la eficiencia de costos para procesamiento batch esporádico. Seleccionar entre las tres opciones de despliegue (EC2, Serverless, EKS) según las características de la carga de trabajo, y abordar proactivamente errores operativos como el Small File Problem y el sesgo de datos mediante diseño, son clave para un procesamiento de datos a gran escala estable.