# 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

```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:

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

Es:

```bash
# 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)**

```markdown
    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

```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

```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

```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

```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)