De caja negra a plano maestro: cómo dbt domestica la arquitectura moderna de datos

Como mencionamos en anteriores publicaciones, el data lakehouse y la Arquitectura Medallion son nuestros planos fundamentales. Entendemos el valor de este enfoque por capas: los datos en bruto llegan a la capa Bronce, se limpian y se conforman en la capa Plata, y finalmente se modelan en agregados listos para el negocio en la capa Oro.

Esta arquitectura nos brinda un framework sólido y escalable para organizar nuestros datos. Proporciona un camino claro y lógico para que los datos fluyan desde la ingesta hasta la obtención de información. Tenemos claramente definido el “qué” y el “dónde” de nuestras capas de datos.

Sin embargo, tener datos bien estructurados es solo la mitad de la batalla. A medida que nuestras canalizaciones crecen en número y complejidad, la semántica de esos datos se vuelve difusa. Aunque sabemos dónde reside nuestra tabla gold_customer_lifetime_value, la historia de cómo fue construida a menudo se pierde. La intrincada red de transformaciones, lógica de negocio y dependencias que conecta una fuente en bruto con un KPI crítico sigue siendo una caja negra, documentada únicamente en fragmentos dispersos de scripts SQL o, peor aún, en la memoria de un antiguo colega. Es aquí donde comienzan a aparecer las grietas en nuestra arquitectura, por lo demás perfecta.

La Arquitectura Medallion nos da un excelente mapa del destino de nuestros datos, pero no nos dice nada sobre el viaje. En un entorno real, el camino de Bronce a Oro rara vez es una línea recta. Es una red compleja de transformaciones y, sin un marco adecuado para gestionarla, esa red se convierte rápidamente en un enredo frágil y difícil de mantener.

Veamos los problemas específicos que surgen de esta “caja negra de transformaciones”:

1. El Déficit de Confianza Imagina que un líder de negocio pregunta: “Veo que el KPI de ‘Ingresos Trimestrales’ en el dashboard bajó un 5%. ¿Puedes explicar por qué?” En una arquitectura opaca, responder a esa pregunta se convierte en una excavación arqueológica. Primero hay que encontrar el script SQL que materializó la tabla Oro, luego rastrear las transformaciones de la capa Plata y finalmente intentar mapearlas a las fuentes Bronce. Es un proceso lento, propenso a errores y que a menudo termina con una respuesta incierta: “Creo que es por cómo estamos gestionando las devoluciones de la tienda de la UE.” Cuando el linaje de las métricas críticas no está claro, la confianza en los datos se erosiona—no solo para los usuarios de negocio, sino también para los propios equipos de datos.
2. El Efecto Castillo de Naipes Los datos no son estáticos. La lógica de negocio cambia, los sistemas de origen se actualizan y surgen nuevos requisitos. En un mundo donde las transformaciones son solo un conjunto de scripts SQL desconectados, hacer un cambio sencillo se siente como jugar al Jenga. ¿Necesitas añadir una nueva columna a una tabla Plata central? Tienes que identificar manualmente todas las tablas Oro que dependen de ella, actualizar su código y rezar para no haber pasado por alto ninguna. Un solo error puede derribar una cascada de dashboards críticos. Esta fragilidad hace que el desarrollo sea lento y arriesgado, sofocando la agilidad que el lakehouse promete.
3. El Cuello de Botella en la Colaboración Cuando la lógica de transformación vive en cuadernos personales o en scripts oscuros dentro de un repositorio Git, se crean silos de conocimiento. El “experto” en datos de clientes se convierte en la única persona capaz de modificar los modelos de forma segura. Esto genera un cuello de botella para todo el equipo. Incorporar a un nuevo ingeniero significa semanas, si no meses, de aprender reglas no escritas y descifrar código críptico. No existe una única fuente de verdad sobre cómo se define el negocio en los datos, lo que lleva a lógica inconsistente y trabajo duplicado, ya que distintos ingenieros resuelven el mismo problema de maneras diferentes.

En esencia, aunque nuestra arquitectura de almacenamiento (lakehouse) es moderna y escalable, nuestra arquitectura de transformaciones sigue siendo primitiva. Estamos intentando construir un rascacielos sobre unos planos dispersos. Lo que necesitamos con urgencia es un marco que trate la lógica de transformación como un ciudadano de primera clase, que aporte estructura, visibilidad y fiabilidad a la parte más crítica de nuestra canalización de datos. Necesitamos una forma de gestionar el “cómo” y el “por qué” con el mismo rigor que aplicamos al “qué” y al “dónde.”

Si el problema es la falta de estructura y visibilidad en nuestras transformaciones, la solución es una herramienta que trate esa lógica como un ciudadano de primera clase dentro de nuestra arquitectura de datos. Aquí entra en juego dbt (data build tool).

Entonces, ¿qué es exactamente dbt?

En esencia, dbt es un flujo de trabajo de transformación open-source que permite a los equipos de datos construir, probar y documentar modelos de manera colaborativa directamente dentro de su data warehouse o lakehouse. No es una nueva base de datos ni una herramienta de movimiento de datos. Es un marco que trae las mejores prácticas de la ingeniería de software al mundo de la analítica de datos. dbt adopta el paradigma moderno de ELT: primero Extraes los datos, luego los Cargas en tu almacén, y finalmente los Transformas en el lugar con dbt.

dbt resuelve los problemas que mencionamos cambiando de forma fundamental cómo escribimos y gestionamos nuestra lógica de transformación.

1. Restaurar la Confianza con Documentación y Linaje Automáticos: ¿Recuerdas el “Déficit de Confianza”? dbt lo elimina al hacer que el linaje y la documentación de los datos sean parte nativa del proceso de desarrollo. Cuando escribes un modelo en dbt, no solo estás creando un script SQL; estás definiendo un nodo en un grafo. Usando funciones simples como ref() para referenciar otras tablas, dbt entiende automáticamente toda la cadena de dependencias.

Con un solo comando, dbt docs generate, dbt analiza tu proyecto completo, inspecciona el almacén y produce un sitio de documentación interactivo. Este sitio muestra:

• Todas las tablas y columnas del proyecto.
• El código SQL exacto usado para crear cada modelo.
• Un grafo visual de dependencias (DAG) que te permite rastrear cualquier tabla Oro hasta sus fuentes Bronce.

Responder a “¿Por qué cambiaron los ingresos?” deja de ser una excavación arqueológica y se convierte en una exploración con unos pocos clics.

2. Reemplazar el Castillo de Naipes con un DAG Resiliente: El “Efecto Castillo de Naipes” se mitiga gracias a la innovación central de dbt: el grafo acíclico dirigido (DAG). Cuando ejecutas dbt run, dbt no corre tus modelos en orden aleatorio. Analiza las dependencias definidas con ref() y construye un DAG, ejecutando cada modelo solo después de que todos sus padres se hayan completado con éxito.

Esto significa que puedes modificar con confianza una tabla Plata central. dbt identificará y reconstruirá automáticamente todos los modelos descendientes que dependan de ella, garantizando consistencia en todo tu ecosistema de datos. Además, el marco de pruebas integrado de dbt te permite asegurar la calidad de los datos (por ejemplo, que customer_id nunca sea nulo, o que order_date sea siempre una fecha válida) y detectar errores antes de que lleguen a la capa Oro.

3. Romper los Cuellos de Botella con un Marco Colaborativo: dbt aborda el “Cuello de Botella en la Colaboración” proporcionando una estructura de proyecto estandarizada y modular. Te anima a pensar en términos de componentes reutilizables. En lugar de copiar y pegar lógica compleja, puedes crear macros que se usan en todo el proyecto. Esto genera una única fuente de verdad para la lógica de negocio.

Los nuevos miembros del equipo pueden ponerse al día rápidamente leyendo la documentación generada automáticamente y entendiendo la estructura modular del proyecto. Las revisiones de código se vuelven significativas porque los cambios se realizan dentro de un contexto estructurado, no en un conjunto de scripts improvisados. dbt convierte la transformación de datos de un acto solitario de “magia” en una disciplina de ingeniería colaborativa.

En resumen, dbt es la pieza que faltaba en la arquitectura moderna de datos. Proporciona la capa semántica, la gobernanza y el rigor operativo necesarios para transformar un lakehouse bien organizado de un simple repositorio de datos en un motor confiable, escalable y digno de confianza para la inteligencia de negocio.

Veamos cómo funciona en la práctica. Imagina que tenemos datos de pedidos de e‑commerce en bruto que llegan a nuestra capa Bronce. Queremos crear una tabla limpia y agregada en la capa Oro que muestre el importe total de pedidos por cliente.

Así es como lo modelaríamos usando dbt.

Paso 1: La Capa Plata – Preparando los Datos en Bruto

Primero, creamos un modelo de staging para limpiar y preparar nuestros datos en bruto. Este modelo leerá de nuestra fuente orders y aplicará transformaciones básicas.

models/staging/stg_orders.sql

-- Este modelo limpia nuestros datos de pedidos en bruto.
-- Renombramos columnas para mayor claridad, convertimos tipos de datos y filtramos datos inválidos.

select
    order_id,
    user_id as customer_id, -- Renombrado para consistencia
    order_date,
    status,
    -- Convertimos el precio a tipo numérico y manejamos posibles errores
    safe_cast(amount as numeric(10, 2)) as order_amount,

from {{ source('raw_ecommerce', 'orders') }} -- Referencia a los datos Bronce

where status not in ('returned', 'cancelled') -- Solo queremos pedidos completados

Este sencillo archivo SQL ya es un modelo dbt. Hemos renombrado columnas, convertido tipos de datos y filtrado pedidos irrelevantes, creando una tabla confiable stg_orders en nuestra capa Plata.

Paso 2: La Capa Oro – Creando Valor de Negocio

Ahora, creamos nuestro modelo Oro. Este modelo no leerá directamente de los datos en bruto, sino que se construirá sobre nuestro modelo Plata limpio usando la función ref().

models/marts/fct_customer_orders.sql

-- Este modelo agrega datos de pedidos por cliente para analítica de negocio.
-- Usa nuestro modelo stg_orders como fuente, creando una dependencia clara.

with
customer_orders as (

    select * from {{ ref('stg_orders') }} -- ¡Aquí está la magia!

)

select
    customer_id,
    count(order_id) as number_of_orders,
    sum(order_amount) as lifetime_value

from customer_orders
group by 1

La función ref('stg_orders') es el corazón de dbt. Le dice a dbt: “Este modelo depende de stg_orders.” dbt usa esta información para construir automáticamente el grafo de dependencias (DAG). Al ejecutar dbt run, sabe que debe construir stg_orders con éxito antes de intentar construir fct_customer_orders.

Paso 3: Añadiendo Pruebas de Calidad de Datos

Finalmente, podemos añadir pruebas a nuestro modelo Plata para asegurar su calidad, justo al lado del código.

models/staging/schema.yml

version: 2

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: customer_id
        tests:
          - not_null
      - name: order_amount
        tests:
          - dbt_expectations.expect_column_values_to_be_of_type:
              column_type: NUMBER

Ahora, cada vez que ejecutamos dbt test, dbt validará estas reglas sobre la tabla stg_orders, fallando la construcción si un order_id está duplicado o es nulo. Esto detecta problemas de calidad antes de que contaminen la capa Oro.

Con solo estos tres archivos tenemos:

• Linaje Claro: La documentación mostrará que fct_customer_orders depende directamente de stg_orders. Sin más suposiciones.
• Resiliencia: Si actualizamos la lógica en stg_orders, dbt run reconstruirá automáticamente fct_customer_orders. Sin rastreo manual.
• Colaboración: La lógica es modular, documentada y probada. Cualquier miembro del equipo puede entenderla y contribuir con confianza.

Este ejemplo sencillo ilustra cómo dbt aporta estructura, fiabilidad y visibilidad directamente al proceso de transformación, resolviendo los problemas centrales del modern data stack.

Hemos recorrido el camino desde el mundo bien organizado pero opaco de la Arquitectura Medallion hacia un nuevo paradigma de claridad y control. El lakehouse nos dio una base poderosa y escalable para almacenar nuestros datos. Pero sin una forma de gestionar el significado y la transformación de esos datos, nos quedamos con una biblioteca hermosa pero ininteligible.

dbt es la pieza que faltaba. Es el marco esencial que completa la arquitectura moderna de datos. No reemplaza tu data warehouse; desbloquea todo su potencial. Al tratar SQL como código, dbt introduce el rigor, la disciplina y la colaboración de la ingeniería de software en el mundo de la analítica de datos.

El resultado es mucho más que canalizaciones más limpias. Es un cambio fundamental en cómo trabajamos con los datos:

• La confianza se restaura porque cada métrica puede rastrearse hasta su fuente con un solo clic.
• La agilidad se logra porque los cambios dejan de ser arriesgados y pasan a estar gestionados, probados y desplegados con confianza.
• La colaboración se convierte en la norma porque el conocimiento está codificado, documentado y compartido, no aislado en scripts individuales.

La combinación de un data lakehouse y dbt ya no es una elección de nicho; es el estándar emergente para construir una plataforma de datos verdaderamente robusta e inteligente. Proporciona la “capa semántica” que se sitúa sobre tus datos en bruto, traduciéndolos en un conjunto consistente, confiable y comprensible de verdades de negocio. Esta es la base sobre la cual las grandes empresas están construyendo su futuro impulsado por los datos. Es hora de dejar de simplemente almacenar datos y empezar a ingeniarlos con intención.