Arquitectura Medallion en Google Cloud: Bronze, Silver y Gold con GCS y BigQuery
Descubre cómo estructurar un Data Lakehouse de nivel empresarial en GCP desacoplando almacenamiento inmutable en Google Cloud Storage y cómputo de alta concurrencia en BigQuery mediante BigLake, particionamiento y clustering. Si quieres ver la evolución desde un Data Lake crudo hasta la capa analítica final, te conviene seguir con la guía de construcción de un Data Warehouse con Google Antigravity y Medallion.
Objetivos de la Arquitectura
Topología de la Arquitectura Medallion en GCP
El patrón Medallion (Bronze ➔ Silver ➔ Gold) organiza los datos en capas incrementales de calidad y estructura. En el ecosistema de Google Cloud Platform, la implementación óptima combina la flexibilidad y bajo coste de Google Cloud Storage (GCS) con la potencia de indexación, caching y cómputo distribuido de BigQuery.
| Capa Medallion | Tecnología Base | Formato / Almacenamiento | Gobernanza / SLAs | Patrón de Consumo |
|---|---|---|---|---|
| Bronze (Raw) | GCS Buckets (Standard/Nearline) | JSON, Avro, CSV, Parquet Crudo (Append-only) | Inmutabilidad (Object Lock), retención definida | BigLake External Tables, batch pipelines de transformación |
| Silver (Conformed) | BigQuery Native o BigLake (Iceberg) | Esquema tipado, limpio, deduplicado (CDC aplicado) | Control de acceso por columna/fila (Dataplex) | Data Engineers, Data Scientists, consultas exploratorias ad-hoc |
| Gold (Curated) | BigQuery Native Storage + BI Engine | Modelos dimensionales (Kimball), Vistas Materializadas | Máximo SLA, indexación semántica estricta | Dashboards ejecutivos (Looker), APIs analíticas, ML Feature Store |
⚠️ Antipatrón Crítico & Fuga FinOps en Producción
El error: Consultar ficheros crudos directamente en GCS mediante tablas externas tradicionales de BigQuery sin metadatos cacheados para servir dashboards de analítica.
El impacto: Cada ejecución realiza un listado exhaustivo de objetos en el bucket de GCS y un escaneo no indexado de archivos, provocando un consumo descontrolado de slots y tiempos de latencia erráticos.
La solución arquitectónica: Implementar BigLake con aceleración de metadatos habilitada (Metadata Caching) para Bronze/Silver, y forzar la materialización con clustering multidimensional en tablas nativas de BigQuery para la capa Gold.
Pipeline Incremental Idempotente: Bronze a Silver en BigQuery
A continuación se muestra un procedimiento SQL de producción que ingesta eventos CDC crudos alojados en una tabla BigLake (Bronze) y realiza un MERGE idempotente con deduplicación por ventana temporal sobre la tabla concurrida (Silver), aplicando poda de particiones estricta.
CREATE OR REPLACE PROCEDURE `empresa_lakehouse.silver_layer.sp_merge_customer_events`(
IN p_processing_date DATE
)
BEGIN
-- 1. Declaración de variables de control
DECLARE v_records_updated INT64 DEFAULT 0;
-- 2. Ejecución del MERGE incremental idempotente
MERGE INTO `empresa_lakehouse.silver_layer.dim_customers` AS target
USING (
WITH deduplicated_bronze AS (
SELECT
customer_id,
email,
country_code,
account_status,
updated_at,
ingestion_timestamp,
-- Deduplicación determinista: última versión por clave de negocio
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY updated_at DESC, ingestion_timestamp DESC
) AS row_rank
FROM `empresa_lakehouse.bronze_layer.ext_gcs_raw_customer_events`
-- Pruning estricto en la tabla BigLake / Externa
WHERE _PARTITIONDATE = p_processing_date
)
SELECT
customer_id,
email,
country_code,
account_status,
updated_at,
p_processing_date AS partition_date
FROM deduplicated_bronze
WHERE row_rank = 1
) AS source
ON target.partition_date = source.partition_date
AND target.customer_id = source.customer_id
-- 3. Actualización de registros mutados
WHEN MATCHED AND source.updated_at > target.updated_at THEN
UPDATE SET
target.email = source.email,
target.country_code = source.country_code,
target.account_status = source.account_status,
target.updated_at = source.updated_at,
target.last_modified_timestamp = CURRENT_TIMESTAMP()
-- 4. Inserción de nuevas entidades
WHEN NOT MATCHED THEN
INSERT (
customer_id,
email,
country_code,
account_status,
updated_at,
partition_date,
created_timestamp,
last_modified_timestamp
)
VALUES (
source.customer_id,
source.email,
source.country_code,
source.account_status,
source.updated_at,
source.partition_date,
CURRENT_TIMESTAMP(),
CURRENT_TIMESTAMP()
);
END;
Patrones de Diseño y Directrices de Gobernanza
Para que un Lakehouse sobre GCP alcance madurez empresarial, deben observarse cuatro pilares arquitectónicos esenciales:
1. Ingesta Inmutable y Gestión de Ciclo de Vida (GCS)
La capa Bronze en GCS debe organizarse mediante rutas de partición compatibles con Hive (ej. gs://bucket-bronze/dominio/año=YYYY/mes=MM/dia=DD/). Configure Object Lifecycle Management para transicionar automáticamente archivos con más de 90 días a Cloud Storage Coldline/Archive, garantizando cumplimiento regulatorio a costes mínimos.
2. Unificación y Seguridad de Metadatos con Dataplex
Utilice Dataplex como plano de control unificado para orquestar zonas de datos lógicas sobre buckets de GCS y datasets de BigQuery. Defina políticas de etiquetado de datos (Policy Tags) para habilitar enmascaramiento dinámico (Data Masking) y control de acceso granular por columna en Silver y Gold sin alterar el código de las consultas.
3. Particionamiento y Clustering Compuesto
En BigQuery Silver y Gold, establezca particionamiento temporal (por ejemplo, TIMESTAMP_TRUNC(event_time, DAY)) combinado con clustering sobre hasta 4 campos de alta cardinalidad (ej. tenant_id, customer_id, status). Esto permite al optimizador de BigQuery omitir bloques de datos irrelevantes de forma instantánea.
Framework de Implementación en 5 Fases
Aprovisionamiento de Infraestructura como Código (Terraform)
Despliegue buckets GCS con cifrado CMEK, datasets de BigQuery segregados por capa y las conexiones de servicio de BigLake (Service Accounts delegadas).
Configuración de Tablas BigLake sobre GCS Bronze
Defina tablas externas con formato Parquet/Iceberg habilitando metadata_cache_mode = 'AUTOMATIC' para acelerar el descubrimiento de esquemas.
Orquestación Incremental de Transformaciones (Silver)
Programe pipelines en Dataform o Cloud Workflows que ejecuten procedimientos almacenados tipo MERGE con validación de calidad de datos intermedia.
Modelado Semántico y Materialización (Gold)
Genere modelos de estrella o vistas materializadas de autoservicio optimizadas con reservas de BigQuery BI Engine para latencias submétricas.
Auditoría FinOps y Gobernanza Continua
Monitoree el consumo de bytes escaneados a través de las tablas INFORMATION_SCHEMA.JOBS_BY_PROJECT y configure alertas presupuestarias en Cloud Billing.
Preguntas Frecuentes (FAQ)
Conviene mantener Silver en GCS (mediante formatos abiertos como Parquet o Iceberg) con BigLake cuando existen motores de cómputo externos heterogéneos (ej. Dataproc/Spark, Trino, Vertex AI) que necesitan consultar los datos sin incurrir en costes de exportación o duplicación de almacenamiento, manteniendo al mismo tiempo el control de acceso unificado y la aceleración de metadatos de BigQuery.
Se previene aplicando particionamiento estricto por fecha de ingestión en Bronze/Silver, combinando sentencias MERGE con predicados de poda de particiones (Partition Pruning) y utilizando clustering sobre las claves de unión de negocio para evitar full-table scans durante el proceso de deduplicación y CDC.
Las vistas lógicas recalculan las transformaciones y agregaciones en cada consulta, lo que incrementa el consumo de slots y la latencia. Las tablas físicas o vistas materializadas con refresco incremental optimizan los tiempos de respuesta a milisegundos para herramientas de BI, reduciendo drásticamente el escaneo de bytes en entornos analíticos concurrentes.
