Atelier de migration Snowflake NYC Taxi
Migrez vers ClickHouse Cloud une charge Snowflake représentative de la production — 50 millions de lignes, un pipeline dbt Medallion, sept requêtes analytiques, des producteurs actifs et des tableaux de bord BI — puis défendez vos choix.
Bienvenue dans le guide pratique de l’atelier de migration Snowflake NYC Taxi. Cet atelier s’adresse aux architectes solutions ClickHouse et aux partenaires qui apprennent à migrer vers ClickHouse Cloud une charge Snowflake de niveau production : un flux synthétique de courses de taxi à New York comportant 50 millions de lignes, un pipeline dbt Medallion complet, sept requêtes analytiques complexes, des producteurs de données actifs et des tableaux de bord Superset. L’ensemble reproduit le type de charge que vous rencontrerez lors de missions réelles chez des clients.
Pourquoi cet atelier
Cet atelier ne consiste pas simplement à déplacer des lignes d’un warehouse à un autre —
un script de copie suffirait. Il s’agit de prendre, puis de défendre, les décisions
qu’impose une migration réelle : quelle famille de moteurs MergeTree convient à chaque
table, comment concevoir une clé ORDER BY véritablement utile et quels idiomes SQL de
Snowflake n’ont pas d’équivalent direct dans ClickHouse. À l’issue de l’atelier, vous
saurez établir le profil d’une charge Snowflake, choisir correctement les moteurs et les
schémas, exécuter une migration de type production avec un script reprenable,
reconstruire un pipeline dbt dans ClickHouse, chiffrer l’intérêt économique à l’aide d’un
benchmark de sept requêtes, puis expliquer et défendre chacune de ces décisions.
Ce guide comporte trois parcours. Le parcours participant constitue la formation à suivre. Le parcours formateur accompagne les mêmes modules avec le minutage, le fil conducteur, les erreurs courantes et les étapes de réinitialisation. La section Référence rassemble des guides permanents sur les moteurs, dbt et les tableaux de bord ; ils sont destinés à être consultés en parallèle d’un module, et non dans un ordre imposé.
Modules
| N° | Participant | Formateur | Résultat |
|---|---|---|---|
| 00 | Préparation | notes | Chaîne d’outils installée, deux comptes d’essai cloud créés, dépôt cloné et deux environnements virtuels dbt configurés — tout ce dont la migration a besoin avant de manipuler les données |
| 01 | Environnement source | notes | Un environnement Snowflake représentatif d’un déploiement client réel : 50 millions de lignes, un pipeline dbt Medallion, un producteur de courses actif et trois tableaux de bord Superset |
| 02 | Planification et conception | notes | Profil de la charge Snowflake et décisions d’architecture rendues explicites avant leur mise en œuvre : choix des moteurs, clés de tri, traduction du schéma, vagues de déploiement et conception des modèles dbt |
| 03 | Provisionnement et migration | notes | ClickHouse Cloud provisionné avec Terraform, tables cibles créées à partir de votre plan et 50 millions de lignes déplacées avec un script de migration Python reprenable |
| 04 | Reconstruction du pipeline dbt | notes | Pipeline Medallion reconstruit dans ClickHouse avec dbt-clickhouse — modèles incrémentiels delete_insert, ReplacingMergeTree, vues matérialisées actualisables — et dictionnaire des zones créé |
| 05 | Benchmark et bascule | notes | Tableaux de bord reconstruits dans ClickHouse, sept requêtes comparées sur les deux moteurs, producteur basculé, parité vérifiée et deux environnements cloud supprimés |
| 06 | Évaluation | notes | Évaluation à livre ouvert terminée — 20 questions à choix multiple et 4 questions ouvertes — afin d’obtenir le ClickHouse Migration Proficiency Badge |
Ce que cet atelier ne couvre pas
L’atelier se concentre sur le schéma de migration principal. Les sujets suivants sont volontairement hors périmètre :
- Ingestion de flux en temps réel — après la bascule, l’atelier emploie un producteur de courses sous Docker pour les écritures actives, et non Kafka, Kinesis ou des sources de streaming ClickPipes.
- Clusters ClickHouse multinœuds — tous les travaux reposent sur un déploiement ClickHouse Cloud à service unique ; les déploiements distribués autohébergés (sharding, topologie de réplication) ne sont pas abordés.
- Gouvernance des données et contrôle d’accès — le contrôle d’accès par rôles, la sécurité au niveau des lignes et les politiques de masquage ne sont pas mis en œuvre.
- Évolution incrémentielle du schéma — l’atelier conserve un schéma fixe ; la gestion des changements de schéma en direct pendant la migration n’est pas couverte.
- Sources autres que Snowflake — le modèle de migration est propre à Snowflake. PostgreSQL, MySQL, BigQuery et les autres sources emploient des dialectes SQL et des approches CDC différents.
- SLA et supervision en production — l’observabilité, les alertes et la gestion des SLA dans ClickHouse Cloud en production ne sont pas abordées.
Durée et coût
| Module | Durée écoulée | Crédits Snowflake | ClickHouse Cloud |
|---|---|---|---|
| 00 — Préparation | ~30 min | — | — |
| 01 — Environnement source | ~45 min | ~2–4 crédits | — |
| 02 — Planification et conception | ~90 min | ~0,5 crédit | — |
| 03 — Provisionnement et migration | ~60 min | ~1–2 crédits | ~1–2 $ (essai) |
| 04 — Reconstruction du pipeline dbt | ~30 min | ~0,5–1 crédit | ~0,5–1 $ (essai) |
| 05 — Benchmark et bascule | ~45 min | ~1–2 crédits | ~0,5–1 $ (essai) |
| 06 — Évaluation | ~60 min | — | — |
| Total | ~6 heures | ~6–10 crédits | ~2–4 $ |
Les estimations de crédits Snowflake supposent un warehouse X-Small standard. Le coût ClickHouse Cloud suppose un service de niveau Development supprimé au bout de quelques heures.