ADR-0012 — Nube (fase 2): almacén analítico tipo lakehouse

Contexto

Tras el traslado a la nube, todos los datos viven en la base de datos operacional, en el disco del clúster y con una retención corta de laboratorio. Esto plantea dos problemas: con el clúster apagado (el modelo de encendido bajo demanda) los datos no se pueden consultar, y la retención corta descarta el histórico.

Se busca un almacén barato, duradero y consultable con el clúster apagado, que sirva de base para la analítica, la inteligencia de negocio y el ML, junto con una política de datos clara.

Decisión

Estratificar los datos en dos capas, al estilo lakehouse:

• Capa caliente u operacional: la base de datos de series temporales, sin cambios. Guarda los datos recientes, sirve consultas rápidas y alimenta los dashboards y la API, con retención corta.
• Capa fría o analítica: un almacén de objetos con archivos en formato columnar (Parquet) más un almacén de datos sin servidor (BigQuery). Es la fuente de verdad histórica y la base de la analítica y el ML. Al ser sin servidor, se consulta aunque el clúster esté apagado, que es precisamente lo que hace seguro el modelo de encendido bajo demanda.

La infraestructura (bucket con ciclo de vida hacia clases de almacenamiento más frías y baratas con el tiempo, conjunto de datos analítico y permisos sin claves mediante identidad de carga de trabajo) se define como código. El trabajo de exportación se orquesta como un flujo diario más dentro del orquestador, lo que aporta consistencia con el resto del batch, observabilidad, dependencias, reintentos y reprocesamiento. La política de datos distingue qué se conserva para siempre (lecturas validadas, anomalías), qué se guarda solo como auditoría (crudo e inválido) y qué es recomputable. El archivo se expone como tabla externa (sin duplicar) y los datos limpios y agregados como tablas nativas particionadas por fecha, de forma que las consultas escanean solo lo pedido.

Consecuencias

Positivas:

• Histórico prácticamente infinito y barato, consultable con el clúster apagado.
• Base sólida para el ML (datos de entrenamiento) y la inteligencia de negocio.
• Desacopla "tener y consultar los datos" de "tener el clúster encendido".

Negativas o deuda asumida:

• La exportación es por lotes: existe una latencia (de horas) entre la capa operacional y la analítica. Suficiente para analítica.
• La idempotencia inicial es sencilla (añadir sin más); una estrategia de fusión con marca de agua queda para más adelante.

Alternativas descartadas

• Streaming directo desde la capa de mensajería al almacén de objetos: menor latencia, pero más piezas; para analítica basta el batch.
• Todo en el almacén de datos sin la capa de objetos: se pierde el archivo barato y la tabla externa; la combinación de objeto más formato columnar es el patrón estándar de lake.
• Enviar los datos analíticos por un camino distinto del orquestador: se opta por integrarlo como un flujo más para ganar consistencia, observabilidad y reprocesamiento.