DBT

En este post voy a hablar un poco sobre una herramienta que he utilizado mucho últimamente y está comenzando a adoptarse en el campo de la ingeniería de datos: DBT

DBT (Data Build Tool) es una herramienta para el modelado de datos. Como veremos a continuación, está orientada al desarrollo de pipelines de datos.

Vamos a ver las principales características de esta herramienta:

• Tiene conectores a las principales plataformas de datos (Snowflake, Postgres, Redshift, Databricks...).
• Utiliza Python, lo cual implica que es muy sencillo de instalar y es multiplataforma.
• Genera código SQL mediante el renderizado de plantillas Jinja.

Podríamos resumir DBT como un renderizador de código SQL a partir de plantillas. En pocas palabras: genera código SQL y lo ejecuta por nosotros en el destino que especifiquemos en la configuración.

Por supuesto, tiene otras muchas funcionalidades interesantes que mencionaré más adelante, pero la esencia es básicamente esa.

Entonces, ¿cuáles son las principales ventajas de usar DBT? ¿Por qué no simplemente escribir SQL plano y ejecutarlo u orquestarlo con alguna otra herramienta dedicada?

Ventajas

1. En primer lugar, nos permite adoptar un modelo ELT frente al ETL algo más tradicional. Recordad que mientras que en una ETL, transformamos los datos al vuelo antes de insertarlos en nuestro destino, ELT trata de cargar los datos en crudo en el destino y transformarlos una vez estén en el propio destino. Os dejo una imagen para refrescar el concepto:
   
   DBT permite utilizar SQL para transformar los datos una vez están ya cargados en el warehouse.

2. Una ventaja fundamental para mí es poder hacer un seguimiento de las transformaciones que se van realizando a lo largo de los distintos modelos. A esto se le conoce como linaje de datos. Podemos saber exactamente qué datos están siendo usados por cada modelo. Esto es increíblemente útil, ya sea para estimar el riesgo de actualizar una tabla o simplemente entender las transformaciones que se van realizando. DBT te permite visualizar esto mediante un DAG (Directed Acyclic Graph), lo cuál es muy oportuno ya que es una manera muy sencilla de entender las relaciones entre todos tus modelos.

3. Nos permite tener versionados todos nuestros modelos. Podéis usar vuestra herramienta de control de versiones favoritas, en mi caso git, para hacer un seguimiento de todos los cambios que se llevan a cabo. No me digáis que no es horrible tener miles de tablas o vistas con sus definiciones guardadas en otro lugar y, lo más seguro, desactualizadas.

4. Documentación automática. DBT tiene un par de comandos muy sencillos que permiten generar automáticamente y servir la documentación del proyecto. Además, se puede (y se debe) añadir toda la información que se desee a los modelos mediante ficheros YAML. Lo sé... no soy un gran fan del YAML pero en DBT se utiliza para todo así que es lo que hay. Yo concretamente suelo utilizar GitHub Pages para desplegar la documentación y no tener que ocuparme de absolutamente nada, pero también se puede hostear localmente en un periquete.

5. Es SQL-first. ¿Qué quiero decir con esto? Que, quitando toda la parafernalia de la configuración del proyecto, tan sólo hay que escribir SQL con plantillas. Esto significa que no hace falta saber Python ni nada raro para utilizar la herramienta, simplemente SQL (templatizado). De esta manera, otros equipos como el de analíticas pueden colaborar en el desarrollo de los modelos.

6. Es open source. Creo que no hay nada más que añadir.

7. Nos permite añadir distintos tests. Por ejemplo, comprobar que los valores de una columna sean únicos o no nulos. O alertarnos si una fuente de datos no ha sido actualizada en un cierto plazo de tiempo. Podemos definir nuestros propios tests o utilizar paquetes de terceros que vengan ya con tests predefinidos.

Hasta aquí las principales ventajas que existen al utilizar esta herramienta, vamos ahora con la otra cara de la moneda.

Desventajas

1. Se añade complejidad. Configurar el proyecto y orquestarlo todo requiere bastante tiempo aunque no sea difícil per se. Además, se convierte en una nueva pieza que supervisar en nuestro stack de datos... Hay que sopesar el valor que vamos a poder sacar en cada caso antes de implementar esta herramienta para ver si merece la pena el esfuerzo adicional o no.

2. ELT no es siempre la mejor opción. En muchas ocasiones, el tradicional ETL es más adecuado y más sencillo dependiendo del caso de uso.
   

3. Me parece costosos manejar distintos proyectos/entornos. Hay que configurar un montón de perfiles, targets etc.. para que cada cosa se renderice donde toca y a veces es frustrante, ya que la herramienta hace muchas cosas por debajo y hay que entender bien el funcionamiento interno para conseguir que se comporte como deseamos.

4. No tiene GUI. Aunque esto no sea necesariamente una desventaja, si que hace que no sea tan intuitivo, sobre todo para principiantes.

5. Hay que seguir las convenciones y mejores prácticas a raja tabla. Este tipo de proyectos crecen muy rápido y si no se organizan bien de forma clara y con una convención acordada desde el inicio, el proyecto puede desbordarse muy rápido y volverse ilegible. Y, creedme, puede volverse un verdadero infierno. Con macros que interfieren con el funcionamiento esperado, modelos por todas partes, sources inexistentes que hacen saltar errores y código no uniforme por doquier.

Y hasta aquí esta pequeña sinopsis sobre la herramienta y sus principales características. Ya sabéis que lo bueno, si breve, dos veces bueno. En un futuro (espero que próximo) subiré contenido más técnico sobre DBT.