- Tiempo de lectura: 9 minutos
- Problema: los entornos industriales generan datos de morfología variable, dificultando su gestión y tratamiento
- Observación: existen tecnologías y diseños orientados a optimizar el tratamiendo de este tipo de datos
- Propuesta: estudiar una posible integración de los conceptos sobre Data Lakes en los entornos de Big Data industrial
En este artículo quiero revisar un concepto que está ganando fuerza, y que está siendo también fuente de una interesante controversia; los sistemas de gestión de datos denominados Data Lakes.
Definición
Lo primero es identificar con exactitud a qué nos estamos refiriendo. La primera alusión al término se le atribuye a James Dixon, quien lo describió con la siguiente analogía en su blog: «If you think of a datamart as a store of bottled water – cleansed and packaged and structured for easy consumption – the data lake is a large body of water in a more natural state. The contents of the data lake stream in from a source to fill the lake, and various users of the lake can come to examine, dive in, or take samples.»
Profundizando un poco más en su analogía, podemos deducir que un Data Lake es un gran volumen de datos, en el que los datos se almacenan con su formato original, sin modificar su estructura o contenido. No se realiza ningún tipo de normalización o procesamiento sobre la entrada de datos, por lo que éstos «reposan» cómodamente en el Data Lake sin haber sufrido ningúna alteración. Esto supone que los datos tienen que ser tratados cuando son demandados (habitualmente mediante técnicas de map & reduce), no cuando se incluyen al repositorio. El acceso a la información, y la comprensión de su morfología, se hace en base a un conjunto de metadatos asociados a la información almacenada.
Data Lake vs Data Warehouse
Prácticamente la mayoría de argumentos que esgrimen los expertos que abogan por la implantación de Data Lakes están orientados a demostrar sus bondades frente a sistemas más tradicionales de Data Warehouse, posiblemente como evolución lógica a partir de las herramientas de Business Intelligence que tanto han proliferado en la última década.
Tomando como referencia la definición anterior, las diferencias son bastante obvias, sobre todo en lo referente a la organización de la información en el repositorio. En un DW nos encontramos con una estructura bastante rígida, enfocada a cruzar datos, y en la que ya están determinados los atributos que se van a almacenar para cada dato. Por tanto, la capacidad de investigar los datos, y por tanto de poder deducir conclusiones a partir de los mismos, se encuentra ya limitada. Está de alguna forma predeterminada y condicionada por el diseño del repositorio. En un Data Lake los datos se almacenan en su estado natural, sin forzarlos a encajar en ninguna estructura predeterminada, con la intención de que la investigación y explotación posterior de dichos datos no se vea limitada por la estructura impuesta por el repositorio. Entre otras muchas, esta es posiblemente la principal diferencia entre ambos diseños.
El coste de infraestructura es también un factor a tener en cuenta. Las herramientas de gestión de backend que se utilizan para implantar Data Lakes están diseñadas para instalarse sobre «commodity hardware«. Según varios proveedores de herramientas basadas en Hadoop, el coste de infraestructura para el almacenamiento en un DW puede llegar a ser hasta 250 veces superior frente a un clúster basado en Hadoop.
Data Lake & Big Data
Existen muchas formas de implantar un entorno Big Data, al igual que existen muchas tecnologías de soporte para crear este tipo de backends. En realidad, decidir si un entorno Big Data se organiza a modo de Data Lake tiene más que ver con el modo en el que se va a almacenar la información, y los mecanismos por los cuales dicha información va a ser recuperada.
Una característica importante en la que podemos fijarnos para determinar si estamos ante un escenario Data Lake es, como ya he mencionado, el momento en el que se requiere la capacidad de cómputo para estructurar la información. Es la «batalla» entre los modelos schema-on-write y schema-on-read: en el primer caso, se requiere de capacidad de cómputo en el momento de la llegada del dato para integrar la estructura de los nuevos datos a la morfología del backend. La intención es poder recuperar los datos con un formato unificado que no requiera procesamiento para su transformación (aunque sí requerirá el procesamiento para resolver y servir la consulta). En el segundo caso, se respeta el estado original del dato, y la carga computacional para procesamiento se realiza en el momento en el que lo datos son requeridos. El procesamiento se aplica únicamente sobre los datos consultados, y la versión original permanece intacta en el Data Lake.
Uso de Data Lakes
Ahora que ya tenemos claras las principales bondades que pueden aportar los Data Lakes a nuestros sistemas, dediquemos un momento a reflexionar los escenarios en los que su implantación pueda ser beneficiosa, y en cuáles pueda resultar contraproducente.
Sabemos que los datos que tienen una misma estructura se pueden cruzar más fácil, incluso se pueden utilizar herramientas estandarizadas. De ahí la proliferación de los DW como soporte a las herramientas de BI, que están hoy en día incluso utilizando variantes de Big Data semiestructurado. Las herramientas de consulta estandarizadas pueden a su vez interactuar con sistemas de visualización también estandarizados, pudiendo crear paquetes y módulos implantables en herramientas de BI. Un Data Lake no aporta homogenización en la morfología de los datos almacenados, y por tanto no es la elección adecuada para aquellas herramientas que necesiten cruzar datos de forma intensiva, sobre todo si se hace frecuentemente sobre una parte importante de los mismos.
Otro caso habitual es el de sistemas en los que sabemos que el volumen completo de datos va a requerir un procesamiento concreto, y esto es más importante que mantener la esencia natural de los datos. Suelen ser sistemas en los que la recepción de datos es un flujo constante, y además tienen una fuerte variabilidad en la demanda de consumo de datos. En este escenario, puede que necesitemos sacrificar futura capacidad de análisis como contraprestación a poder distribuir la capacidad de cómputo de nuestro cloud de forma más uniforme en el tiempo. Esto permite minimizar los recursos necesarios, manteniéndolos a su vez en un nivel de uso alto, ya que el modelo schema-on-write para flujos de datos constantes permite reducir los picos de carga que provocaría la demanda si se hubiera optado por schema-on-read. Recordemos que los picos de carga son siempre complejos de gestionar, incluso en un entorno tan flexible como son las infraestructuras Cloud. Si se sobredimensionan los sistemas se está perdiendo dinero, y si se infradimensionan la experiencia de usuario se ve degradada por el aumento del tiempo de espera, u otro tipo de problemas.
Por lo que hemos visto hasta ahora, los Data Lakes no son una buena solución para todos aquellos entornos en los que exista un usuario final que carezca de conocimientos tecnológicos específicos, así como para aquellos en los que la estandarización de la información almacenada sea imprescindible. Pero existe un entorno ideal para trabajar con Data Lakes; imaginemos un escenario en el que recibimos grandes volúmenes de datos, con estructuras y morfologías diferentes. Imaginemos también que en este escenario el usuario final no es el protagonista, aquí la estrella es el Científico de Datos que va a bucear en el lago con la intención de deducir conocimiento útil. En este escenario interesa mantener los datos en su estado original, y adaptar los mecanismos de recuperación de datos para que realicen las tareas de transformación. Logramos una gran capacidad de recepción y almacenamiento de información, gracias a la no necesidad de pre-procesamiento de los datos. Además, sólo se procesarán aquellos datos que se hayan solicitado. Y mantenemos la capacidad de poder seguir investigando, tal vez en un futuro podamos obtener nuevas conclusiones sobre esos datos, y esto lo podremos hacer gracias a no haberlos condenado a una estructura rígida predefinida.
Entornos industriales
La implantación de Data Lakes en entornos industriales no atiende exactamente a las mismas intenciones que la implantación de Big Data. Recordemos que la visualización estandarizada de los datos y el cruce de grandes bloques de información no son puntos fuertes de los Data Lakes. Gran parte de las aplicaciones para industria están centradas en la generación de cuadros de control a diferentes niveles, bien sea en forma de SCADA en el propio shopfloor, o en forma de KPI integrado con el ERP en gerencia. Esto no quiere decir que la herramienta de BI de la planta no vaya a poder obtener datos desde el Data Lake, pero exclusivamente esa tarea no justifica la implantación de un Data Lake. Además, los datos de origen industrial suelen ser en su mayoría series temporales, provenientes de la sensorización de sucesos físicos a lo largo del tiempo. Es por eso que los historiadores han sido la elección preferida en lo que respecta al almacenamiento de datos industriales.
Pero entonces ¿en qué casos puede ser interesante su aplicación? Las necesidades que está destinado a cubrir un Data Lake en un entorno industrial son principalmente dos: por un lado ofrecer la capacidad de almacenar datos heterogéneos provenientes de grandes flujos de información, y hacerlo con un coste reducido. Y por otro lado ofrecer un repositorio de datos puros, que no han sido alterados para cumplir con ningún requisito estructural. Este repositorio ofrece, a su vez, un amplio abanico de posibilidades, entre las que destacan el posibilitar que profesionales especializados puedan investigar y aplicar algorítmica a los datos, con el objetivo de obtener nuevos conocimientos, así como la integración de otros sistemas que puedan nutrirse de la información aportada por el Data Lake, tales como sistemas ERP, MES, GMAO, etc. El objetivo no es sustituir los sistemas existentes, sino complementarlos.
Conclusión
Hasta hace poco, las herramientas de gestión de datos que se utilizaban en entornos industriales eran más que suficientes, ya que cubrían todas las necesidades que estaban identificadas, tales como generación de SCADAs, cuadros de control tipo KPI, intregación con ERPs, análisis de OEE, generación de informes, alarmas, etc. Hoy en día las herramientas que se implantan tienen que ofrecer soluciones no sólo para cubrir las necesidades actuales, sino también para cubrir las que puedan surgir en un futuro. No me refiero a la capacidad de escalar, es decir, no consiste en poder cubrir una demanda creciente, sino en cubrir diferentes necesidades que puedan surgir. La rigidez de las herramientas actuales es lógica ya que viene derivada de un diseño orientado a cubrir una necesidad específica, pero reduce mucho las posibilidades de investigación futuras. El uso de Data Lakes puede mejorar esta situación, como un complemento a las herramientas actuales.
Es cierto que existen ciertos peligros en el uso de este tipo de backend. Por un lado, existe el riesgo de caer en el «síndrome de Diógenes» reinante hoy en día en cuanto a almacenamiento de datos, que se ve alimentado por el aumento constante de la capacidad de transmisión de datos, y el abaratamiento del almacenamiento masivo de información. Es cierto que, si hablamos de registrar hoy para investigar mañana, ya estamos de alguna manera incitando al almacenamiento de todo lo que se nos pase por delante de las narices. No sea que, por no haberlo guardado, luego no podamos usarlo cuando lo necesitemos. Pero también es cierto que el aumento exponencial del volumen de datos almacenados también hace que aumente la complejidad de su tratamiento; datos que no recordamos qué son y que permanecen eternamente en nuestro Data Lake, la convivencia entre datos con diferentes calidades, datos que han quedado obsoletos y que siguen en nuestro sistema introduciendo ruido en nuestros modelos, etc.
Gartner avisaba hace tiempo de los problemas que podía suponer el uso de este tipo de tecnología, pero la realidad es que los grandes players del mercado la utilizan de forma intensiva, y además lo incluyen en su oferta de productos y servicios. Tal es el caso de Pivotal (EMC + VMWare + GE), o Microsoft Azure.
Se trata de un concepto que no es nuevo, pero cuya aplicación real sí es bastante innovadora. Pese a que Pivotal y Microsoft quieran convencernos de lo contrario, la implantación de este tipo de conceptos todavía dista mucho de ser una solución llave en mano, especialmente en la casuística de los entornos industriales. Como con tantos otros casos que hemos ido conociendo a lo largo de la historia, existirán «early adopters» que harán el esfuerzo de implantación antes que otros, con la intención de lograr o mantener una ventaja competitiva, y habrá otros que esperarán a que sea un producto más cerrado para poder utilizarlo sin riesgos. En cualquier caso, todavía vamos a tener que esperar para ver si realmente se consolida como la potente herramienta que promete ser, y será decisión de cada uno elegir un papel más activo o más pasivo en lo que se refiere a su implantación.