Incrementalidad en DBT como estándar en el Datalake de Mercadona IT

Autores

Jacobo Reyes Beltrán y Alejandro Mir Belert, junto al equipo técnico de la División de Informática del Dato — Mercadona IT

Resumen

El crecimiento sostenido del volumen de datos y de los casos de uso analíticos en Mercadona IT nos ha llevado a evolucionar los patrones tradicionales de procesamiento basados en full-refresh hacia modelos más eficientes, resilientes y sostenibles. En este contexto, la incrementalidad en DBT se ha consolidado como un estándar clave en las capas Bronze y Silver de nuestro Datalake sobre BigQuery.

Este post describe el enfoque adoptado para la implementación de incrementalidad, los criterios de diseño definidos, su encaje dentro de la arquitectura Medallion y los mecanismos operativos que lo hacen sostenible en el tiempo. El objetivo es compartir un caso de uso real que permita comprender cómo este modelo contribuye a mejorar el rendimiento, reducir costes y reforzar la calidad y disponibilidad del dato.

1. Introducción

En arquitecturas analíticas modernas, el procesamiento completo de los datos en cada ejecución (full-refresh) presenta limitaciones claras cuando el volumen, la frecuencia de actualización y la criticidad de los datos aumentan. Este enfoque impacta directamente en el coste de infraestructura, en los tiempos de procesamiento y en la capacidad de escalar la plataforma de forma controlada.

La incrementalidad surge como una evolución natural de estos modelos, permitiendo procesar únicamente los registros que cambian en origen. En Mercadona IT, hemos incorporado este patrón de forma progresiva en DBT, con el objetivo de estandarizar decisiones técnicas, mejorar la eficiencia operativa y garantizar la consistencia entre capas del Datalake.

2. Contexto arquitectónico

Nuestro Datalake corporativo se apoya en una arquitectura Medallion, estructurada en capas Bronze, Silver y Gold, sobre BigQuery. En este esquema:

• Bronze: actúa como capa de ingestión y estandarización inicial de los datos.
• Silver: refina la información, aplicando reglas de negocio básicas, deduplicación y control de cambios.
• Gold: expone los datos listos para consumo analítico y BI.

La incrementalidad se ha definido como un criterio transversal en Bronze y Silver, garantizando que el dato fluye de forma consistente, controlada y eficiente a lo largo de todo el flujo.

3. ¿Qué entendemos por incrementalidad?

Desde un punto de vista funcional, la incrementalidad permite evolucionar del procesamiento completo de tablas hacia un modelo capaz de gestionar:

• Inserciones de nuevos registros.
• Modificaciones de registros existentes.
• Borrados lógicos procedentes de los sistemas de origen.

Para ello, nuestro modelo se apoya en la gestión del ciclo de vida del dato mediante marcas temporales (timestamps), que permiten identificar qué información debe ser procesada en cada ejecución y asegurar la consistencia eventual entre capas.

4. Criterios de diseño y estandarización

Con el fin de evitar soluciones ad-hoc y asegurar decisiones homogéneas, hemos definido una serie de criterios comunes para la implementación de incrementalidad en DBT:

4.1 Gestión temporal del dato

Cada registro incorpora fechas relevantes que permiten identificar su estado y evolución:

• evented_at: momento en el que el evento es ingerido en BigQuery desde el conector.
• deleted_at: marca temporal asociada a un borrado lógico (tombstone).
• updated_at: instante en el que se ejecuta el proceso que transforma el dato.

Estas fechas constituyen la base para identificar cambios y garantizar la coherencia entre capas.

4.2 Estrategia de actualización

Realizamos la actualización de datos mediante estrategias MERGE basadas en claves primarias únicas, lo que permite:

• Mantener la trazabilidad de los registros.
• Evitar duplicidades.
• Gestionar de forma controlada inserciones, actualizaciones y borrados lógicos.

4.3 Optimización en BigQuery

En tablas de alto volumen, complementamos la incrementalidad con técnicas nativas de BigQuery:

• Particionado: Por fecha para limitar el volumen de datos leídos.
• Clustering: Por claves de negocio relevantes, mejorando el rendimiento de las operaciones de merge.

Estas decisiones permiten reducir significativamente el coste asociado a la lectura y procesamiento de datos.

4.4 Árbol de decisión de incrementalidad

No todos los orígenes ni todos los flujos presentan las mismas características. Por este motivo, se ha definido un árbol de decisión que guía al desarrollador en función de distintos escenarios (tipo de tópico, presencia de borrados, volumen, criticidad), asegurando una implementación coherente y alineada con el estándar corporativo.

5. Consistencia y calidad del dato

Uno de los principales retos al que nos enfrentamos con los modelos incrementales es el de garantizar la consistencia eventual entre capas. En este enfoque, se asegura que una capa procese la misma cantidad de información que en la capa anterior. Esto se implementa a través de establecer un límite superior a partir del cual no se procesa información de la capa anterior.

Además, la incrementalidad se acompaña de:

• Pruebas técnicas automáticas en DBT.
• Comparativas entre entornos en procesos de refactorización.
• Validaciones conjuntas con la capa Gold y el equipo de BI.

6. Operación y sostenibilidad del modelo

La incrementalidad no se concibe únicamente como un patrón técnico, sino como un modelo operativo sostenible. Para ello, se han definido mecanismos específicos en el Trabajo Rutinario (TR) del Datalake:

• Monitorización y observabilidad de conectores, tópicos Kafka y DAGs en Composer.
• Planes de actuación frente a incidencias (DLQs, cambios de esquema, consumo de recursos).
• Capacidad de desactivar incrementalidad y orquestar full-refresh de forma controlada cuando es necesario.

Este enfoque nos permite anticiparnos a problemas, reducir tiempos de resolución y mantener la plataforma preparada para escalar.

7. Impacto en eficiencia y costes

La adopción de incrementalidad ha supuesto una mejora directa en:

• Reducción del volumen de datos procesados por ejecución.
• Mejora de los tiempos de disponibilidad del dato.
• Optimización del coste asociado a BigQuery.

8. Conclusiones

La incrementalidad en DBT se ha consolidado como un pilar clave en la evolución del Datalake de Mercadona IT. Más allá de una mejora técnica puntual, representa un cambio en la forma de diseñar, operar y escalar los pipelines de datos.

Este modelo aporta:

• Arquitectura estandarizada y decisiones consistentes.
• Mejores SLAs en disponibilidad y calidad del dato.
• Una plataforma más eficiente, robusta y sostenible.

Seguimos teniendo margen de mejora, la experiencia adquirida nos demuestra que la combinación de método, estandarización y control operativo es clave para seguir impulsando una cultura de ingeniería del dato orientada a la calidad y la eficiencia.

9. Referencias

Las decisiones técnicas y los patrones descritos en este documento se apoyan en buenas prácticas ampliamente adoptadas en arquitecturas analíticas modernas y en la documentación oficial de las tecnologías utilizadas:

• dbt Labs — Incremental Models. Documentación oficial sobre modelos incrementales, estrategias de actualización y patrones recomendados para la gestión de grandes volúmenes de datos.
• Google Cloud — BigQuery Documentation. Guías oficiales sobre particionado, clustering, costes de consulta y optimización del rendimiento en BigQuery.
• Google Cloud — Medallion Architecture. Referencias sobre el uso de arquitecturas por capas (Bronze, Silver, Gold) para la gestión progresiva del dato.
• Apache Kafka Documentation. Conceptos relacionados con eventos, gestión de borrados lógicos (tombstones) y consistencia en flujos de datos.
• Data Engineering Best Practices. Publicaciones y guías de referencia sobre diseño de pipelines escalables, consistencia eventual y control del ciclo de vida del dato.

Estas fuentes constituyen la base conceptual sobre la que se ha construido y adaptado el enfoque de incrementalidad descrito, contextualizándolo a las necesidades y particularidades del entorno de Mercadona IT.

Agradecimientos

Agradecemos a Jesús Soler Tomás (Coordinador Técnicos del Dato) y a Carlos Barberá Domingo (Coordinador División de Informática del Dato) el apoyo, el tiempo y el espacio para compartir y contrastar este enfoque dentro de División de Informática del Dato.