La elección entre data lake y data warehouse empieza por la pregunta de negocio, no por la herramienta. Si la dirección necesita las mismas veinte respuestas cada mes (ingresos por canal, margen por producto, abandono por segmento), un warehouse gestionado lo resuelve y un lake solo añade trabajo. Si la empresa necesita guardar logs, documentos, eventos de navegación y datos de sensores para preguntas que todavía no sabe formular, el warehouse por sí solo resulta caro y estrecho.
Lo que ha cambiado en los últimos años es que las dos opciones han dejado de ser excluyentes. Hoy se pueden guardar datos en formato abierto, en almacenamiento de objetos barato, y consultarlos con el motor del warehouse. Eso cambia la decisión, pero no elimina la pregunta de partida.
La diferencia que sigue vigente
Un data warehouse guarda datos estructurados con un esquema definido en la escritura (schema-on-write): la tabla de ventas tiene columnas, tipos y reglas antes de recibir su primera fila. Está optimizado para SQL, BI y preguntas recurrentes. BigQuery, Snowflake y Amazon Redshift son los ejemplos más habituales.
Un data lake guarda archivos en bruto en almacenamiento de objetos (Amazon S3, Google Cloud Storage, Azure Data Lake Storage) y aplica el esquema en la lectura (schema-on-read). Admite CSV, JSON, Parquet, imágenes, PDF, logs. Es barato para almacenar y flexible para explorar, pero traslada los problemas de calidad y gobierno a quien consume los datos.
El artículo que popularizó el término lakehouse, publicado por Armbrust, Ghodsi, Xin y Zaharia en CIDR 2021, describe bien la arquitectura de dos capas que montaron muchas empresas: los datos llegan al lake, una parte se copia al warehouse mediante ETL y las dos copias acaban desalineadas. Los autores enumeran los costes de esa separación: datos desactualizados, problemas de fiabilidad entre copias, mayor coste total, dependencia del proveedor y poco soporte para ciencia de datos.
Lo que cambió el lakehouse
La respuesta técnica llegó con los formatos abiertos de tabla. Apache Iceberg y Delta Lake añaden una capa de metadatos sobre archivos Parquet en almacenamiento de objetos y, con ella, transacciones ACID, evolución de esquema, consulta de versiones anteriores (time travel) y borrado de filas concretas. En la práctica, los archivos del bucket pasan a comportarse como una tabla.
Los tres grandes warehouses en la nube ya leen estos formatos:
- Snowflake declaró las tablas Apache Iceberg disponibles de forma general en junio de 2024.
- Amazon Redshift consulta tablas Iceberg catalogadas en AWS Glue, mediante Redshift Spectrum o Redshift Serverless.
- BigQuery ofrece tablas BigLake para Apache Iceberg, con los datos en buckets del propio cliente.
La consecuencia para quien decide: guardar datos en Iceberg o Delta reduce el riesgo de quedar atado a un proveedor, porque otro motor puede leer la misma copia. El precio es una pieza más que operar: catálogo, compactación de archivos pequeños, política de retención de snapshots. En un equipo pequeño, eso pesa.
El modelo de facturación pesa tanto como la arquitectura
Muchas decisiones de datos fallan en la factura, no en el diagrama. Los tres proveedores cobran de forma distinta, y cada modelo penaliza un comportamiento distinto.
BigQuery. En el modelo on-demand, se cobra por el volumen de datos que lee cada consulta: el primer TiB del mes es gratuito, y la tabla de precios indica 6,25 dólares por TiB a partir de ahí en regiones como us-central1. También existe el modelo por capacidad, en slots. El on-demand penaliza las consultas que recorren tablas enteras: un panel mal construido que lee una tabla grande en cada actualización se convierte en una línea visible de la factura. Particionar por fecha y agrupar por las columnas más filtradas suele ser el primer ahorro.
Snowflake. El procesamiento se ejecuta en virtual warehouses que consumen créditos facturados por segundo, con un mínimo de 60 segundos cada vez que el warehouse arranca. Aquí lo que pesa son los warehouses encendidos sin uso y los que tienen más tamaño del que pide la carga. Un auto-suspend corto y tamaños separados para carga y para BI resuelven buena parte.
Redshift. Hay clústeres aprovisionados, en los que se paga por los nodos encendidos, y Redshift Serverless, facturado por capacidad usada (RPU-hora), por segundo con un mínimo de 60 segundos. La propia documentación de AWS advierte de un coste que sorprende: las consultas de health check de los pools de conexión, como un SELECT 1 periódico, se facturan como uso normal. Una aplicación que mantiene conexiones abiertas puede generar coste sin que nadie consulte nada.
Ninguno de estos modelos es mejor en términos absolutos. Una carga estable y previsible suele salir más barata con capacidad reservada; una carga irregular, con picos a fin de mes, tiende a favorecer on-demand o serverless. Por eso conviene medir el perfil de uso real antes de firmar un compromiso anual.
Un checklist para decidir
Responda a estas preguntas antes de elegir tecnología:
- ¿Cuáles son las preguntas recurrentes? Enumere las que la dirección y las áreas hacen cada mes. Si todas salen del ERP, el CRM y finanzas, está en terreno de warehouse.
- ¿Qué tipos de datos entran? ¿Solo tablas de sistemas transaccionales, o también eventos web y de app, logs, documentos, audio, telemetría? Los datos no estructurados en volumen empujan hacia un lake o un lakehouse.
- ¿Quién los consume? ¿Analistas con SQL y una herramienta de BI, o científicos de datos con Python y Spark entrenando modelos? El segundo grupo se beneficia del acceso directo a archivos en formato abierto.
- ¿Quién lo va a operar? Un lakehouse con Iceberg exige ingeniería de datos de verdad. Si el equipo de datos es una persona, un warehouse gestionado es la opción más segura.
- ¿En qué nube está ya la empresa? Contratos, red, identidad y seguridad ya configurados valen dinero. En Google Cloud el camino corto es BigQuery; en AWS, Redshift y Athena.
- ¿Cuánta dependencia del proveedor tolera? Si quiere poder cambiar de motor dentro de tres años, guardar en formato abierto desde ahora es barato; hacerlo después, no.
- ¿Cómo atiende las solicitudes de supresión del RGPD o de la LGPD? Una solicitud de borrado de datos personales tiene que cumplirse en todas las copias. En un lake de archivos sueltos, localizar y borrar los registros de un cliente es trabajo manual; en un warehouse o en una tabla Iceberg o Delta, es una sentencia DELETE.
Tres escenarios habituales
Empresa mediana con ERP, CRM y hojas de cálculo. Unos cientos de gigabytes, preguntas conocidas, equipo de datos pequeño. Warehouse gestionado en la nube que ya usa la empresa, una herramienta de ingesta y una capa de modelado en SQL. Aquí un lake es coste sin retorno.
Comercio digital con clickstream, catálogo y planes de recomendación. Eventos en gran volumen, datos semiestructurados, científicos de datos que necesitan el histórico en bruto. Almacenamiento de objetos con tablas Iceberg, leídas por el warehouse para BI y por Spark o Python para los modelos.
Industria con sensores y sistemas heredados. Telemetría de alta frecuencia que nadie consulta entera, más datos de producción y calidad que la dirección consulta a diario. Telemetría en bruto en el lake, agregados por turno y por máquina en el warehouse.
El error más caro
Migrar a un data lake pensando que resolverá el desorden de los datos. Si hoy nadie sabe qué hoja de cálculo tiene la cifra correcta de clientes activos, un lake guardará todas las versiones equivocadas, con mucho más espacio. El problema en esos casos es de gobierno: un responsable para cada tabla importante, una definición única de cada métrica, un catálogo que diga de dónde sale cada número. Ninguna arquitectura sustituye eso, y un lake sin gobierno acaba siendo lo que el sector llama un data swamp.
Siguiente paso
Antes de comparar proveedores, reúna las diez preguntas que más hace la dirección y marque, para cada una, de qué sistema vienen los datos y con qué frecuencia debe actualizarse la respuesta. Esa lista de una página decide más que cualquier benchmark de rendimiento y muestra si su problema es de arquitectura o de gobierno.
Si quiere ayuda para elaborar esa lista y convertirla en arquitectura, es el trabajo que hacemos en Datos e IA. Cuando la duda es concreta, como saber si merece la pena migrar un warehouse a Iceberg, una Cyborg Forge de pocas semanas mide coste y rendimiento con sus propios datos.