Dónde consultas de verdad: el almacén analítico

Primer día en la oficina. Te han dado un portátil, unas credenciales y una tarea: «necesitamos saber cuántos usuarios nuevos se registraron este mes por canal de adquisición». Sabes SQL. Sabes escribir un SELECT, un GROUP BY, un WHERE con fechas. Pero hay una pregunta que nadie te ha respondido todavía: ¿dónde ejecutas esa query? ¿En qué base de datos? ¿Es la misma que usa la aplicación web que tiene la empresa? Spoiler: no lo es, y entender por qué es lo primero que te separa de alguien que sabe SQL de academia de alguien que trabaja con datos de verdad.

Esta lección responde la pregunta que todo analista junior se hace en su primera semana y que nadie le explica de forma clara: ¿de dónde salen los datos que consulto, por qué no toco la base de producción, y qué capas hay entre el usuario que hace clic y la tabla que yo veo en mi herramienta? Vamos a hablar desde tu experiencia como persona que consulta, no como persona que construye.

### La tienda y la trastienda: por qué existen dos sitios

Imagina un supermercado. En la zona de cajas hay un sistema que registra cada venta en tiempo real: escanea el código de barras, cobra al cliente, actualiza el stock del almacén. Ese sistema necesita ser rápido — si se ralentiza, hay cola. Ahora imagina que el director financiero quiere saber cuánto se ha vendido de cada categoría este trimestre comparado con el anterior. ¿Pondrías al director a consultar directamente el ordenador de las cajas en hora punta? No, ¿verdad? Le harías una copia de los datos en otro sitio — un despacho con sus informes, tranquilo, donde puede cruzar y analizar sin que la cola de la caja se detenga.

Eso es, en esencia, la diferencia entre la base de datos de producción y el almacén analítico. La base de producción es la caja del supermercado: gestiona la operación en vivo. El almacén analítico es el despacho del director: una copia preparada para que tú analices sin romper nada. Y esa separación no es un capricho técnico — es una necesidad que nació de la experiencia.

### Por qué no puedes consultar la base de producción

Cuando dices «la base de datos», la mayoría de la gente piensa en una sola cosa. Pero en cualquier empresa con un producto digital hay, como mínimo, dos mundos separados. El primero es la base transaccional — la que usa la aplicación. Cada vez que un usuario se registra, compra algo, cambia su dirección o envía un mensaje, esa base inserta o actualiza una fila. Está diseñada para operaciones rápidas sobre registros individuales: buscar un usuario por su email, comprobar si tiene saldo, descontar una unidad de stock. Milisegundos. Una fila cada vez.

Ahora piensa en lo que tú necesitas como analista. Tu pregunta no es «¿tiene saldo el usuario 48.923?». Tu pregunta es «¿cuántos usuarios activos tenemos por mes, segmentados por plan de suscripción, en los últimos doce meses?». Eso implica recorrer millones de filas, agruparlas, compararlas y cruzar varias tablas. Si lanzas esa query contra la base de producción, pasan tres cosas malas:

1. 01.Ralentizas la aplicación. Tu query compite por los mismos recursos (CPU, memoria, disco) que usan los usuarios reales. Si tu consulta tarda 40 segundos escaneando millones de filas, la aplicación puede volverse lenta o caer.
2. 02.Bloqueas operaciones. En muchas bases de datos, una lectura grande puede bloquear escrituras. Mientras tu consulta analítica escanea la tabla de pedidos, un cliente puede no poder completar su compra.
3. 03.Ves datos en crudo. La base de producción está diseñada para la aplicación, no para ti. Las tablas tienen nombres crípticos, los estados son códigos numéricos, hay columnas técnicas que no significan nada para el negocio, y la misma información puede estar repartida en veinte tablas sin documentar.

Por eso existe un segundo mundo: el almacén analítico, también llamado data warehouse (almacén de datos). Es una copia de los datos de producción — pero transformada, limpia y organizada para que tú puedas analizarla sin hacer daño. Alguien (un ingeniero de datos, un proceso automático) se encarga de copiar los datos de producción al almacén de forma periódica. Tú consultas el almacén. Producción sigue funcionando como si no existieras.

### Un poco de historia: por qué alguien inventó esto

En los años 80, las empresas guardaban sus datos en grandes bases de datos que servían para todo: gestionar las operaciones y, de paso, sacar informes. El problema era predecible. Cada cierre de mes, cuando el departamento de finanzas lanzaba sus informes, el sistema se arrastraba y los cajeros no podían procesar ventas. La solución de la época era sacar los informes de madrugada — los famosos «procesos batch de la noche» — para no molestar a la operación diurna.

En 1992, Bill Inmon publicó «Building the Data Warehouse» y formalizó la idea que muchas empresas ya practicaban por necesidad: separa los datos analíticos de los operativos. Ponlos en otro sitio. Organízalos para responder preguntas de negocio, no para procesar transacciones. Así nació el concepto de data warehouse (almacén de datos) como disciplina. No fue un invento de un día — fue la respuesta a décadas de viernes con los sistemas caídos.

Hoy esa idea sigue viva, aunque la tecnología ha cambiado. En los 90, un almacén de datos era un servidor carísimo en el sótano de la empresa. Hoy puede ser un servicio en la nube al que accedes con tu navegador: BigQuery de Google, Redshift de Amazon, Snowflake, Databricks. El principio es el mismo: producción va por un lado, análisis va por otro. Tú, como analista, vives en el segundo.

### Las tres capas que vas a encontrar

En una empresa madura, los datos no pasan directamente de producción a tu consulta. Hay un proceso intermedio que los transforma. El patrón más extendido hoy organiza el almacén en tres capas — tres «pisos» por los que el dato va subiendo. En cada piso, el dato es un poco más limpio, más organizado y más fácil de consultar para ti. Los nombres pueden variar de una empresa a otra, pero la idea es universal:

La capa bronze (bronce, o raw en algunas empresas) es una copia casi literal de lo que hay en producción. Llega sin transformar: con los mismos nombres de columna que puso el programador, con los mismos códigos de estado (0, 1, 2 en vez de «pendiente», «activo», «cancelado»), con los duplicados que la aplicación no impidió. Es el «volcado en bruto». Tú no consultas aquí salvo para investigar un problema muy concreto.

La capa silver (plata, o clean) ya ha pasado un proceso de limpieza: se han eliminado duplicados, se han convertido los tipos de datos (esa columna que era un texto «2024-03-15» ahora es una fecha de verdad), se han renombrado columnas crípticas. Es una versión fiable de los mismos datos. Algunos analistas trabajan directamente aquí cuando necesitan el grano fino.

La capa gold (oro, o business) es donde vives tú como analista la mayor parte del tiempo. Aquí las tablas ya no se llaman «usr_evt_log» sino «eventos_usuario». Las métricas están precalculadas o son fáciles de calcular. Las dimensiones (cliente, producto, fecha, canal) están limpias y cruzadas. Cuando tu jefa te dice «necesito la facturación por país y mes», abres la capa gold y en tres líneas de SQL tienes la respuesta.

### Qué herramienta usarás para conectarte

Vale, ya sabes que tus datos están en un almacén analítico, no en producción. Pero ¿cómo te conectas a ese almacén? ¿Abres una terminal y escribes SQL? ¿Usas una hoja de cálculo? ¿Una aplicación web? Depende de la empresa, pero hay un patrón bastante predecible.

En la mayoría de empresas medianas y grandes, el analista trabaja con una herramienta que tiene un editor SQL integrado y te deja ver los resultados en una tabla. Algunos nombres que te vas a encontrar en las ofertas de trabajo: la consola web de BigQuery (si la empresa usa Google Cloud), el Query Editor de Redshift (si usa Amazon), Snowsight de Snowflake, la interfaz de Databricks SQL, o herramientas independientes como DBeaver, DataGrip, o incluso una interfaz interna que ha construido el equipo de datos de la empresa. En startups más pequeñas, a veces es literalmente un cliente SQL conectado a un PostgreSQL dedicado para analítica.

Lo que tienen en común todas estas herramientas: te dan un cuadro de texto donde escribes SQL, un botón para ejecutar, y una tabla con el resultado. El SQL que ya sabes — SELECT, FROM, WHERE, GROUP BY, JOINs — funciona en todas. Los detalles cambian (cada motor tiene sus funciones propias y sus caprichos de sintaxis), pero la lógica es la misma. No vas a tener que aprender un lenguaje nuevo para cada herramienta.

### Warehouse, lakehouse y la sopa de nombres

Si lees ofertas de trabajo o hablas con ingenieros de datos, te van a caer encima varios términos: data warehouse, data lake, lakehouse, data mesh, data mart… Respira. Para ti, como analista que consulta, la diferencia práctica es mucho menor de lo que parece. Vamos a desmitificarlo:

• ▹Data warehouse (almacén de datos) — un sistema diseñado exclusivamente para consultas analíticas. Los datos llegan ya estructurados (con tablas, columnas, tipos definidos). Es donde tú escribes SQL. Ejemplos: BigQuery, Redshift, Snowflake.
• ▹Data lake (lago de datos) — un almacenamiento más barato y flexible donde caben datos de cualquier formato: ficheros CSV, JSON, logs, imágenes, vídeos. No todo está limpio ni tiene estructura. Es el «almacén donde lo guardamos todo por si acaso». Tú no consultas aquí directamente, salvo que sepas exactamente lo que buscas.
• ▹Lakehouse — la fusión de los dos anteriores: un lago de datos con una capa de estructura encima que lo hace consultable como un almacén. Databricks lo popularizó. Para ti como analista, se comporta como un warehouse: escribes SQL contra tablas bien definidas.
• ▹Data mart (minialmacén) — un subconjunto del almacén dedicado a un área de negocio concreta: el mart de marketing, el mart de finanzas, el mart de producto. Es como tener tu propia estantería dentro de la biblioteca.

La conclusión práctica para ti: no importa cómo lo llame tu empresa. Lo que importa es que hay un sitio donde los datos están limpios, organizados y listos para que tú los consultes con SQL. Pregunta dónde está, pide acceso, y empieza a trabajar. El nombre de la arquitectura es un detalle de implementación que le importa al ingeniero de datos, no a ti — al menos no en tu primer año.

### Lo que ves cuando te conectas por primera vez

Cuando abres tu herramienta de consulta por primera vez en una empresa nueva, verás algo parecido a un explorador de ficheros: carpetas (que en SQL se llaman esquemas) con tablas dentro. El almacén típico tiene esquemas que siguen las capas que hemos visto:

1-- Lo que ves en el panel lateral de tu herramienta:
2--
3-- raw/              ← Capa bronze: no tocar
4--   raw.users
5--   raw.orders
6--   raw.events
7--
8-- staging/          ← Capa silver: datos limpios
9--   staging.users
10--   staging.orders
11--
12-- analytics/        ← Capa gold: TU TERRITORIO
13--   analytics.dim_clientes
14--   analytics.dim_productos
15--   analytics.fact_pedidos
16--   analytics.fact_eventos
17--
18-- Tu primera query sera algo como:
19SELECT
20    fecha,
21    canal_adquisicion,
22    COUNT(*) AS nuevos_usuarios
23FROM analytics.dim_clientes
24WHERE fecha_registro >= '2024-01-01'
25GROUP BY fecha, canal_adquisicion
26ORDER BY fecha;

Fíjate en algo: la query que has escrito usa el mismo SQL que ya conoces. SELECT, FROM, WHERE, GROUP BY, ORDER BY. La diferencia no está en el lenguaje — está en dónde apuntas. En vez de FROM clientes escribes FROM analytics.dim_clientes. Ese prefijo analytics. es el nombre del esquema, y es la señal de que estás consultando la capa correcta.

### Las cinco preguntas de tu primer día

En toda empresa nueva — da igual si es una startup de 20 personas o una multinacional con 500 analistas — hay un conjunto de preguntas que necesitas resolver antes de escribir tu primera query de verdad. No son preguntas técnicas: son preguntas de orientación. Son el equivalente a preguntar dónde está el baño y la máquina de café el primer día de oficina.

La pregunta 4 es más importante de lo que parece. Si los datos se actualizan cada noche a las 3:00, y tú consultas a las 9:00 de la mañana, estás viendo los datos hasta ayer a medianoche. Si tu jefa te pide «las ventas de hoy», no puedes dárselas — solo tienes hasta ayer. Esto es la latencia del dato, y es una de las primeras cosas que tienes que saber para no prometer lo que no puedes entregar.

La pregunta 5 te puede salvar de una factura dolorosa. En almacenes como BigQuery, cada query tiene un coste proporcional a los datos que escanea. Un SELECT * FROM tabla_de_eventos sobre una tabla de mil millones de filas puede costarte decenas de euros en un solo clic. Por eso siempre seleccionas columnas concretas, filtras por fecha, y miras el estimador de coste antes de ejecutar. Esto lo verás en detalle más adelante, pero quédate con la idea: en la nube, una query analítica no es gratis.

### Qué pasa en empresas pequeñas

Todo lo anterior describe el escenario ideal: una empresa con un equipo de datos que ha montado un almacén en condiciones. Pero en la realidad, muchas startups y pymes no tienen eso. ¿Qué te encuentras?

• ▹Escenario A: no hay almacén. Los datos están en producción y punto. Te dan acceso de solo lectura a la réplica (una copia de la base de producción que se sincroniza cada pocos segundos). Funciona para consultar, pero las tablas son las de la aplicación: sin limpiar, sin documentar, con nombres de programador.
• ▹Escenario B: hay una réplica y «algunas vistas». Alguien (un ingeniero, un analista anterior, el CTO un sábado) creó vistas SQL encima de la réplica para simplificar las consultas frecuentes. Es un proto-almacén: no tiene capas formales, pero las vistas hacen de capa gold casera.
• ▹Escenario C: hay un almacén, pero nadie lo mantiene. Se montó hace dos años, el ingeniero que lo hizo se fue, y algunos datos llegan y otros no. Hay tablas de hace seis meses que nadie usa y tablas críticas con la última actualización de la semana pasada.
• ▹Escenario D: hay un almacén maduro con documentación. El paraíso. Tienes un catálogo de datos, sabes qué significa cada tabla, y hay alguien a quien preguntar. No es lo habitual en tu primer trabajo, pero existe.

En los escenarios A y B, parte de tu trabajo como analista será más duro: tendrás que investigar las tablas por tu cuenta, preguntar a los desarrolladores qué significa cada columna, y montar tus propias vistas limpias. Es más difícil, pero también es donde más aprendes. No te asustes si llegas a una empresa y no hay un almacén perfecto esperándote — es lo normal en startups y pymes.

### Resumen: tu mapa mental

Vamos a condensar todo lo que has aprendido en esta lección en un mapa claro que puedas llevar en la cabeza:

1. 01.La base de producción NO es tu territorio. Es de la aplicación y de sus usuarios. Tú no consultas ahí.
2. 02.El almacén analítico (data warehouse) ES tu territorio. Es una copia limpia y organizada de los datos, preparada para responder preguntas de negocio.
3. 03.Los datos viajan de producción al almacén a través de un proceso de copia y transformación (ETL/ELT) que gestiona el equipo de ingeniería de datos.
4. 04.El almacén se organiza en capas: bronze (crudo), silver (limpio) y gold (negocio). Tú consultas gold casi siempre.
5. 05.El SQL que ya sabes funciona en cualquier almacén. La herramienta cambia, la habilidad viaja contigo.
6. 06.En tu primer día, haz las cinco preguntas: dónde me conecto, qué capa consulto, hay diccionario, con qué frecuencia se actualiza, y hay límites de coste.