Apache Airflow 2.x en Kubernetes – Orquestación de datos lista para producción a escala Big Data

Apache Airflow 2.x es un framework open-source de orquestación de flujos de trabajo usado para ETL, ingeniería de datos y pipelines de machine learning. Combinado con el Kubernetes Executor en un entorno de producción, permite ejecutar dinámicamente tareas en contenedores con control preciso de recursos, ideal para procesar los 5 V del Big Data (Volumen, Velocidad, Variedad, Veracidad y Valor).

Este documento presenta una arquitectura de producción, especificaciones de configuración y una comparativa con Azure Data Factory (ADF) para implementaciones a nivel empresarial.

---

Requisitos de un entorno Big Data en producción

Un despliegue de Airflow 2.x en Kubernetes, diseñado para pipelines de datos críticos y a gran escala, debe cumplir con:

• Volumen – Manejar terabytes a petabytes de datos en sistemas de almacenamiento distribuido.
• Velocidad – Soportar ingesta y transformación en modo batch y cuasi tiempo real.
• Variedad – Orquestar fuentes heterogéneas (bases de datos, APIs, colas de mensajes, data lakes).
• Veracidad – Integrar controles de calidad, validaciones de esquema y lógica de reintento.
• Valor – Garantizar SLA confiables para analítica y toma de decisiones.

---

Arquitectura de despliegue en Kubernetes

Componentes principales:

• Airflow 2.x Scheduler: se ejecuta en un pod dedicado, gestiona el parseo de DAGs y la planificación de tareas.
• Kubernetes Executor: crea un pod por tarea bajo demanda en un namespace definido.
• Base de datos de metadatos: PostgreSQL o MySQL (RDS o CloudSQL recomendado para alta disponibilidad).
• Webserver: proporciona la interfaz de Airflow con RBAC y autenticación (OAuth2, SAML).
• Registro y monitoreo:
  • Logs centralizados en S3/GCS con políticas de ciclo de vida.
  • Métricas en Prometheus/Grafana.
• Secrets y configuración: gestionados vía Kubernetes Secrets, AWS Secrets Manager o HashiCorp Vault.

Almacenamiento y acceso a datos:

• Volúmenes persistentes para espacio temporal de trabajo.
• DAGs sincronizados desde Git (sidecar Git-Sync) o almacenamiento de objetos (S3/GCS).
• Políticas de red para aislar acceso a la base de datos y al data lake.

---

Transferencia de datos e integración

• Ingesta: DAGs de Airflow con operadores para Kafka, AWS S3, Azure Blob Storage, Google Pub/Sub.
• Transformación: PySpark en EMR, Dataproc o Spark-on-K8s nativo.
• Carga: escritura en Redshift, Snowflake, BigQuery o Delta Lake sobre S3.
• Metadatos y gobernanza: integración con AWS Glue Data Catalog o Apache Atlas.

---

Comparación: Apache Airflow 2.x en K8s vs Azure Data Factory

---

Benchmark: Rendimiento de transferencia S3 en Airflow 2.x (KubernetesExecutor)

Este benchmark mide el rendimiento de extremo a extremo al mover datos de S3 → almacenamiento efímero del pod → S3 usando un contenedor que ejecuta aws s3 cp (o s5cmd) en pods Kubernetes lanzados por Airflow. Muestra el impacto de límites CPU/memoria, concurrencia y clase de red en el throughput sostenido.

Objetivo

• Medir el throughput de transferencia S3 por pod y a nivel de cluster en un escenario realista de Airflow.
• Validar el dimensionamiento de pods para los 5 V: Volumen/Velocidad sostenidos, garantizando Veracidad (checksums) y maximizando Valor (rendimiento por coste).

Dataset de prueba

• Origen: s3://my-ingest-bucket/bench/source/ con ~50 GB en Parquet/CSV.
• Destino: s3://my-ingest-bucket/bench/output/${RUN_ID}/
• Región: mantener pods y bucket en la misma región/AZ.

---

Configuración de pods (KubernetesExecutor)

Se prueban tres tamaños de pods, usados por Airflow mediante un pod template.

Pod template (pod_templates/transfer-small.yaml):

[...yaml igual al original...]

Large (transfer-large.yaml):

[...yaml igual al original...]

Notas

• Usar instancias con alto ancho de banda de red (p. ej. familias c6i/m6i).
• Si es posible, adjuntar almacenamiento rápido (NVMe efímero).
• Sustituir aws s3 sync por s5cmd para más paralelismo dentro del pod.

---

DAG de Airflow (KubernetesPodOperator)

[...código igual al original...]

---

Recopilación de métricas

• Por pod: bytes transferidos, duración, MB/s promedio.
• Cluster (Prometheus): CPU/memoria, tráfico de red, reinicios.

---

Resultados (ejemplo)

---

Validación e integridad de datos

• Activar checksums (--checksum con s5cmd) o validar hashes.
• Usar multipart S3 para archivos grandes.
• Evitar transferencias entre AZ.

---

Costes y optimización

• Usar nodos spot para benchmarks no críticos.
• Dimensionar correctamente requests/limits.
• Habilitar HPA para webserver/scheduler si hay alta carga.

---

Opción: Spark para transferencia + transformación

Si se requiere transformación, reemplazar el contenedor de transferencia por Spark-on-K8s o EMR on EKS.

---

Lo que muestra este benchmark

• Límite práctico de rendimiento por pod y rendimiento agregado.
• Trade-off entre pods grandes y más pods.
• Impacto del tipo de nodo y clase de almacenamiento.

---