English
FrançaisEl panorama tecnológico actual en el mundo de los datos está en constante evolución. Cada vez se demandan más herramientas y plataformas que faciliten la gestión y transformación de grandes volúmenes de información de forma eficiente y escalable. Una de esas herramientas es DBT, una poderosa solución que permite a los equipos de análisis y datos transformar y organizar datos en un entorno manejable y reproducible.
En este artículo, exploraremos cómo integrar DBT en un entorno que combine las capacidades de Azure y Snowflake. Ambas son dos de las plataformas en la nube más destacadas para la gestión de datos. Específicamente, nos centraremos en el uso de Azure Container Instances también llamado ACI para ejecutar contenedores DBT. Con él se logra una gestión flexible y escalable de transformaciones de datos manteniendo los costes bajo control.
Además, abordaremos el ciclo de Integración Continua e Implementación Continua (CI/CD) usando GitHub y Azure Container Registry, llamado ACR. Cabe añadir que este enfoque no solo facilita la automatización del proceso de creación e implementación de imágenes de contenedores DBT. Es decir, también garantiza que cualquier cambio en los scripts de transformación se pruebe e implemente de manera eficaz.
Para garantizar una implementación fácil y reproducible de todos estos componentes, utilizaremos Terraform laC. Esta es una herramienta de infraestructura como código (IaC). Terraform permite el aprovisionamiento y gestión de recursos de infraestructura de forma declarativa. Además, facilita el despliegue y configuración de entornos de nube de forma automatizada y eficiente.
Al final de este artículo queremos demostrar de principio a fin una aplicación de DBT. Desde cuando un desarrollador comienza a crear sus transformaciones personalizadas hasta la implementación en producción de este desarrollo.
Todo el código de este artículo está subido en el siguiente repositorio[1].
¿Qué necesitas para entender este artículo?
- Conceptos de Terraform[2].
- Algunos conceptos de DBT[3].
- Introducción a conceptos de Azure[4].
- Algunos conceptos de Snowflake[5].
- Una cuenta de Azure y Snowflake.
Arquitectura
Para todos los componentes utilizados en DBT implementaremos un nuevo grupo de recursos en Azure y como pieza central para el procesamiento usaremos ACI. El uso de este servicio se debe a que podemos desplegar nuestros contenedores fácilmente y a un bajo coste. Para el despliegue de estos contenedores utilizaremos una Github Action. El proceso que se hará en esta demo es que cada vez que haya un nuevo push en la rama principal construiremos la imagen de nuestro desarrollo y la publicaremos en ACR con el SHA del commit como etiqueta. Una vez que la imagen esté publicada en ACR, implementaremos el contenedor de instancias para usar la nueva imagen. Para todo ello utilizaremos Terraform, como veremos con más detalle.
Una vez publicada e implementada la nueva imagen, el contenedor se ejecutará inmediatamente, con la lógica que se quiera realizar para la transformación. Para cierta información confidencial, como las credenciales de Snowflake, usaremos el servicio Azure Key Vault. De esta manera, almacenaremos estas credenciales como un secreto. Al iniciar el contenedor descargaremos las credenciales de Snowflake para poder realizar esta conexión.
La ventaja de esta arquitectura es que usaremos la potencia de Snowflake para todo el procesamiento. Ya que DBT lanzará la consulta contra el data warehouse que le indiquemos, no necesitaremos casi ningún recurso para ejecutar el ACI. Esto abre un mundo de posibilidades ya que podremos olvidarnos de la computación del lado de Azure. Así, sólo tendremos que crear diferentes tipos de warehouse en Snowflake para los distintos casos de usos.
Despliegue de la infraestructura
Una vez explicada la arquitectura vamos a proceder al despliegue de todos los componentes, para lo cual vamos a utilizar Terraform como herramienta. Como partes importantes de esta implementación tendremos la parte de infraestructura más tradicional. Estos son los grupos de recursos, Azure Key Vault y Azure Container Registry. Puede encontrar todo el código de implementación en la carpeta de baseline.
Empecemos por la explicación de la infraestructura más clásica. Para este despliegue haremos uso de tres recursos:
El grupo de recursos lo usaremos para desplegar toda la infraestructura necesaria. El registro de contenedores de Azure será el lugar donde guardaremos todas las imágenes que generamos para la aplicación. Por otro lado el último servicio Azure Key Vault donde guardaremos todos los secretos que usamos en la aplicación de DBT, credenciales, cadenas de conexión… .
Para el despliegue de la parte Azure Container Instances usaremos el código que está almacenado en la carpeta infra. Esta separación la hacemos en dos carpetas porque cada vez que hay un cambio en el código DBT se hará la ejecución de este recurso y así separamos la infraestructura base de la de desarrollo. La única parte que destaca es que tenemos que pasar por variable la imagen que usaremos en el despliegue. Esta parte se incluye en la Github Action para que sea transparente para el desarrollador.
Configuración de snowflake
Snowflake es una plataforma de datos en la nube diseñada para manejar grandes volúmenes de datos y ejecutar cargas de trabajo de análisis complejas. Es ampliamente reconocido por su arquitectura única y su capacidad para ofrecer un rendimiento rápido.
El punto clave de esta plataforma es que ha separado completamente el almacenamiento del procesamiento de datos. Es decir, almacena datos en formato comprimido y en columnas en su propio sistema de archivos propietario. Sin duda facilita la recuperación y el procesamiento rápidos y puede crear diferentes clústeres de procesamiento para sus diferentes casos de uso. Los clústeres de computación pueden crecer o reducirse dinámicamente. Esto depende según las necesidades de la carga de trabajo y pueden tener distintos recursos asociados.
Una vez implementada toda la infraestructura pasaremos a la configuración de Snowflake. Para ello necesitamos haber generado una cuenta y crear un almacén para la demo. El conjunto de datos utilizado para realizar las transformaciones es tpch_sf1[10], haciendo uso de las tablas de customer y orders para la limpieza de datos y transformaciones simples.
Para esta demostración usaremos el almacén COMPUTE_WH que luego configuraremos en DBT:
Para conservar la información una vez transformada con DBT, generaremos una nueva base de datos llamada DBT_MODELS. Dentro de esta base de datos creamos dos nuevos esquemas: staging y staging_intermediate. En el primero ingestaremos la primera capa de datos limpiando ciertas columnas para recolectar sólo los datos que queremos. En el segundo esquema tendremos la información del negocio con la lógica aplicada a la primera capa con ciertas intersecciones. Esta última capa será permitirá explotar desde las herramientas de visualización o el propio científico de datos para realizar cualquier tipo de análisis:
Finalmente generaremos un certificado en snowflake para conectarnos desde nuestra aplicación DBT, siguiendo esta guía[9].
Configuración de DBT
DBT es una herramienta que permite a los equipos y analistas transformar, gestionar y documentar de manera eficiente sus datos dentro de sus almacenes de datos.
Esta herramienta está diseñada para ser utilizado por profesionales que ya conocen SQL. En este sentido, DBT simplifica el desarrollo, las pruebas y la implementación de transformaciones de datos. Para ello se realiza a través de un enfoque basado en código y flujos de trabajo colaborativos. Su punto fuerte es que no consume recursos de procesamiento. Es decir, los recursos los consume el data warehouse que está utilizando. Además, cuenta con una gran cantidad de conectores para las diferentes herramientas líderes del mercado. Entre ellas encontramos como Snowflake, Bigquery, Redshift y otras muchas más.
El uso de DBT permite a los desarrolladores generar sus propias clases y configuraciones para que sean reutilizables. Lo realiza de una forma muy sencilla ya que permite el uso de SQL. Además, una de sus mayores fortalezas es que se integra fácilmente con diferentes herramientas CI/CD. El resultado es garantizar buenas prácticas en el desarrollo de aplicaciones y productos de datos.
Para esta demostración usaremos el código que se encuentra en la carpeta tpch_transform. Posteriormente revisaremos la parte de configuración de los elementos más importantes.
Como hemos comentado anteriormente usaremos el poder de DBT para ejecutar la consulta contra Snowflake. Así no gastarás casi recursos de compute en Azure. Una de las ventajas más importantes con el uso de DBT es poder elegir cómo se materializan nuestras transformaciones. Podemos generar desde vistas para algunas transformaciones hasta tablas materializadas para otras. De esta forma sacamos así el máximo rendimiento a nuestro warehouse y a su posterior explotación
Otro de los beneficios de DBT es su facilidad para contenerizar la aplicación. Podemos generar un contenedor de una manera sencilla con el que poder ejecutar nuestras transformaciones de datos en cualquier plataforma de gestión de contenedores. Un buen punto si no te quieres preocupar por posibles migraciones y control de versiones de tu herramienta de transformación de datos.
La arquitectura final será la siguiente:
Configuracion Github Actions
Como último punto de nuestra plataforma tendremos GitHub Actions. Una plataforma de automatización de flujos de trabajo. Lo que destaca es su capacidad para facilitar a los desarrolladores a automatizar tareas de desarrollo de software directamente en sus repositorios de GitHub. Con GitHub Actions, los usuarios pueden definir flujos de trabajo personalizados que se ejecutan en respuesta a eventos en el repositorio. Como por ejemplo, commits, pull requests, deployments y más.
La arquitectura de alto nivel será la siguiente:
Para este proyecto, el flujo que hemos creado está desarrollado para que cada vez que haya un nuevo commit en la rama main, se ejecute la Action de Github. Esta Action de github tiene dos etapas. La primera es crear y publicar la imagen en Azure Container Registry y la segunda etapa de la Action es implementar la parte de infraestructura y ejecutar la transformación. Para esto, usaremos el código de la carpeta de infra. En la construcción de la infraestructura pasaremos como variable la versión de la imagen que hemos construido previamente. Esto sirve para que cuando se arranque el Container Instances use la nueva versión generada y guardada en Azure Container Registry.
Conclusiones
La integración de DBT con Azure y Snowflake, utilizando Azure Container Instances (ACI) y una canalización de CI/CD con GitHub y Azure Container Registry (ACR) para el registro de imágenes, proporciona una solución sólida y escalable para la transformación y administración de datos. A lo largo de este artículo, hemos explorado cómo cada componente contribuye a crear un flujo de datos eficiente y automatizado. En el destacamos los siguientes puntos clave:
Eficiencia y escalabilidad:
La combinación de DBT con Snowflake y Azure permite aprovechar el poder de ambas plataformas para manejar grandes volúmenes de datos y ejecutar transformaciones complejas. Azure Container Instances brinda la flexibilidad de escalar las operaciones de DBT según las necesidades del proyecto.
Automatización y robustez con CI/CD:
La implementación de un ciclo de integración continua e implementación continua (CI/CD) con GitHub Actions y Azure Container Registry facilita la automatización de la compilación, prueba e implementación de imágenes DBT. Esto garantiza que cualquier cambio en los scripts de transformación se pruebe e implemente de manera consistente y confiable.
Gestión de infraestructura con Terraform:
El uso de Terraform para implementar y administrar componentes de infraestructura proporciona una forma declarativa y reproducible de configurar el entorno. Lo que reduce la posibilidad de errores manuales y mejora la coherencia de las implementaciones.
Modularidad y reutilización de modelos:
DBT promueve la creación de modelos de datos modulares y reutilizables, lo que simplifica la gestión de las transformaciones de datos y facilita el mantenimiento del pipeline. Esto permite que los equipos de datos se adapten rápidamente a los cambios en los requisitos comerciales.
Seguridad y mejores prácticas:
al separar las configuraciones confidenciales en el archivo profiles.yml y usar GitHub para la administración de código, se promueven prácticas de seguridad y colaboración. Esto garantiza que las credenciales y configuraciones se manejen de manera segura y controlada.
En resumen, la integración de estas tecnologías y prácticas crea un entorno de datos moderno, eficiente y altamente adaptable. No solo mejora la productividad del equipo de datos, sino que también garantiza que los procesos de análisis y transformación de datos sean robustos y escalables. Además está alineado con las mejores prácticas de desarrollo de software y DevOps. Esta configuración permite a las organizaciones maximizar el valor de sus datos. Es decir, proporcionando información precisa y oportuna para la toma de decisiones y acelerando la creación de productos de datos.
Si te ha gustado este artículo te animamos a que lo compartas con tus compañeros de trabajo y amigos. Recuerda que en Syntonize somos expertos en #Data, #IA y #Cloud si estás interesado en potenciar e impulsar tu negocio contáctanos.
Referencias
[1] Repositorio de Github. [link]
[2]Introducción a Terraform. [link]
[3] Intro a DBT. [link]
[4] Introducción a Azure. [link]
[5] La Introducción a Snowflake. [link]
[6] Terraform de Azure Resource group. [link]
[7] Registry de Terraform de Azure Container Registry. [link]
[8] Registry de Terraform de Azure Key Vault. [link]
[9] Guía para guardar un certificado en Snowflake. [link]
[10] Ejemplos de datos de Snowflake. [link]
