El relato del data lake
Cuando apareció Hadoop y la posibilidad de armar clusters distribuidos con hardware commodity, el relato era atractivo: podés guardar todo, de cualquier formato, a un costo mucho menor que un data warehouse tradicional. La escala dejaba de ser un problema físico.
Muchas empresas compraron ese relato. Todo el mundo quería tener su cluster. La promesa era que si juntabas suficientes datos, eventualmente ibas a poder hacer algo valioso con ellos.
El problema es que "juntar datos" no es lo mismo que "tener un proyecto de datos".
Qué salió mal
Lo que terminó pasando en muchas organizaciones fue predecible: se empezaron a acumular clusters y datos sin un propósito claro. Había quizás algún proyecto que funcionaba, pero la generalidad fue una gran decepción.
El data lake prometía un montón y después no entregó. Pero no por una cuestión técnica, sino por una cuestión de falta de gobierno.
Donde no hay gobierno, hay descontrol. Y donde hay descontrol, no hay proyectos de datos reales. Lo que hay son proyectos de subirse a la moda de lo que sea.
La diferencia entre un proyecto de datos y un ejercicio de acumulación es el problema de negocio. Si no hay un problema concreto que resolver, no hay criterio para decidir qué datos importan, cómo se relacionan, ni cómo se van a consumir. Sin ese criterio, el lake se convierte en un repositorio de archivos que nadie entiende ni usa.
El patrón que se repite
Este patrón no es exclusivo del data lake. Cada vez que aparece una tecnología nueva que promete resolver problemas de escala o costo, hay una tentación de adoptarla sin preguntarse primero qué problema de negocio va a resolver.
Con el data lake fue "tiremos todo acá a ver qué pasa". Con otras tecnologías el patrón es similar: la herramienta se convierte en el objetivo en lugar de ser el medio para resolver algo concreto.
El resultado es siempre el mismo: inversión en infraestructura que no se traduce en valor, equipos frustrados, y eventualmente un cambio de rumbo hacia la siguiente promesa tecnológica.
Qué distingue a los proyectos que funcionaron
Los proyectos de datos que sí funcionaron sobre data lakes tenían algo en común: arrancaron desde un problema de negocio, no desde la tecnología.
Primero definieron qué querían resolver. Después evaluaron qué datos necesitaban. Después decidieron cómo los iban a procesar y consumir. La tecnología era una consecuencia de esas decisiones, no el punto de partida.
También tenían gobierno. No necesariamente un framework complejo de data governance, pero sí criterios claros: quién es responsable de qué datos, qué significa cada campo, cómo se actualiza, quién puede acceder. Sin eso, el volumen de datos se convierte en un problema en lugar de un activo.
Qué llevarse de esta historia
El data lake como concepto técnico sigue siendo válido. Guardar datos en formatos abiertos sobre almacenamiento barato tiene sentido en muchos contextos. Lo que falló no fue la arquitectura sino la forma de adoptarla.
No importa si usás Hadoop, Spark, un lakehouse moderno o lo que venga después. Si no tenés un problema de negocio claro y un mínimo de gobierno sobre los datos, vas a repetir el mismo patrón.
Antes de preguntarte qué tecnología usar, preguntate qué problema vas a resolver y cómo vas a saber si lo resolviste. Si no podés responder eso, la tecnología que elijas es irrelevante.