Orquestar Spark en AWS EMR con Apache Airflow — Enfoque Low-Ops

Ejecutar Apache Spark a gran escala es un problema resuelto desde hace tiempo — pero la forma en que lo ejecutas puede tener un impacto considerable en los costes, la estabilidad y la carga operativa.
Si tu plataforma de datos ya utiliza Apache Airflow para la orquestación, puede que te tiente lanzar Spark directamente en pods de Kubernetes. Esto funciona, pero implica gestionar imágenes de runtime de Spark, servicios de shuffle, ajuste de JVM y aislamiento de recursos en Kubernetes.

Existe un camino más sencillo: dejar que Airflow actúe como el director de orquesta y que AWS EMR haga el trabajo pesado de Spark.

En este artículo veremos por qué este enfoque funciona tan bien y revisaremos una configuración mínima de Airflow 2.x para lanzar trabajos Spark en EMR — sin complejidades adicionales de Kubernetes.

---

Por qué EMR + Airflow funcionan bien juntos

Con EMR obtienes un runtime Spark gestionado que ya sabe comunicarse con S3, integrarse con Glue Data Catalog y escalar bajo demanda.
El papel de Airflow se limita a la orquestación: planificación, dependencias, reintentos y seguimiento del estado de los trabajos.

Ventajas clave:

• Sin babysitting de clústeres: EMR se encarga del ajuste del runtime, actualizaciones de Hadoop/Spark y auto-escalado.
• Integración nativa con AWS: S3, Glue, KMS y logs en CloudWatch listos para usar.
• Coste elástico: EMR Serverless para pagar solo por ejecución, o clústeres EMR transitorios para cargas pesadas puntuales.
• Entorno estable: sin diferencias entre Spark local en desarrollo y Spark en pods Kubernetes.

---

Elegir el modo EMR adecuado

Existen dos opciones principales para combinar Airflow y EMR:

Nos centraremos en EMR Serverless por su simplicidad, aunque el modo transitorio es igualmente fácil de implementar después.

---

DAG mínimo de Airflow para EMR Serverless

El camino más corto entre Airflow y Spark en EMR Serverless es así:

from datetime import datetime
from airflow import DAG
from airflow.providers.amazon.aws.operators.emr import EmrServerlessStartJobOperator
from airflow.providers.amazon.aws.sensors.emr import EmrServerlessJobSensor

APPLICATION_ID = "TU-APP-ID"  # Aplicación Spark EMR Serverless
S3_SCRIPT = "s3://mi-bucket/code/job.py"
S3_LOGS = "s3://mi-bucket/logs/"

with DAG(
    dag_id="spark_en_emr_serverless",
    start_date=datetime(2025, 1, 1),
    schedule=None,
    catchup=False,
) as dag:

    start_job = EmrServerlessStartJobOperator(
        task_id="iniciar_spark",
        application_id=APPLICATION_ID,
        execution_role_arn="arn:aws:iam::123456789012:role/EmrJobRole",
        job_driver={
            "sparkSubmit": {
                "entryPoint": S3_SCRIPT,
                "sparkSubmitParameters": (
                    "--conf spark.executor.instances=4 "
                    "--conf spark.executor.memory=4g "
                    "--conf spark.executor.cores=2 "
                )
            }
        },
        configuration_overrides={
            "monitoringConfiguration": {
                "s3MonitoringConfiguration": {"logUri": S3_LOGS}
            }
        },
        aws_conn_id="aws_default",
        wait_for_completion=False,
    )

    wait_job = EmrServerlessJobSensor(
        task_id="esperar_spark",
        application_id=APPLICATION_ID,
        job_id=start_job.output,
        aws_conn_id="aws_default",
        poke_interval=30,
        timeout=3600,
    )

    start_job >> wait_job

Qué hace:

• EmrServerlessStartJobOperator: envía tu script PySpark a EMR Serverless con parámetros de ejecución.
• EmrServerlessJobSensor: espera la finalización del trabajo antes de pasar a la siguiente tarea.
• Sin YAML de clúster, sin mantenimiento de imagen JVM — solo gestionas tu código Spark.

---

Ejemplo de trabajo Spark

Un script PySpark sencillo (job.py) en S3:

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("EjemploJob").getOrCreate()

data = [("Alice", 34), ("Bob", 45), ("Cathy", 29)]
df = spark.createDataFrame(data, ["nombre", "edad"])

df.filter(df.edad > 30).show()

spark.stop()

---

Comparativa con Spark sobre Kubernetes

---

Conclusión

Si tu prioridad es entregar pipelines de datos en lugar de gestionar infraestructura, ejecutar Spark en EMR desde Airflow es una elección clara. Más adelante siempre podrás migrar a Kubernetes si el multi-cloud o los runtimes personalizados se vuelven esenciales — pero EMR te llevará a producción más rápido y con menos fricción.

Consejo: Empieza con EMR Serverless para resultados rápidos. Si el rendimiento o el coste lo requieren, evalúa clústeres EMR transitorios con grupos de instancias optimizados.

¿Quieres que también prepare una versión corta de este mismo texto como excerpt para usarlo en tu listado de artículos?

---