Data Build Tool (dbt)

Es una herramienta que permite realizar operaciones de transformación de datos desde tus almacenes. En otras palabras permites simplemente realizar transformaciones, y la ventaja respecto a otra herramientas (similares) es la eficacia.

DBT tiene dos componentes: un compiler y un runner, el IDE en la version cloud y/o del proyecto inicializado y visto desde un IDE local es un espacio donde los usuarios puedes escribir código dbt (sql + sentencias dbt) de forma correcta y amigable, para luego ejecutarlo desde la linea de comando.

La manera en la que dbt procesa la información es: compilando todos los archivos .sql y ejecutándolos en el Warehouse configurado.

• Web oficial: https://www.getdbt.com/

DBT en el ecosistema BI

Si bien dbt no realiza ni extracciones ni cargas de datos, realiza “transform after load”, pues esta es la T en el ELT.

DBT Stack

Componentes de un proyecto DBT

• dbt_project.yml: es un archivo de configuración .yml , que contiene la información detallada el proyecto (nombre, conector al Warehouse, materialized properties, etc); estos puede ser sobre escritos cuando crees archivos .sql.
• Models: directorio que contiene los archivos .sql que ejecutan los pipelines: creación de tablas, vistas o tablas efímeras.
• Tests: son archivos .sql que son usados para ejecutar pruebas personalizadas.
• Macros: son archivos .sql que interactúan con jinja, la idea es que estos modelos sean para eventos reusables.
• Analysis: son modelos que no se ejecutan cuando despliegas tu proyecto, es diseñados para ser consultas on-demand, son usada a menudo en tablas y vistas especializadas en soluciones analíticas.
• Docs: archivo usado para la documentación.
• Logs: son generado cuando el comando dbt run es ejecutado.

Configuración de un proyecto DBT

Recuerda tener una cuenta en Github u otro repositorio, una base de datos habilitada, en nuestro caso tenemos Snowflake, y tener instalado python.

• dbt CLI: nos sirve para instalar dbt solo en nuestra maquina, pero aboyándonos en un repositorio git podemos clonar el proyecto en DBT Cloud.
• dbt Cloud: Puede crearte una cuenta free en www.getdbt.com
• Puedes crearte un repositorio en GIT, yo me apoye en Github (https://github.com/illarek/dbt_cobrakai)
• Creamos un proyecto dbt vacío con el comando es dbt init dbt_cobrakai y personalizamos el archivo dbt_project.yml.

Proyecto cobrakai_dbt

• Para configurar una base de datos debes editar el archivo profile.yml que se encuentra en .dbt, nosotros trabajaremos con snowflake.

snowflake_cobrakai:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: te29317.us-central1.gcp
# User/password auth
      user: DBT_CLOUD_DEV
      password: *****
role: TRANSFORMER_DEV
      database: DEV
      warehouse: TRANSFORMING_DEV
      schema: dbt_cobrakai
      threads: 10
      client_session_keep_alive: False

• Desde el directorio del proyecto y con el comando es dbt debug probamos las conexión.

Conexión a Snowflake

• Ejecutas el proyecto con el comando dbt run, y se ejecutaran los ejemplos del modelo.

Ejecución de los modelos de prueba

Modelos creados en Snowflake

• Salva los resultados en tu repositorio git, en mi caso en Github.
• Una alternativa a la creación del proyecto exclusivamente en DBT Cloud es, que podamos clonar el repositorio de Github, para ellos habilitamos las integraciones en DBT Cloud.

Creación de un modelo personalizado

Recuerda tener un data set de pruebas, nosotros trabajaremos con una tabla llamada DIM_DATE , los queries para la creación de esta tabla se encuentran en file.text.

• Creamos un nuevo brach con la idea de eventualmente incorporar propiedades CI/CD, ejecutar el comando git checkout -b cobrakai-model.
• (*)Creamos un nuevo modelo (dates_view.sql) y ejecutamos el comando dbt run , recuerda que debes generar una operación en nuestro caso usamos esta sentencia, donde el resultado por defecto es la creación de una vista:

with Year_2020 as (
    select *
    from DEMO_DB.FUENTES_DEMO.DIM_DATE
    where YEAR_NUMBER = 2000
),
Day_number as(
    select
        DAY_WEEK_NUMBER,
        count(1) as days_qty 
    from Year_2020
    group by DAY_WEEK_NUMBER
    order by DAY_WEEK_NUMBER asc
)
select * from Day_number 

• (*)Para trabajar con tablas debes configurar en materialized en el archivo dbt_project.yml o puede tambien configurarlo en el modelo .sql antecediendo el siguiente código:

{{
  config(
    materialized='table'
  )
}}
...

• Ahora crearemos procesos dependiente, para ello nos apoyaremos exclusivamente de la base de datos que nos da snowflake; y dentro de directorio models/customers_sales_dir creamos los siguientes archivos .sql.

stg_customers.sql

    select
        C_CUSTOMER_SK,
        C_FIRST_NAME,
        C_LAST_NAME,
        C_EMAIL_ADDRESS
    from SNOWFLAKE_SAMPLE_DATA."TPCDS_SF100TCL".CUSTOMER

stg_sales.sql

    select
        SS_CUSTOMER_SK,
        SS_SOLD_TIME_SK,
        SS_EXT_SALES_PRICE,
        dd.D_DATE
    from SNOWFLAKE_SAMPLE_DATA."TPCDS_SF100TCL".STORE_SALES as ss
    inner join SNOWFLAKE_SAMPLE_DATA."TPCDS_SF100TCL".DATE_DIM as dd
    on ss.SS_SOLD_DATE_SK = dd.D_DATE_SK and dd.D_YEAR = 1999

customer_sales.sql

    {{
      config(
        materialized='table'
      )
    }}
    with customers as (
        select * from {{ ref('stg_customers') }}
    ),
    sales as (
        select * from {{ ref('stg_sales') }}
    ),
    customer_sales as (
        select 
          *
        from customers c
        inner join sales s on c.C_CUSTOMER_SK=s.SS_CUSTOMER_SK
    )
    select
        C_CUSTOMER_SK as CUSTOMER_SK,
        C_FIRST_NAME,
        C_LAST_NAME,
        C_EMAIL_ADDRESS,
        count(SS_EXT_SALES_PRICE) as QTY,
        sum(SS_EXT_SALES_PRICE) AS AMOUNT
    from customer_sales
    group by CUSTOMER_SK,C_FIRST_NAME,C_LAST_NAME,C_EMAIL_ADDRESS

Modelo con dependencias

• Recuerda que puedes ejecutar tu proyecto en dbt cloud, pues este se actualiza al momento de hacer el Push; la sincronización la puede hacer en cualquier momento:

Integración con GitHub (illarek)

• Debes hacer un pull y puedes elegir que branch deseas ejecutar, esto sirve para poder trabajar con multiples ambientes, en el IDE de dbt podemos ejecutar y probar algunas sentencias sql o algunos comando dbt, si la ejecución del comando dbt run es correcta podemos realizar el PR (tambien lo podemos probar en el CLI).

Ejecución del proyecto dbt_cobrakai sobre dbt cloud

• En caso la pruebas sean exitosas podemos hacer el PR, pues la ideas que si algún proceso de un branch se ejecuta correctamente ejecutar el merge al branch que es usado para los diferentes ambientes (desarrollo, pruebas o producción).

PR del branch cobrakai-model

Merge to main branch

• En nuestro caso nuestro ambiente se llama proofs_environment , y se ejecuta sobre el branch main.

Configuration de ambiente proofs_environment

• Sobre nuestro ambiente podemos crear multiples job y dispararlo de forma personalizada

Ejecución de los Jobs de prueba

Nota

(*) : son sentencias que puede obviarlas en caso no tener una fuente con ese nombre, no afecta el flujo del proceso.

Conclusiones

En el caso expuesto para explicar como funciona DBT obviamos profundizar en tópicos específicos, y por lo que se contaba en los pasos seguidos dbt incluye muchas posibilidades, sin embargo recomendamos trabajar con proyecto CI/CD, para poder aprovechar todas las capacidades de la herramienta, esto implica crear tus ambientes de trabajo con los respectivas conexiones, permisos y restricciones.

En trabajos futuros relataremos un proyecto dedicado exclusivamente a un caso de uso y enfocado en CI/CD.

Recursos

Snowflake Trial

illarek/dbt_cobrakai

Overview | dbt Docs

Note: All resources used to these proof are free of cost or we use in there free-trial versions. / Todos los recourses usados en este experimento son gratuitos.