02 Planificación y diseño

Complemento para la lección 02 Planificación y diseño.

Tiempo

Unos 90 minutos, y casi ninguno de ellos es desatendido. Es el único módulo que gira en torno a hojas de trabajo individuales o por parejas, en vez de scripts que se ejecutan en segundo plano. El Paso 1, el script de perfilado, es la única parte automatizada y termina en pocos minutos; el resto —las cinco hojas del Paso 2 y migration-plan.md en el Paso 3— es donde se emplean realmente los 90 minutos. No programes una pausa dentro de este módulo. Si la sala la necesita, hazla al pasar al módulo 03 y no a mitad de las hojas de trabajo.

Guion

• Empieza por aclarar lo que este módulo no es: no es una demora antes de la migración «real» del módulo 03. La causa más habitual de que una migración a ClickHouse rinda menos de lo esperado es un problema de arquitectura, no de ajuste: los equipos mueven primero los datos y dejan el diseño para después.
• Dilo expresamente, porque es el mejor argumento para dedicarle los 90 minutos: es el módulo que los participantes se sienten más tentados de omitir, ya que setup.sh en el módulo 03 se limita a avisar cuando falta migration-plan.md o está incompleto; nunca impide continuar.
• Explica qué ocurre si aun así alguien se lo salta. La mecánica del módulo 03 seguirá funcionando: fact_trips se creará como ReplacingMergeTree y los datos se moverán. Sin embargo, esa persona no sabrá por qué se eligió ese motor en vez de un MergeTree sencillo, cómo se dedujo la clave ORDER BY de la carga de consultas, qué significan delete_insert y FINAL en la configuración de dbt ni cómo explicar o reproducir para un cliente las mejoras del benchmark del módulo 05.
• Señala la página de referencia con el ejemplo resuelto solo después de que los participantes hayan intentado elaborar su propio plan. Es una comprobación de coherencia, no una plantilla que deban copiar antes de reflexionar.

Fallos habituales

• ACCOUNT_USAGE no está disponible al ejecutar el script de perfilado del Paso 1. Hace falta esperar entre 1 y 3 horas para que los datos se propaguen después de crear la cuenta de Snowflake, o bien usar el rol ACCOUNTADMIN. El script recurre automáticamente a INFORMATION_SCHEMA y anota lo que no ha podido medir. Es una degradación controlada, no un fallo, pero el participante podría no advertir que se ha utilizado la alternativa. Si el perfil automatizado resulta escaso, indícale scripts/02_query_history.sql, que puede ejecutar manualmente en la interfaz de Snowflake.
• Un participante trata como opcional la lista de finalización de migration-plan.md. No lo es: setup.sh del módulo 03 la lee, y una casilla sin marcar es la señal de que el módulo se ha omitido en la práctica aunque el archivo exista.
• TODO: a diferencia de los módulos 01 y 03, el README de este módulo no contiene una sección de solución de problemas. Completa esta lista con lo observado durante el ensayo una vez que se haya realizado el bloque de hojas de trabajo con una sala real.

Pasos de restablecimiento

• profile_report.md, la salida del Paso 1, se ignora en Git y se vuelve a generar desde la cuenta activa de Snowflake del propio participante en cada ejecución. Si parece obsoleto o incorrecto, repite ./scripts/01_profile_snowflake.sh. No hay nada que desmontar.
• Las cinco hojas se rellenan en el sitio, se califican al instante y se guardan en el navegador del participante (localStorage), no en el repositorio. migration-plan.md, en cambio, sí se edita directamente en el repositorio. Este módulo no aprovisiona nada en ninguna nube, así que no hay teardown.sh ni opciones del script de preparación a las que recurrir.
• Si una hoja queda en un estado incorrecto, indica al participante que use el control «Clear answers» de esa misma hoja y no que restaure archivos con Git: sus respuestas nunca se guardaron en el repositorio, por lo que hacerlo no serviría de nada.