Google Cloud Data Fusion: Arquitectura ETL/ELT, Aislamiento VPC y Estrategia FinOps

Matriz de Decisión de Ingesta & Transformación en GCP

La selección del motor de procesamiento en GCP suele generar solapamientos entre Cloud Data Fusion, Cloud Dataflow y Cloud Composer. La siguiente matriz evalúa la idoneidad técnica según latencias, modelos de desarrollo y gobernanza requerida:

Antipatrones Comunes y Riesgos FinOps en Producción

Cloud Data Fusion separa el plano de control (donde opera la interfaz gráfica, el servidor de metadatos y el pipeline runner de CDAP) del plano de ejecución (los recursos de cómputo donde se procesan las transformaciones Spark). Una arquitectura deficiente suele cometer los siguientes errores:

Principales Vectores de Fallo:

• Agotamiento de IPs en la Subred de Dataproc: Diseñar subredes con máscaras reducidas (ej. /28) para perfiles efímeros de Data Fusion provoca que pipelines paralelos fallen por falta de direcciones IP internas durante el auto-escalado horizontal.
• Falta de Directrices Private Google Access: Si los nodos efímeros de Dataproc en la VPC no tienen activado Private Google Access, los jobs fallarán al intentar descargar librerías de dependencias desde Cloud Storage o escribir en BigQuery mediante Private IP.
• Sobrecarga del Pipeline Runner por Ingestas Pequeñas: Utilizar Data Fusion para mover archivos de unos pocos kilobytes cada 5 minutos sobrecarga la inicialización de Spark (overhead de 2 a 3 minutos por cluster efímero). Para ingestas de baja latencia o archivos microscópicos, el patrón recomendado es Cloud Functions + Pub/Sub + Dataflow.

Infraestructura como Código (IaC): Data Fusion Private Instance & Peering

El siguiente manifiesto en Terraform aprovisiona una instancia empresarial privada de Cloud Data Fusion, configura el rango de IP asignado y establece el VPC Network Peering necesario para la comunicación interna con la VPC corporativa de Google Cloud:

# 1. Rango de IP Reservado para la VPC Administrada de Data Fusion
resource "google_compute_global_address" "data_fusion_ip_range" {
  name          = "data-fusion-reserved-range"
  purpose       = "VPC_PEERING"
  address_type  = "INTERNAL"
  prefix_length = 22
  network       = google_compute_network.analytics_vpc.id
}

# 2. Conexión de Servicios Privados (Peering de Red)
resource "google_service_networking_connection" "private_service_access" {
  network                 = google_compute_network.analytics_vpc.id
  service                 = "servicenetworking.googleapis.com"
  reserved_peering_ranges = [google_compute_global_address.data_fusion_ip_range.name]
}

# 3. Instancia de Cloud Data Fusion (Edición Enterprise, Private IP)
resource "google_data_fusion_instance" "enterprise_instance" {
  name                          = "cdf-enterprise-prod"
  description                   = "Data Fusion Enterprise para Ingesta y ETL"
  region                        = "europe-west1"
  type                          = "ENTERPRISE"
  enable_stackdriver_logging    = true
  enable_stackdriver_monitoring = true
  private_instance              = true

  network_config {
    network       = google_compute_network.analytics_vpc.name
    ip_allocation = "10.150.0.0/22" # Bloque /22 no solapado asignado para CDAP
  }

  dataproc_service_account = google_service_account.dataproc_runner_sa.email

  depends_on = [
    google_service_networking_connection.private_service_access
  ]
}

# 4. Regla de Firewall para permitir la comunicación Tenant Project -> Dataproc Nodes
resource "google_compute_firewall" "allow_cdf_to_dataproc" {
  name    = "fw-allow-cdf-to-dataproc-subnetwork"
  network = google_compute_network.analytics_vpc.name

  allow {
    protocol = "tcp"
    ports    = ["0-65535"]
  }

  source_ranges = ["10.150.0.0/22"]
  target_tags   = ["cdf-dataproc-worker"]
}

Patrones de Diseño: Perfiles de Cómputo Efímero y Storage Optimization

Para conseguir pipelines resilientes con eficiencia en costes, los arquitectos de datos deben aplicar tres principios esenciales en Cloud Data Fusion:

1. Compute Profiles con Autoscaling Policies Dinámicas

En lugar de usar la configuración por defecto de Dataproc (que instancia nodos fijos), se debe registrar un Compute Profile que asocie una política de autoescalado basada en métricas de memoria de YARN (yarn:memory-mb). Esto permite que el clúster efímero arranque con 2 nodos trabajadores y escale hasta 20 únicamente durante las fases de barajado (shuffle) y joins pesados, reduciendo los minutos de computación facturados.

2. Optimización del Conector BigQuery Sink

Al escribir en BigQuery desde Data Fusion, se debe priorizar el uso del plugin BigQuery Multi Table Sink o habilitar la BigQuery Storage Write API sobre el método tradicional de carga vía archivos temporales en Cloud Storage. Esto evita la latencia añadida de escribir en buckets intermedios y reduce el consumo de operaciones I/O.

3. Wrangler Direct Transformation vs Spark Pipelines

El módulo Data Fusion Wrangler permite preparar recetas visuales de limpieza de datos. No obstante, para transformaciones analíticas complejas que involucren agregaciones multi-tabla o particionamiento dinámico, se recomienda aplicar las directivas de transformación directamente en un nodo Wrangler Plugin dentro de un Data Pipeline Batch, garantizando que el optimizador de Spark compile las operaciones de manera nativa en código Scala/Java bytecode.

Checklist de Implementación Empresarial

1. Diseño de Subredes y Topología VPC

   Reservar un bloque CIDR dedicado (mínimo /22) libre de colisiones y habilitar Private Google Access en la subred donde residirán los workers de Dataproc.

2. Configuración de IAM y Principio de Menor Privilegio

   Separar la Service Account del Data Fusion Tenant Project de la Service Account que ejecutan los jobs en Dataproc, otorgando a esta última únicamente roles de roles/bigquery.dataEditor y roles/storage.objectAdmin sobre buckets específicos.

3. Definición de Perfiles de Cómputo (Compute Profiles)

   Crear perfiles efímeros con tipos de máquina ajustados (ej. n2-standard-4) y habilitar Secondary Workers (Spot VMs / Preemptible) para cargas batch tolerantes a fallos.

4. Integración CI/CD y Control de Versiones con CDAP Pipelines

   Exportar los pipelines en formato JSON e integrarlos en pipelines de Cloud Build / GitLab CI para automatizar el despliegue entre entornos (DEV -> UAT -> PROD) utilizando la API REST de CDAP.

Preguntas Frecuentes Técnicas (FAQ)