Las 26 preguntas y respuestas más frecuentes en entrevistas de trabajo sobre DBT para 2026

Preguntas de entrevista intermedias sobre DBT 

Ahora que hemos cubierto las preguntas básicas sobre dbt, aquí hay algunas preguntas de nivel intermedio sobre dbt. Se centran en aspectos técnicos y conceptos específicos.

¿Qué son las fuentes en dbt? 

En dbt, las fuentes son las tablas de datos sin procesar. No escribimos consultas SQL directamente en esas tablas sin procesar, sino que especificamos el esquema y el nombre de la tabla y los definimos como fuentes. Esto facilita la referencia a objetos de datos en tablas.  

Imagina que tienes una tabla de datos sin procesar en tu base de datos llamada « orders » en el esquema « sales ». En lugar de consultar esta tabla directamente, la definirías como fuente en dbt de la siguiente manera:

Define la fuente en tu archivo sources.yml:

version: 2

sources:
  - name: sales
    tables:
      - name: orders

Utiliza la fuente en tus modelos dbt:

Una vez definida, puedes hacer referencia a la tabla sin procesar orders en tus transformaciones de la siguiente manera:

SELECT *
FROM {{ source('sales', 'orders') }}

Este enfoque abstrae la definición de la tabla sin procesar, lo que facilita su gestión y garantiza que, si cambia la estructura de la tabla subyacente, puedas actualizarla en un solo lugar (la definición de origen) en lugar de en cada consulta.

Ventajas de utilizar fuentes en dbt:

• Organización: Las fuentes organizan tus datos sin procesar y facilitan su gestión dentro de un proyecto.
• Resumen: Abstrayes los detalles del esquema, lo que reduce los errores y mejora la flexibilidad.
• Documentación: Definir las fuentes ayuda a crear una mejor documentación para tus entradas de datos sin procesar.

¿Qué es un modelo DBT?

Un modelo dbt es esencialmente un archivo SQL o Python que define la lógica de transformación de los datos sin procesar. En dbt, los modelos son el componente central en el que escribes tus transformaciones, ya sean agregaciones, uniones o cualquier tipo de manipulación de datos.

• Modelos SQL en dbt usan instrucciones ` SELECT ` para definir transformaciones y se guardan como archivos `.sql `.
• Los modelos Python, introducidos con el soporte de dbt para Python, se guardan como archivos .py y te permiten utilizar bibliotecas Python como pandas para manipular datos.

Ejemplo de modelo SQL:

Un modelo SQL transforma datos sin procesar mediante consultas SQL. Por ejemplo, para crear un resumen de los pedidos de una tabla orders:

--orders_summary.sql
WITH orders_cte AS (
    SELECT
        customer_id,
        COUNT(order_id) AS total_orders,
        SUM(order_amount) AS total_revenue
    FROM {{ ref('orders') }}
    GROUP BY customer_id
)

SELECT *
FROM orders_cte

En este ejemplo:

• El modelo orders_summary.sql crea un resumen del total de pedidos e ingresos de cada cliente utilizando SQL.
• El modelo hace referencia a la tabla orders (ya definida como modelo o fuente dbt).

Ejemplo de modelo Python:

Un modelo Python manipula datos sin procesar utilizando código Python. Puede resultar especialmente útil para lógicas complejas que podrían resultar engorrosas en SQL.

# orders_summary.py
import pandas as pd

def model(dbt, session):
    # Load the source data
    orders = dbt.ref("orders").to_pandas()

    # Perform transformations using pandas
    orders_summary = orders.groupby('customer_id').agg(
        total_orders=('order_id', 'count'),
        total_revenue=('order_amount', 'sum')
    ).reset_index()

    return orders_summary

En este ejemplo:

• El modelo Python utiliza pandas para transformar los datos agrupando los pedidos por cliente y calculando el número total de pedidos y los ingresos.
• El resultado se devuelve como un DataFrame, que dbt puede integrar en su canalización.

¿Cómo crearías un modelo dbt? 

A continuación se explica cómo crear un modelo dbt: 

• Crea un directorio en lacarpeta « models » del proyecto dbt. 
• Añade un nuevo archivo de texto con la extensión .sql dentro del directorio (o .py si se trata de un modelo Python).
• Ahora, escribe una consulta SQL o código para transformar los datos sin procesar. 
• Ejecuta elcomando « dbt run » para aplicar la transformación y crear el modelo.

¿Cómo gestiona dbt las dependencias entre modelos?

dbt gestiona las dependencias de los modelos mediante la función « ref() », que crea una cadena de dependencias clara entre los modelos. 

Cuando defines una transformación en dbt, en lugar de hacer referencia directa a las tablas de tu almacén, haces referencia a otros modelos dbt utilizando la función « ref() » (usar tabla de referencia). Esto garantiza que dbt construya los modelos en el orden correcto identificando qué modelos dependen de otros.

Por ejemplo, si tienes un modelo orders_summary que depende del modelo orders, lo definirías así:

WITH orders AS (
    SELECT * FROM {{ ref('orders') }}
)
SELECT
    customer_id,
    COUNT(order_id) AS total_orders,
    SUM(order_amount) AS total_revenue
FROM orders
GROUP BY customer_id

En este ejemplo, la función « {{ ref('orders') }} » garantiza que el modelo « orders » se construya antes que « orders_summary », ya que « orders_summary » depende de los datosdel modelo « orders ».

¿Qué son las macros en dbt y cómo se ejecutan? 

Las macros en dbt son bloques reutilizables de código SQL escritos con el motor de plantillas Jinja. Te permiten automatizar tareas repetitivas, abstraer lógica compleja y reutilizar código SQL en múltiples modelos, lo que hace que tu proyecto dbt sea más eficiente y fácil de mantener. 

Las macros se pueden definir en archivos .sql dentro del directorio macros de tu proyecto dbt.

Las macros son especialmente útiles cuando necesitas realizar transformaciones similares en varios modelos o necesitas una lógica específica para cada entorno, como utilizar diferentes esquemas o modificar los formatos de fecha en función de los entornos de implementación (por ejemplo, desarrollo, prueba o producción).

Ejemplo de creación de macros:

• Macro de formato de fecha: Puedes crear una macro para estandarizar el formato de fecha en todos los modelos. En lugar de repetir la lógica del formato de fecha, puedes crear una macro como esta:

-- macros/date_format.sql
{% macro format_date(column) %}
FORMAT_TIMESTAMP('%Y-%m-%d', {{ column }})
{% endmacro %}

Uso en un modelo:

SELECT
    customer_id,
    {{ format_date('order_date') }} AS formatted_order_date
FROM {{ ref('orders') }}

En este ejemplo, se utiliza la macro format_date para estandarizar el formato de la columna order_date en cualquier modelo en el que se llame.

• Macro de nombre de esquema personalizado: Esta macro cambia dinámicamente los nombres de los esquemas en función del entorno (por ejemplo, desarrollo o producción). Esto ayuda a gestionar entornos sin tener que cambiar manualmente los nombres de los esquemas.

-- macros/custom_schema.sql
{% macro custom_schema_name() %}
{% if target.name == 'prod' %}
'production_schema'
{% else %}
'dev_schema'
{% endif %}
{% endmacro %}

Uso en un modelo:

SELECT *
FROM {{ custom_schema_name() }}.orders

Aquí, la macro comprueba si el entorno (target.name) es «prod» y devuelve el nombre de esquema correcto en función de eso.

Cómo ejecutar macros:

Las macros no se ejecutan directamente como los modelos SQL. En su lugar, se hace referencia a ellas en tus modelos u otras macros y se ejecutan cuando se ejecuta el proyecto dbt. Por ejemplo, si utilizas una macro dentro de un modelo, la macro se ejecutará cuando ejecutes el comando « dbt run » (Aplicar macro).

• Llamar a una macro dentro de un modelo: Cuando incluyes una macro en un modelo SQL, la macro se ejecuta durante la ejecución del modelo.
• Ejecutar macros manualmente: También puedes ejecutar ciertas macros manualmente llamándolas con el comando « dbt run-operation ». Esto se utiliza normalmente para tareas puntuales, como introducir datos o realizar operaciones de mantenimiento.

¿Cuáles son los dos tipos de pruebas que existen en la TDC? 

Las pruebas singulares y las pruebas genéricas son los dos tipos de pruebas que existen en dbt: 

• Las pruebas singulares se centran en condiciones específicas en un modelo dbt. Si la condición de prueba falla, devolverá las filas.

Ejemplo: Supongamos que quieres asegurarte de que ningún pedido tenga un valor negativo en order_amount. Puedes escribir una prueba singular en el directorio tests de la siguiente manera:

-- tests/no_negative_order_amount.sql
SELECT *
FROM {{ ref('orders') }}
WHERE order_amount < 0

Si esta prueba falla, dbt devolverá todas las filas de la tabla orders en las que order_amount sea negativo.

• Las pruebas genéricas son pruebas predefinidas que aceptan argumentos. Se dividen a su vez en los siguientes tipos: 

Ejemplo: Puedes aplicar fácilmente una prueba genérica para garantizar que customer_id en la tabla customers sea único y no nulo definiéndolo en tu archivo schema.yml:

version: 2

models:
  - name: customers
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null

En este ejemplo:

• La prueba única comprueba que cada customer_id en la tabla customers sea único.
• La prueba not_null comprueba que no falte ningún valor customer_id ni haya ningún valor nulo.

Preguntas avanzadas para entrevistas sobre dbt 

A medida que avances, es posible que te encuentres con situaciones más complejas y conceptos más avanzados. A continuación, te presentamos algunas preguntas difíciles para entrevistas que te ayudarán a evaluar tu experiencia y prepararte para puestos de ingeniería de datos de alto nivel.

¿Cómo se pueden crear modelos incrementales en dbt y cuándo se utilizan?

Los modelos incrementales en dbt se utilizan para procesar únicamente los datos nuevos o modificados, en lugar de volver a procesar todo el conjunto de datos cada vez. Esto resulta especialmente útil cuando se trabaja con grandes conjuntos de datos, en los que reconstruir todo el modelo desde cero requeriría mucho tiempo y recursos.

Un modelo incremental permite a dbt añadir solo datos nuevos (o actualizar los datos modificados) en función de una condición, normalmente una columna de marca de tiempo (como updated_at).

Cómo crear un modelo incremental:

1. Define el modelo como incremental especificándolo en la configuración del modelo:

{{ config(
    materialized='incremental',
    unique_key='id'  -- or another unique column
) }}

2. Utiliza la función « is_incremental() » para filtrar las filas nuevas o modificadas:

SELECT *
FROM source_table
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

3. Cuando dbt ejecuta este modelo por primera vez, procesará todos los datos. Para ejecuciones posteriores, solo procesará filas en las que updated_at sea mayor que el valor más reciente que ya se encuentra en el modelo.

Cuándo utilizar modelos incrementales:

• Conjuntos de datos de gran tamaño: Cuando tienes una tabla grande con millones o miles de millones de filas, reconstruir toda la tabla durante cada ejecución sería ineficiente.
• Actualizaciones frecuentes: Si tu almacén de datos recibe actualizaciones frecuentes o datos nuevos, pero no necesitas volver a procesar todo el conjunto de datos, los modelos incrementales pueden reducir significativamente el tiempo de procesamiento.
• Datos de streaming: En los casos en los que los datos se transmiten o actualizan con regularidad, los modelos incrementales ayudan a mantener las transformaciones actualizadas sin tener que volver a ejecutar todo.

¿Cómo utilizas Jinja para mejorar tu código SQL?

Jinja hace que vuestro código SQL sea más flexible. Con Jinja, podemos definir plantillas reutilizables para patrones SQL comunes. Y dado que los requisitos cambian constantemente, podemos utilizar las sentencias « if » ( ) y «» ( ) de Jinja para ajustar nuestras consultas SQL en función de las condiciones. Hacerlo suele mejorar el código SQL al desglosar la lógica compleja, lo que facilita su comprensión. 

Por ejemplo, si deseas convertir el formato de fecha de «AAAA-MM-DD» a «MM/DD/AAAA», aquí tienes un ejemplo de macro dbt para ello, que ya vimos en una pregunta anterior:

{% macro change_date_format(column_name) %}

  to_char({{ column_name }}::date, 'MM/DD/YYYY')

{% endmacro %}

En este ejemplo de código, {{ column_name }} es donde Jinja inserta el nombre real de la columna cuando usas la macro. Se sustituirá por el nombre real de la columna durante el tiempo de ejecución. Como hemos visto en ejemplos anteriores, Jinja utiliza {{ }} para mostrar dónde se producirá la sustitución.

¿Cómo crearías una materialización personalizada en dbt? 

A continuación, se explica cómo crear una materialización personalizada en dbt: 

• Crea el archivo SQL para la materialización personalizada. 
• A continuación, define una macro de materialización como materialization_name: 

{% materialization materialization_name, default -%}

• Utiliza las macros predefinidas de dbt adapter.get_relation para configurar la tabla de destino. Aquí es donde se cargarán los datos. 
• Ahora, define y ejecuta los comandos SQL para crear y cargar datos en las tablas: 

{% set sql %}
    SELECT * FROM {{ ref('your_source_table') }}
    WHERE your_conditions = true
{% endset %}
{{ adapter.execute(sql) }}

• Al final, devuelve la relación de destino para actualizar la caché de dbt y optimizar la ejecución de la consulta. 

{{ return(target_relation) }}
{% endmaterialization %}

¿Cómo puedes depurar tus modelos dbt? Cuéntanos dos formas. 

Aquí hay dos formas de depurar nuestros modelos dbt: 

1. Accede a los archivos SQL compilados en la carpeta de destino para identificar y programar errores.

Cuando ejecutas un proyecto dbt, dbt compila tus modelos (escritos utilizando plantillas Jinja) en consultas SQL sin procesar y los guarda en el directorio target. Este SQL compilado es exactamente lo que dbt ejecuta en tu plataforma de datos, por lo que revisar estos archivos puede ayudarte a identificar dónde se producen los problemas:

• Ejecuta tus modelos dbt (por ejemplo, dbt run o dbt test).
• Ve a la carpeta « target/compiled/ » en el directorio de tu proyecto dbt.
• Abre el archivo SQL compilado para el modelo que estás depurando. El archivo contendrá el código SQL sin procesar ejecutado por dbt, incluidas todas las transformaciones de las macros y referencias de Jinja.
• Copia la consulta SQL compilada y ejecútala directamente en el editor SQL de tu plataforma de datos (por ejemplo, Postgres, BigQuery) para obtener mensajes de error detallados o ver el comportamiento real de la consulta.

2. Utilizala extensión dbt Power User Extension para VS Code de para revisar los resultados de las consultas directamente.

La extensión dbt Power User para Visual Studio Code (VS Code) es una herramienta útil para depurar modelos dbt. Esta extensión te permite revisar y probar tus consultas directamente en tu IDE, lo que reduce la necesidad de cambiar entre dbt, el terminal y tu base de datos.

¿Cómo compila las consultas el dbt? 

dbt compila las consultas siguiendo los siguientes pasos:

1. Análisis: dbt lee todos los archivos SQL, configuraciones YAML y macros del proyecto.
2. Creación de contexto: Crea un contexto para cada modelo, incluyendo configuraciones y macros disponibles.
3. Renderización Jinja: A continuación, procesa los archivos SQL como plantillas Jinja para sustituir las etiquetas y expresiones por los resultados evaluados.
4. Compilación SQL: Se generan consultas SQL puras para cada modelo.
5. Generación de artefactos: El SQL compilado se guarda en el directorio target/compiled.
6. Preparación de la ejecución: Para dbt run, las consultas se preparan para su ejecución, posiblemente con un envoltorio adicional.

Este proceso transforma el SQL modular y basado en plantillas en consultas ejecutables específicas para tu almacén de datos. Podemos utilizar dbt compile o consultar el directorio target/compiled para ver y depurar el SQL final de cada modelo.

Preguntas de entrevista sobre almacenamiento de datos e integración basada en dbt

La mayoría de los trabajos de los ingenieros de datos giran en torno a la creación e integración de almacenes de datos con dbt. Las preguntas relacionadas con estas situaciones son muy habituales en las entrevistas, por eso he recopilado las más frecuentes: 

Explica tres ventajas de integrar dbt con Airflow. 

La integración de dbt con Airflow ayuda a crear un canal de datos optimizado. Estas son algunas de sus ventajas: 

• Proceso ETL: Airflow gestiona la extracción y la carga de datos, lo que garantiza que dbt pueda centrarse en la etapa de transformación, lo que se traduce en un flujo de trabajo general más fluido.
• Automatización de tareas dbt: Airflow automatiza la programación y ejecución de modelos dbt, lo que reduce la intervención manual y mejora la eficiencia de tus transformaciones de datos.
• Ejecución paralela de tareas: Airflow permite ejecutar tareas en paralelo, lo que facilita el procesamiento de grandes conjuntos de datos sin comprometer el rendimiento, lo que ayuda a mantener canales de datos rápidos y fiables. 

¿Cuál es la arquitectura de la capa semántica de dbt? 

La capa semántica de dbt nos permite traducir los datos sin procesar al lenguaje que entendemos. También podemos definir métricas y consultarlas con una interfaz de línea de comandos (CLI). 

Esto nos permite optimizar el costo, ya que la preparación de los datos lleva menos tiempo. Además, todos trabajáis con las mismas definiciones de datos, lo que garantiza la coherencia de las métricas en toda la organización. 

dbt y la capa semántica. Fuente de la imagen: dbt

Si utilizas BigQuery, ¿es dbt una capa innecesaria de transformación de datos? 

Aunque BigQuery es muy útil y puede gestionar muchas transformaciones de forma nativa, es posible que sigas necesitando dbt. He aquí por qué:

• dbt te permite controlar las versiones de tus transformaciones, algo que no es compatible de forma nativa con BigQuery.
• dbt proporciona marcos de pruebas integrados y generación de documentación, lo que mejora la calidad y la comprensión de los datos.
• La función y las macros ` ref() ` de dbt permiten un código SQL más modular y reutilizable.
• dbt facilita la gestión de múltiples entornos (desarrollo, pruebas, producción) en BigQuery.
• dbt proporciona una forma coherente de gestionar las dependencias entre transformaciones.

¿DBT garantiza la seguridad de los datos? 

dbt viene en dos versiones: dbt Core y dbt Nube, como se ha visto en una pregunta anterior. dbt Core es de código abierto y funciona como versión gratuita. Por eso no ofrece ninguna función de seguridad integrada, y los usuarios son responsables de su implementación y seguridad. 

Sin embargo, dbt Nube está diseñado para proporcionar una seguridad completa. Cumple con la HIPAA y otros marcos comunes para garantizar que no se vulnere la privacidad. Por lo tanto, dependiendo de vuestras necesidades, debéis elegir una versión de dbt que se adapte a vuestros requisitos de cumplimiento normativo empresarial.

¿Cómo puedes optimizar el rendimiento de las transformaciones dbt en conjuntos de datos grandes?

Optimizar las transformaciones dbt para grandes conjuntos de datos es fundamental para mejorar el rendimiento y reducir los costes, especialmente cuando se trabaja con almacenes de datos basados en la nube como Snowflake, BigQuery o Redshift. A continuación, se indican algunas técnicas clave para optimizar el rendimiento de dbt:

1. Utilizar modelos incrementales

Los modelos incrementales permiten a dbt procesar solo los datos nuevos o actualizados, en lugar de volver a procesar todo el conjunto de datos cada vez. Esto puede reducir significativamente los tiempos de ejecución para grandes conjuntos de datos. Este proceso limita la cantidad de datos procesados, lo que acelera los tiempos de transformación.

2. Aprovecha la partición y la agrupación en clústeres (para bases de datos como Snowflake y BigQuery).

La partición y agrupación de tablas grandes en bases de datos como Snowflake o BigQuery ayudan a mejorar el rendimiento de las consultas al organizar los datos de manera eficiente y reducir la cantidad de datos escaneados durante las consultas.

La partición garantiza que solo se consulten las partes relevantes de un conjunto de datos, mientras que la agrupación optimiza la disposición física de los datos para agilizar su recuperación.

3. Optimizar materializaciones (tabla, vista, incremental)

Utiliza materializaciones adecuadas para optimizar el rendimiento:

• Las vistas son útiles para transformaciones ligeras, pero no son ideales para cargas de trabajo pesadas.
• Las tablas almacenan los datos físicamente, lo que mejora el rendimiento pero ocupa más espacio de almacenamiento.
• Los modelos incrementales son los más adecuados para conjuntos de datos grandes que se actualizan periódicamente.

4. Utiliza LIMIT durante el desarrollo.

Al desarrollar transformaciones, resulta útil añadir una cláusula « LIMIT » a las consultas para restringir el número de filas procesadas. Esto acelera los ciclos de desarrollo y evita tener que trabajar con enormes conjuntos de datos durante las pruebas.

5. Ejecutar consultas en paralelo

Aprovecha la capacidad de tu almacén de datos para ejecutar consultas en paralelo. Por ejemplo, dbt Nube admite el paralelismo, que se puede ajustar en función de tu infraestructura.

6. Utiliza funciones de optimización específicas de la base de datos.

Muchos almacenes de datos en la nube ofrecen funciones de optimización del rendimiento, como:

• BigQuery: Utiliza vistas materializadas o tablas particionadas.
• Snowflake: Habilita la agrupación automática y el escalado del almacén para la ejecución paralela.

¿Cómo optimizas las ejecuciones de dbt en Snowflake? 

Para optimizar las ejecuciones de dbt en Snowflake:

1. Utiliza la agrupación de tablas:

{{ config(
    cluster_by = ["date_column", "category_column"]
) }}
SELECT ...

2. Aprovecha los almacenes multiclúster de Snowflake para la ejecución paralela de modelos:

models:
  my_project:
    materialized: table
    snowflake_warehouse: transforming_wh

3. Utiliza modelos incrementales cuando sea apropiado:

{{ config(materialized='incremental', unique_key='id') }}
SELECT *
FROM source_table
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

Estas optimizaciones pueden mejorar el rendimiento y la rentabilidad de las ejecuciones de dbt en Snowflake.

Preguntas de entrevista sobre comportamiento y resolución de problemas (DBT) 

Al final del proceso de entrevista, los entrevistadores suelen poner a prueba tus habilidades para resolver problemas. Es posible que te hagan preguntas para ver cómo respondes ante situaciones de la vida real. A continuación, te planteamos algunas preguntas sobre comportamiento y resolución de problemas: 

¿Cómo gestionarías la implementación de dbt en múltiples entornos (desarrollo, staging, producción)?

A continuación, se explica cómo puedes gestionar la implementación de dbt en distintos entornos:

1. Configuraciones específicas del entorno

dbt te permite definir diferentes configuraciones para cada entorno (desarrollo, staging y producción) en el archivo dbt_project.yml. Puedes especificar diferentes configuraciones para aspectos como el esquema, la base de datos y las configuraciones del almacén de datos.

Ejemplo en dbt_project.yml:

models:
  my_project:
    dev:
      schema: dev_schema
    staging:
      schema: staging_schema
    prod:
      schema: prod_schema

En este ejemplo, dbt selecciona automáticamente el esquema correcto en función del entorno de destino (desarrollo, staging o producción) al ejecutar el proyecto.

2. Uso de la variable objetivo

La variable target en dbt se utiliza para definir en qué entorno estás trabajando (desarrollo, staging, producción). Puedes hacer referencia a esta variable en tus modelos o macros para personalizar el comportamiento en función del entorno.

Ejemplo en un modelo:

{% if target.name == 'prod' %}
    SELECT * FROM production_table
{% else %}
    SELECT * FROM {{ ref('staging_table') }}
{% endif %}

Esta lógica garantiza que se utilicen diferentes tablas o esquemas en función del entorno.

3. Ramificación y control de versiones

Cada entorno debe tener su propia rama en el control de versiones (por ejemplo, Git). Los programadores trabajanen la rama dev, los probadores y analistas utilizan staging, y solo los cambios aprobados se fusionan en la rama prod.

4. Integración continua (CI) e implementación continua (CD)

En producción, es importante contar con un canal de implementación automatizado que realice pruebas y validaciones antes de implementar los modelos. En dbt Nube, puedes configurar programaciones de tareas para ejecutar tareas específicas en función del entorno. En el caso de dbt Core, esto se puede lograr mediante herramientas de CI/CD como GitHub Actions o Jenkins.

¿Cómo gestionas el control de versiones en dbt, especialmente cuando trabajas con varios miembros del equipo?

El control de versiones es esencial cuando se trabaja en proyectos dbt, especialmente en un entorno de equipo en el que varias personas contribuyen al mismo código base. Así es como gestiono el control de versiones en dbt:

1. Utiliza Git para el control de versiones.

Utilizamos Git como herramienta principal para el control de versiones en nuestros proyectos dbt. Cada miembro del equipo trabaja en su propia rama para cualquier cambio o característica que estéis implementando. Esto permite un desarrollo aislado y evita conflictos entre los miembros del equipo que trabajan en diferentes tareas simultáneamente.

Ejemplo: Cuando trabajo en un nuevo modelo dbt, creo una nueva rama de características como feature/customer_order_transformation.

2. Estrategia de ramificación

Seguimos una estrategia de ramificación Git en la que:

• La rama « dev » se utiliza para el desarrollo y las pruebas continuas.
• La rama « staging » se utiliza para preparar los cambios para la producción.
• La rama main o prod está reservada para el entorno de producción.

Los miembros del equipo envían sus cambios a la rama dev y abren solicitudes de extracción (PR) para la revisión del código. Una vez que los cambios se revisan y aprueban, se fusionan en staging para realizar más pruebas y, a continuación, se promocionan a production.

3. Integración continua (CI)

Hemos integrado un canal de CI (por ejemplo, GitHub Actions, CircleCI) que ejecuta automáticamente pruebas dbt en cada solicitud de extracción. Esto garantiza que cualquier código nuevo supere las pruebas necesarias antes de integrarse en la rama principal. 

El proceso de CI ejecuta dbt run para crear modelos y dbt test para validar los datos y comprobar si hay errores o inconsistencias.

4. Resolver conflictos de fusión

Cuando varios miembros del equipo realizan cambios en el mismo modelo o archivo, pueden producirse conflictos de fusión. Para solucionar esto, primero reviso los marcadores de conflicto en el código y decido qué cambios conservar:

• Si ambos cambios son válidos, los combino en una nueva versión.
• Si solo un conjunto de cambios es correcto, los conservo y descarto el otro.

Después de resolver el conflicto, realizo pruebas localmente para asegurarme de que la resolución del conflicto no haya introducido ningún error nuevo. Una vez confirmados, vuelvo a enviar los cambios resueltos a la rama.

5. Documentación y colaboración

Nos aseguramos de que cada solicitud de fusión o extracción incluya la documentación adecuada de los cambios realizados. Actualizamos la documentación dbt generada automáticamente para que todos los miembros del equipo comprendan claramente los modelos nuevos o actualizados.

¿Cómo implementarías dbt en un canal de datos existente?  

Así es como implementaría dbt en un canal existente:

1. Evalúa el proceso actual: Identificar ineficiencias y áreas en las que dbt puede mejorar los procesos de transformación.
2. Configura dbt: Instala dbt, crea un nuevo proyecto y configura las conexiones con el almacén de datos.
3. Convertir transformaciones: Migrar el SQL existente o la lógica de transformación a modelos dbt, garantizando la modularidad y la claridad.
4. Añadir pruebas y documentación: Implementa las pruebas y la documentación integradas en dbt para garantizar la calidad y la transparencia de los datos.
5. Integración con la orquestación: Programa ejecuciones de dbt utilizando herramientas existentes como Airflow o Prefect.
6. Empieza poco a poco: Implementa dbt en un pequeño subconjunto del proceso para validar los cambios antes de ampliarlos.
7. Supervisar y optimizar: Supervisa continuamente el rendimiento y optimiza los modelos según sea necesario.

Imagina que un modelo dbt falla debido al error «la relación no existe». ¿Cómo se depura un error como este?

Cuando aparece el error «relation does not exist» (la relación no existe) en dbt, normalmente significa que el modelo está intentando hacer referencia a una tabla o modelo que no se ha creado o que está mal escrito. Así es como lo depuraría:

1. Comprueba si hay errores tipográficos: Asegúrate de que el nombre de la tabla o del modelo esté escrito correctamente en la función ` ref() ` y comprueba que se esté haciendo referencia al modelo o a la tabla correctos.

SELECT * FROM {{ ref('orders') }}  -- Ensure 'orders' is the correct model name

1. Verifica las dependencias del modelo: Si tu modelo depende de otros modelos, comprueba el DAG (grafo acíclico dirigido) de dbt para asegurarte de que los modelos ascendentes se han creado correctamente antes de que se ejecute el modelo defectuoso.
2. Ejecuta dbt en modo de depuración: Utiliza dbt debug y comprueba los registros para obtener información detallada sobre lo que dbt intentó hacer y por qué falló.
3. Comprueba los permisos de la plataforma de datos: Asegúrate de que dbt tenga los permisos adecuados para acceder a la tabla o modelo referenciado en el almacén de datos.
4. Ejecuta modelos individuales: Prueba a ejecutar los modelos dependientes individualmente (por ejemplo, dbt run --models orders) para verificar que existen y que están construidos correctamente antes del modelo defectuoso.

Consejos para prepararse para una entrevista de dbt

dbt es un nuevo marco que está mejorando gradualmente. Puede resultar abrumador estar al día de las nuevas actualizaciones mientras sigues aprendiendo el material antiguo. Por eso debes adoptar un enfoque equilibrado y empezar por las funciones básicas. Una vez que los domines, explora las novedades para comprender qué ha cambiado. 

Sé que las entrevistas pueden ser estresantes, especialmente para una herramienta especializada como dbt. Pero no te preocupes, he recopilado algunos consejos para ayudarte a prepararte y sentirte seguro:

Características principales de dbt

No puedo insistir lo suficiente en esto: familiarízate con los conceptos fundamentales de DBT, incluidos los modelos, las pruebas, la documentación y cómo encajan todos ellos entre sí. Un buen dominio de estos conceptos básicos te será muy útil en las discusiones técnicas.

DataCamp tiene el curso perfecto para esto: Introducción a dbt 

DataCamp también ofrece algunos cursos aptos para principiantes que tratan otros temas relacionados con la ingeniería de datos en profundidad:

• Para los conceptos básicos de ingeniería de datos: Comprender la ingeniería de datos 
• Para el diseño de bases de datos: Diseño de bases de datos 
• Para conocer los conceptos básicos del almacenamiento de datos: Conceptos de almacenamiento de datos 
• Para conocer los conceptos básicos de Snowflake: Introducción a Snowflake 
• Para la arquitectura de datos: Comprender la arquitectura de datos moderna 
• Para aprender ETL y ELT en Python: ETL y ELT en Python 

Adquiere experiencia práctica con dbt

Leer sobre algo es bueno, pero hacerlo es aún mejor. Esta es una de las formas más eficaces de dominar las habilidades de dbt. Puedes encontrar una amplia lista de conjuntos de datos sin procesar en línea para realizar transformaciones y ejecutar pruebas. Configura tu propio proyecto dbt y prueba las diferentes funciones. Esto hará que te sientas mucho más seguro al hablar sobre dbt cuando lo hayas utilizado realmente.

Prepara ejemplos del mundo real.

A los entrevistadores les encanta escuchar sobre aplicaciones prácticas. ¿Se te ocurre algún problema que hayas resuelto utilizando dbt o cómo podrías utilizarlo en una situación hipotética? Ten preparados algunos de estos ejemplos para compartir. Para recopilar algunos ejemplos, puedes incluso estudiar varios casos prácticos en el sitio web oficial de dbt u obtener ideas de proyectos públicos de dbt en Git. 

Conclusión 

Hemos cubierto un amplio espectro de preguntas de entrevista sobre DBT, desde básicas hasta avanzadas, que te ayudarán en tu búsqueda de empleo. Al comprender cómo integrar dbt con los almacenes de datos en la nube, estarás bien equipado con habilidades avanzadas de transformación de datos, que son el núcleo de cualquier proceso de integración de datos. 

Sin embargo, aprender DBT y SQL van de la mano. Por lo tanto, si eres nuevo en SQL, echa un vistazo a los cursos de SQL de DataCamp.