Hoja 5: diseño de modelos dbt

Tiempo estimado: 15–20 minutos Referencia: dbt en ClickHouse

Concepto

Las Hojas 1–4 produjeron el qué: qué motor, qué ORDER BY y qué tipos de ClickHouse. Esta hoja produce el cómo: la manera de expresar esas decisiones como configuración de dbt antes de escribir una sola línea de SQL.

Un modelo de dbt-clickhouse tiene tres capas de configuración en las que los desarrolladores de Snowflake no suelen tener que pensar:

1. Materialización: qué objeto físico crea dbt (view, table, incremental o ephemeral).
2. Configuración del motor: en las tablas y los modelos incrementales, qué motor de ClickHouse y qué columna de versión utiliza.
3. Estrategia incremental: en los modelos incrementales, cómo gestiona dbt las filas nuevas o actualizadas.

Existe además una cuestión de corrección específica de ReplacingMergeTree:

4. Colocación de FINAL: en qué punto del DAG de dbt debe aparecer FINAL para garantizar lecturas deduplicadas.

Utiliza este árbol de decisión para elegir la materialización:

• ¿Lectura de solo inserción desde una fuente, sin escribir en el modelo? → view
• ¿Lógica pura de unión, no consultada directamente? → ephemeral
• ¿Reconstrucción total en cada dbt, sin actualizaciones parciales? → table
• ¿Solo procesa filas nuevas o cambiadas? → incremental

Los modelos de staging siempre son vistas, la misma regla que se presentó en la Hoja

1. stg_trips y stg_taxi_zones son lecturas de paso que no reciben escrituras propias, por lo que permanecen como vistas independientemente del comportamiento de sus datos de origen.

Ejercicio 1: selección de materialización

Elige la materialización de dbt correcta para cada modelo y responde después a la pregunta que aparece debajo de la tabla para justificar por qué.

Ejercicio 2: configuración del motor

Solo los modelos con materialización table o incremental necesitan un motor de ClickHouse; las vistas y los modelos ephemeral no tienen ninguno. Consulta tus respuestas de la Hoja 1: la configuración del motor en dbt es la implementación de las decisiones que ya tomaste allí.

Ejercicio 3: estrategia incremental

Para cada modelo incremental, diseña la configuración completa: unique_key, incremental_strategy y el filtro SQL que debe ir dentro del bloque de protección is_incremental():

{% if is_incremental() %}
  WHERE <your filter here>
{% endif %}

Ejercicio 4: colocación de FINAL

La deduplicación de ReplacingMergeTree es asíncrona. FINAL obliga a realizarla en el momento de la lectura, pero colocar FINAL en el modelo equivocado tiene consecuencias para la corrección o el rendimiento. Para cada modelo siguiente, decide si FINAL debe aparecer en la cláusula FROM del propio modelo.

Loading worksheet...

Transfiérelo a migration-plan.md

Cuando hayas completado esta hoja, rellena la Sección 10 de migration-plan.md con tus respuestas y marca:

- [ ] dbt model design: completed