Definición y claves principales sobre el concepto de “Data Lake”

Uno de los términos que aparece frecuentemente asociado a la recopilación de grandes cantidades de datos de diferentes fuentes para su posterior procesamiento con tecnologías Big Data es el de los "lagos de datos" o "Data Lakes". Son muchas las referencias que hablan de dicho concepto pero los detalles sobre cómo interpretarlo varían de unas a otras, por lo que en esta entrada vamos a repasar el origen del concepto y las claves principales para interpretarlo correctamente.

La expresión "Data Lake" tiene su origen en una entrada de octubre de 2010 del blog de James Dixon, CTO de la empresa Pentaho, en la que reflexionaba sobre el trabajo realizado para lanzar su primera distribución de Hadoop y lo que había aprendido de la interacción durante ese período con diferentes empresas usuarias de Hadoop. Analizando los factores comunes que había visto en dichos casos, extrajo la conclusión de que la gran mayoría de dichas empresas manejaban datos estructurados o semi-estructurados provenientes típicamente de una única aplicación o sistema, en un volumen que hacía inviable técnica o económicamente el uso de un sistema de base de datos relacional para almacenarlos y que, aunque algunas de las preguntas que se querían hacer sobre los datos eran conocidas de antemano, muchas no lo eran e irían surgiendo en el futuro.

Partiendo de estas conclusiones, Dixon propuso una visión de cómo deberían almacenarse este tipo de datos, sin tener que pasar por un preprocesamiento que extrajera los atributos que en principio se pensase que iban a ser utilizados en las consultas y sin tener que agregarlos necesariamente, para así no perder capacidad de ser usados a posteriori según otras necesidades. De ahí surge la analogía del "lago de datos", donde los datos (el agua del lago, según la analogía) provienen de un origen y "llenan el lago" sin haber sido aún limpiados, procesados o empaquetados a priori. De esa manera los datos se almacenarán en crudo y en su totalidad, y serán las necesidades de los diferentes grupos de usuarios las que permitirán identificar las versiones filtradas o procesadas de dichos datos que harán falta para resolver dichas necesidades (bien sea en forma de consultas preprocesadas por ser las más frecuentes, o como entrada para un data warehouse con una estructura de datos determinada para agregarlo a otras fuentes). En este breve vídeo de 10 minutos Dixon explica esta idea apoyandose en varios gráficos explicativos.

La diversidad de usos e interpretaciones posteriores del concepto de Data Lake se han ido alejando, en muchos casos, de la idea inicial con la que Dixon proponía su uso. Tanto es así que posteriormente el propio Dixon, en una entrada en su blog en septiembre de 2014, entra al detalle de refutar varias de estas interpretaciones y vuelve a explicar los conceptos fundamentales que quería "encapsular" dentro de la idea de los Data Lakes.

Aunque en dicha entrada no establece una relación con la propuesta de la Arquitectura Lambda (aún consolidándonse por aquel entonces), en mi opinión el concepto de Data Lake tiene muchos puntos en común con la aproximación de "datos inmutables" que propone el paradigma de la Arquitectura Lambda, en la que se apuesta por almacenar todos los datos en crudo a medida que se generan, y que sean las diferentes capas de la arquitectura (implementadas usando las herramientas correspondientes) las que nos permitan ofrecer versiones procesadas de los datos en función de las necesidades de los usuarios y del sistema a desplegar. La diferencia princial entre ambas nociones estaría en que Dixon asocia la idea de Data Lake a una única fuente de datos "sin destilar", mientras que en la propuesta de la Arquitectura Lambda no se restringe explícitamente el número de fuentes de datos que alimentan el dataset maestro, por lo que podríamos estar aglutinando un conjunto de Data Lakes.