Airflow Migración y Limpieza de Datos de Bigtable a Snowflake con Airflow 2.9 en Kubernetes

Este documento describe una implementación reciente que involucra la extracción, validación, transformación y carga programada de datos de series temporales desde Google Bigtable hacia Snowflake, utilizando Apache Airflow 2.9 desplegado sobre Kubernetes con Horizontal Pod Autoscaling (HPA). El objetivo fue procesar diariamente grandes lotes de registros con limpieza de datos y bajo mantenimiento operativo.

---

Contexto

Los datos de origen consistían en aproximadamente 1.200 millones de registros almacenados en Google Bigtable, con incrementos diarios entre 3 y 10 millones de filas. El destino era Snowflake, donde análisis y dashboards aguas abajo requerían consistencia y baja latencia. Entre los retos estaban:

• Evolución del esquema a lo largo del tiempo
• Alineación de timestamps anidados para datos temporales
• Carga multi-región con variabilidad de rendimiento
• Necesidad de portabilidad en la nube y baja complejidad operativa

---

Resumen de Arquitectura

El pipeline se construyó utilizando:

• Apache Airflow 2.9 con KubernetesExecutor
• EKS (Elastic Kubernetes Service) con HPA definido por plantilla de pod
• Cloud Functions y Pub/Sub para eventos de activación
• Parquet y PyArrow para entrada/salida
• Snowflake como destino, usando COPY INTO desde un stage externo en S3

Un stack de logs compartido (FluentBit → OpenSearch) permitió trazabilidad y observabilidad de métricas.

---

Pasos del Pipeline

1. Extracción desde Bigtable

Cada ejecución comenzaba con una Cloud Function activada por Pub/Sub, que notificaba a Airflow sobre un nuevo lote. Un cliente Python para Bigtable realizaba escaneos limitados y escribía archivos Parquet comprimidos en GCS usando PyArrow.

• La extracción se paralelizaba por rangos de claves de fila
• La lógica de reintentos y retroceso estaba implementada en operadores personalizados de Airflow

2. Limpieza y Validación de Datos

Cada fragmento Parquet se procesaba en un pod dedicado con la siguiente lógica:

• Eliminar filas con campos obligatorios faltantes
• Normalizar columnas de fecha/hora a UTC
• Forzar tipos de datos según una versión dinámica de esquema en JSON
• Eliminar duplicados mediante claves hash compuestas
• Agregar campos de metadatos (ID de lote y timestamp de procesamiento)

Esta etapa se implementó con pandas y pyarrow, ejecutada dentro de pods que se escalaban horizontalmente usando HPA según CPU y memoria.

3. Preparación y Carga en Snowflake

Los datos limpios se trasladaban a un área de staging en S3 mediante operaciones gsutil rsync paralelas (multi-nube). Se usaba el mecanismo de stage externo de Snowflake con COPY INTO orquestado desde Airflow.

• Se aplicó particionado por fecha y región para mejorar el rendimiento de carga
• La supervisión se integró mediante callbacks de Airflow y métricas Prometheus personalizadas

---

¿Por qué Airflow 2.9 y Kubernetes con HPA?

• Airflow 2.9 ofrecía mejoras en TaskFlow, soporte más sólido para KubernetesExecutor y seguimiento de dependencias más robusto
• HPA permitió un uso eficiente de recursos: los DAGs operaban con bajo costo nocturno y escalaban dinámicamente en picos de carga
• Airflow sobre Kubernetes facilitó el aislamiento de errores por pod y actualizaciones independientes de imágenes de operadores

---

Resultados

• Promedio diario de filas procesadas: ~7 millones
• Duración típica del DAG: ~28 minutos
• Máximo de pods paralelos (HPA): 96
• Tasa de fallos en validación de datos: < 0.04 %
• Velocidad de carga en Snowflake: ~9–11 millones de filas/min (bulk load)

---

Lecciones Aprendidas

• La validación explícita de tipos y versionado de esquemas evitó errores en ingestión a medida que evolucionaba el origen
• La modularización con TaskGroups mejoró la visibilidad de DAGs y facilitó los reintentos
• La sincronización multi-nube (GCS → S3) fue estable, pero requiere planificación de costos por salida regional
• Las herramientas de observabilidad (OpenTelemetry / Prometheus) fueron útiles para diagnosticar el autoscaling

---

Conclusión

Esta implementación refleja un patrón técnico viable para migraciones de datos a gran escala desde Bigtable hacia Snowflake, utilizando Airflow 2.9 sobre Kubernetes. La arquitectura ofreció rendimiento estable ante cargas variables y altos estándares de calidad de datos, con poca intervención operativa continua.

---

🔍 ¿Necesitas diseñar pipelines ETL resilientes sobre Kubernetes?

Asistimos a equipos que construyen pipelines de datos con Airflow, Snowflake y entornos multi-nube. Contáctanos para asesoramiento técnico o revisión arquitectónica.

---