Snowflake MigrationClickHouse Workshops

01 Entorno de origen

Provisiona un entorno Snowflake realista: 50 M de filas, canalización Medallion dbt, productor en vivo y tres paneles Superset.

Punto de partida

Has completado el módulo 00: las herramientas están instaladas, las dos cuentas cloud de prueba están activas, el repositorio está clonado y el entorno virtual de dbt-snowflake está construido. Este módulo tarda unos 45 minutos y consume aproximadamente entre 2 y 4 créditos de Snowflake.

Por qué

No puedes planificar una migración a partir de un origen de juguete. Una sola tabla plana con un puñado de filas permitiría eludir cada una de las decisiones que dificultan una migración real. Por eso este módulo construye la forma de un despliegue auténtico de cliente: una columna VARIANT con JSON semiestructurado, un stream de CDC, tareas programadas, una canalización incremental basada en MERGE y una capa de BI que lee por encima de todo ello. Cada elemento se convertirá en una decisión de migración concreta en el módulo 02. El objetivo es que, cuando llegue esa decisión, puedas señalar un sistema real y no una abstracción.

Conceptos internos

Infraestructura (Terraform). setup.sh provisiona:

  • Warehouses: TRANSFORM_WH (SMALL, para ELT) y ANALYTICS_WH (MEDIUM, para BI), además de un monitor de recursos (ANALYTICS_WH_MONITOR) limitado a 50 créditos al mes.
  • Base de datos: NYC_TAXI_DB, con tres esquemas: RAW, STAGING, ANALYTICS.
  • Roles: TRANSFORMER_ROLE, ANALYST_ROLE, DBT_ROLE, LOADER_ROLE.

Entorno de origen Snowflake: un generador puntual y un productor Docker continuo insertan en NYC_TAXI_DB, que tres paneles leen mediante el warehouse analítico

Forma Medallion. Los datos pasan por tres capas de NYC_TAXI_DB:

  • RAW: TRIPS_RAW contiene 50 millones de filas sintéticas de viajes, incluida una columna TRIP_METADATA de tipo VARIANT que simula telemetría de la aplicación. Este es el reto de migrar JSON. También incluye las tablas de dimensiones (DIM_TAXI_ZONES, DIM_PAYMENT_TYPE, DIM_VENDOR).
  • STAGING: vistas de dbt que limpian los tipos y aplanan la columna VARIANT.
  • ANALYTICS: tablas y modelos incrementales de dbt: fact_trips (50 millones de filas, con estrategia MERGE), cuatro tablas de dimensiones y agg_hourly_zone_trips, un agregado incremental.

Dos objetos de Snowflake mantienen esta canalización en movimiento por sí solos, con independencia de dbt:

  • TRIPS_CDC_STREAM: un stream de captura de cambios (CDC) sobre TRIPS_RAW.
  • CDC_CONSUME_TASK: lee ese stream cada 5 minutos; se ejecuta en RAW y se reanuda durante la preparación. A ella se suma HOURLY_AGG_TASK, que actualiza el agregado horario cada hora; se ejecuta en STAGING y se reanuda después de que dbt construya los modelos.

Dentro de NYC_TAXI_DB: TRIPS_RAW con VARIANT alimenta un stream CDC y una tarea, mientras dbt crea vistas staging, hechos, dimensiones y agregados

Superset. Los tres paneles leen del esquema ANALYTICS a través de ANALYTICS_WH; ninguno accede directamente a RAW ni STAGING. Esa ruta de lectura es la que reproducirás más adelante en el taller del lado de ClickHouse.

Paso 1 — Configura credenciales

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/01-setup-snowflake"

cp .env.example .env
# Edit .env with your Snowflake credentials

cp dbt/nyc_taxi_dbt/profiles.yml.example ~/.dbt/profiles.yml
# Edit ~/.dbt/profiles.yml with your account details

Tanto .env como ~/.dbt/profiles.yml se ignoran en Git porque contienen la cuenta, el usuario y la contraseña de Snowflake. No incorpores nunca ninguno de los dos archivos al repositorio.

Paso 2 — Ejecuta la configuración

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/01-setup-snowflake"
source .env && ./setup.sh

El proceso tarda 5–10 minutos, dedicados principalmente a generar 50 millones de filas sintéticas de viajes con TABLE(GENERATOR). setup.sh aprovisiona en una sola ejecución la infraestructura de Terraform, carga TRIPS_RAW, ejecuta la compilación de dbt e inicia Docker Compose con el productor de viajes y Superset.

Paso 3 — Inicia el productor y Superset

setup.sh inicia Docker Compose con el entorno correcto, registra la conexión de Snowflake en Superset e importa automáticamente los tres paneles.

Los ZIP en superset/dashboards/ tienen sqlalchemy_uri sustituida por marcadores (LAB_USER, MYORG-MYACCOUNT). La importación automática vuelve a asignar la URI a partir de tu .env, de modo que este detalle resulta transparente cuando se ejecuta setup.sh. Si importas un ZIP manualmente desde la interfaz de Superset, la conexión creada utilizará esos marcadores y no podrá conectarse; edítala después para que apunte a tu cuenta real de Snowflake.

Para reiniciar Superset manualmente:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/01-setup-snowflake/superset"
docker-compose --env-file ../.env up -d

La opción --env-file ../.env carga las variables de entorno desde el directorio padre.

Fuentes de paneles Superset: tres paneles operativos leen el esquema analítico mediante el warehouse analítico

Los tres paneles son Operations Command Center, Executive Weekly Report y Driver & Quality Analytics. Este último es deliberadamente lento, porque más adelante será el objetivo del benchmark de ClickHouse. Para conocer la construcción completa de los paneles —fuentes de datos, gráficos y filtros—, consulta Superset sobre Snowflake.

Paso 4 — Mantén dbt actualizado

El productor de viajes inserta continuamente unas 60 filas por minuto en TRIPS_RAW. Para mantener actualizados fact_trips y agg_hourly_zone_trips mientras trabajas, ejecuta el bucle de actualización de dbt en otro terminal:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/01-setup-snowflake"

# Default: refresh every 5 minutes (auto-sources .env)
./scripts/run_dbt.sh

# Custom interval
./scripts/run_dbt.sh --interval 15m

# Run once and exit
./scripts/run_dbt.sh --once

# Include dbt tests after each run
./scripts/run_dbt.sh --test
FlagEfecto
--interval <n>Intervalo: 30s, 5m, 1h o segundos simples (predeterminado 5m)
--onceEjecuta una actualización y termina
--testEjecuta dbt test tras cada dbt run

El script siempre se ejecuta de forma incremental: nunca realiza un --full-refresh, por lo que conserva las filas insertadas por el productor. Puedes pulsar Ctrl-C en cualquier momento para detenerlo, pero déjalo funcionando en su propio terminal durante el resto del laboratorio; el módulo 03 todavía depende de él.

Paso 5 — Explora la biblioteca de consultas

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/01-setup-snowflake"

El directorio (workshop_public/snowflake_migration_lab/01-setup-snowflake/queries/) contiene siete archivos SQL anotados. Cada uno se ejecuta contra el entorno de Snowflake que acabas de construir y plantea deliberadamente un reto de migración que el módulo 02 traducirá a ClickHouse:

ConsultaConstructoDesafío
Q1DATE_TRUNC, DATEADDDiferencia sintáctica menor
Q2Ventana ROWS BETWEENCasi idéntica en ClickHouse
Q3QUALIFYNativo desde v24.5, pero aquí se reescribe como subconsulta por portabilidad
Q4LATERAL FLATTENSin equivalente; usa JSONExtract o preaplana
Q5Ruta con dos puntos VARIANTSustituye por JSONExtractFloat/JSONExtractString
Q6MERGE INTOSin equivalente; usa ReplacingMergeTree
Q7Streams de SnowflakeSe retiran en la transición; el productor escribe directamente en ClickHouse

Abre cada archivo y ejecútalo contra tu entorno de Snowflake antes de continuar. El bloque de comentarios de cada consulta ya bosqueja su equivalente en ClickHouse; en el módulo 02 escribirás y ejecutarás de verdad esa versión.

Cómo verificar la finalización

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/01-setup-snowflake"
source .env && ./scripts/verify_environment.sh

El script comprueba lo siguiente:

  1. Base y esquemas: NYC_TAXI_DB con RAW, STAGING, ANALYTICS.
  2. Tablas y datos: TRIPS_RAW tiene unos 50 millones de filas, FACT_TRIPS está poblada y existen las dimensiones.
  3. Stream CDC: TRIPS_CDC_STREAM existe sobre TRIPS_RAW.
  4. Tareas: CDC_CONSUME_TASK y HOURLY_AGG_TASK están en estado started.
  5. Actividad de CDC: las tareas se han ejecutado recientemente.
  6. Flujo del productor: el productor de viajes inserta datos continuamente.
  7. Superset: los paneles de BI están accesibles en http://localhost:8088.

Si prefieres comprobarlo manualmente, ejecuta SHOW TASKS LIKE '%TASK' IN DATABASE NYC_TAXI_DB; con el rol ACCOUNTADMIN, propietario de las tareas, para confirmar que ambas están en ejecución.

Recapitulación

Volverás varias veces a este entorno durante los próximos módulos, y una ejecución completa de ./setup.sh cuesta entre 5 y 10 minutos que no querrás repetir cada vez que modifiques un archivo de Terraform o un modelo de dbt. setup.sh admite precisamente para eso las siguientes opciones:

FlagCuándo usarlo
(ninguno)Primera ejecución. Aprovisiona todo y genera 50 millones de filas sintéticas (unos 12 min en total).
--skip-seedLa infraestructura ya existe y TRIPS_RAW ya contiene datos. Omite la generación sintética (ahorra unos 8 min).
--skip-dbtLos objetos de Snowflake existen, pero no necesitas repetir las transformaciones de dbt, por ejemplo al probar cambios de Terraform.
--skip-supersetDocker no está en ejecución o todavía no necesitas la capa de BI.
--full-refreshObliga a dbt a reconstruir desde cero todos los modelos incrementales, por ejemplo después de cambiar un esquema.

Las opciones se pueden combinar. Estas son dos combinaciones habituales:

# Re-run after a Terraform or SQL change — skip the ~10 min data load
./setup.sh --skip-seed

# Iterate on dbt models only — skip everything else
./setup.sh --skip-seed --skip-superset

Nota de costes. La siembra de datos tarda unos 12 minutos y consume 2 créditos ($6); una compilación completa de dbt tarda unos 8 minutos y consume 1,5 créditos ($5). Una sesión de laboratorio de 8 horas por participante añade aproximadamente 12 créditos más (~$36). Los warehouses se suspenden automáticamente cuando están inactivos, por lo que el coste deja de acumularse entre sesiones. El total aproximado por participante y día es de 16 créditos, unos $47.

Estado final

Snowflake está activo: NYC_TAXI_DB está completamente construido, el stream de CDC y las dos tareas programadas están en ejecución, el productor de viajes escribe unas 60 filas por minuto en TRIPS_RAW y los tres paneles de Superset están disponibles en http://localhost:8088.

Deja el productor activo. No detengas la pila de Docker Compose ni ejecutes ./teardown.sh: los módulos 02–05 dependen de que este entorno permanezca en funcionamiento, y la transición del módulo 05 mide exactamente el desfase que crea el productor entre Snowflake y ClickHouse durante la migración. Desmontarlo ahora provocaría un fallo en el resto del taller cuya causa resultaría difícil de rastrear hasta este paso. El desmontaje se realiza al final del módulo 05, no aquí.

En esta página

¿Quieres seguir tu progreso?

Opcional. Enviaremos un enlace por correo para confirmar tu dirección; el progreso se registrará cuando lo abras.

Usa tu correo de trabajo, no uno personal.

Para seguir el progreso también debes aceptar los Términos del servicio actuales en la Configuración de privacidad.

ES