04 Reconstrucción de la canalización dbt

Complemento para el facilitador de la lección del participante 04 Reconstrucción de la canalización dbt.

Tiempo

Unos 30 minutos. El único tramo con verdadero tiempo muerto es el segundo dbt run del Paso 1, que tarda aproximadamente entre 8 y 12 minutos en procesar 50 millones de filas a través de los modelos incrementales. Suele ser demasiado breve para justificar una pausa propia, pero lo bastante largo como para narrarlo en vez de contemplarlo en silencio. El Paso 2, dedicado al diccionario de zonas, y las consultas de verificación son rápidos e interactivos.

Guion

• Presenta el módulo como prueba de la canalización, no de los datos: el Módulo 03 probó que ClickHouse puede contener 50 millones de filas; este demuestra que la misma canalización Medallion del módulo 01 —vistas de staging, tabla de hechos incremental, recargas de dimensiones y pruebas— conserva su forma al ejecutarse en ClickHouse.
• Detente en delete_insert: sustituye MERGE INTO (ClickHouse no tiene MERGE) y ReplacingMergeTree es la red de seguridad, no su sustituto. Si delete_insert termina normalmente, RMT no limpia nada; solo importa tras una interrupción.
• Destaca mv_live_trip_feed: no tiene equivalente Snowflake. Una vista materializada estándar solo ve las filas del lote que la activa; una vista materializada REFRESHABLE vuelve a ejecutar periódicamente la consulta completa y, por tanto, puede mantener un agregado de todo el historial. Es una capacidad nueva que aporta la migración, no un traslado directo de algo que ya existía.
• Avísalo antes de que pregunten: agg_hourly_zone_trips queda vacía tras dbt run y es correcto. Su filtro WHERE pickup_at >= now() - INTERVAL 2 HOUR solo coincide con filas escritas por un productor en vivo; todas las filas recién migradas son históricas. Seguirá vacía hasta que el módulo 05 inicie el productor de ClickHouse durante la transición. Los participantes suelen interpretar esta situación como una canalización rota, así que anticípate a la pregunta.

Fallos habituales

• agg_hourly_zone_trips devuelve 0 filas y se informa como error. No lo es. Confirma que dim_taxi_zones (265 filas) y fact_trips (unos 50 millones) estén pobladas como se espera antes de dedicar tiempo a agg_hourly_zone_trips. Si esas dos están bien, el agregado vacío funciona exactamente como se diseñó. Este es el fallo principal del módulo: cuenta con que la pregunta aparecerá cada vez.
• dbt run falla o no conecta. Depende del perfil creado en el Módulo 03 (~/.dbt/profiles.yml, nyc_taxi_ch). Si falta, la causa raíz está en el Paso 2, «Configura el perfil dbt», de 03 Aprovisionamiento y migración. En ese caso, el Paso 1 falla aquí, un módulo después de la omisión que provocó el problema.
• TODO: la sección ## dbt on ClickHouse de Solución de problemas no tiene una entrada específica para un fallo que solo se manifiesta en este paso. Añade aquí cualquier particularidad observada durante el ensayo.

Pasos de restablecimiento

• Repite dbt run sin problema: es incremental y seguro volver a ejecutarlo, y nada de este módulo requiere un desmontaje.
• Tras cambiar un modelo o un esquema, fuerza una reconstrucción completa de los modelos incrementales con dbt run --full-refresh desde workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch.
• Si el diccionario de zonas parece incorrecto u obsoleto, repite scripts/04_create_dictionary.sql; utiliza CREATE OR REPLACE DICTIONARY y se puede ejecutar de nuevo con seguridad sin borrar nada antes.
• No hay un restablecimiento específico del entorno para este módulo. Su desmontaje es el mismo workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/teardown.sh que se explica en el módulo 03; no lo ejecutes a mitad de este módulo.