Data lake

Un data lake (lago de datos) es un repositorio centralizado que almacena grandes volúmenes de datos en su formato nativo y crudo, sin imponer una estructura previa al momento de cargarlos. A diferencia de una base de datos tradicional, recibe por igual tablas relacionales, archivos JSON, logs, correos, imágenes, audio o video, y deja la organización del dato para más adelante.

Su rasgo definitorio es el esquema en lectura (schema-on-read): en lugar de modelar y transformar los datos antes de guardarlos, el data lake los conserva tal cual llegan y aplica la estructura recién cuando alguien los consulta. Esto lo hace flexible y económico para almacenar todo lo que una empresa genera, incluso aquello cuyo uso futuro todavía no está definido.

En la práctica, un data lake suele ser la capa de almacenamiento crudo sobre la que después se construye la analítica de negocio. Esa explotación (modelado, métricas y tableros) es parte de lo que resuelve Metrix, que convierte ese volumen disperso en información accionable.

Un data lake nació como respuesta a un problema concreto: las empresas generan cada vez más datos que no encajan en filas y columnas. Un correo de un cliente, las coordenadas de un camión, una foto de góndola, los clics en un sitio o las conversaciones de WhatsApp son datos valiosos que un esquema rígido obliga a descartar o deformar. El data lake los acepta a todos en su estado original y los guarda baratos, a la espera de darles uso.

Cómo funciona por dentro

La idea central es separar el almacenamiento del procesamiento. El dato entra crudo y se deposita en un almacenamiento de objetos de bajo costo (en la nube o en infraestructura propia). No se lo transforma al ingresar: esa es la diferencia con el clásico ETL, donde primero se limpia y modela y recién después se carga. En un data lake suele invertirse el orden (cargar primero, transformar después), porque el objetivo es no perder nada y decidir el modelado cuando aparece la pregunta de negocio.

Un data lake bien gestionado se organiza por zonas, normalmente tres:

• Zona cruda (raw): el dato tal cual llegó de la fuente, sin tocar. Es la copia fiel y auditable.
• Zona procesada (curada): datos ya limpios, validados y enriquecidos, listos para análisis confiable.
• Zona de consumo: vistas y conjuntos modelados para tableros, reportes o modelos de machine learning.

Por qué le importa al negocio

El valor real de un data lake no es guardar por guardar: es habilitar preguntas que antes no se podían responder. Al concentrar en un solo lugar datos de ventas, marketing, logística y finanzas, una empresa puede cruzar información que vivía en silos. También es el insumo natural de la IA: los modelos de machine learning y los proyectos de análisis predictivo necesitan grandes volúmenes de datos históricos crudos para entrenarse, y el data lake es donde viven.

Ejemplo concreto (LATAM)

Pensá en una distribuidora de Consumo Masivo en Argentina. Sus pedidos están en el ERP, las visitas de los vendedores en una app, las fotos de exhibición en otra herramienta y las quejas de clientes en WhatsApp. Por separado, cada fuente cuenta media historia. Volcando todo a un data lake, el equipo puede preguntarse si las sucursales con mejor exhibición en góndola venden más del SKU promocionado. Esa correlación, imposible con datos aislados, surge al tener todo bajo un mismo techo. Después, una capa de analítica modela esos datos crudos en métricas comparables.

Data lake vs data warehouse

Es la comparación más útil para entender el concepto. No son rivales: muchas empresas usan los dos, y el data lake suele alimentar al warehouse.

El error más común: el data swamp

El mayor riesgo de un data lake es degenerar en un pantano de datos (data swamp): un depósito gigante donde nadie sabe qué hay, de dónde vino ni si es confiable. Sin gobierno de datos, catálogo y metadatos, el lago se vuelve inservible. Por eso un data lake sano es inseparable del gobierno de datos y de la calidad del dato: no alcanza con acumular, hay que documentar el linaje, controlar accesos y garantizar que el dato curado sea creíble. Otros errores frecuentes son tratarlo como un simple disco de respaldo, no separar las zonas crudas de las consumibles, y subir datos sin ninguna política de retención ni catalogación.