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) yANALYTICS_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.
Forma Medallion. Los datos pasan por tres capas de NYC_TAXI_DB:
- RAW:
TRIPS_RAWcontiene 50 millones de filas sintéticas de viajes, incluida una columnaTRIP_METADATAde tipoVARIANTque 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 estrategiaMERGE), cuatro tablas de dimensiones yagg_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) sobreTRIPS_RAW.CDC_CONSUME_TASK: lee ese stream cada 5 minutos; se ejecuta enRAWy se reanuda durante la preparación. A ella se sumaHOURLY_AGG_TASK, que actualiza el agregado horario cada hora; se ejecuta enSTAGINGy se reanuda después de que dbt construya los modelos.
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 detailsTanto .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.shEl 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 -dLa opción --env-file ../.env carga las variables de entorno desde el directorio padre.
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| Flag | Efecto |
|---|---|
--interval <n> | Intervalo: 30s, 5m, 1h o segundos simples (predeterminado 5m) |
--once | Ejecuta una actualización y termina |
--test | Ejecuta 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:
| Consulta | Constructo | Desafío |
|---|---|---|
| Q1 | DATE_TRUNC, DATEADD | Diferencia sintáctica menor |
| Q2 | Ventana ROWS BETWEEN | Casi idéntica en ClickHouse |
| Q3 | QUALIFY | Nativo desde v24.5, pero aquí se reescribe como subconsulta por portabilidad |
| Q4 | LATERAL FLATTEN | Sin equivalente; usa JSONExtract o preaplana |
| Q5 | Ruta con dos puntos VARIANT | Sustituye por JSONExtractFloat/JSONExtractString |
| Q6 | MERGE INTO | Sin equivalente; usa ReplacingMergeTree |
| Q7 | Streams de Snowflake | Se 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.shEl script comprueba lo siguiente:
- Base y esquemas:
NYC_TAXI_DBconRAW,STAGING,ANALYTICS. - Tablas y datos:
TRIPS_RAWtiene unos 50 millones de filas,FACT_TRIPSestá poblada y existen las dimensiones. - Stream CDC:
TRIPS_CDC_STREAMexiste sobreTRIPS_RAW. - Tareas:
CDC_CONSUME_TASKyHOURLY_AGG_TASKestán en estadostarted. - Actividad de CDC: las tareas se han ejecutado recientemente.
- Flujo del productor: el productor de viajes inserta datos continuamente.
- 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:
| Flag | Cuándo usarlo |
|---|---|
| (ninguno) | Primera ejecución. Aprovisiona todo y genera 50 millones de filas sintéticas (unos 12 min en total). |
--skip-seed | La infraestructura ya existe y TRIPS_RAW ya contiene datos. Omite la generación sintética (ahorra unos 8 min). |
--skip-dbt | Los objetos de Snowflake existen, pero no necesitas repetir las transformaciones de dbt, por ejemplo al probar cambios de Terraform. |
--skip-superset | Docker no está en ejecución o todavía no necesitas la capa de BI. |
--full-refresh | Obliga 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-supersetNota 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í.
00 Preparación
Instala herramientas, crea dos cuentas cloud de prueba, clona el repositorio y construye ambos entornos virtuales dbt antes de tocar datos.
02 Planificación y diseño
Perfila la carga Snowflake y toma las decisiones que ejecutará la migración: motor, claves, traducción, oleadas y modelos dbt.