DBT: modelado de datos a otro nivel

Photo by Sarah Miller-Coral on Unsplash

DBT (Data Build Tool) es una herramienta que apareció no hace demasiado y está facilitando la vida de los ingenieros y analistas de datos en cuanto a la transformación de datos.

En este post quiero mostrarte alguna de las funciones principales de DBT y de cómo sacarle partido rápidamente para optimizar los procedimientos de ingesta, procesado y transformación de datos.

Modelado, testeo y documentación de datos más óptimo

Como analista de datos me enfrentaba muchas veces a lanzar la misma query una y otra vez para un análisis o a conectar queries a diferentes herramientas de visualización, con la posibilidad de error que dejan los procedimientos manuales.

Si además, tenía que trabajar con tablas externas, era un poco rollo subir manualmente tablas para cruzarlas en las diferentes queries que necesitaba.

Mejorando los procesos de ETL

Los procesos de ETL (extract, transform, load) han evolucionado mucho para optimizar costes y procesamientos, al punto de que ha pasado de ser un proceso linear de E — T — L a ser un proceso de E — L — T, en el que la transformación de los datos despega.

Es aquí, en la transformación, donde DBT da mayor independencia a los analistas y mayor conocimiento de los pasos de ingeniería, para dejarnos volar.

DBT facilita la transformación de datos basada en lenguaje SQL

Si ya has visto potencial solo en la transformación que puedes hacer con tus propias manos y SQL, espera a ver las principales funcionalidades de DBT.

¿Cómo funciona DBT?

Solo una pequeña aproximación de cómo funciona técnicamente DBT, para tener una idea general.

1 - GitHub

DBT trabaja siguiendo el workflow de Git, para poder gestionar repositorios y seguir un control de versiones.

2 - Tablas efímeras vs. materializadas

Una de las claves es evitar exponer una alta cantidad de tablas intermedias, para ello, existen las tablas de staging (o efímeras) y que no son necesarias desplegar en el data warehouse.

Un ejemplo para una base de datos de tickets de clientes. Si necesitas reunir información de un ticket proveniente de diferentes fuentes para generar una tabla transaccional puedes generar diferentes stagings:

1. Una tabla de staging con la info de las dimensiones de los tickets: cliente, tipo de pago, fecha de operación.
2. Una tabla de staging con la info de revenue: si tienes diferentes pagos por conceptos.
3. Una tabla de staging con la info de costes asociados: los correspondientes a los conceptos del ticket.

Por último, solo necesitas materializar la info de las tres tablas de staging a la tabla final que se despliega en producción.

Y si necesitas un paso más de optimizanción, también están las tablas o modelos incrementales.

3 - Seeds

Una de las funcionalidades que te evitará subir manualmente tablas al data warehouse, es la generación de tablas de configuración (seed) directamente en DBT.

4 -Test

Antes de desplegar un modelo en producción, una build te permite comprobar que las transformaciones que has hecho son correctas mediante tests. Así puedes evitar duplicados, que no se escapen valores nulos o que los evites si es necesario, etc.

5 - Recicla, reutiliza, reduce código

DBT facilita la reutilización de código a través de las macros. Las macros son snippets de código que parametrizan jobs y que se automatizan fácilmente.

Siguiendo el ejemplo del modelo de tickets. Si tienes varios modelos que incluyen información sobre los tickets y necesitas comprobar que no tienes tickets duplicados, puedes generar una macro para testear varios modelos a la vez:

{% macro unique_ticket(model) %}
select
model.{{ticket}} AS ticket,
count(*) as total
from
{{ ref(model) }} model
inner join
{{ ref("tickets")}} tic
on model.{{ticket}} = tic.ticket
group by
model.{{ticket}}
having total > 1
{% endmacro %}

6 - Documentación

La documentación facilita encontrar campos, saber cómo se construye un modelo o cómo se calcula un campo, qué dependencias tiene, etc. En DBT la documentación se orquesta en documentos tipo .yml y luego se puede consultar fácilmente por cualquier persona del equipo en la página de DBT.

7 - SQL

Sí, todo el modelado se ejecuta en SQL y DBT se encarga de testear y de la materialización en el data warehouse.

8 - Jinja

Es un web template engine de Python que facilita escribir queries de SQL de forma más concisa, evitando repetir código y a su vez, esquiva errores de copy/paste. Jinja también ayuda a saber cuál es el orden en el que deben ejecutarse los modelos.

Generando un loop en Jinja para recorrer los métodos de pago

9 - DAGs (Direct Acyclical Graphs)

La orquestación de los modelos de SQL usando Jinja facilita el mapeo del linaje de los datos y genera un esquema (Direct Acyclical Graphs) por el que se puede navegar para conocer las referencias y dependencias de los modelos.

10 - Y conexión directa a tu data warehouse

DBT materializa en Google BigQuery, Redshift y PostgreSQL…allá donde esté tu data warehouse, datos modelados, testados, documentados y listos para el próximo análisis.

Happy coding!