Hoja 1: selección del motor MergeTree

Tiempo estimado: 15–20 minutos Referencia: Motores MergeTree

Concepto

En Snowflake creas una tabla y la plataforma decide cómo almacenarla. En ClickHouse eliges el motor, una decisión que determina la corrección, no solo el rendimiento.

Estos son los tres motores que necesitas para el laboratorio:

MergeTree: el motor base. Los datos se almacenan en archivos columnares ordenados y no se deduplican. Utilízalo cuando la tabla sea de solo inserción o cuando la canalización gestione las actualizaciones de manera externa, por ejemplo con una recarga completa en cada ejecución de dbt.

ReplacingMergeTree(version_col): amplía MergeTree con deduplicación en segundo plano. Si varias partes contienen filas con la misma clave ORDER BY, después de una fusión solo se conserva la fila con el valor más alto de version_col. Utilízalo cuando las filas puedan actualizarse y exista una columna cuyo valor aumente de forma monótona en cada actualización, como el timestamp updated_at.

Advertencia crítica: la deduplicación es asíncrona. Hasta que ClickHouse ejecuta una fusión en segundo plano, la versión antigua y la nueva de una fila coexisten. Usa siempre SELECT ... FINAL sobre tablas ReplacingMergeTree para forzar la deduplicación en el momento de la consulta.

AggregatingMergeTree: amplía MergeTree mediante la combinación de estados agregados parciales. Utilízalo cuando una tabla almacene estados agregados combinables, como sketches de HyperLogLog o resúmenes de cuantiles, y necesites agregarlos en segundo plano. No hace falta para el laboratorio de NYC Taxi: dbt reconstruye las tablas de agregados en vez de acumularlas.

Árbol de decisión

Does the table receive UPDATE or DELETE operations?
│
├── No (insert-only)
│   └─► MergeTree()
│
└── Yes
    ├── Is there a timestamp/version column that increases on every update?
    │   ├── Yes → ReplacingMergeTree(version_col)
    │   └── No (e.g., full-reload dimension tables)
    │       └─► MergeTree()  — dbt handles upsert via atomic table swap (full rebuild)
    │
    └── Does the table store partial aggregate states (AggregateFunction types)?
        └── Yes → AggregatingMergeTree()

Los modelos de staging siempre son vistas

Con dbt y ClickHouse, los modelos de staging deben materializarse como vistas, no como tablas. Las vistas no consumen almacenamiento y siempre reflejan los datos actuales: son simplemente SQL guardado, no objetos físicos.

El ejercicio siguiente cubre los modelos dbt de la capa de analytics —tablas de hechos, agregados y dimensiones— y la vista materializada de ClickHouse. No incluye trips_raw ni los modelos de staging:

• trips_raw es una tabla base creada directamente por el script (scripts/02_migrate_trips.py), no un modelo dbt. Usa ReplacingMergeTree(_synced_at) porque el script de migración puede reintentar un lote y volver a insertar el mismo trip_id. Después de la transición, el productor en vivo también puede repetir un intento ante un fallo transitorio; _synced_at DateTime DEFAULT now() garantiza que prevalezca la escritura más reciente.
• stg_trips es una vista dbt sobre trips_raw. Aplica SELECT ... FROM trips_raw FINAL para resolver cualquier duplicado que todavía no se haya fusionado antes de que los datos lleguen a los modelos de analytics posteriores. La responsabilidad de deduplicar corresponde a esta vista, no a una tabla de staging ReplacingMergeTree.

Ejercicio: selección de motores

Para cada tabla siguiente, determina el patrón de actualización, identifica la columna de versión, si existe, y elige el motor que mantenga la tabla correcta. Después de rellenar todas las filas, responde las preguntas de razonamiento.

Loading worksheet...

Transfiérelo a migration-plan.md

Cuando hayas completado la hoja, copia tus decisiones sobre los motores en la Sección 3 de migration-plan.md y marca:

- [ ] Engine selection: completed