Laboratorio de migración de NYC Taxi desde Snowflake
Migra a ClickHouse Cloud una carga Snowflake de producción —50 millones de filas, una canalización Medallion con dbt, siete consultas analíticas, productores en vivo y paneles de BI— y defiende tus decisiones.
Bienvenido a la guía del laboratorio de migración de NYC Taxi desde Snowflake. Está dirigido a arquitectos de soluciones de ClickHouse y partners que aprenden a migrar una carga Snowflake de nivel productivo a ClickHouse Cloud: un flujo sintético de viajes en taxi de Nueva York con 50 millones de filas, una canalización Medallion completa en dbt, siete consultas analíticas complejas, productores de datos en vivo y paneles de Superset, construido para simular las cargas que encontrarás con clientes reales.
Por qué existe este taller
El objetivo no es trasladar filas de un warehouse a otro: un script de copia ya lo hace.
El objetivo es tomar y defender las decisiones que impone una migración real: qué familia
de motores MergeTree encaja con cada tabla, cómo diseñar una clave ORDER BY que se gane
su lugar y qué modismos SQL de Snowflake no tienen equivalente directo en ClickHouse. Al
terminar podrás perfilar una carga de Snowflake, tomar decisiones correctas sobre el
motor y el esquema, ejecutar una migración al estilo de producción mediante un script
reanudable, reconstruir una canalización de dbt en ClickHouse, cuantificar el caso de
negocio con un benchmark de siete consultas y explicar y defender cada una de esas
decisiones.
Esta guía tiene tres itinerarios. El itinerario del participante es la lección práctica que debes completar. El itinerario del instructor sirve de complemento al facilitador para los mismos módulos: incluye tiempos, guiones, fallos habituales y pasos de restablecimiento. La sección de referencia contiene material permanente —guías sobre motores, dbt y paneles— pensado para consultarse junto a cualquier módulo, no en un orden concreto.
Módulos
| # | Alumnado | Instructor | Resultado |
|---|---|---|---|
| 00 | Preparación | notas | Herramientas instaladas, las dos cuentas cloud de prueba creadas, el repositorio clonado y los dos entornos virtuales de dbt construidos: todo lo que necesita la migración antes de tocar los datos |
| 01 | Entorno de origen | notas | Un entorno de Snowflake que reproduce un despliegue real de cliente: 50 millones de filas, una canalización Medallion de dbt, un productor de viajes en vivo y tres paneles de Superset |
| 02 | Planificación y diseño | notas | La carga de Snowflake perfilada y las decisiones arquitectónicas que ejecutará la migración hechas explícitas: selección de motores, claves de ordenación, traducción del esquema, oleadas de despliegue y diseño de modelos dbt |
| 03 | Aprovisionamiento y migración | notas | ClickHouse Cloud aprovisionado con Terraform, las tablas de destino creadas a partir del plan y 50 millones de filas trasladadas mediante un script de migración reanudable en Python |
| 04 | Reconstrucción de la canalización dbt | notas | Canalización Medallion reconstruida en ClickHouse con dbt-clickhouse —modelos incrementales delete_insert, ReplacingMergeTree y vistas materializadas actualizables—, junto con el diccionario de zonas |
| 05 | Benchmark y transición | notas | Paneles reconstruidos en ClickHouse, las siete consultas medidas en ambos motores, el productor trasladado, la paridad verificada y ambas nubes desmontadas |
| 06 | Evaluación | notas | Evaluación a libro abierto de 20 preguntas de opción múltiple y 4 preguntas abiertas completada para obtener la insignia ClickHouse Migration Proficiency |
Qué no cubre el laboratorio
El alcance se limita al patrón principal de migración. Quedan fuera intencionadamente:
- Ingesta en streaming en tiempo real: después de la transición, el laboratorio utiliza un productor de viajes basado en Docker para las escrituras en vivo, no Kafka, Kinesis ni orígenes de streaming de ClickPipes.
- Clústeres ClickHouse multinodo: todo el trabajo se realiza en un único servicio de ClickHouse Cloud. No se tratan los despliegues distribuidos autogestionados, como el sharding o la topología de replicación.
- Gobernanza de datos y control de acceso: no se implementan el acceso basado en roles, la seguridad a nivel de fila ni las políticas de enmascaramiento.
- Evolución incremental del esquema: el laboratorio utiliza un esquema fijo en todo momento; no se explica cómo gestionar cambios de esquema en vivo durante la migración.
- Fuentes distintas de Snowflake: el patrón de migración es específico de Snowflake. PostgreSQL, MySQL, BigQuery y otras fuentes utilizan dialectos SQL y enfoques de CDC diferentes.
- SLA y monitorización de producción: no se cubren la observabilidad, las alertas ni la gestión de acuerdos de nivel de servicio en ClickHouse Cloud para producción.
Tiempo y coste
| Módulo | Tiempo transcurrido | Créditos Snowflake | ClickHouse Cloud |
|---|---|---|---|
| 00 — Preparación | ~30 min | — | — |
| 01 — Entorno de origen | ~45 min | ~2–4 créditos | — |
| 02 — Planificación y diseño | ~90 min | ~0,5 créditos | — |
| 03 — Aprovisionamiento y migración | ~60 min | ~1–2 créditos | ~$1–2 (prueba) |
| 04 — Reconstrucción dbt | ~30 min | ~0,5–1 créditos | ~$0,5–1 (prueba) |
| 05 — Benchmark y transición | ~45 min | ~1–2 créditos | ~$0,5–1 (prueba) |
| 06 — Evaluación | ~60 min | — | — |
| Total | ~6 horas | ~6–10 créditos | ~$2–4 |
Las estimaciones de Snowflake suponen un warehouse X-Small estándar. El coste de ClickHouse Cloud supone un servicio Development desmontado en pocas horas.