Logo Google Cloud con Eduardo

Google Cloud con Eduardo

Recibe el código de la lección en tu correo
Te enviaremos el enlace directo al archivo (.zip) y te sumaremos a nuestra newsletter de Google Cloud.

Información básica de protección de datos: Responsable: Eduardo Martínez Agrelo. Finalidad: Facilitar el recurso solicitado y enviar comunicaciones periódicas de valor sobre Google Cloud. Legitimación: Consentimiento del interesado (Art. 6.1.a RGPD). Destinatarios: Plataforma Odoo y proveedores de infraestructura técnica (Google Cloud / Firebase). Derechos: Acceso, rectificación y supresión en eduardomartinezagrelo@gmail.com.
✦ Guía Técnica & Arquitectura

GCP Apache Airflow Managed Service: Orquestación Empresarial en Google Cloud Composer

El ecosistema de datos moderno demanda orquestación de flujos de trabajo desacoplada, elástica y resistente a fallos. En Google Cloud Platform (GCP), el servicio totalmente gestionado para Apache Airflow es Google Cloud Composer. Esta guía profundiza en las decisiones de diseño arquitectónico, la evolución de Composer 2 vs. Composer 3, patrones asíncronos y optimizaciones críticas de FinOps para ingenieros y arquitectos de datos.

✦ Claves Arquitectónicas del Servicio

✓

Arquitectura Tenant vs. Customer: Comparación de aislamiento y red en Composer 2 y Composer 3.

✓

FinOps & Deferrable Operators: Supresión de slots de workers bloqueantes mediante triggers asíncronos.

✓

Mitigación de Sobrecarga en Scheduler: Eliminación del antipatrón de Top-Level Code y contención de parsing.

✓

Pipeline Pattern BigQuery & Vertex AI: Implementación declarativa con TaskFlow API y linaje gobernado.

Google Cloud Composer 3 Apache Airflow GKE Autopilot CeleryExecutor Async Triggerer VPC Service Controls Google Cloud Storage (DAG Sync) BigQuery Operators

✦ Matriz de Decisión: Opciones de Airflow en Google Cloud

Elegir la estrategia adecuada de orquestación en GCP implica balancear sobrecarga operativa, aislamiento de infraestructura, control de dependencias binarias y modelo de costes.

Criterio Cloud Composer 2 (GKE Híbrido) Cloud Composer 3 (Serverless-like) Airflow Custom en GKE / Compute
Plano de Cómputo GKE Autopilot en proyecto del usuario Tenant Project abstraído (Completamente gestionado) Nodos GKE / VMs administradas manualmente
Escalado de Workers Autoscaling horizontal (0.5 a X workers) Autoscaling por Workload Units y perfiles preconfigurados KEDA / Horizontal Pod Autoscaler manual
Overhead Operativo Bajo (Mantenimiento de cuotas GKE y rangos IP) Mínimo (Cero gestión de infraestructura de red/k8s) Muy Alto (Patching de OS, metadata DB, backup, Webserver)
Modelo de Costes Tarifa fija de entorno + consumo vCPU/Mem de GKE Consumo por hora de recursos de componentes Airflow Coste directo de instancias GCE / Persistent Disks
Caso de Uso Ideal Empresas con políticas rígidas sobre GKE expuesto Equipos modernos de Data/AI centrados en código Casos extremos con parches personalizados del core Airflow

✦ Antipatrones en Producción y Fugas de Costes (FinOps)

ALERTA: El Antipatrón de Top-Level Code y Sensores Síncronos

El Airflow DAG Processor parsea los archivos de la carpeta de DAGs cada min_file_process_interval segundos. Si incluyes llamadas a la API de GCP (como google.cloud.secretmanager o consultas de metadatos SQL) en el scope global del archivo:

  • El scheduler agotará su cuota de CPU parseando repetidamente conexiones externas.
  • Generarás miles de peticiones innecesarias por minuto a los endpoints de GCP.
  • Los workers de Celery mantendrán hilos bloqueados esperando jobs de BigQuery de larga duración, disparando el escalado automático y multiplicando la factura de Cloud Composer.

Solución Arquitectónica: Mueve toda inicialización pesada dentro de los operadores y adopta el flag deferrable=True en todos los operadores estándar de Google Cloud.

✦ Implementación en Producción: DAG con Deferrable Operators y TaskFlow

El siguiente pipeline demuestra el estándar moderno para Cloud Composer: uso de la TaskFlow API, ejecución asíncrona mediante BigQueryInsertJobOperator en modo diferido y parametrización limpia sin top-level overhead.

dags/gcp_composer_optimized_pipeline.py Python 3.11+ / Airflow 2.8+
"""
Pipeline de Producción en GCP Cloud Composer 2/3
Patrón: Deferrable BigQuery ETL + TaskFlow Decorators
Autor: Eduardo Martínez Agrelo (AI & Data Architect)
"""

from __future__ import annotations
from datetime import datetime, timedelta
from airflow.decorators import dag, task
from airflow.providers.google.cloud.operators.bigquery import BigQueryInsertJobOperator
from airflow.providers.google.cloud.transfers.gcs_to_bigquery import GCSToBigQueryOperator

PROJECT_ID = "enterprise-data-mesh-prod"
DATASET_ID = "analytics_staging"
RAW_BUCKET = "gs://raw-telemetry-lakehouse-prod"

DEFAULT_ARGS = {
    "owner": "data-architecture-team",
    "depends_on_past": False,
    "email_on_failure": True,
    "email": ["data-alerts@enterprise.com"],
    "retries": 2,
    "retry_delay": timedelta(minutes=3),
    "retry_exponential_backoff": True,
    "max_retry_delay": timedelta(minutes=15),
}

@dag(
    dag_id="gcp_composer_optimized_elt",
    default_args=DEFAULT_ARGS,
    schedule_interval="@daily",
    start_date=datetime(2026, 1, 1),
    catchup=False,
    max_active_runs=1,
    tags=["finops", "bigquery", "deferrable", "production"],
)
def gcp_managed_pipeline():

    # 1. Ingestión GCS a BigQuery Staging (Idempotente)
    ingest_gcs_to_stg = GCSToBigQueryOperator(
        task_id="ingest_telemetry_to_staging",
        bucket=RAW_BUCKET.replace("gs://", ""),
        source_objects=["events/{{ ds }}/*.parquet"],
        destination_project_dataset_table=f"{PROJECT_ID}.{DATASET_ID}.stg_events_{{{{ ds_nodash }}}}",
        source_format="PARQUET",
        write_disposition="WRITE_TRUNCATE",
        autodetect=True,
    )

    # 2. Transformación SQL Serverless (Operador Deferrable)
    # Al activar deferrable=True, el worker cede el hilo al Triggerer
    transform_aggregation = BigQueryInsertJobOperator(
        task_id="transform_analytics_mart",
        configuration={
            "query": {
                "query": f"""
                    CREATE OR REPLACE TABLE `{PROJECT_ID}.analytics_mart.daily_kpis_{{{{ ds_nodash }}}}` AS
                    SELECT 
                        event_type,
                        COUNT(1) AS total_events,
                        AVG(session_duration_sec) AS avg_duration,
                        CURRENT_TIMESTAMP() AS processed_at
                    FROM `{PROJECT_ID}.{DATASET_ID}.stg_events_{{{{ ds_nodash }}}}`
                    GROUP BY 1;
                """,
                "useLegacySql": False,
            }
        },
        deferrable=True,  # Clave FinOps: libera slots de Celery durante el query
    )

    # 3. Validación de Calidad de Datos vía TaskFlow
    @task
    def validate_mart_quality(table_suffix: str) -> dict:
        # Import local dentro de la tarea para evitar degradación de parsing del Scheduler
        from google.cloud import bigquery
        
        client = bigquery.Client()
        query = f"SELECT count(*) as rows_count FROM `{PROJECT_ID}.analytics_mart.daily_kpis_{table_suffix}`"
        query_job = client.query(query)
        result = list(query_job.result())
        count = result[0].rows_count
        
        if count == 0:
            raise ValueError("Data Quality Check Failed: Tabla de KPIs vacía.")
            
        return {"status": "SUCCESS", "row_count": count}

    quality_check = validate_mart_quality(table_suffix="{{ ds_nodash }}")

    # Dependencias declarativas
    ingest_gcs_to_stg >> transform_aggregation >> quality_check

pipeline = gcp_managed_pipeline()

✦ Patrones de Diseño de Alto Rendimiento

1. Dynamic DAG Generation

Evita archivos estáticos duplicados. Genera DAGs a partir de esquemas YAML/JSON cargados de forma perezosa en memoria usando fábricas de DAGs sin saturar el scheduler.

2. Isolation via KubernetesPodOperator

Para pipelines con dependencias binarias complejas (ej. modelos de C++, compilaciones Rust o TensorFlow legacy), aísla la ejecución en contenedores dedicados de Pods en lugar de saturar los paquetes PyPI del entorno de Composer.

3. VPC Service Controls & IAM

Asegura el bucket de Cloud Storage asociado a Composer mediante Service Accounts con permisos mínimos (principio de menor privilegio) y perímetros de seguridad VPC-SC para mitigar exfiltración de datos.

✦ Framework de Implementación de Cloud Composer en la Empresa

  1. Fase 1: Dimensionamiento y Sizing: Definir el tipo de entorno (Small, Medium, Large en Composer 3) y configurar los límites de autoscaling de workers basándose en el pico de concurrencia esperado de tareas.
  2. Fase 2: Estrategia de CI/CD para DAGs: Implementar un pipeline en Cloud Build o GitHub Actions con linters (flake8, ruff), validación estática con dag.test() y sincronización automática hacia gs://<composer-bucket>/dags.
  3. Fase 3: Optimización del Airflow Scheduler: Ajustar los parámetros scheduler.parsing_processes y scheduler.min_file_process_interval para balancear la frescura de DAGs con la carga de CPU.
  4. Fase 4: Observabilidad & Alertas: Configurar Cloud Monitoring Dashboards para monitorear métricas clave: Scheduler Heartbeat, Celery Queue Latency, Worker Memory Usage y DAG Processing Time.

✦ Preguntas Frecuentes Técnicas

¿Cuál es la diferencia fundamental entre Cloud Composer 2 y Cloud Composer 3 en GCP?
Cloud Composer 2 ejecuta los workers y componentes en un clúster de GKE Autopilot visible dentro del proyecto del cliente. Cloud Composer 3 abstrae la infraestructura al tenant de Google, eliminando la sobrecarga de red y direccionamiento IP en tu VPC, con un arranque de entorno mucho más rápido y un modelo de consumo por Workload Units más eficiente.
¿Cómo reducen los Deferrable Operators el coste operativo de Airflow en Google Cloud?
Al utilizar deferrable=True, los operadores de BigQuery, Dataproc o Dataflow suspenden el pod/worker de Airflow mientras el trabajo externo se ejecuta en Google Cloud. El estado es monitorizado por el proceso asíncrono Airflow Triggerer, liberando capacidad computacional de los workers y evitando el autoscaling horizontal descontrolado.
¿Por qué el "Top-Level Code" es el antipatrón más crítico en Cloud Composer?
Cualquier código fuera de los callables o métodos de operadores se ejecuta cada vez que el DAG File Processor lee el archivo (cada pocos segundos). Incluir llamadas a APIs o consultas de bases de datos degrada drásticamente la latencia del scheduler, congela la interfaz web y dispara la contención de recursos.

Sobre el Autor: Eduardo Martínez Agrelo

AI & Data Architect

Especialista en el diseño e implementación de plataformas de datos a escala petabyte, arquitecturas de orquestación distribuida, gobernanza en Data Mesh y sistemas avanzados de Inteligencia Artificial en Google Cloud Platform. Comprometido con la divulgación de mejores prácticas de ingeniería de datos, optimización FinOps y resiliencia en arquitecturas Cloud Native.