Fiche 1 : choix du moteur MergeTree
Choisissez un moteur MergeTree pour chaque table NYC Taxi et recevez une correction immédiate pour chaque réponse.
Durée estimée : 15 à 20 minutes Référence : Moteurs MergeTree
Concept
Dans Snowflake, vous créez une table et Snowflake décide de son mode de stockage. Dans ClickHouse, vous choisissez le moteur de stockage — et ce choix conditionne l’exactitude, pas seulement les performances.
Les trois moteurs nécessaires à cet atelier sont les suivants :
MergeTree — moteur de base. Les données sont conservées dans des fichiers colonnes triés. Aucune déduplication. Utilisez-le lorsque la table ne reçoit que des insertions ou quand le pipeline gère les mises à jour ailleurs (par exemple par un rechargement complet à chaque exécution dbt).
ReplacingMergeTree(version_col) — étend MergeTree avec une déduplication en
arrière-plan. Lorsque des lignes ayant la même clé ORDER BY existent dans plusieurs
parties, seule celle dont la valeur version_col est la plus élevée est conservée après
une fusion. Utilisez-le lorsque les lignes peuvent être mises à jour et qu’une colonne
augmente de façon monotone à chaque modification (par exemple l’horodatage updated_at).
Piège essentiel : la déduplication est asynchrone. Tant que ClickHouse n’a pas effectué une fusion en arrière-plan, l’ancienne et la nouvelle version d’une ligne coexistent. Utilisez toujours
SELECT ... FINALsur les tables ReplacingMergeTree pour forcer la déduplication au moment de la requête.
AggregatingMergeTree — étend MergeTree avec la fusion d’états d’agrégation partiels. Utilisez-le lorsque la table conserve des états d’agrégation combinables (par exemple des esquisses HyperLogLog ou des synthèses de quantiles) qui doivent être agrégés en arrière-plan. Il n’est pas nécessaire dans l’atelier NYC Taxi : les tables d’agrégats sont reconstruites par dbt, et non accumulées.
Arbre de décision
Does the table receive UPDATE or DELETE operations?
│
├── No (insert-only)
│ └─► MergeTree()
│
└── Yes
├── Is there a timestamp/version column that increases on every update?
│ ├── Yes → ReplacingMergeTree(version_col)
│ └── No (e.g., full-reload dimension tables)
│ └─► MergeTree() — dbt handles upsert via atomic table swap (full rebuild)
│
└── Does the table store partial aggregate states (AggregateFunction types)?
└── Yes → AggregatingMergeTree()Les modèles de préparation sont toujours des vues
Avec dbt et ClickHouse, les modèles de préparation doivent être matérialisés sous forme de vues, et non de tables. Les vues n’occupent aucun stockage et restent toujours à jour : ce sont simplement des requêtes SQL enregistrées, pas des objets physiques.
L’exercice ci-dessous porte sur les modèles dbt de la couche analytics (tables de
faits, agrégats et dimensions) ainsi que sur la vue matérialisée ClickHouse. Il n’inclut
ni trips_raw ni les modèles de préparation :
trips_rawest une table ClickHouse de base créée directement par le script de migration (scripts/02_migrate_trips.py) — ce n’est pas un modèle dbt. Elle utiliseReplacingMergeTree(_synced_at)parce que le script peut recommencer un lot et insérer à nouveau le mêmetrip_id. Après la bascule, le producteur actif peut également retenter une écriture après une erreur transitoire ;_synced_at DateTime DEFAULT now()garantit que l’écriture la plus récente l’emporte.stg_tripsest une vue dbt construite surtrips_raw. Elle appliqueSELECT ... FROM trips_raw FINALpour éliminer les doublons non encore fusionnés avant que les données n’atteignent les modèles analytics en aval. La responsabilité de la déduplication se trouve ici, et non dans une table de préparation ReplacingMergeTree.
Exercice : choix du moteur pour les tables NYC Taxi
Pour chaque table ci-dessous, déterminez le modèle de mise à jour, identifiez la colonne de version éventuelle et choisissez le moteur qui garantit l’exactitude de la table. Répondez ensuite aux questions de raisonnement une fois toutes les lignes remplies.
Loading worksheet...
Report dans migration-plan.md
Après avoir rempli cette fiche, copiez vos choix de moteurs dans la section 3 de
migration-plan.md et cochez :
- [ ] Engine selection: completed02 Planification et conception
Établissez le profil de la charge Snowflake, puis prenez les décisions d’architecture que la migration mettra en œuvre — moteurs, clés de tri, traduction du schéma, vagues de déploiement et conception des modèles dbt.
Fiche 2 : conception des clés de tri (ORDER BY)
Déduisez la clause ORDER BY de chaque table NYC Taxi à partir de ses requêtes et recevez une correction immédiate pour chaque réponse.