El problema
Cuando empezás a trabajar con datos en la nube, tarde o temprano te cruzás con el object storage: S3 en AWS, Blob Storage en Azure, Cloud Storage en GCP. Es barato, escala sin límite práctico, y se convirtió en el lugar natural para guardar datos analíticos.
Pero hay algo que no es obvio hasta que lo necesitás: no podés hacer un UPDATE.
Si tenés un archivo Parquet con un millón de registros y necesitás modificar uno, no podés abrir el archivo, cambiar ese registro y guardarlo. Tenés que borrar el archivo entero y volver a cargarlo completo.
Eso no es un bug ni una limitación temporal, sino cómo está diseñado el sistema.
La restricción de diseño
El object storage está construido sobre un principio: los objetos no se modifican parcialmente. Podés reemplazar un objeto completo o sobrescribir una key, pero no abrir un archivo y cambiar una fila adentro como harías con una base transaccional.
Esto tiene sentido desde la perspectiva del sistema. Ese modelo simplifica la replicación, la consistencia entre regiones, el versionado y la auditoría. Es lo que permite que el almacenamiento sea tan barato y tan confiable a la vez.
Pero genera un problema cuando querés usar ese almacenamiento para analítica que necesita actualizaciones.
Pensalo así: en una base de datos relacional, un UPDATE es una operación atómica. El motor se mete en el registro, lo modifica, y listo. En object storage, eso no existe. Un update implica meterse dentro del objeto de datos y modificarlo. Por defecto, eso no se puede.
Por qué importa en la práctica
En analítica, las actualizaciones son inevitables. Un cliente cambia de dirección. Un producto cambia de precio. Un empleado cambia de departamento. Si estás modelando dimensiones, necesitás poder reflejar esos cambios.
Durante años, la solución fue usar data warehouses tradicionales que manejaban esto internamente. Pero esos sistemas tenían otro problema: el cómputo y el almacenamiento estaban acoplados. Si necesitabas más capacidad de procesamiento, tenías que comprar más almacenamiento aunque no lo necesitaras. Y viceversa.
El object storage resolvía el problema del costo y la escala, pero introducía el problema de la inmutabilidad.
La solución: una capa encima
Ahí aparecen los lakehouse, que son la respuesta a esta restricción física (no una moda ni un rebranding de marketing).
La idea es simple: si no podés modificar el archivo, llevás un registro de qué cambios querés hacer. En lugar de reescribir el Parquet, escribís un log que dice "el registro con ID 12345 ahora tiene este valor". Cuando alguien consulta los datos, el motor combina el archivo original con el log de cambios y devuelve la versión actualizada.
Eso es lo que hacen formatos como Iceberg, Delta Lake y Hudi. No modifican los archivos subyacentes. Agregan una capa de metadatos y logs transaccionales que emulan las operaciones de una base de datos sobre almacenamiento inmutable.
El resultado es que podés tener lo mejor de los dos mundos: el costo y la escala del object storage, con la semántica de updates, deletes y transacciones que necesitás para analítica seria.
Trade-offs y consideraciones
Esta arquitectura tiene costos. Agregar una capa de metadatos y logs introduce complejidad operativa. Tenés que elegir un formato (y en muchos equipos Iceberg aparece con mucha fuerza, aunque la elección depende del ecosistema), configurar el motor de consultas para que lo entienda, y mantener procesos de compactación para que los logs no crezcan indefinidamente.
También cambia cómo pensás el diseño. En un data warehouse tradicional, el almacenamiento y el procesamiento vienen juntos. En un lakehouse, los desacoplás: el almacenamiento es object storage puro, y el cómputo puede ser cualquier motor que entienda el formato (Spark, Trino, DuckDB, Athena, el que sea).
Eso te da flexibilidad para cambiar de motor sin migrar datos, pero también te obliga a entender qué está pasando en cada capa.
En resumen
El object storage no está pensado para modificar parcialmente objetos. Esa restricción no es un defecto: es lo que permite que sea barato, confiable y escalable.
Pero cuando necesitás hacer updates sobre datos analíticos, esa inmutabilidad se convierte en un problema. Los lakehouse existen para resolverlo: agregan una capa de logs y metadatos que emula operaciones transaccionales sobre archivos que se reemplazan, no se actualizan fila por fila.
Entender esto te ayuda a tomar mejores decisiones de arquitectura. No elegís un lakehouse porque está de moda. Lo elegís porque necesitás updates sobre object storage, y esa es la forma de conseguirlos.
Lo que viene en esta colección
Esta restricción física es el punto de partida para entender las decisiones de arquitectura en datos. Desde acá vamos a ver cómo la separación de cómputo y almacenamiento cambió el modelo de costos, qué pasa cuando un data lake crece sin gobierno, cómo elegir entre herramientas modulares y plataformas integradas, qué estrategia de procesamiento usar según la latencia que necesitás, y cómo elegir la herramienta correcta para cada problema.
Todas esas decisiones tienen algo en común: no se toman en el vacío. Se toman entendiendo las restricciones físicas y los trade-offs de cada capa.