Hoja 4: plan de oleadas de migración

Tiempo estimado: 15–20 minutos Referencia: Módulo 03 — Aprovisionamiento y migración → Módulo 04 — Reconstrucción dbt → Módulo 05 — Benchmark y transición para el orden de ejecución

Concepto

Los objetos de una base de datos tienen dependencias. Una vista que consulta fact_trips no puede crearse antes de que exista esa tabla. Una vista materializada que lee de trips_raw no puede poblarse antes de que esa tabla contenga datos. Migrar en un orden incorrecto provoca fallos al crear tablas, resultados vacíos o datos incompletos cuya causa resulta difícil de diagnosticar.

La solución consiste en planificar oleadas. Organiza todos los objetos en oleadas numeradas, de modo que cada una contenga únicamente objetos cuyas dependencias ya hayan sido satisfechas por las oleadas anteriores.

Calificar la complejidad ayuda a priorizar el esfuerzo de migración. La frontera entre B y C depende de si hay que reestructurar una instrucción o basta con cambiar los tipos:

• Grado A: trivial; una tabla estándar o una vista de paso, sin lógica especial y con un mapeo de tipos directo.
• Grado B: medio; hay un constructo específico de ClickHouse que se debe aprender y probar, pero la traducción en sí es una sustitución: un motor de ClickHouse más una configuración incremental, un CREATE DICTIONARY, el REFRESH EVERY de una vista materializada actualizable o una ruta JSONExtract* que sustituye una lectura VARIANT.
• Grado C: complejo; hay que reconstruir la instrucción, no solo tiparla (QUALIFY en una subconsulta o MERGE INTO sustituido por una estrategia incremental. Además, esa reescritura debe seguir siendo coherente con la elección de motor y con la ubicación de FINAL en todos los objetos posteriores; pruébala con cuidado.
• Grado D: requiere rediseño; una función específica de Snowflake sin equivalente directo, como sustituir Streams por la transición del productor a ClickHouse o Tasks por vistas materializadas actualizables o ejecuciones programadas de dbt.

El Ejercicio 3 pide calificar en una escala comprimida de tres niveles, en vez de las cuatro letras anteriores: Bajo (Grado A), Medio (Grado B) y Alto (Grado C o D). Para secuenciar el esfuerzo, la diferencia importante es entre algo trivial, algo que requiere pruebas y algo que requiere un rediseño, no la división en cuatro niveles. La explicación de cada respuesta indica cuál de las categorías A–D se aplica, para que puedas seguir relacionándola con la letra correspondiente.

Ejercicio 1: DAG de dependencias

Para cada objeto siguiente, elige de qué depende. Tres de los diez son datos de referencia estáticos sin ninguna dependencia; esa es una respuesta válida, no un hueco que debas completar más adelante.

Ejercicio 2: asignación de oleadas

Las oleadas 0 y 1 aparecen cumplimentadas como contexto, incluida trips_raw. Para las oleadas 2–4, elige los objetos que pertenecen a cada una y explica qué ocurre realmente con fact_trips en esa fase.

Ejercicio 3: calificación de complejidad

Califica cada objeto y responde después la pregunta sobre su desafío principal que aparece debajo de la tabla.

Preguntas de reflexión

Las dos últimas preguntas cubren las tres entradas del registro de riesgos de la clave de respuestas: verificar fact_trips (Grado C) y agg_hourly_zone_trips después de que se hayan migrado, y verificar la transición del productor que sustituye TRIPS_CDC_STREAM y CDC_CONSUME_TASK (Grado D). El registro no equivale simplemente al conjunto de elementos de Grado C o D: agg_hourly_zone_trips tiene una complejidad Media, pero su ventana móvil de recálculo es el aspecto más fácil de implementar de forma sutilmente incorrecta en toda la canalización.

Loading worksheet...

Transfiérelo a migration-plan.md

Copia el plan de oleadas y las calificaciones de complejidad en la Sección 6 de migration-plan.md y marca:

- [ ] Migration wave plan: completed