Dos mundos de datos: por qué no consultas la base de la app

Tu primer día en una empresa con datos. Te sientas, te dan acceso a "la base de datos" y te dicen: "aquí tienes todo lo que necesitas". Abres el cliente SQL, ves 247 tablas, y no sabes por dónde empezar. Pero hay algo peor que no saber por dónde empezar: empezar por el sitio equivocado. Porque en la mayoría de empresas con un mínimo de madurez, los datos no viven en UN sitio. Viven en dos mundos completamente diferentes, diseñados para propósitos opuestos. Y si consultas el equivocado, o no entiendes lo que ves, o directamente te dicen que no toques eso.

Esta lección te da el mapa de esos dos mundos. No vas a construir ninguno de los dos — eso es trabajo de ingeniería de datos. Lo que vas a aprender es a reconocerlos, a saber cuál te corresponde como analista, y a entender por qué las cosas están separadas. Es la diferencia entre llegar a un hospital y saber que quirófano y consultas externas son dos sitios distintos con reglas distintas, aunque los dos tengan médicos dentro.

### El mundo transaccional: donde la app guarda los pedidos

El primer mundo se llama OLTP, que significa Online Transaction Processing (procesamiento de transacciones en línea). Es la base de datos que alimenta la aplicación: la web, la app del móvil, el sistema de facturación. Cada vez que un cliente compra algo, se registra, cambia su dirección o cancela un pedido, esa acción se graba aquí. La prioridad absoluta de esta base es la velocidad de escritura: tiene que procesar miles de operaciones por segundo sin que el usuario note un parpadeo.

Piensa en la caja registradora de un supermercado. Su trabajo es cobrar rápido al cliente que tiene delante: escanear productos, sumar el total, registrar el pago y pasar al siguiente. Está diseñada para eso y solo para eso. No está diseñada para que el director financiero se siente a calcular las ventas del último trimestre mientras hay cola. Si alguien intentara hacer cuentas en esa caja, bloquearía a todos los clientes que están esperando para pagar.

• ▹Propósito: que la aplicación funcione sin errores ni retrasos
• ▹Operaciones típicas: guardar un pedido, actualizar un perfil, registrar un pago — una fila a la vez
• ▹Velocidad de respuesta: milisegundos (el usuario está esperando)
• ▹Usuarios: la app entera — cientos o miles de conexiones simultáneas
• ▹Estructura de las tablas: normalizada, con muchas tablas pequeñas relacionadas entre sí para evitar datos duplicados
• ▹Ejemplo: la base PostgreSQL o MySQL que alimenta la web de la empresa

### El mundo analítico: de donde tú consultas

El segundo mundo se llama OLAP, que significa Online Analytical Processing (procesamiento analítico en línea). Es una base de datos diseñada para leer grandes cantidades de datos históricos y hacer cálculos sobre ellos: sumas, promedios, comparaciones entre periodos, agrupaciones por cualquier dimensión. Aquí es donde vives tú como analista. Aquí lanzas tus queries, aquí conectas tus dashboards (los cuadros de mando que se actualizan solos), aquí investigas cuando un número se mueve.

Si la base OLTP es la caja registradora, la base OLAP es la oficina de contabilidad del supermercado. Nadie va a la oficina de contabilidad a cobrar a un cliente: van a sumar las ventas del mes, a comparar este enero con el anterior, a ver qué categoría de producto ha crecido más. Pueden tardar diez segundos en hacer un cálculo complejo y no pasa nada, porque no hay nadie esperando con el monedero en la mano.

• ▹Propósito: responder preguntas de negocio sobre datos históricos
• ▹Operaciones típicas: sumar millones de filas, comparar periodos, agrupar por categoría — lectura masiva
• ▹Velocidad de respuesta: segundos (nadie está esperando en una cola)
• ▹Usuarios: analistas, dashboards, herramientas de BI — decenas de conexiones
• ▹Estructura de las tablas: desnormalizada, con tablas grandes y anchas preparadas para leer de un solo golpe
• ▹Ejemplo: BigQuery, Redshift, Snowflake, o un DuckDB con los datos ya preparados

### Por qué están separados: la historia en tres minutos

En los años 80, todo vivía junto. Los programadores escribían las consultas analíticas contra la misma base que servía la aplicación. Funcionaba cuando las empresas tenían miles de registros. Dejó de funcionar cuando tenían millones. Un informe que tardaba cuarenta segundos bloqueaba la aplicación durante cuarenta segundos. Un directivo que pedía "las ventas del último año" sin querer podía dejar sin servicio a miles de clientes. La solución fue obvia en retrospectiva: copiar los datos a otra base de datos separada, diseñada para leer mucho y escribir poco. Esa otra base es el almacén analítico, el data warehouse (almacén de datos).

La separación no es un capricho de arquitecto. Es una necesidad física. Los motores de base de datos están optimizados para una cosa o para otra, igual que un coche de carreras y un camión de reparto se parecen ambos en que tienen ruedas y motor, pero están diseñados para problemas opuestos. Un motor OLTP almacena los datos por filas: toda la información de un pedido está junta en disco, porque la operación más frecuente es "dame TODO el pedido número 12345". Un motor OLAP almacena los datos por columnas: todos los importes de todas las ventas están juntos en disco, porque la operación más frecuente es "suma TODOS los importes del mes pasado".

### Lo que un analista ve en cada mundo

Si alguna vez te dejan ver la base transaccional, notarás algo inmediatamente: hay muchas tablas y parecen pequeñas e incomprensibles. Una tabla users con 15 columnas, una tabla orders con 8, una tabla order_items con 5, una tabla addresses con 7, una tabla payments con 6... Para saber "cuánto vendimos por país" tienes que hacer JOIN de cinco tablas. Es un laberinto diseñado para que la app funcione rápido, no para que tú entiendas el negocio.

En el almacén analítico, la foto es otra. Ves pocas tablas, pero grandes y anchas. Una tabla de ventas con 30 columnas que ya tiene dentro el nombre del producto, la categoría, el país del cliente y el mes. Para saber "cuánto vendimos por país" escribes un GROUP BY con una sola tabla. Es un sitio diseñado para que TÚ entiendas el negocio rápido. Alguien — un ingeniero de datos o un equipo de datos — se ha encargado de transformar el laberinto de la app en algo que tú puedes consultar sin perder la cordura.

### Qué pasa si consultas el sitio equivocado

Pasan dos cosas malas, una técnica y otra política. La técnica: tu query es lenta. Escanear dos años de ventas en una base diseñada para escribir un pedido cada 200 milisegundos es como pedir un camión de mudanzas para llevar a tu hijo al colegio. Funciona, pero tarda y molesta. Si la base es de producción y tu query tarda 40 segundos, durante esos 40 segundos estás compitiendo por los mismos recursos que los clientes de la app. En el peor caso, ralentizas la aplicación para los usuarios reales.

La política: el equipo de backend te va a pedir, con más o menos educación, que no vuelvas a hacer eso. Y tienen razón. Es como entrar en un quirófano a buscar un termómetro: puede que lo encuentres, pero estás donde no debes estar y puedes causar un problema que no te corresponde resolver. Tu sitio es el almacén analítico. Si no lo hay, la conversación no es "dejadme consultar producción", sino "la empresa necesita un almacén de datos".

### Almacenamiento por filas vs por columnas: la razón física

La diferencia entre OLTP y OLAP no es solo de propósito. Es física: almacenan los datos de forma diferente en disco. Un motor por filas (como PostgreSQL o MySQL) guarda toda la información de un registro junta: id, nombre, fecha, importe, todo en la misma línea del disco. Esto es perfecto para la operación "dame TODO el pedido 12345", porque solo lee una posición del disco y encuentra todo lo que necesita.

Un motor por columnas (como BigQuery, Redshift o DuckDB) guarda todos los valores de la misma columna juntos: todos los importes de todos los pedidos están seguidos, todos los países de todos los clientes están seguidos. Cuando tu query dice "suma todos los importes del mes", el motor solo lee la columna de importes y la de fechas — ignora completamente las otras 28 columnas que no necesita. El resultado: para queries analíticas puede ser entre 10 y 100 veces más rápido, porque lee una fracción de los datos.

1-- Tu query como analista:
2SELECT
3    date_trunc('month', fecha_venta) AS mes,
4    SUM(importe) AS total_ventas
5FROM ventas
6GROUP BY 1
7ORDER BY 1;
8
9-- En un motor OLTP (por filas):
10--   Lee TODA la tabla: 100M filas x 30 columnas = mucho dato
11--   Tiempo: ~45 segundos
12
13-- En un motor OLAP (por columnas):
14--   Lee SOLO fecha_venta + importe: 100M filas x 2 columnas
15--   Quince veces menos datos que leer la tabla entera
16--   Tiempo: ~2 segundos

### Cómo llegan los datos de un mundo al otro

Los datos no aparecen en el almacén analítico por arte de magia. Alguien — un ingeniero de datos, un proceso automatizado — los extrae de la base transaccional, los transforma (limpia, une, desnormaliza) y los carga en el almacén. A ese proceso se le llama ETL (Extract, Transform, Load) o ELT (Extract, Load, Transform), según donde se haga la transformación. Como analista no necesitas construir ese proceso, pero sí necesitas saber que existe, porque determina tres cosas que te afectan directamente:

1. 01.La frescura del dato — si el ETL corre cada noche, tus datos tienen un día de retraso. Si ves algo raro a las 10 de la mañana, puede que sea de ayer, no de hoy.
2. 02.La cobertura — no todo lo que existe en la app llega al almacén. Si un campo se añadió hace dos semanas pero el ETL no lo recoge todavía, no lo vas a encontrar por más que busques.
3. 03.Las transformaciones — el dato que ves puede no coincidir exactamente con el de la app. Un pedido cancelado puede haberse eliminado del almacén, o puede estar con un flag "cancelado". Depende de cómo lo diseñara el equipo de ingeniería.

### Resumen: tu checklist del primer día

1. 01.Pregunta dónde consultar. No asumas que "la base de datos" es un solo sitio.
2. 02.Identifica si es OLTP (app) u OLAP (almacén). Si ves muchas tablas pequeñas con nombres como user_sessions o payment_transactions, probablemente estás viendo el OLTP.
3. 03.Consulta siempre desde el OLAP. Si no hay uno, escálalo.
4. 04.Averigua cuándo se actualiza. Tus datos tendrán un desfase y necesitas saber cuál es.
5. 05.Pregunta qué falta. No todo lo que está en la app ha llegado al almacén.

Ya tienes el primer concepto del mapa: hay dos mundos, y tú vives en el analítico. En la siguiente lección vas a descubrir cómo está organizado ese mundo analítico por dentro: qué tipos de tablas hay y cómo se relacionan entre sí. Porque no basta con saber que el almacén existe — necesitas entender su estructura para consultarlo sin cometer errores que parecen invisibles hasta que alguien pregunta "¿de dónde sale ese número?".