Logo Google Cloud con Eduardo

Google Cloud con Eduardo

Descarga el código de la lección

Información básica de protección de datos: Responsable: Eduardo Martínez Agrelo. Finalidad: Gestionar y facilitar la descarga del recurso solicitado. Legitimación: Consentimiento del interesado (Art. 6.1.a RGPD). Destinatarios: Proveedor de infraestructura técnica (Google Cloud / Firebase). Derechos: Acceso, rectificación y supresión en eduardomartinezagrelo@gmail.com.
Arquitectura Medallion en Google Cloud: Bronze, Silver y Gold con GCS y BigQuery
✦ Guía Técnica & Arquitectura

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

Desacoplamiento Total: Ingesta Raw sin transformar en GCS con retención inmutable y metadatos unificados.
Unificación con BigLake: Consultas externas sin duplicar almacenamiento ni penalizar el control de accesos.
CDC e Idempotencia: Patrón de deduplicación y MERGE incremental optimizado para la capa Silver.
FinOps & Poda: Reducción drástica de escaneo de bytes en BigQuery con clustering y vistas materializadas en Gold.
Google Cloud Storage BigQuery Native & BigLake Apache Iceberg / Parquet Cloud Workflows & Dataform Dataplex Catalog & Governance FinOps Optimization

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.

SQL (BigQuery Procedure) — bronze_to_silver_merge.sql Producción GCP
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

1

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).

2

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.

3

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.

4

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.

5

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)

¿Cuándo conviene mantener la capa Silver en GCS con BigLake en lugar del almacenamiento nativo de BigQuery?

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.

¿Cómo se previene el coste excesivo en BigQuery al procesar cargas incrementales de Bronze a Silver?

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.

¿Cuál es el impacto en latencia de usar vistas lógicas frente a tablas materializadas en la capa Gold?

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.

Sobre el Autor: Eduardo Martínez Agrelo

AI & Data Architect

Especialista en diseño de arquitecturas de datos a gran escala, plataformas Lakehouse y sistemas analíticos avanzados en Google Cloud Platform. Enfocado en la optimización de rendimiento, FinOps, gobernanza de datos y sistemas de inteligencia artificial en producción.