Concepto de Pipeline Orquestrador

Airflow, Kubeflow, Prefect, Dagster: La pregunta que todos hacen mal

Ayer vimos por qué un script no es un pipeline.

Hoy la pregunta obvia: “¿Qué orquestador uso?”

Pero esa no es la pregunta correcta.

Historia real:

Hace tiempo, un colega me preguntó: “¿Por qué no usamos Airflow como para todo lo demás?”

Pregunta legítima. Teníamos Airflow funcionando perfecto para:

• ETLs diarios

• Reportes automáticos

• Data pipelines batch

¿Por qué necesitábamos evaluar Kubeflow?

---

El problema apareció con ML:

python

# Lo que funcionaba para ETL
@task
def process_data():
    df = read_database()
    df = transform(df)
    save_to_warehouse(df)
    # Siempre el mismo flujo, predecible

# Lo que necesitábamos para ML
@task
def train_model():
    # Necesito ejecutar 100 combinaciones
    # de hiperparámetros EN PARALELO
    # con GPUs
    # y solo registrar el mejor
    # ¿Cómo hago eso en Airflow?

Ahí entendí algo fundamental:

Los orquestadores vienen de mundos diferentes y resuelven problemas diferentes.

No hay “el mejor”. Solo el mejor para tu problema.

---

Primero: ¿Qué es un orquestador?

Si vienes de CI/CD (como yo), es como GitHub Actions pero para workflows de datos/ML.

En vez de:

# .github/workflows/deploy.yml
build → test → deploy

Es:

# ml_pipeline.py
ingest → validate → train → evaluate → deploy

Con 3 diferencias clave:

1. Workflows más largos (horas, no minutos)

2. Dependencias de datos (no solo código)

3. Fallos esperados (datos malos, métricas bajas)

---

Lo que TODOS los orquestadores te dan:

Conceptualmente, estas 4 cosas:

1. DAGs (Directed Acyclic Graphs)

    ingest
     / \
validate process
     \ /
    train → evaluate → deploy

Defines dependencias. “Step B solo corre si Step A pasó”

2. Scheduling

• “Ejecuta esto cada día a las 2am”

• “Ejecuta cuando lleguen nuevos datos”

• Triggers customizados

3. Retries & Error Handling

• Reintentos automáticos

• Alertas de fallos

• Recuperación desde puntos específicos

4. Observabilidad

• Logs centralizados de cada paso

• Visualización de flujos

• Métricas de ejecución

Eso es un orquestador. El resto es implementación.

---

Los 4 grandes (y de dónde vienen):

Airflow

De: Data Engineering
Para: ETLs batch, scheduling robusto

python

from airflow import DAG
from airflow.operators.python import PythonOperator

with DAG('ml_pipeline', schedule='@daily') as dag:
    ingest = PythonOperator(task_id='ingest', ...)
    train = PythonOperator(task_id='train', ...)
    
    ingest >> train  # Dependencias explícitas

Úsalo si:

• Ya tienes Airflow para ETLs

• Workflows batch tradicionales

• Necesitas ecosistema maduro (1000+ operators)

Evítalo si:

• Workflows ML complejos (hyperparameter tuning)

• Necesitas ejecución dinámica

• Quieres mejor developer experience

---

Kubeflow Pipelines

De: ML en Kubernetes
Para: Training distribuido, GPUs, ML nativo

python

from kfp import dsl

@dsl.pipeline(name='ml_pipeline')
def pipeline():
    ingest = dsl.ContainerOp(
        name='ingest',
        image='gcr.io/my-project/ingest:v1'
    )
    train = dsl.ContainerOp(
        name='train',
        image='gcr.io/my-project/train:v1'
    )
    train.after(ingest)

✅ Úsalo si:

• Ya vives en Kubernetes

• Necesitas GPU scheduling

• Hyperparameter tuning nativo

❌ Evítalo si:

• No quieres gestionar K8s

• Workflows simples

• Equipo pequeño sin expertise K8s

Prefect

De: “Airflow pero mejor UX”
Para: Workflows dinámicos, developer experience

python

from prefect import task, flow

@task
def ingest():
    return fetch_data()

@task
def train(data):
    return train_model(data)

@flow
def ml_pipeline():
    data = ingest()
    model = train(data)  # Dependencias implícitas

✅ Úsalo si:

• Quieres Airflow pero mejor DX

• Workflows dinámicos (loops, conditionals)

• Deployment más simple

❌ Evítalo si:

• Necesitas ecosistema gigante de plugins

• Tu equipo ya domina Airflow

• Quieres UI súper robusta (aunque ha mejorado)

---

Dagster

De: “Data pipelines como software engineering”
Para: Data platforms, software-defined assets

python

from dagster import asset, Definitions

@asset
def raw_data():
    return fetch_data()

@asset
def trained_model(raw_data):
    # Dagster sabe que depende de raw_data
    return train_model(raw_data)

defs = Definitions(assets=[raw_data, trained_model])

✅ Úsalo si:

• Construyes data platform desde cero

• Quieres “assets” en vez de “tasks”

• Testing robusto de pipelines

❌ Evítalo si:

• Solo necesitas scheduling simple

• Learning curve no vale la pena

• Stack legacy

---

Comparativa rápida:

Feature	Airflow	Kubeflow	Prefect	Dagster
Origen	Data Eng	ML/K8s	Airflow 2.0	Data Platform
Curva aprendizaje	Media	Alta	Baja	Media-Alta
Kubernetes	Opcional	Requerido	Opcional	Opcional
ML específico	🟡 Plugins	✅ Nativo	🟡 Posible	🟡 Posible
DX	🟡 Mejoró en 2.0	🔴 Complejo	✅ Excelente	✅ Muy bueno
Madurez	✅ Battle-tested	✅ Google-backed	🟡 Creciendo	🟡 Emergente

---

Framework de decisión:

PASO 1: ¿Ya tienes uno? → Sí? Úsalo hasta que realmente no puedas
→ No? Continúa ↓

PASO 2: ¿Cuál es tu stack? → Kubernetes everywhere? → Kubeflow
→ Python + infra simple? → Prefect
→ Múltiples data teams? → Dagster
→ Legacy + necesitas estabilidad? → Airflow

PASO 3: ¿Qué tan complejo es tu ML? → ETLs + modelos simples? → Airflow/Prefect
→ Hyperparameter tuning + GPUs? → Kubeflow
→ Data platform end-to-end? → Dagster

PASO 4: ¿Qué puede mantener tu equipo? → Esta es LA pregunta más importante

---

Mi take honesto (Platform Engineer):

En 2025-2026:

• ¿Tienes Airflow funcionando? → Quédate ahí hasta que duela

• ¿Stack K8s nativo + GPUs? → Kubeflow es la opción obvia

• ¿Greenfield project + equipo Python? → Prefect (mejor DX)

• ¿Construyendo data platform? → Dagster (pero evalúa el costo)

Lo que aprendí:

No busques “el mejor orquestador”.

Busca el que resuelve tu problema específico con tu stack actual que tu equipo puede mantener.

Las preguntas correctas:

• “¿Cuál es mejor?”

• “¿Qué problema estoy resolviendo?”

• “¿Qué usa Google?”

• “¿Qué puede mantener mi equipo?”

• “¿Cuál tiene más estrellas en GitHub?”

• “¿Cuál se integra con mi stack?”

---

Volviendo a mi historia:

¿Qué elegimos?

Airflow para ETLs, Kubeflow para ML.

¿Es ideal? No.
¿Funciona? Sí.
¿Lo haría diferente hoy? Tal vez Prefect.

Pero ya tenemos Airflow funcionando y el equipo lo conoce.

No seas la empresa con 4 orquestadores diferentes.

---

Mañana hablamos de scheduling:

Tienes tu orquestador. Cool.

Ahora: ¿Cuándo ejecutas tus pipelines?

• ¿Cada día a las 2am?

• ¿Cada hora?

• ¿Cuando lleguen datos nuevos?

Jobs batch vs event-driven. Y por qué importa para ML.

---

Tu turno:

• ¿Qué orquestador usas (o te gustaría usar)?

• ¿Cuántos orquestadores diferentes tiene tu empresa? 😅

(He visto empresas con 3+… no seas esa empresa o peor aun, usan servidores windows para production)