Tu primer Data Lake en Google Cloud con Antigravity paso a paso
Construir un Data Lake escalable y desacoplado ya no requiere semanas de configuración manual ni cientos de líneas de código escritas desde cero. En esta guía arquitectónica analizamos cómo orquestar un pipeline de datos completo en Google Cloud Platform —desde la ingesta en bruto mediante Cloud Functions y Cloud Storage, hasta su analítica en BigQuery y Looker Studio con Terraform— aprovechando la potencia del desarrollo agéntico con Google Antigravity.
Puntos Clave del Pipeline
Matriz de Decisión: Patrones de Ingesta y Consulta en GCP
Al diseñar la arquitectura de un Data Lake en Google Cloud, elegir entre almacenamiento nativo, virtualización externa o ingesta por lotes define el coste de infraestructura (FinOps) y la latencia analítica:
| Patrón Arquitectónico | Almacenamiento | Latencia Ingesta | Coste de Storage | Rendimiento SQL (OLAP) | Caso de Uso Recomendado |
|---|---|---|---|---|---|
| Raw Data Lake + External Table (Implementado) | GCS (JSON / Parquet) | Segundos / Minutos | Mínimo (~$0.02/GB/mes) | Medio (Escaneo bajo demanda) | Capas de ingesta bruta, exploración ágil y datasets históricos. |
| Managed BigQuery Table | BigQuery Capacitor | Minutos (Batch Load) | Estándar BigQuery Storage | Ultra Alto (Optimizado en columnas) | Data Warehouses de producción y consumo intensivo de BI. |
| BigQuery Storage Write API | BigQuery Capacitor | Milisegundos (Streaming) | Coste de almacenamiento + Ingesta por MB | Ultra Alto | Detección de fraude, telemetría IoT y analítica en tiempo real. |
Antipatrones Comunes y Consideraciones FinOps
⚠️ Antipatrón: Duplicación Temprana de Almacenamiento
Cargar directamente datos en bruto a tablas gestionadas de BigQuery sin una capa intermedia en Cloud Storage provoca un consumo innecesario de almacenamiento estructurado y dificulta el re-procesamiento histórico ante cambios de esquema (Schema Drift).
Solución: Persistir siempre el payload crudo en Cloud Storage bajo un bucket versionado y utilizar BigQuery External Tables. De este modo, BigQuery sólo factura por los bytes escaneados durante las consultas, sin coste de carga ni almacenamiento redundante.
💡 FinOps Tip: Control de Autenticación OIDC en Scheduler
Configurar funciones HTTP públicas para ser invocadas por Cloud Scheduler abre vectores de vulnerabilidad y riesgo de denegación de servicio que disparan la factura. Emplea siempre Service Accounts dedicadas con el rol roles/cloudfunctions.invoker o roles/run.invoker y tokens OIDC configurados en el Terraform.
Implementación de Producción con Terraform
A continuación se detalla la infraestructura declarativa completa en Terraform generada por el agente de Antigravity para orquestar el bucket de ingesta, el despliegue de la Cloud Function, la programación en Cloud Scheduler y el enlace de la tabla externa en BigQuery:
# 1. Bucket de almacenamiento para la capa Raw del Data Lake
resource "google_storage_bucket" "datalake_bucket" {
name = "demo-datalake-raw-${var.project_id}"
location = var.region
uniform_bucket_level_access = true
force_destroy = true
}
# 2. Dataset analítico en BigQuery
resource "google_bigquery_dataset" "bitcoin_data" {
dataset_id = "bitcoin_data"
friendly_name = "Bitcoin Analytics Dataset"
location = var.region
default_table_expiration_ms = null
}
# 3. BigQuery External Table apuntando a los archivos JSON del Data Lake
resource "google_bigquery_table" "bitcoin_prices_raw" {
dataset_id = google_bigquery_dataset.bitcoin_data.dataset_id
table_id = "bitcoin_prices_raw"
external_data_configuration {
autodetect = true
source_format = "NEWLINE_DELIMITED_JSON"
source_uris = [
"${google_storage_bucket.datalake_bucket.url}/*.json"
]
}
depends_on = [google_bigquery_dataset.bitcoin_data]
}
# 4. Trigger de ejecución programada con Cloud Scheduler (Ejecución Diaria)
resource "google_cloud_scheduler_job" "daily_trigger" {
name = "daily-bitcoin-price-trigger"
description = "Orquestador diario de ingesta hacia el Data Lake"
schedule = "0 9 * * *" # Todos los días a las 09:00 UTC
time_zone = "UTC"
attempt_deadline = "320s"
http_target {
http_method = "POST"
uri = google_cloudfunctions2_function.price_fetcher.service_config[0].uri
oidc_token {
service_account_email = var.service_account_email
}
}
}
Patrones de Diseño y Buenas Prácticas
1. Particionamiento y Formato de Almacenamiento
Para entornos de gran escala, almacena los objetos en GCS siguiendo particiones jerárquicas como gs://bucket/data/year=YYYY/month=MM/day=DD/data.json. BigQuery External Tables permite mapear automáticamente las claves del path como columnas particionadas con Hive Partitioning Options, reduciendo drásticamente el escaneo de datos.
2. Idempotencia y Backfilling Histórico
El pipeline implementa funciones con nombre de archivo determinista (basado en timestamp/fecha). Esto garantiza que la ejecución manual de un script de backfilling para recuperar meses o años pasados no duplique registros ni corrompa el catálogo de datos.
3. Capa de Visualización desacoplada
Al conectar Looker Studio a BigQuery mediante consultas directas a la External Table, los cuadros de mando obtienen acceso a datos frescos sin necesidad de intermediar con procesos de sincronización ETL complejos.
Framework de Despliegue Paso a Paso
- Definición del Plan con Antigravity: Indicar al agente conversacional el origen de datos (API pública), la arquitectura requerida y los componentes serverless a generar.
-
Generación de Código e IaC: Revisión del
main.py(extracción del payload y subida a GCS) y manifiestos de Terraform (Storage, Functions, Scheduler, BigQuery). -
Despliegue de Infraestructura: Ejecución de
terraform inityterraform applyen el proyecto GCP de destino. - Backfill y Prueba de Ingesta: Ejecutar el script de carga histórica para poblar el bucket con datos pasados y validar la respuesta en los logs de Cloud Logging.
- Validación SQL y Cuadro de Mando: Ejecutar consultas SQL en BigQuery sobre la External Table y modelar el gráfico de series temporales en Looker Studio.
Preguntas Frecuentes (FAQ)
Las External Tables permiten virtualizar datos crudos alojados en Cloud Storage sin incurrir en costes dobles de almacenamiento ni en latencias de carga por lotes (Load Jobs). Es el desacoplamiento ideal entre almacenamiento y cómputo para la capa de ingesta bruta (Raw Zone).
Google Antigravity genera planes de implementación completos y cohesivos: resuelve simultáneamente el código de ingesta en Python, los scripts de backfilling y los manifiestos de Terraform, reduciendo el tiempo de prototipado y despliegue de días a minutos.
Configurando Cloud Scheduler con tokens de autenticación OIDC vinculados a una Service Account con los privilegios mínimos necesarios (roles/run.invoker o roles/cloudfunctions.invoker), garantizando acceso seguro y cerrado al tráfico público.
