Autor: Eduardo Martínez Agrelo
Bienvenidos al inicio de vuestro camino en el mundo de SCD Tipo 1 [4]. En este sexto módulo, sentaremos las bases de la sincronización incremental. No se trata solo de sobrescribir si un registro ha cambiado, sino de transformar eventos históricos en registros consolidados de verdad [4]. Utilizaremos Google Cloud para pasar de un modelo de adición inmutable a uno dinámico, eliminando la redundancia de datos y mejorando la fiabilidad del servicio.
La Evolución: De Carga Total a Carga Incremental
El procesamiento analítico tradicional basado en la reconstrucción completa de tablas ha llegado a su límite. En entornos con grandes volúmenes de datos e integraciones complejas, el consumo de computación es inabarcable para un presupuesto. La carga incremental surge como la respuesta necesaria:
- Limitaciones: Las cargas totales con sobreescritura (como el clásico delete e insert) generan demasiado gasto de procesamiento y picos de facturación.
- La Solución: El motor analítico de BigQuery permite identificar modificaciones, correlacionar eventos históricos y actualizar los registros modificados en su lugar sin afectar al resto de la tabla [1].
El Motor de la De-duplicación: Ventanas de Tiempo e Idempotencia
Para que nuestra capa Silver pueda consolidarse, necesita datos de-duplicados de calidad. En este curso trabajaremos sobre la de-duplicación analítica aplicando reglas de precedencia temporal:
ROW_NUMBER() OVER (PARTITION BY document_id ORDER BY event_timestamp DESC)
Aprenderemos que una tabla sin control de versiones históricas es inútil para la consistencia; por ello, nos enfocaremos en la generación de consultas de fusión estructuradas que sirvan como fuente de verdad para nuestros reportes analíticos y de negocio.
SCD Tipo 1 e Idempotencia con BigQuery SQL
En el modelado Silver, la eficiencia de carga empieza en la consulta. No ejecutamos actualizaciones descontroladas en las tablas; utilizamos GoogleSQL para crear un entorno incremental, de-duplicado y profesional:
- Dimensión de Clientes: Aplicaremos Slowly Changing Dimension Tipo 1 sobre silver.customers para consolidar de forma limpia los perfiles procedentes de Firestore [4].
- Hechos de Órdenes: Evitaremos la inserción de registros duplicados en silver.orders causados por reintentos de red durante cargas masivas de datos históricos.
Implementación práctica
En este laboratorio práctico, configurarás tu script de consolidación incremental aplicando sentencias MERGE [1].
Crearemos un archivo SQL llamado silver_customers_merge.sql que simulará el comportamiento de un motor de-duplicador durante las cargas.
Observarás cómo este script inyecta actualizaciones en tiempo real en los datos, creando la base perfecta para estructurar la capa Silver en los módulos siguientes,
y consolidando tu paso en este portafolio de GitHub.
Conclusión: Los cimientos de la incrementalidad
Has completado la fase de de-duplicación e incrementalidad. Has aprendido que mantener registros únicos no requiere reconstruir las tablas, sino una arquitectura bien diseñada basada en sentencias condicionales avanzadas [1]. Ya tienes el "upsert" listo en Google Cloud; el siguiente paso es conectar estos datos con reglas de calidad estrictas para empezar a filtrar registros corruptos antes de que lleguen a producción.