¡Buenas y santas, estimados lectores! Y sean bienvenidos a la tercera y última nota de esta serie sobre el maravilloso mundo de DBT. En las entregas anteriores, exploramos en profundidad cómo estructurar la data en las capas iniciales de un proyecto de DBT: los modelos de staging para unificar la data y los modelos intermedios que aplican lógica de negocio para realizar transformaciones a esos datos.

En esta nota, vamos a ver el estadío final de esas transformaciones: la capa de marts, el lugar donde la data está disponible para ser consumida, lista para el negocio y útil para hacer analítica avanzada o usarla con herramientas de BI.

¿Qué es un mart en DBT?

Un mart es la capa final y curada de nuestro data warehouse, representada al igual que el resto de los componentes de nuestro proyecto por un archivo .sql que contiene una selección de columnas. Su propósito es exponer datasets limpios, confiables y con orientación de negocio que los analistas y usuarios de negocio pueden consumir directamente.

A diferencia de los modelos de staging e intermedios que se enfocan en la integridad de la data y transformaciones lógicas, los marts se enfocan en usabilidad.

Por eso, representan la culminación de todo el trabajo de modelado que fuimos haciendo hasta ahora. Es donde nuestras transformaciones dejan de ser simplemente decisiones de estructuras de datos y pasan a ser apoyos para la toma de decisiones, seguimiento de performance, monitoreo de riesgo o análisis de resultados de negocio.

Los marts típicamente son desnormalizados, es decir, consolidan información de múltiples intermedios en una única tabla de mayor tamaño. Cada registro representa una entidad de negocio clara -como un préstamo, cliente o transacción-, enriquecida con KPIs o métricas agregadas y listas para visualizarlas en un dashboard de BI o consumir para un modelo de machine learning.

Por esto es que un mart bien diseñado muchas veces se parece mucho a un documento de negocio más que a un artefacto técnico. Seguramente una persona que no tenga conocimientos de SQL no pueda interpretar en profundidad un intermedio, pero un mart debe ser claro y comprensible. Los nombres de las columnas deberían ser legibles y claros (total_disbursed_amount en vez de td_amt) y la tabla resultante debe alinear cómo el negocio piensa en sus operaciones. En esencia, los marts toman pipelines de data complejos y los convierte en datasets accesibles y confiables.

Veamos un ejemplo de un mart simple:

Este mart joinea varias fuentes de datos intermedias para producir una visión final y unificada de la performance de un crédito de una hipotética fintech. El resultado es este dataset limpio, prolijo y listo para realizar analíticas y que puede alimentar reportes financieros, análisis de riesgo y dashboard de operaciones.

De pordiosero a KPI: el camino del linaje de los datos

La capa de mart es la conclusión natural de la jerarquía de modelos de DBT, que se ve así:

Raw → Staging → Intermediate → Mart

Cada uno de estos pasos depende de la calidad del anterior. Staging maneja las transformaciones esenciales, como limpieza de columnas, casteo de tipos de datos y eliminación de registros duplicados. Los modelos intermedios agregan lógica de negocio, como cálculos de KPIs claves para la operatoria. Y por último, la capa de mart unifica todo lo disponibiliza.

En DBT, podemos ver este linaje de fuentes y transformaciones mediante el uso del comando dbt docs generate. Al ejecutarlo, veremos algo similar a esto:

raw_customer_data → stg_customers → int_loans_data → mart_loans

Esta trazabilidad visual, altamente simplificada para este ejemplo, es una de las características más potentes de DBT. Nos asegura que cada métrica de negocio puede ser recorrida de principio a fin, desde su fuente hasta su mart, y darnos tranquilidad y transparencia en el proceso de análisis.

¿Qué hace a un buen mart?

El diseño de los marts requiere especial atención a temas como nomenclatura, organización de schemas y definición de tests. Estos aspectos son los que separan a un modelo funcional de uno sustentable y listo para salir a la cancha de producción.

Desde una perspectiva de nomenclatura, los marts deben ser fácilmente identificables, por lo que usar sufijos o prefijos como _mart o mart_ ayudan a distinguirlos claramente. Además, deberían contener algo en su nombre que nos indique su uso en el negocio. Un buen nombre podría ser mart_loan_performance.sql. 

La organización de schemas es igualmente importante. Mantener los marts en un schema dedicado (usualmente llamado, adivinaron, marts) ayuda a mantener la organización de los componentes de nuestros pipelines de datos dentro de nuestro data warehouse. Esto simplifica también la asignación de permisos, ya que los marts suelen ser el único schema expuesto a analistas BI. En nuestro dbt_project.yml (que ya lo vimos en notas anteriores), esto se puede configurar así:

Data quality siempre tiene que ser un tema en nuestra cabeza, más cuando estamos trabajando con transformaciones tan complejas. Por eso, los tests son un componente fundamental de cualquier proyecto de DBT maduro y bien diseñado. Con ese fin, podemos agregar tags a nuestros marts en el .yaml de proyecto que nos ayuden a discernir los marts críticos para cada operación de negocio:

E incluso podemos seguir definiendo tests específicos que garanticen la calidad de los datos y que las transformaciones que hayamos hecho para llegar acá o que realicemos en el futuro sigan cumpliendo nuestros estándares de data, con el fin de evitar errores costosos o que nos lleven a tomar malas decisiones de negocio.

Performance a punto caramelo

Como los marts gestionan y manejan data agregada o histórica, la optimización de performance de nuestros procesos es fundamental para mantener la eficiencia y escalabilidad de nuestro proyecto a medida que aumenta también nuestro caudal de datos. Afortunadamente, DBT ofrece varias opciones de materialización que determinan cómo se construyen y almacenan nuestros modelos.

Por ejemplo, para marts pequeños o medianos, la materialización de tipo table suele ser más que suficiente. Lo que hace es recrear la tabla cada vez y nos garantiza la consistencia del resultado final a costa de tiempos de construcción un poco más largos. En cambio, para datasets grandes, es preferible la lógica de incremental, ya que sólo procesa la información nueva o actualizada en cada corrida del proceso.

Una configuración típica de mart incremental se ve de la siguiente manera:

Inclusive, si estamos trabajando en data warehouses que lo permiten (como Google BigQuery o Amazon Redshift), podemos optimizar incluso más nuestro proceso mediante la definición de estrategias de particionado y clustering:

Este tipo de configuraciones pueden mejorar significativamente la performance de nuestras queries, especialmente para dashboards o queries analíticas que se ejecutan con regularidad. El particionado ayuda a aislar la data más reciente para actualizaciones de incrementales más veloces, mientras que el clústering mejora la performance del filtrado y joineo.

¿Y la docu?

Finalmente, llegamos al punto cúlmine de todo proyecto… ¡la documentación! Sin documentación, cualquier persona que quiera ingresar a nuestro proyecto y quiera entender de qué se trata, o simplemente tenga una duda general sobre su estructura, va a estar en serios problemas.

En DBT, la documentación es lo que transforma a un mart de una tabla usable a un data asset compartido por toda la organización. Afortunadamente, también nos facilita mucho el proceso de documentación, ya que está embebida directamente en el proyecto. Esto nos garantiza que el contexto de negocio se transmite en simultáneo con las definiciones técnicas.

¿A qué me refiero con esto? Cada mart individual debería tener un archivo schema.yml que describa su propósito, las columnas que contiene y las métricas claves. Por ejemplo:

Esto ya de por sí es muy útil, pero podemos ir un paso más allá: una vez definido este archivo y con la documentación en su lugar, podemos generar un sitio interactivo y navegable usando los siguientes comandos:

dbt docs generate
dbt docs serve

Esto, como por arte de magia código, crea un catálogo de datos con gráficos de linaje, descripción de columnas y sus relaciones. No hace falta aclarar que esto es un recurso invaluable para para analistas, ingenieros de datos y usuarios de negocio por igual: no sólo ayuda a entender qué contiene cada mart, sino que también muestra cómo llegamos a los números finales que exponemos en nuestros marts.

Hasta aquí hemos llegado…

Antes que nada, queridos lectores, quiero agradecerles por haber llegado hasta acá. Fueron tres notas con mucho desarrollo conceptual y técnico, con mucha demo y snippet de código, pero creo que aprender a usar un framework tan flexible y útil como DBT debería estar en el arsenal de cualquier data developer hoy en día. Tiene la ventaja de ser SQL simple y de ser legible, mantenible, y escalable. Espero que hayas visto que es una herramienta fundamental en el ecosistema de datos moderno, y que la puedas incorporar en tu día a día.