Cuando una empresa decide ordenar sus datos para tomar mejores decisiones, aparece casi siempre la misma disyuntiva: ¿un data lake o un data warehouse? Las dos son formas de centralizar información para analizarla, las dos viven cómodamente en la nube, y las dos prometen “una sola fuente de verdad”. La diferencia no está en cuál es mejor, sino en qué problema resuelve cada una — y elegir sin criterio se paga después en costo, en tiempo de respuesta o en un proyecto de datos que nunca termina de dar valor.
Esta guía compara ambas opciones con criterios de decisión para gerentes de tecnología, no solo para arquitectos de datos.
Qué es cada uno, en una frase
- Un data warehouse es un repositorio de datos ya estructurados y depurados, pensado para responder preguntas de negocio conocidas con consultas SQL rápidas: ventas por región, márgenes por producto, indicadores para tableros. Define la estructura antes de guardar el dato. En AWS, ese servicio es Amazon Redshift.
- Un data lake es un repositorio que guarda datos en su formato original —tablas, archivos, logs, datos de sensores, texto, imágenes— sin exigir una estructura previa. Aplica la estructura recién cuando alguien lee el dato. En AWS, se construye típicamente sobre Amazon S3, con AWS Glue y AWS Lake Formation alrededor.
La confusión es comprensible: los dos “guardan datos para analizar”. Pero el orden en que ordenan la información es distinto, y ese orden es el que decide.
Los criterios que realmente deciden
1. El tipo de dato que necesitas guardar
Este criterio filtra antes que cualquier otro. Si tus datos son mayormente estructurados y ya conocidos —transacciones, registros de tu ERP, tablas de un sistema de facturación—, el data warehouse los recibe naturalmente. Si necesitas guardar datos variados y en crudo —archivos de distinto formato, datos de dispositivos, contenido semiestructurado que todavía no sabes cómo vas a usar—, el data lake fue diseñado exactamente para eso: acepta todo sin pedirte que definas la estructura de antemano.
Según la documentación de AWS, el data warehouse exige diseñar el esquema antes de escribir el dato —un enfoque schema-on-write—, mientras que el data lake aplica el esquema al leer —schema-on-read—, lo que le da flexibilidad para admitir formatos diversos.
2. Quién va a usar los datos
El warehouse está hecho para el área de negocio y los analistas: gente que hace preguntas conocidas en SQL, arma reportes y vive en tableros. El lake está hecho para ciencia de datos e ingeniería: perfiles que exploran, entrenan modelos de machine learning y necesitan el dato en bruto, no una versión ya resumida. Preguntarte quién va a consumir la información —y con qué herramientas— ordena la decisión más rápido que cualquier comparación técnica.
3. El momento del procesamiento: ETL vs ELT
Aquí está una diferencia operativa concreta. El warehouse suele exigir preparar el dato antes de guardarlo: se extrae, se transforma y se carga ya limpio (el patrón ETL). El lake invierte el orden: carga el dato primero y lo transforma solo cuando hace falta (patrón ELT). Esto tiene consecuencias de costo y de velocidad de arranque: el lake te deja empezar a guardar sin resolver toda la transformación de entrada; el warehouse te pide ese trabajo por adelantado, y a cambio entrega consultas más rápidas y predecibles.
4. Costo y gobernanza
El almacenamiento de objetos sobre el que vive el data lake es económico y crece sin sobreaprovisionar, lo que lo vuelve atractivo para guardar volúmenes grandes de datos que todavía no producen valor directo. Pero esa misma flexibilidad tiene un riesgo conocido: sin catálogo, sin control de accesos y sin calidad, un data lake se convierte en un “pantano de datos” donde nadie encuentra nada confiable. Por eso la gobernanza —catalogar con AWS Glue, controlar accesos con AWS Lake Formation— no es opcional en un lake. El warehouse, al imponer estructura desde el inicio, trae buena parte de esa gobernanza incorporada, a cambio de menos flexibilidad.
Data lake vs data warehouse: la tabla de decisión
| Criterio | Data warehouse (Amazon Redshift) | Data lake (Amazon S3 + Glue) |
|---|---|---|
| Tipo de dato | Estructurado y depurado | Cualquier formato, en crudo |
| Esquema | Se define antes de escribir (schema-on-write) | Se aplica al leer (schema-on-read) |
| Procesamiento | ETL: transformar antes de cargar | ELT: cargar y transformar después |
| Usuario típico | Negocio y analistas (SQL, BI) | Ciencia de datos e ingeniería |
| Caso ideal | Reportería, tableros, consultas conocidas | Exploración, machine learning, datos variados |
| Costo de almacenamiento | Mayor, optimizado para consulta | Bajo, escala con el uso |
| Gobernanza | Estructura incorporada | Requiere catálogo y control explícito |
Cuándo conviene cada uno
Elige el data warehouse cuando tu necesidad urgente es reportería confiable y tableros para gerencia, cuando tus datos ya son estructurados y conocidos, y cuando el tiempo de respuesta de las consultas importa para la operación diaria.
Elige el data lake cuando necesitas consolidar datos dispersos de muchas fuentes y formatos, cuando quieres habilitar ciencia de datos y machine learning sobre datos en crudo, o cuando el volumen y la variedad hacen impráctico estructurar todo por adelantado.
La respuesta madura: no elegir, combinar
En la práctica, la mayoría de las empresas no eligen uno u otro: los combinan. El data lake recibe todo el dato crudo a bajo costo; el data warehouse toma de ahí lo que el negocio consulta a diario y lo sirve rápido. Esa combinación tiene nombre —arquitectura lakehouse— y es hacia donde apunta el diseño moderno de datos en AWS: Amazon S3 como capa de almacenamiento, AWS Glue para catalogar y transformar, y Amazon Redshift capaz de consultar datos del lake sin moverlos. No son dos mundos separados que hay que elegir; son dos capas de una misma plataforma.
Cómo lo abordamos en Caleidos
En Caleidos, como AWS Advanced Tier Services Partner, esta decisión es parte de nuestra práctica de datos y analítica y de data engineering: empezamos por la pregunta de negocio, no por la herramienta, dimensionamos qué capa entrega valor primero en tu caso, y diseñamos la arquitectura para que el lake y el warehouse trabajen juntos en lugar de competir. Si quieres entender primero cada pieza, profundizamos en qué es un data warehouse, qué es un data lake y qué es Amazon Redshift.
¿Ordenando la estrategia de datos de tu empresa?
Conversemos sobre tu caso: en 30 minutos te damos una lectura concreta de si tu punto de partida es un data warehouse, un data lake o una arquitectura que combine ambos.
