dbt: transforma datos con SQL y pruebas
dbt ayuda a transformar datos dentro de un almacén o plataforma analítica mediante SQL, plantillas, pruebas, documentación y un grafo de dependencias. Aplica prácticas de ingeniería de software a la capa de transformación: control de versiones, modularidad, revisión y despliegues reproducibles.
El enfoque ELT
En un flujo ELT, los datos se extraen y cargan primero en la plataforma; después dbt ejecuta transformaciones allí. dbt no suele ser la herramienta que ingiere archivos o replica bases operativas. Su ámbito principal comienza cuando los datos ya son consultables.
Los modelos son archivos SELECT. dbt compila las referencias y materializa el resultado como vista, tabla, modelo incremental u otra estrategia soportada por el adaptador.
Primer modelo
select
order_id,
customer_id,
cast(order_date as date) as order_date,
amount
from {{ source('raw_sales', 'orders') }}
where order_id is not null
source declara una entrada externa gestionada fuera de dbt. ref apunta a otro modelo:
select *
from {{ ref('stg_orders') }}
ref crea la dependencia en el grafo y resuelve el nombre físico según entorno. Es preferible a escribir esquemas y tablas manualmente.
Capas de modelado
Una organización frecuente usa staging para renombrar y tipar fuentes, intermediate para lógica reutilizable y marts para entidades y métricas de negocio. No es una obligación universal, pero separa limpieza técnica de conceptos consumibles.
Evita modelos gigantes que realizan todo en un archivo o cadenas de modelos triviales sin valor. Cada capa debe tener propósito, propietario y nivel de granularidad claros.
Pruebas de datos
Las pruebas verifican afirmaciones como unicidad, ausencia de nulos, relaciones y valores aceptados. También puedes escribir pruebas singulares mediante una consulta que devuelva filas inválidas.
Una prueba no mejora los datos por sí sola. Define severidad, responsable y respuesta. Prueba las claves y reglas que afectarían decisiones, no únicamente columnas fáciles.
Las pruebas unitarias de modelos, cuando estén disponibles en tu versión, aíslan entradas pequeñas y resultados esperados. Complementan las pruebas sobre datos reales.
Modelos incrementales
Un incremental procesa solo registros nuevos o modificados después de la primera ejecución. Reduce coste, pero introduce estado: una lógica corregida quizá necesite un full refresh, y las actualizaciones tardías requieren una ventana o estrategia merge.
Define una unique_key cuando corresponda y prueba duplicados. Usa el intervalo del dato, no solo la fecha de carga, y documenta cómo reconstruir el modelo desde cero.
Snapshots
Los snapshots capturan cambios de registros mutables a lo largo del tiempo, por ejemplo el estado histórico de un cliente. Requieren una clave única y una estrategia para detectar cambios. No sustituyen una fuente de eventos cuando necesitas cada transición exacta.
Seeds y macros
Los seeds cargan archivos CSV pequeños y versionados, apropiados para catálogos estáticos, no para datos masivos o sensibles. Las macros reutilizan lógica Jinja y ayudan a estandarizar patrones.
No escondas una consulta incomprensible dentro de una macro. La abstracción debe reducir duplicación manteniendo el SQL compilado auditable.
Documentación y linaje
Describe modelos y columnas, declara fuentes y genera documentación. El grafo muestra dependencias entre transformaciones. Esta visibilidad permite evaluar impacto antes de cambiar una columna.
Añade propietario, granularidad, actualización y contrato de uso. La documentación generada solo es valiosa si permanece alineada con el código.
Entornos y CI
Separa desarrollo, integración y producción mediante esquemas o catálogos. En una pull request, compila, ejecuta selectivamente modelos modificados y sus dependencias, y prueba sobre un entorno aislado. La deferencia y la selección por estado pueden reducir trabajo, según tu plataforma.
Nunca permitas que un desarrollo sobrescriba tablas de producción. Protege credenciales, limita permisos y revisa paquetes de terceros.
dbt frente a un orquestador
dbt construye y prueba transformaciones; Airflow u otro orquestador coordina ingesta, dbt, controles y entregas entre sistemas. dbt puede programarse en un servicio gestionado, pero su grafo no reemplaza automáticamente todos los workflows externos.
Buenas prácticas
Usa sources y ref, establece convenciones, prueba claves, documenta granularidad, evita SELECT *, controla contratos y coste, y conserva un camino de reconstrucción. Observa duración, filas y frescura. Un proyecto dbt profesional hace que una modificación sea pequeña, revisable y rastreable hasta sus consumidores.
Continúa aprendiendo
Amplía este tema con nuestras guías sobre Apache Airflow, data warehouse, calidad de datos.
Fuentes oficiales
Preguntas frecuentes
¿Qué es dbt?
Es una herramienta para transformar datos en plataformas analíticas mediante SQL, pruebas, documentación y dependencias versionadas.
¿dbt extrae datos de sistemas fuente?
Su foco principal es la transformación después de la carga. La ingesta suele realizarse con otras herramientas.
¿Qué diferencia hay entre ref y source?
source declara una entrada externa; ref enlaza otro modelo de dbt y crea una dependencia en el grafo.
¿Qué es un modelo incremental?
Un modelo que, después de su primera construcción, procesa solo datos nuevos o modificados según una estrategia definida.
¿dbt reemplaza a Airflow?
No necesariamente. dbt gestiona transformaciones; un orquestador coordina tareas y sistemas más amplios.
¿Para qué sirven las pruebas?
Para detectar violaciones de reglas como unicidad, no nulos, relaciones, rangos y lógica de negocio.
Deja una respuesta