04 Reconstruction du pipeline dbt

Complément formateur du module participant 04 Reconstruction du pipeline dbt.

Durée

Environ 30 minutes. Le seul véritable temps mort est le deuxième dbt run de l’étape 1 (environ 8 à 12 minutes pour faire passer 50 millions de lignes dans les modèles incrémentiels) : trop court pour nécessiter une pause, mais assez long pour mériter une explication plutôt qu’une attente silencieuse. L’étape 2 (dictionnaire des zones) et les requêtes de vérification sont rapides et interactives.

Fil conducteur

• Présentez ce module comme la validation du pipeline, et non des données : le module 03 a prouvé que ClickHouse peut contenir 50 millions de lignes ; celui-ci prouve que le même pipeline Medallion que dans le module 01 — vues de préparation, table de faits incrémentielle, rechargement des dimensions et tests — conserve la même forme dans ClickHouse.
• Le mécanisme dbt à détailler est le suivant : delete_insert remplace MERGE INTO (ClickHouse n’a pas d’instruction MERGE) et ReplacingMergeTree constitue une protection sous-jacente, pas un substitut. Si delete_insert se termine normalement, RMT n’a rien à nettoyer ; il n’intervient qu’en cas d’interruption à mi-parcours.
• Mentionnez explicitement mv_live_trip_feed : cette vue n’a aucun équivalent dans Snowflake. Une vue matérialisée standard ne voit que les lignes du lot qui la déclenche ; une vue matérialisée ACTUALISABLE réexécute toute sa requête selon un planning et peut donc maintenir un agrégat sur toute la durée. Il s’agit d’une capacité ajoutée par la migration, pas d’un simple portage.
• Dites-le avant toute question : agg_hourly_zone_trips sera vide après le dbt run de l’étape 1, et c’est correct, pas une anomalie. Son filtre incrémentiel est WHERE pickup_at >= now() - INTERVAL 2 HOUR, qui ne correspond qu’aux lignes écrites par un producteur actif ; toutes les lignes qui viennent d’être migrées sont historiques. La table reste vide jusqu’au démarrage du producteur ClickHouse lors de la bascule du module 05. Les partenaires pensent systématiquement que le pipeline est cassé : devancez la question.

Erreurs courantes

• agg_hourly_zone_trips renvoie 0 ligne après l’étape 1 et un partenaire le signale comme une anomalie. Ce n’en est pas une — reportez-vous au fil conducteur. Vérifiez que dim_taxi_zones (265 lignes) et fact_trips (environ 50 millions de lignes) sont remplies avant de consacrer du temps à agg_hourly_zone_trips. Si ces deux tables sont correctes, la table agrégée vide fonctionne exactement comme prévu. C’est la principale fausse alerte du module : attendez-vous à cette question à chaque session.
• Le dbt run de l’étape 1 échoue ou ne parvient pas à se connecter. Ce module dépend du profil dbt ClickHouse que le module 03 aurait dû créer (~/.dbt/profiles.yml, nyc_taxi_ch). Si ce profil manque — consultez « Configurer le profil dbt » à l’étape 2 de 03 Provisionnement et migration —, l’étape 1 échoue ici, un module après la cause initiale.
• À FAIRE : la section ## dbt on ClickHouse de la page Résolution des problèmes ne contient aucune entrée consacrée à une erreur propre à cette étape. Ajoutez ici tout problème observé pendant les répétitions.

Étapes de réinitialisation

• Relancez librement dbt run : l’exécution est incrémentielle et peut être répétée en toute sécurité ; aucune suppression d’environnement n’est nécessaire.
• Après une modification d’un modèle dbt ou du schéma, forcez une reconstruction complète des modèles incrémentiels avec dbt run --full-refresh (depuis workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch).
• Si le dictionnaire des zones paraît erroné ou obsolète, relancez simplement scripts/04_create_dictionary.sql : il utilise CREATE OR REPLACE DICTIONARY et peut être exécuté à nouveau sans rien supprimer au préalable.
• Il n’existe aucune réinitialisation au niveau de l’environnement propre à ce module : le script est le même workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/teardown.sh que dans le module 03 ; ne l’exécutez pas au milieu du module.