Qué es un data warehouse y en qué se diferencia de un data lake

El problema no es que falten datos, es que nadie confía en el número

El choque más común en una empresa con algunos años no es la falta de información, es que sobra y no se puede confiar en ella. El gerente pide cuánto se vendió por canal, y recibe tres respuestas distintas: la de ventas, la de finanzas y la del que arma el tablero en su laptop. Cada una salió de un sistema diferente, con un criterio distinto sobre qué cuenta como venta y en qué fecha. El resultado es que la reunión de resultados se va en discutir cuál cifra es la buena, no en decidir qué hacer con ella.

Detrás de eso hay una causa concreta: los datos viven repartidos en el ERP, el CRM, la planilla de recursos humanos, la plataforma de e-commerce y una decena de hojas de cálculo. Cada sistema fue diseñado para operar, no para reportar. Cuando alguien necesita una vista consolidada, un analista se pasa días exportando archivos y cuadrando a mano, y para cuando termina, el dato ya cambió. Ahí es donde entra la palabra data warehouse en la conversación, y ahí también empieza la confusión más cara del tema: comprarlo sin distinguirlo de un data lake, y terminar con una obra de infraestructura que nadie usa para decidir nada.

Qué es un data warehouse en criterio de negocio

Un data warehouse es, en la práctica, el lugar donde la empresa deja el dato ya ordenado, cuadrado y con una sola definición acordada, para que cualquiera saque el mismo número sin volver a discutirlo. No es donde se opera el día a día: es donde se va a mirar el negocio con perspectiva. La información llega desde los sistemas operativos, se limpia, se unifica bajo reglas comunes (qué es un cliente, qué es una venta cerrada, qué fecha manda) y queda lista para reportes, tableros y análisis.

La consecuencia para el negocio es directa. Cuando el reporte sale del data warehouse, todas las áreas parten del mismo número porque la definición se acordó una vez y se aplicó para todos. Deja de existir el “mi Excel dice otra cosa”. A cambio, hay un costo que conviene nombrar desde el inicio: alguien tuvo que decidir esas reglas y alguien tiene que mantener el flujo que alimenta el almacén cuando los sistemas de origen cambian. El almacén ordenado no se sostiene solo, y esa es la parte que las propuestas suelen callar.

Data warehouse y data lake: la diferencia que decide en qué gastas

La confusión más común es tratarlos como sinónimos o como si uno reemplazara al otro. No es así. La diferencia está en un momento: cuándo le das forma al dato. El data warehouse ordena la información antes de guardarla, con un esquema definido. El data lake la guarda tal cual llega, en su formato original, y le da forma recién cuando alguien la necesita. Esa decisión de “ordenar antes” o “guardar primero” cambia el costo, la velocidad y para quién sirve cada uno.

Cómo distinguirlos sin ser técnico

• Qué guardan: el warehouse guarda datos ya procesados y estructurados (tablas, columnas, reglas claras). El lake guarda todo, incluidos correos, imágenes, logs y archivos que todavía no tienen forma de tabla.
• Cuándo se ordena el dato: en el warehouse, antes de entrar. En el lake, después, cuando alguien lo va a usar. Por eso el warehouse tarda más en cargar pero responde rápido, y el lake carga fácil pero exige trabajo al consultarlo.
• Para quién sirve: el warehouse lo usa el negocio directamente, con reportes y tableros que abre un gerente. El lake lo usa sobre todo el equipo de datos, que necesita el material crudo para explorar o entrenar modelos.
• Qué cuesta: el warehouse cuesta trabajo por adelantado (definir reglas, cuadrar antes de guardar). El lake es barato de llenar y caro de aprovechar si nadie le da orden después.

La forma sana de verlo no es cuál gana, sino que muchas empresas grandes tienen los dos y conectados: el lake recibe todo lo crudo, y de ahí se destila hacia el warehouse lo que ya tiene una pregunta de negocio detrás. Para una empresa mediana que solo quiere reportes confiables, casi siempre el punto de partida correcto es el warehouse, no el lake. Elegir el lake por moda, cuando el problema real era cuadrar reportes, es gastar en un depósito que nadie ordena.

Cómo se usa de verdad en la operación de una empresa

Un data warehouse no se “enciende”, se conecta a decisiones concretas que hoy cuestan tiempo o dinero por falta de un número confiable. La pregunta correcta no es “¿montamos un warehouse?”, es “¿qué decisión estamos tomando a ciegas o con un número que nadie confía, y cuánto nos cuesta esa ceguera?”. Si nadie puede nombrar esa decisión con esa precisión, todavía no hay proyecto, hay ganas de ordenar.

Los usos que más veo dando resultado

• Reportes de dirección que cuadran solos: ventas, margen y cobranza en un tablero donde todas las áreas ven el mismo número, sin el ritual mensual de cuadrar Excels entre correos.
• Análisis por canal, producto o zona: cruzar datos que hoy viven separados, como lo que vende el e-commerce con lo que registra el ERP, para ver dónde de verdad se gana y dónde se pierde.
• Histórico confiable para comparar: el warehouse guarda la foto en el tiempo, así que comparar este trimestre con el mismo del año pasado deja de depender de que alguien haya archivado el reporte viejo.
• Base para tableros e indicadores: cualquier herramienta de visualización sobre un warehouse ordenado rinde; sobre datos sueltos, solo repite el desorden con colores.

El patrón es siempre el mismo: existe una decisión recurrente que hoy se toma tarde o mal porque el dato no está a mano y cuadrado. Un warehouse montado “porque toca modernizar los datos”, sin esa decisión detrás, termina siendo un proyecto caro que el negocio no abre después del segundo mes.

Lo que la empresa necesita tener antes de montarlo

Esta es la parte que las propuestas suelen saltarse, porque no es lo vistoso. Un data warehouse no crea datos buenos: ordena y consolida los que ya existen. Si lo que existe está sucio, duplicado o sin una definición acordada, el almacén va a consolidar exactamente ese desorden, ahora con apariencia de reporte oficial. Lo mínimo que reviso con un cliente antes de recomendar el gasto:

• Definiciones de negocio acordadas: qué cuenta como venta, cliente activo o fecha válida. Si cada área lo define distinto, ese acuerdo es el primer trabajo y no lo resuelve la herramienta.
• Fuentes de datos accesibles: los sistemas de origen (ERP, CRM, e-commerce) deben poder entregar su información de forma automática y periódica, no por exportaciones manuales cada fin de mes.
• Un responsable del dato con nombre y apellido: alguien que responda por que las reglas y las cargas sigan vigentes cuando el negocio cambie. Sin esa figura, el warehouse envejece y vuelve la desconfianza.
• Una pregunta de negocio concreta para empezar: un tablero, un reporte, una decisión. No “todos los datos de la empresa”, porque el alcance amplio es la forma más eficiente de gastar sin mostrar valor.
• Un criterio de calidad mínimo en el origen: si el ERP tiene clientes duplicados y montos mal cargados, eso se limpia antes o se arrastra prolijamente hacia adentro.

Ninguno de estos puntos es tecnología: todos son decisiones de orden interno. Por eso el trabajo de datos y de acuerdos va antes que la compra del almacén. La herramienta no puede consolidar una definición que la empresa nunca se puso de acuerdo en tener.

Qué NO es y qué no resuelve un data warehouse

El entusiasmo con un data warehouse viene de que promete orden. El riesgo es asumir que ordena todo lo que está alrededor. Esto es lo que se le atribuye y no hace:

• No arregla datos malos en el origen. Si el ERP registra mal, el warehouse va a consolidar el error de forma prolija. Limpia y unifica bajo reglas, no adivina cuál era el dato correcto.
• No es una base para operar. No reemplaza al ERP ni al CRM: está pensado para consultar y analizar, no para procesar la venta o emitir la factura en el momento.
• No es un data lake. Si lo que necesitas es guardar material crudo y variado para que un equipo lo explore o entrene modelos, el warehouse no es esa herramienta, y forzarlo sale caro.
• No garantiza que alguien use los reportes. Que el número esté bien y a tiempo no significa que dirección cambie una decisión por él. La adopción es un trabajo aparte del técnico.
• No se mantiene solo. Cuando cambia un sistema de origen o una regla de negocio, el flujo hay que ajustarlo. Sin mantenimiento, el almacén se desactualiza y regresa la desconfianza que vino a resolver.

Decir esto antes cuesta alguna reunión, pero evita el momento incómodo del mes cuatro, cuando alguien reclama que “el warehouse no sirvió” por algo que nunca estuvo en su alcance y que nadie se atrevió a aclarar al inicio.

Cuándo tiene sentido montarlo y cuándo conviene esperar

No es una decisión de tamaño de empresa ni de moda. Es una decisión sobre cuánto te cuesta hoy no tener un número confiable y consolidado, y sobre si existe una decisión recurrente que dependa de ese número.

Señales de que tiene sentido ahora

• El cierre de mes se va en cuadrar cifras entre áreas, y ese tiempo es medible y se repite mes a mes.
• Las decisiones de dirección dependen de cruzar datos que hoy viven en sistemas separados.
• La empresa necesita comparar contra el histórico y hoy eso depende de que alguien haya guardado el reporte viejo.
• Ya hay varias herramientas de reportes tirando números distintos del mismo negocio.
• Existe un responsable del dato que puede sostener las reglas y las cargas en el tiempo.

Señales de que conviene ordenar antes

• Cada área define de forma distinta qué es una venta o un cliente, y no hay acuerdo a la vista.
• Los datos de origen están sucios o duplicados y ese costo de limpieza no está presupuestado.
• El objetivo declarado es “tener todos los datos juntos” sin una decisión ni un reporte concreto detrás.
• Lo que en realidad se necesita es guardar material crudo y variado para explorar: eso apunta a un lake, no a un warehouse.
• No hay quién responda por el mantenimiento una vez entregado el proyecto.

Mi criterio sobre cuándo vale la inversión

Cuando una empresa me pide un data warehouse, lo primero que reviso no es qué tecnología usar ni qué proveedor de nube conviene. Reviso otra cosa mucho más barata de averiguar y mucho más reveladora sobre el estado real del negocio.

La decisión de negocio va antes que la herramienta

El orden que uso para este tema es el mismo de siempre: primero el dolor, después el proceso, después los datos y recién al final la herramienta. El dolor es una decisión que se toma tarde o a ciegas. El proceso es cómo se produce hoy ese número y quién lo cuadra. Los datos son si existen, si están limpios y si hay una definición acordada. Y solo cuando eso está claro tiene sentido preguntar si el almacén correcto es un data warehouse, un data lake o los dos conectados.

Un data warehouse bien planteado hace más de lo que promete el reporte: obliga a la empresa a ponerse de acuerdo en sus propias definiciones, y ese acuerdo queda incluso si algún día se cambia de tecnología. En varios casos el mayor retorno no fue el tablero nuevo, fue descubrir que media organización llamaba “venta” a cosas distintas. Empieza por la decisión que quieres dejar de tomar a ciegas, no por el tamaño del almacén.