01 Environnement source

Complément formateur du module participant 01 Environnement source.

Durée

Environ 45 minutes au total. L’étape 2 (./setup.sh) est la seule phase autonome — environ 5 à 10 minutes, principalement consacrées à la génération synthétique avec TABLE(GENERATOR) — et il vaut mieux la commenter que la regarder en silence ; c’est un bon moment pour suivre le fil conducteur ci-dessous. Le reste du temps (étapes 1 et 3 à 5) nécessite le partenaire au clavier : configuration des identifiants, vérification du démarrage du producteur et de Superset, lancement de la boucle d’actualisation dbt et lecture des sept requêtes.

Fil conducteur

• Ce module sert à créer une source qui mérite d’être migrée : une colonne VARIANT, un stream CDC, deux tâches planifiées et une couche BI qui s’appuie sur l’ensemble — pas une table jouet. Chacun de ces éléments donnera lieu à une décision de migration précise dans le module 02.
• Parcourez une fois la forme Medallion sur le schéma : RAW -> STAGING -> ANALYTICS dans NYC_TAXI_DB, ainsi que les objets qui maintiennent le mouvement indépendamment de dbt — TRIPS_CDC_STREAM et les deux tâches planifiées.
• Attirez l’attention sur la bibliothèque de requêtes (étape 5), même si les partenaires ne les traduiront qu’au module 02 : chacune comporte déjà un commentaire qui esquisse son équivalent ClickHouse, ce qui leur permet de commencer à reconnaître les motifs.
• Dites clairement, puis répétez à la fin du module, qu’il faut laisser fonctionner le producteur et la boucle d’actualisation dbt. La bascule du module 05 mesure précisément l’écart que le producteur crée entre Snowflake et ClickHouse pendant la migration ; un partenaire qui « range » l’environnement en l’arrêtant ici détruit silencieusement cette démonstration trois modules plus tard.

Erreurs courantes

• terraform init échoue avec une erreur de fournisseur. Vérifiez que Terraform >= 1.6 est installé et que la machine accède au registre Terraform sur Internet.
• snowsql refuse la connexion. Vérifiez SNOWFLAKE_ORG et SNOWFLAKE_ACCOUNT, puis testez directement avec snowsql -a ${SNOWFLAKE_ORG}-${SNOWFLAKE_ACCOUNT} -u ${SNOWFLAKE_USER}.
• dbt run échoue avec relation not found. Exécutez d’abord ./setup.sh --skip-seed — qui crée la structure de la base — et vérifiez que profiles.yml pointe vers NYC_TAXI_DB.
• Superset affiche connection refused. Superset a besoin d’environ 60 secondes pour s’initialiser après docker-compose up ; consultez docker logs nyc_taxi_superset s’il n’est toujours pas disponible ensuite.
• Le chargement initial prend plus de temps que prévu. L’insertion avec TABLE(GENERATOR) produit 50 millions de lignes en 10 à 12 minutes environ ; l’UPDATE qui renseigne ensuite la colonne JSON TRIP_METADATA sur ces 50 millions de lignes peut ajouter 15 à 20 minutes avec un warehouse SMALL. C’est un comportement normal de Snowflake lors d’une mise à jour importante d’une colonne VARIANT, pas un blocage : dites-le avant qu’un partenaire ne tente de dépanner un script qui fonctionne.
• Un partenaire arrête le producteur de courses parce que ce module semble « terminé ». Il ne l’est pas : les modules 02 à 05 dépendent de son maintien en activité, et la bascule du module 05 mesure précisément l’écart qu’il crée. C’est l’erreur de rangement la plus dommageable de tout l’atelier ; répétez-le explicitement.

Étapes de réinitialisation

• Reprovisionner sans repayer les quelque 10 minutes de chargement : ./setup.sh --skip-seed (l’infrastructure existe déjà et TRIPS_RAW contient des données).
• Modifier uniquement Terraform ou SQL : ./setup.sh --skip-seed suffit.
• Modifier uniquement les modèles dbt en ignorant complètement Superset : ./setup.sh --skip-seed --skip-superset.
• Tester des changements Terraform sans relancer dbt : ajoutez --skip-dbt.
• Après un changement du schéma d’un modèle dbt, forcez une reconstruction incrémentielle complète avec --full-refresh (à combiner avec --skip-seed pour ne pas relancer le chargement des données).
• Ne procédez à une réinitialisation complète que si l’environnement est irrécupérable : exécutez source .env && ./teardown.sh depuis workshop_public/snowflake_migration_lab/01-setup-snowflake/, puis relancez simplement ./setup.sh. Cette opération est destructive et répète tout le chargement de 10 à 12 minutes : n’en faites pas le premier réflexe face à un partenaire bloqué.