02 Planification et conception

Complément formateur du module participant 02 Planification et conception.

Durée

Environ 90 minutes, presque entièrement sous forme de travail actif. Ce module est le seul construit autour de fiches remplies individuellement ou en binôme, plutôt que de scripts qui tournent en arrière-plan. L’étape 1 (script de profilage) est la seule partie automatisée et se termine en quelques minutes ; les 90 minutes sont réellement consacrées aux cinq fiches de l’étape 2 et à migration-plan.md à l’étape 3. Ne prévoyez pas de pause au milieu de ce module ; si la salle en a besoin, placez-la à la transition avec le module 03, et non pendant les fiches.

Fil conducteur

• Commencez par expliquer ce que ce module n’est pas : il ne retarde pas la « vraie » migration du module 03. Les migrations ClickHouse décevantes souffrent le plus souvent d’un problème d’architecture, pas d’optimisation — les équipes déplacent d’abord les données et conçoivent ensuite.
• Dites-le directement, car c’est le meilleur argument pour consacrer 90 minutes à ce travail : c’est le module que les partenaires seront le plus tentés de sauter, puisque le setup.sh du module 03 se contente d’avertir si migration-plan.md est absent ou incomplet ; il ne bloque jamais.
• Décrivez ce qui se passe si un partenaire le saute malgré tout : le module 03 réussira mécaniquement — fact_trips sera créé avec ReplacingMergeTree et les données seront déplacées — mais le partenaire ignorera pourquoi ce moteur est préférable à un simple MergeTree, comment la clé ORDER BY découle des requêtes, ce que signifient delete_insert et FINAL dans la configuration dbt, et comment expliquer ou reproduire les gains du benchmark du module 05 chez un client.
• Ne montrez la page de référence Exemple résolu qu’après que les partenaires ont essayé de rédiger leur propre plan : c’est une vérification, pas un modèle à copier avant de réfléchir.

Erreurs courantes

• ACCOUNT_USAGE n’est pas disponible lorsque le script de profilage de l’étape 1 s’exécute. Il faut soit attendre 1 à 3 heures après la création du compte Snowflake, soit utiliser le rôle ACCOUNTADMIN. Le script se rabat automatiquement sur INFORMATION_SCHEMA et indique les mesures impossibles à obtenir : il s’agit d’une dégradation contrôlée, pas d’un plantage, mais le partenaire peut ne pas remarquer le repli. Orientez-le vers scripts/02_query_history.sql, exécutable manuellement dans l’interface Snowflake, si le profil automatique paraît trop sommaire.
• Un partenaire considère comme facultative la liste de contrôle d’achèvement dans migration-plan.md. Elle ne l’est pas : le setup.sh du module 03 la lit, et une case non cochée signale que ce module a été omis sur le fond, même si le fichier existe.
• À FAIRE : contrairement aux modules 01 et 03, le README de ce module ne contient pas de section de résolution des problèmes. Complétez cette liste après une répétition des fiches avec un groupe réel.

Étapes de réinitialisation

• profile_report.md (sortie de l’étape 1) est ignoré par Git et est régénéré à partir du compte Snowflake actif du partenaire à chaque exécution. S’il semble obsolète ou incorrect, relancez simplement ./scripts/01_profile_snowflake.sh. Rien n’est à supprimer.
• Les cinq fiches sont remplies sur le site ; les réponses sont évaluées immédiatement et enregistrées dans le navigateur du participant (localStorage), pas dans le dépôt. migration-plan.md reste modifié directement dans le dépôt. Ce module ne provisionne rien dans les clouds : il n’existe donc ni teardown.sh ni option de préparation à utiliser.
• Si une fiche se retrouve dans un mauvais état, utilisez sa commande « Effacer les réponses » plutôt qu’un checkout Git : les réponses n’ont jamais touché Git, un checkout ne servirait donc à rien.