Qué es un data lake y para qué sirve

Tener mucha data no es tener datos útiles, y ese es el malentendido caro

El disco se llena, el equipo compra más almacenamiento, y la sensación general en la empresa es que “tenemos muchísima data”. Meses después alguien de dirección pide algo simple, cuánto vendió cada canal el último año cruzado con el costo de adquisición, y nadie puede armarlo sin dos semanas de trabajo manual. La conclusión apurada suele ser que falta una herramienta, cuando el problema real es que los datos están regados en veinte lugares, en formatos que no conversan entre sí, y sin nadie que responda por ellos.

Ahí entra la promesa del data lake, y ahí también empieza el malentendido más caro. La mayoría lo compra como si fuera un depósito mágico donde se vuelca todo y, por el solo hecho de tenerlo junto, la información se vuelve útil. No funciona así. Un data lake resuelve dónde guardar, no qué hacer con lo guardado, y esa diferencia es la que separa un proyecto que devuelve valor de un gasto de infraestructura que crece cada mes sin que nadie sepa cómo apagarlo.

Qué es un data lake en criterio de negocio, no de ingeniería

Un data lake, en criollo, es un solo lugar donde la empresa deposita sus datos tal como llegan, sin obligarlos a entrar en un formato predefinido. Ventas en planillas, registros del sistema, correos, imágenes de producto, actividad de la web, todo cae al mismo repositorio en su forma original. La idea de fondo es no perder información por no haber decidido de antemano para qué la ibas a usar.

Lo que hace atractivo al data lake para el negocio es que separa dos decisiones que antes iban juntas: guardar y estructurar. Guardas primero, barato y sin fricción, y le das forma recién cuando aparece la pregunta concreta. Eso tiene una consecuencia que conviene entender antes de firmar nada: el trabajo de ordenar no desaparece, se posterga. Alguien lo va a pagar después, con la diferencia de que para entonces el volumen es mayor y el desorden también.

Data lake y data warehouse no son lo mismo ni compiten

La confusión más común es tratar data lake y data warehouse como sinónimos, o peor, como si uno reemplazara al otro. No compiten: resuelven momentos distintos del mismo problema y en la práctica suelen convivir.

La diferencia en criterio de negocio

• El data lake guarda crudo: recibe el dato en su formato original, sin limpiarlo ni ordenarlo, y es barato de alimentar. Su fuerte es no descartar nada y aceptar cualquier tipo de información, incluso la que hoy no sabes si vas a usar.
• El data warehouse guarda cocinado: recibe datos ya limpios, ordenados y con un esquema fijo, listos para reportes y tableros. Es más caro de mantener, pero responde preguntas de negocio en segundos porque el trabajo sucio ya se hizo antes.
• El orden real suele ser lago y después bodega: el lago recibe todo, y desde ahí se procesa hacia el warehouse solo lo que el negocio consulta seguido. Uno es la materia prima, el otro es el estante ordenado del que sale el reporte.

Para una empresa la pregunta no es cuál elegir en abstracto, es qué necesita responder y con qué frecuencia. Si lo que hay son reportes recurrentes y bien definidos, el warehouse hace el trabajo. Si además hay datos variados que todavía no sabes cómo vas a explotar, el lago evita tirarlos mientras lo decides. Comprar el lago sin saber qué preguntas quieres responder es comprar el depósito antes de saber qué negocio vas a montar en él.

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

Un data lake no se enciende y entrega valor solo, es una base sobre la que se apoyan otros trabajos. En la operación real suele justificar su existencia en tres frentes concretos.

Para qué lo usan las empresas que le sacan provecho

• Consolidar fuentes que hoy no conversan: ventas en un sistema, marketing en otro, atención en un tercero. El lago junta todo en un lugar para poder cruzarlo, en vez de exportar planillas y pegarlas a mano cada fin de mes.
• Alimentar análisis y modelos de IA: los proyectos de IA predictiva o los sistemas de recuperación necesitan datos históricos y variados. El lago es donde ese material vive antes de convertirse en algo consultable, por ejemplo cuando se generan embeddings para buscar por significado.
• Guardar datos que hoy no usas pero podrías necesitar: registros de actividad, versiones históricas, datos de sensores. Barato de almacenar, imposible de recuperar si ya lo borraste. El lago te compra la opción de decidir después.

El patrón sano es el mismo que en cualquier proyecto de datos: primero el proceso o la pregunta de negocio, después el dato, y recién al final la infraestructura. Un data lake que se monta “porque toca tener uno” termina siendo un disco caro donde nadie entra y que dirección no sabe cómo defender cuando revisa gastos.

Lo que la empresa necesita tener antes de volcar el primer archivo

Esta es la parte que las propuestas de infraestructura suelen minimizar, porque no está en el precio del almacenamiento. Un data lake sin gobierno no es un activo, es un pasivo que crece. Lista mínima que reviso antes de recomendar el primer paso:

• Un catálogo de qué hay adentro: saber qué datos entraron, de dónde vienen y qué significan. Sin catálogo, el lago se vuelve una caja negra donde nadie encuentra nada y todos desconfían de todo.
• Dueños por tipo de dato: alguien con nombre y apellido que responda por cada fuente, su vigencia y su calidad. Sin dueños, la información envejece sin que nadie lo note hasta que ya tomaste una decisión con un dato viejo.
• Reglas de acceso y permisos: un lago concentra datos sensibles de toda la empresa en un solo lugar. Eso lo vuelve práctico y, al mismo tiempo, un punto único de riesgo si cualquiera entra a todo sin control.
• Un criterio de qué entra y qué no: guardar todo no significa guardar basura. Duplicados, archivos rotos y exportaciones a medias ensucian el lago igual que ensucian una carpeta compartida.
• Un primer caso de uso concreto: una pregunta de negocio que justifique el esfuerzo desde el inicio. El lago que arranca sin caso de uso nunca demuestra su valor y es el primero que se recorta cuando ajustan presupuesto.

Ninguno de estos puntos es tecnología, todos son decisiones de gobierno. Por eso el data lake es tanto un tema de dirección como de sistemas: la herramienta es la parte fácil, sostener el orden en el tiempo es la difícil y la que casi nadie presupuesta.

Cuando el lago se convierte en pantano

En la industria hay un término para el data lake que salió mal: pantano de datos. Es el mismo repositorio, con la misma tecnología, pero convertido en un vertedero donde entra información sin control, sin catálogo y sin dueño, hasta que nadie confía en lo que hay adentro ni se atreve a borrar nada por si acaso.

El deslizamiento hacia el pantano es silencioso y casi siempre sigue los mismos pasos. Se empieza volcando todo “para no perder nada”. Como guardar es barato y ordenar cuesta, nadie ordena. Al año hay quince versiones del mismo reporte, tablas sin descripción y datos que nadie sabe si están vigentes. Cuando por fin alguien necesita una respuesta, el costo de encontrar el dato correcto y confiar en él supera lo que habría costado tenerlo ordenado desde el inicio. El lago no falló como tecnología: se usó como excusa para posponer el trabajo de orden que igual había que hacer.

La señal temprana de pantano es fácil de detectar sin abrir ningún sistema: cuando pides un dato y la respuesta del equipo es “sí, eso está en algún lado, déjame buscarlo”, el lago ya empezó a ensuciarse. Un repositorio sano responde con la fuente y su fecha, no con una búsqueda a ciegas.

Qué NO resuelve un data lake, y por qué conviene saberlo antes de firmar

El entusiasmo con el data lake viene de que promete terminar con el desorden de datos. El riesgo es creer que el solo hecho de juntarlo todo ya resuelve algo. Esto es lo que se le atribuye y no hace:

• No limpia ni ordena los datos. Recibe lo que le echas tal como está. Si entra sucio, sale sucio; el lago no mejora la calidad, solo la centraliza en un mismo lugar.
• No responde preguntas de negocio por sí solo. Es materia prima, no reporte. Encima del lago hace falta procesamiento, un warehouse o herramientas de análisis para convertir el dato en una respuesta que dirección pueda usar.
• No es un data warehouse. No está optimizado para consultas rápidas y recurrentes. Pedirle el rol de un warehouse termina en reportes lentos y usuarios que vuelven a la planilla de siempre.
• No reemplaza la ingeniería de datos. Alguien tiene que mover, transformar y mantener el flujo que llena el lago y lo conecta con el resto. El repositorio es el estante, no el trabajo de llenarlo bien.
• No garantiza el cumplimiento legal. Concentrar datos personales en un solo lugar puede facilitar la gestión o multiplicar el riesgo, según cómo se controle el acceso. La herramienta no te vuelve conforme con la normativa, el gobierno sí.

Aclarar esto antes de firmar evita el reclamo del mes seis, cuando dirección esperaba tableros y lo que hay es un depósito lleno de archivos que todavía necesitan a alguien que los trabaje para que digan algo.

Cuándo tiene sentido montar un data lake y cuándo conviene esperar

La decisión no es de tamaño de empresa ni de moda tecnológica. Es sobre la variedad de tus datos, el estado de tu orden interno y si tienes un equipo que pueda sostener el gobierno en el tiempo.

Señales de que tiene sentido ahora

• Tienes datos de muchas fuentes y formatos distintos que hoy viven aislados y que necesitas cruzar para decidir.
• Hay proyectos de análisis o de IA en el horizonte que van a necesitar datos históricos y variados como insumo.
• Estás descartando información valiosa solo porque no tienes dónde guardarla de forma barata.
• Existe un equipo o un responsable que puede hacerse cargo del catálogo, los permisos y la calidad de forma sostenida.

Señales de que conviene ordenar antes

• Tus necesidades son reportes bien definidos y recurrentes: un data warehouse, o incluso planillas ordenadas, resuelven eso mejor y más barato.
• Nadie va a hacerse cargo del gobierno del repositorio; sin dueño, el lago nace pantano.
• El objetivo declarado es “tener toda la data junta” sin una pregunta de negocio que lo justifique.
• Todavía no resolviste la calidad de tus datos en el origen: juntar datos malos solo los hace más fáciles de mezclar entre sí.

Primero la pregunta de negocio, recién al final el repositorio

Por eso el orden de la decisión no cambia, sea un data lake o cualquier otra pieza de datos. Primero el dolor, la pregunta de negocio que hoy cuesta caro no poder responder. Después el proceso y las personas que van a sostenerlo. Luego los datos, su calidad y su dueño. Y recién al final el repositorio donde vivirán. Un data lake montado en ese orden es una base sólida para años de análisis e IA. Montado al revés, es el depósito más caro de la empresa y el primero que nadie sabe cómo justificar cuando llega el ajuste.