Fiche 4 : plan des vagues de migration

Répartissez dix objets NYC Taxi dans des vagues de migration et évaluez la complexité de chacun, avec une correction immédiate pour chaque réponse.

Durée estimée : 15 à 20 minutes Référence : Module 03 — Provisionnement et migration → Module 04 — Reconstruction du pipeline dbt → Module 05 — Benchmark et bascule pour l’ordre d’exécution

Concept

Les objets d’une base de données ont des dépendances. Une vue qui interroge fact_trips ne peut pas être créée avant que fact_trips existe. Une vue matérialisée qui lit trips_raw ne peut pas être remplie avant que trips_raw contienne des données. Une migration dans le mauvais ordre entraîne des échecs de création, des résultats vides ou des données incomplètes difficiles à diagnostiquer.

La solution : planifier par vagues. Répartissez tous les objets dans des vagues numérotées, chacune ne contenant que des objets dont les dépendances ont été satisfaites par les vagues précédentes.

L’évaluation de la complexité aide à hiérarchiser le travail de migration. La limite entre B et C dépend de la nécessité de restructurer une instruction ou simplement d’en modifier les types :

Niveau A — trivial : table standard ou vue de transmission, aucune logique particulière, correspondance des types directe
Niveau B — moyen : une construction propre à ClickHouse à apprendre et à tester, mais la traduction reste une substitution — moteur ClickHouse associé à une configuration incrémentielle, CREATE DICTIONARY, clause REFRESH EVERY d’une MV actualisable ou chemin JSONExtract* remplaçant une lecture VARIANT
Niveau C — complexe : une instruction doit être reconstruite, pas seulement retypée (QUALIFY enveloppé dans une sous-requête, MERGE INTO remplacé par une stratégie incrémentielle), et cette réécriture doit rester cohérente avec le choix du moteur et l’emplacement de FINAL dans tous les objets en aval ; à tester avec soin
Niveau D — reconception nécessaire : fonctionnalité propre à Snowflake sans équivalent direct (Streams → bascule du producteur vers ClickHouse, Tasks → MV actualisables ou exécutions dbt planifiées)

L’exercice 3 demande d’utiliser une échelle condensée à trois niveaux plutôt que les quatre lettres ci-dessus — Low (niveau A), Medium (niveau B), High (niveau C ou D) — car, pour organiser l’effort, la distinction essentielle est trivial / nécessite des tests / nécessite une reconception. L’explication de chaque réponse indique le niveau A à D correspondant, afin que vous puissiez toujours revenir à la note en lettre.

Exercice 1 : DAG des dépendances

Pour chaque objet ci-dessous, indiquez ses dépendances. Trois des dix objets sont des données de référence statiques sans aucune dépendance : c’est une véritable réponse, pas un blanc à remplir plus tard.

Exercice 2 : affectation aux vagues de migration

Les vagues 0 et 1 sont déjà remplies pour donner le contexte. Pour les vagues 2 à 4, choisissez les objets concernés, puis décrivez ce qui s’y passe réellement.

Exercice 3 : évaluation de la complexité

Évaluez chaque objet, puis répondez sous le tableau à la question portant sur sa principale difficulté.

Questions de réflexion

Les deux dernières questions couvrent les trois entrées du registre des risques du corrigé : vérification de fact_trips (niveau C) et de agg_hourly_zone_trips après leur création, puis vérification de la bascule du producteur qui remplace TRIPS_CDC_STREAM et CDC_CONSUME_TASK (niveau D). Le registre ne correspond pas simplement à l’ensemble des niveaux C/D : agg_hourly_zone_trips est de niveau Medium, mais sa fenêtre de recalcul glissante est l’élément le plus facile à rendre subtilement incorrect dans ce pipeline.

Loading worksheet...

Report dans migration-plan.md

Copiez votre plan des vagues et vos niveaux de complexité dans la section 6 de migration-plan.md, puis cochez :

- [ ] Migration wave plan: completed