1.3 · OLTP vs OLAP y arquitecturas analíticas

Dos mundos: operar vs. analizar

Las organizaciones usan sus datos para dos propósitos muy distintos:

• Operar el negocio: registrar una venta, hacer una transferencia, actualizar un pedido.
• Analizar el negocio: ¿cuánto vendimos por región el último trimestre? ¿qué clientes compran más?

Intentar hacer ambas cosas sobre el mismo sistema es una mala idea: las consultas analíticas recorren millones de filas y frenarían las operaciones del día a día. Por eso existen dos familias de sistemas: OLTP y OLAP.

OLTP vs OLAP

Regla práctica: OLTP responde “¿qué está pasando ahora?” y OLAP responde “¿qué ha pasado y por qué?”.

Data warehouse, data lake y data lakehouse

Para alimentar el mundo OLAP se han sucedido tres arquitecturas de almacenamiento:

• Data warehouse: almacén estructurado y depurado, con esquema definido antes de cargar (schema-on-write). Datos limpios, integrados y listos para BI. Costoso y rígido ante nuevos formatos. Ejemplos: Amazon Redshift, Google BigQuery, Snowflake.
• Data lake: repositorio que guarda los datos en crudo, en su formato original (JSON, imágenes, logs), con esquema aplicado al leer (schema-on-read). Barato y flexible, pero sin gobierno puede degradarse en un “data swamp” (pantano de datos).
• Data lakehouse: evolución que combina ambos: almacenamiento barato tipo lake sobre formatos abiertos (Delta Lake, Apache Iceberg) pero con transacciones ACID, esquema y rendimiento de warehouse.

Esquemas analíticos: estrella y copo de nieve

Dentro del data warehouse, los datos se organizan para que las consultas analíticas sean rápidas. El diseño más común es el esquema estrella:

• Una tabla de hechos central con las mediciones del negocio (ventas: cantidad, importe).
• Tablas de dimensiones alrededor que describen el contexto (tiempo, producto, cliente, tienda).

graph TD
DT["dim_tiempo<br/>(fecha, mes, trimestre, año)"] --> H["hechos_ventas<br/>(cantidad, importe)"]
DP["dim_producto<br/>(nombre, categoría)"] --> H
DC["dim_cliente<br/>(nombre, segmento)"] --> H
DS["dim_tienda<br/>(ciudad, región)"] --> H

El esquema copo de nieve es una variante donde las dimensiones se normalizan en sub-tablas (por ejemplo, dim_tienda se divide en tienda → ciudad → región). Ahorra espacio y evita redundancia, pero añade joins y complejidad a las consultas.

ETL vs ELT

¿Cómo llegan los datos de las fuentes OLTP al warehouse? Con procesos de integración:

• ETL (Extract, Transform, Load): se extraen los datos, se transforman en un motor intermedio (limpieza, agregación) y luego se cargan ya depurados en el warehouse. Clásico cuando el destino no tiene potencia de sobra.
• ELT (Extract, Load, Transform): se cargan primero los datos en bruto en el destino y se transforman dentro, aprovechando la potencia del warehouse/lakehouse en la nube. Es el patrón dominante hoy.

graph LR
F1["BD ventas<br/>(OLTP)"] --> E["Extracción"]
F2["CRM"] --> E
F3["Logs web"] --> E
E --> T["Transformación<br/>limpieza, joins,<br/>agregaciones"]
T --> W["Data Warehouse<br/>esquema estrella"]
W --> B["Herramientas BI<br/>dashboards, informes"]
W --> C["Ciencia de datos<br/>modelos ML"]

En la práctica se usan ambos: ELT para llevar todo el dato crudo al lake y ETL (o transformaciones SQL tipo dbt) para construir las capas limpias que consume el negocio.

Ejercicio: consultas OLAP sobre ventas

-- Consulta OLAP tipica: agregar millones de filas a un resumen por dimension
SELECT
  region,
  SUM(importe)  AS importe_total,
  SUM(cantidad) AS unidades_vendidas,
  COUNT(*)      AS num_operaciones
FROM ventas
GROUP BY region
HAVING COUNT(*) > 10
ORDER BY importe_total DESC;

-- Variante: evolucion mensual de ventas (analisis temporal)
SELECT
  DATE_TRUNC('month', fecha) AS mes,
  region,
  SUM(importe) AS importe_total
FROM ventas
GROUP BY mes, region
ORDER BY mes, importe_total DESC;

Comprueba lo aprendido

Resumen

• OLTP ejecuta las operaciones del negocio (pocas filas, alta concurrencia); OLAP analiza la historia (agregaciones sobre millones de filas).
• El data warehouse guarda datos depurados con schema-on-write; el data lake guarda datos crudos con schema-on-read; el lakehouse combina ambos.
• Los warehouses se diseñan con esquema estrella (hechos + dimensiones) o su variante normalizada, el copo de nieve.
• ETL transforma antes de cargar; ELT carga primero y transforma dentro del destino.
• El SQL analítico (GROUP BY, SUM, COUNT, HAVING) es la herramienta básica del mundo OLAP.

📚 Lecturas y fuentes