Almacén de datos (data warehouse)

¿Qué es un almacén de datos?

Un almacén de datos, o data warehouse, es una base de datos diseñada para consultas analíticas y no para hacer funcionar una aplicación. Consolida datos de varias fuentes, tu base de datos de producción, la pasarela de pago, el CRM y el flujo de eventos de producto, en un único sitio estructurado para preguntas que abarcan grandes volúmenes de historia, en lugar de para leer y escribir registros individuales a toda velocidad.

La diferencia está en el tipo de carga, no en el tamaño. Una base de datos de producción está optimizada para recuperar el registro de un cliente en un milisegundo y volver a escribirlo sin riesgo. Un almacén está optimizado para recorrer dos años de eventos y agruparlos por mes sin que nadie lo note. Ambas son bases de datos. Pedirle a una que haga el trabajo de la otra es donde empiezan casi todos los problemas de rendimiento de un panel.

Almacén frente a base de datos transaccional

Las dos cargas de trabajo tienen nombres que conviene conocer, porque casi toda la documentación los da por supuestos:

• OLTP (procesamiento transaccional en línea): la base de datos de tu aplicación. Almacenamiento orientado a filas, muy indexado, ajustado para muchas lecturas y escrituras pequeñas y concurrentes. PostgreSQL y MySQL en su configuración habitual.
• OLAP (procesamiento analítico en línea): el almacén. Almacenamiento orientado a columnas, ajustado para recorrer y agregar millones de filas de una vez. BigQuery, Snowflake, Redshift o ClickHouse.

El almacenamiento columnar explica casi toda la diferencia. Cuando una consulta toca tres columnas de ochenta, un almacén columnar lee solo esas tres, mientras que uno orientado a filas tiene que leer la fila entera y descartar el resto. Por eso una agregación que se arrastra en tu base de datos de aplicación puede responder rápido en un almacén con los mismos datos.

Los costes también se invierten. Los almacenes suelen cobrar por datos escaneados o tiempo de cómputo más que por almacenamiento, así que una consulta mal acotada sale cara de una forma en que una consulta OLTP lenta no. El almacenamiento es barato, escanear no, y ese solo hecho explica la mayor parte del trabajo de optimización de costes.

Almacén, data lake y lakehouse

Tres términos que se usan con ligereza y significan cosas distintas:

• Data warehouse: datos estructurados con esquema definido, limpiados y modelados antes de aterrizar. Decides la forma por adelantado, lo que simplifica las consultas y complica la ingesta.
• Data lake: ficheros en bruto en almacenamiento de objetos, en cualquier formato, con el esquema aplicado solo al leer. Barato y flexible, y con tendencia a convertirse en un pantano inconsultable sin disciplina.
• Lakehouse: formatos de tabla como Iceberg o Delta Lake sobre el almacenamiento del lago para ofrecer garantías propias de un almacén. El término medio práctico, y cada vez más la opción por defecto en equipos grandes.

Para la mayoría de productos SaaS que integran analítica dentro de su propio producto, la opción relevante es el almacén. Los lagos resuelven un problema que aparece cuando un equipo de ciencia de datos necesita datos crudos sin modelar, que no es el mismo problema que servir un gráfico a un cliente en menos de un segundo.

Cuándo lo necesita de verdad un producto SaaS

Añadir un almacén es un compromiso operativo real: otro sistema, una tubería de sincronización y un desfase entre producción y analítica. Muchos productos no deberían hacerlo. Señales razonables de que has cruzado la línea:

• Las consultas analíticas afectan a la aplicación: que las consultas del panel compitan con el tráfico de producción es el detonante más habitual, y una réplica de lectura es el primer arreglo más barato.
• Necesitas cruzar varias fuentes: en cuanto un panel necesita datos de producto junto a los de facturación y CRM, algo tiene que contener los tres.
• El histórico supera lo que producción debería guardar: las aplicaciones rara vez necesitan cuatro años de eventos. La analítica sí, con frecuencia.
• Las agregaciones siguen lentas pese a estar bien indexadas: si ya has indexado bien y preagregado y las consultas aún tardan segundos, la limitación es el modelo de almacenamiento.

Si no se cumple ninguna, PostgreSQL con buenos índices, vistas materializadas y tablas de resumen preagregadas llevará un panel mucho más lejos de lo que la mayoría espera. Recurrir a un almacén antes de necesitarlo es un impulso habitual y caro.

Qué significa para tus paneles

Un almacén cambia cómo construyes la capa que va encima, y hay cuatro consecuencias que importan:

• La frescura pasa a ser una decisión: los datos del almacén llegan por una tubería, así que van minutos u horas por detrás de producción. Decide qué necesita de verdad cada KPI, porque el tiempo real es caro y rara vez hace falta para un gráfico de ingresos.
• Preagrega de forma deliberada: consultar eventos en bruto en cada carga del panel es el camino más rápido a una factura sorprendente. Las tablas de resumen al nivel de detalle que muestras casi siempre compensan.
• Particiona y agrupa por tus columnas de filtro: normalmente fecha e inquilino. Es la mayor palanca sobre la velocidad y sobre el coste de escaneo.
• Define cada métrica en un solo sitio: cuando los datos del almacén alimentan varias superficies, la misma métrica acaba calculándose de forma algo distinta en cada una si no hay una definición compartida. Métricas como la tasa de abandono y la retención neta de ingresos (NRR) son especialmente propensas a divergir en silencio.

Bien planteado, el almacén es invisible para quien usa el producto. Existe para que un panel de datos pueda responder preguntas sobre toda la historia del negocio sin que nadie espere, y para que hacer una pregunta difícil no ponga nunca en riesgo la velocidad de la aplicación.