Cómo Crear un Pipeline ETL en Google Cloud Data Fusion a BigQuery
Construye un pipeline ETL batch visual para importar archivos CSV desde Cloud Storage hasta BigQuery, aplicando transformaciones, validaciones, gobernanza y criterios FinOps sin convertir el proyecto en una colección de scripts difíciles de mantener.
Lo que aprenderás
La arquitectura correcta para un ETL visual
Cloud Data Fusion proporciona un diseñador visual basado en etapas o plugins. Una pipeline se construye conectando fuentes, transformaciones, analítica, sinks y componentes de control. Esto permite separar la lógica de integración de la infraestructura subyacente y reducir el trabajo necesario para implementar conectores y transformaciones recurrentes.
Para el caso de uso de esta guía, el patrón recomendado es: Cloud Storage como landing zone → Wrangler para preparación → BigQuery como analytical sink.
01 · Landing
Los CSV llegan a un bucket de Cloud Storage. Esta capa conserva el fichero original y desacopla la recepción de datos del procesamiento.
02 · Transform
Wrangler permite inspeccionar una muestra y aplicar operaciones de limpieza, normalización, selección y transformación sobre los registros.
03 · Warehouse
BigQuery recibe el dataset preparado y lo convierte en una capa analítica consultable mediante SQL y optimizable con particionado y clustering.
Cloud Data Fusion organiza las pipelines mediante plugins de tipo source, transformation, analytics, sink y componentes de condiciones o errores. :contentReference[oaicite:0]{index=0}
Matriz de decisión: ¿Cloud Data Fusion, SQL o código?
El hecho de poder construir un pipeline visual no significa que sea automáticamente la mejor arquitectura. La decisión debe considerar complejidad, volumen, latencia, gobernanza, coste operativo y capacidades del equipo.
| Patrón | Latencia | Transformación | Coste operativo | Mejor caso de uso |
|---|---|---|---|---|
| Cloud Data Fusion Batch | Minutos / horas | Visual + plugins | Medio | Integraciones ETL empresariales y pipelines recurrentes |
| BigQuery SQL | Segundos / minutos | Alta para transformaciones SQL | Bajo | Transformaciones sobre datos que ya están en BigQuery |
| Python / Dataflow | Minutos / streaming | Máxima flexibilidad | Alto | Lógica compleja, streaming o procesamiento altamente personalizado |
| Ingesta directa a BigQuery | Baja | Limitada en la ingesta | Bajo | Cargas simples donde no existe una fase ETL relevante |
Cómo importar CSV de Cloud Storage a BigQuery
El origen Cloud Storage batch puede leer formatos estructurados como CSV, Avro, Parquet y ORC, además de formatos semiestructurados como JSON y XML. Esto permite utilizar Cloud Storage como una zona de entrada flexible para el pipeline. :contentReference[oaicite:1]{index=1}
El pipeline lógico queda reducido a tres etapas principales:
CSV en Cloud Storage → Cloud Storage Source → Wrangler → BigQuery Sink
Source
Configura el bucket, ruta, formato CSV, delimitador, cabecera y características del esquema necesarias para interpretar el fichero.
Wrangler
Inspecciona una muestra del dataset y corrige nombres de columnas, tipos, valores nulos, formatos de fecha o campos innecesarios.
BigQuery Sink
Define proyecto, dataset y tabla de destino. En producción conviene establecer explícitamente las reglas de creación, escritura y evolución del esquema.
Wrangler permite conectarse a fuentes como Cloud Storage y BigQuery y visualizar una muestra de los datos para trabajar sobre ella. :contentReference[oaicite:2]{index=2}
Antipatrón crítico: tratar Data Fusion como si fuera gratis
⚠ Error FinOps: asumir que porque la pipeline se ejecuta solo una vez al día el coste de Cloud Data Fusion es despreciable.
Cloud Data Fusion cobra por el tiempo durante el cual la instancia está creada, facturando por minutos aunque las tarifas se expresen por hora. Además, la ejecución de pipelines genera costes asociados al procesamiento de Managed Service for Apache Spark y pueden intervenir Cloud Storage, networking y BigQuery. :contentReference[oaicite:3]{index=3}
La consecuencia arquitectónica es importante: optimizar únicamente la consulta de BigQuery no equivale a optimizar el coste total del pipeline. Hay que observar el ciclo completo de ingestión, transformación y carga.
Medir
Registra duración de cada ejecución, volumen procesado y recursos consumidos.
Reducir
Evita transformaciones innecesarias y no proceses repetidamente ficheros históricos cuando solo ha llegado un nuevo lote.
Comparar
Cuando la transformación es predominantemente SQL, evalúa si moverla a BigQuery reduce complejidad y coste operacional.
Implementación práctica: configuración reproducible
Aunque el pipeline se diseña visualmente, es recomendable documentar su configuración de forma reproducible. Un patrón empresarial puede mantener parámetros como proyecto, bucket, dataset, tabla y rutas mediante variables de entorno o argumentos del pipeline.
# Parámetros del pipeline ETL
export GCP_PROJECT="mi-proyecto-data"
export GCS_BUCKET="mi-bucket-landing"
export GCS_INPUT_PATH="raw/customers/"
export BQ_DATASET="analytics"
export BQ_TABLE="customers"
# Contrato lógico del pipeline:
# Cloud Storage CSV
# ↓
# Cloud Data Fusion Batch Source
# ↓
# Wrangler / Data Quality
# ↓
# BigQuery Sink
#
# Recomendación:
# - Mantener raw intacto.
# - Validar esquema antes de cargar.
# - Controlar duplicados.
# - Registrar cada ejecución.
# - Separar datasets raw, staging y curated.Cloud Data Fusion permite desplegar una pipeline después de validarla y ejecutarla bajo demanda, mediante programación o mediante triggers. :contentReference[oaicite:4]{index=4}
Patrones de diseño y mejores prácticas
Landing ≠ Curated
No conviertas el bucket de entrada en tu única fuente de verdad. Conserva los datos raw y utiliza capas posteriores para staging y datasets preparados para consumo.
Schema Contract
Define tipos, columnas obligatorias, reglas de nullability y evolución de esquema antes de permitir que nuevos CSV entren directamente en tablas de consumo.
Idempotencia
Una ejecución repetida no debería producir datos duplicados. Utiliza claves naturales, identificadores de lote o estrategias de staging y MERGE cuando corresponda.
Observabilidad
Monitoriza duración, registros de entrada, registros rechazados, errores de transformación y filas finalmente cargadas.
IAM mínimo
Separa permisos de diseño y ejecución. Evita conceder roles amplios al servicio que ejecuta la pipeline cuando solo necesita acceso a determinados buckets y datasets.
Reutilización
Si varias cargas siguen el mismo patrón, parametriza rutas y destinos en lugar de duplicar pipelines. Cloud Data Fusion contempla pipelines reutilizables y argumentos para cambiar su configuración entre ejecuciones.
Google documenta el uso de pipelines reutilizables para parametrizar, entre otros elementos, entradas de Cloud Storage y destinos. :contentReference[oaicite:5]{index=5}
Checklist de implementación empresarial
Define el contrato de datos
Documenta columnas, tipos, obligatoriedad, claves, formato de fechas y comportamiento esperado ante datos inválidos.
Configura la landing zone
Crea la estructura de Cloud Storage para separar datos de entrada, históricos, procesados y errores.
Crea el pipeline Batch
En Cloud Data Fusion Studio selecciona el modo Data Pipeline - Batch y conecta el origen de Cloud Storage con las transformaciones y el sink.
Transforma y valida
Utiliza Wrangler para normalizar columnas y tipos. Añade validaciones antes de escribir en la tabla analítica.
Configura BigQuery
Selecciona dataset y tabla, define correctamente el esquema y decide si el patrón requiere append, overwrite, staging o una posterior operación MERGE.
Valida antes de desplegar
Utiliza Preview para comprobar los registros y detectar errores antes de promover la pipeline.
Automatiza la ejecución
Programa la pipeline o conéctala mediante triggers según la frecuencia de llegada de los ficheros.
Instrumenta FinOps
Controla el tiempo de vida de la instancia, duración de Spark, volumen procesado, operaciones de BigQuery y almacenamiento generado.
Una instancia de Cloud Data Fusion se crea en una región concreta y su edición debe elegirse al crearla; la documentación actual distingue Developer, Basic y Enterprise según necesidades de coste, concurrencia y RBAC. :contentReference[oaicite:6]{index=6}
FAQ: Cloud Data Fusion + BigQuery
¿Cómo importar un CSV de Cloud Storage a BigQuery con Cloud Data Fusion?
Crea una pipeline batch con Cloud Storage como source, utiliza Wrangler si necesitas transformar o validar los registros y termina con BigQuery como sink. Después valida, despliega y ejecuta la pipeline.
¿Necesito programar código para crear un pipeline ETL con Cloud Data Fusion?
No para el caso de uso ETL básico. Cloud Data Fusion utiliza plugins visuales para conectar fuentes, transformaciones y destinos. El código resulta útil cuando aparecen requisitos de transformación o automatización que no encajan bien en los plugins existentes.
¿Cuál es el principal riesgo de costes en un pipeline Cloud Data Fusion a BigQuery?
Considerar únicamente el coste de las consultas de BigQuery. El coste total también puede incluir la instancia de Cloud Data Fusion, los clusters de Managed Service for Apache Spark y recursos como Cloud Storage y networking. :contentReference[oaicite:7]{index=7}