A las grandes organizaciones no les faltan datos; lo que les falta es acceso a ellos. Cada unidad extrae sus informes de su propia base de datos, el equipo de analítica tiene que obtener permisos y extracciones de varios responsables de datos para cada nueva pregunta y, cuando dos informes muestran cifras distintas para la misma métrica, se pierden semanas averiguando por qué. El almacén de datos tradicional resolvió parte del problema, pero para los datos semiestructurados, los eventos de sensores, las imágenes y el texto, o para las cargas de trabajo de aprendizaje automático, su estructura rígida y su coste se convierten en el obstáculo.
Su importancia se ha multiplicado con la llegada de la IA a la empresa. Los modelos necesitan datos históricos, diversos y de calidad conocida, y deben poder acceder a los datos en bruto, no solo a resúmenes de informes. Los requisitos de auditoría y rendición de cuentas exigen además que una organización pueda indicar de qué fuente, mediante qué transformación y en qué momento se obtuvo una cifra de un informe. Un data lake bien construido responde a ambas necesidades: acceso amplio para el análisis y el modelado, y un linaje claro para la confianza.
Un data lake moderno suele diseñarse en varias zonas sucesivas. La zona en bruto conserva los datos exactamente como llegaron de la fuente, ya sea por carga por lotes o mediante un flujo de eventos. La zona depurada reconstruye los datos con un esquema explícito, tipos estándar y claves de referencia como el identificador dorado de la parte. La zona curada construye modelos de datos temáticos, como cliente, transacción o parcela, para su consumo por la analítica, los cuadros de mando y los modelos. Junto a ellas, un catálogo de datos registra los conjuntos de datos, sus responsables, su calidad y su linaje, y una capa de acceso aplica los permisos por rol.
La primera consideración práctica es la titularidad y la calidad. Cada conjunto de datos del lago debe tener un responsable designado en el negocio que responda de su definición, su calidad y su ciclo de vida. Las reglas de calidad, como la completitud, la unicidad y los rangos permitidos, deben ejecutarse automáticamente en cada carga y su resultado debe publicarse en el catálogo. Por ejemplo, si la carga diaria de transacciones llega de repente con la mitad de su volumen habitual, el sistema debe generar una alerta antes de que se actualicen los cuadros de mando, en lugar de dejar que los directivos descubran una cifra errónea por la mañana.
La segunda consideración es el vínculo con el maestro de partes y con los eventos. Un lago que almacena los datos con los identificadores locales de cada sistema no ha hecho más que reunir la fragmentación en un solo lugar. El valor real aparece cuando, en la zona depurada, cada registro se vincula al identificador compartido de la persona, el producto o la ubicación. Alimentar el lago mediante la plataforma de eventos, en lugar de extraer directamente de las bases de datos operativas, reduce además la carga sobre esos sistemas y lleva la actualidad de los datos de un ciclo nocturno a casi tiempo real, lo que cambia los usos posibles del lago.
La tercera consideración es el consumo. Un data lake que solo utiliza el equipo de datos ha fracasado. La capa de servicio debe ofrecer cuadros de mando e informes a los directivos, consultas interactivas a los analistas y acceso programático a los científicos de datos y a los modelos, todo ello sobre una definición compartida de las métricas. Una capa semántica que conserve la definición oficial de cada métrica evita que un mismo concepto se calcule de forma distinta en distintos lugares y elimina de raíz la discusión sobre qué informe tiene la cifra correcta.
Los errores habituales son conocidos. Primero, el pantano de datos: volcarlo todo sin catálogo, responsables ni reglas de calidad hasta que nadie sabe qué hay en cada sitio ni en qué se puede confiar. Segundo, construir el lago como un proyecto de TI sin un caso de uso de negocio concreto, que acaba al cabo de un año con una masa de datos y ningún consumidor. Tercero, descuidar el control de acceso a nivel de columna y fila, lo que convierte el lago en el mayor punto de fuga de datos sensibles de la organización. Cuarto, ignorar el coste de almacenamiento y procesamiento, que sin una política de retención crece sin límite.
En Niadad, la plataforma Darya es el data lake empresarial: zonas en bruto, depurada y curada, un catálogo de datos con responsables y linaje, reglas de calidad automatizadas y una conexión con la plataforma de eventos para una alimentación casi en tiempo real. Binesh es la capa de inteligencia de negocio que ofrece cuadros de mando, informes y análisis interactivos sobre Darya con definiciones de métricas compartidas. Ambas se utilizan en el proyecto de agricultura inteligente de Niadad para combinar lecturas de sensores, datos meteorológicos y registros agronómicos, y la misma arquitectura se repite en los proyectos bancarios y urbanos de Niadad.
Un data lake se convierte en un activo cuando reúne tres cosas a la vez: gobierno, vínculo con una identidad compartida y consumidores reales. Sin gobierno es un pantano; sin identidad compartida es un almacén de fragmentación; sin consumidores es un coste. Con las tres, es la base sobre la que se construyen la analítica, la IA y la rendición de cuentas de la organización.