Arquitectura BI: Introducción al Data Lake

Toda gran organización es consciente de la importancia de disponer de un adecuado almacenamiento de los datos generados, guardándolos y estructurándolos con determinadas lógicas y normas para tenerlos correctamente ordenados y disponibles.

En entradas anteriores, hemos expuesto estas necesidades y las distintas fórmulas o soluciones para llevarlo a cabo en función de los objetivos que se busquen. Hoy en día, las nuevas tecnologías de captura y procesamiento de datos, acompañadas de las nuevas fuentes de información, tales como el «Social Data» o el «Internet of Things«, están generando unos volúmenes de datos que, en muchos casos, hacen inviables las soluciones tradicionales de almacenamiento. Es aquí donde términos como Data Lake empiezan a quitarle protagonismo a los Data Warehouses basados en modelos relacionales.

Después de esta breve introducción seguramente nos vendrán varias preguntas a la cabeza, pero vayamos por partes y centrémonos en la primera:

¿Qué es un Data Lake?

En pocas palabras y dejando los aspectos técnicos de lado, un data lake no es otra cosa que un repositorio central en el que se almacena toda la información de la organización sin importar su formato u origen.
Visto así, para quienes estén acostumbrados a desarrollar data warehouse tradicionales, los cambios de enfoque son evidentes. En un data lake simple no es necesario limpiar, validar y preparar los datos de manera previa a su carga. No es necesario adaptarlos a un esquema determinado ni aplicar criterios de integración corporativos para cargarlos en un data warehouse.

Parece claro que esto también implica otro escenario en cuanto a análisis previo, tiempos de desarrollo y costes, mucho más reducidos que en arquitecturas tradicionales. Y es que cuando se construye un data lake la principal finalidad es almacenar todos los datos
generados en la organización, sin importar el uso que se les vaya a dar a estos o tan siquiera si lo tienen actualmente.

Aquí radica la gran diferencia entre ambos enfoques: mientras que en un data warehouse tradicional los datos son depurados, validados y adaptados conforme al esquema predefinido del modelo de datos al que han de cargarse; en un data lake, en primera instancia, los datos son almacenados sin importar su esquema y características, éstos no serán adaptados y tratados hasta haberse identificado una necesidad real de negocio.

Por otro lado, si echamos un breve vistazo al componente tecnológico que rodea a los data lakes, nos encontramos con las ventajas de las nuevas tecnologías Big Data: entornos distribuidos, escalabilidad horizontal, flexibilidad, procesamiento en tiempo real, etc. Puntos que, entre otros aspectos, implican una reducción de costes frente a sistemas tradicionales.

Bien, hasta aquí nos podemos haber hecho una idea sobre qué es un data lake pero…

¿Cuáles son los siguientes pasos? ¿Cómo es analizada la información?

En un data lake no todo es blanco o negro, está claro que habrá un capa de raw data pero también puede haber otras capas donde los datos comiencen a ser depurados y preparados para su explotación.
En este sentido, la tecnología normalmente usada para construir este tipo de repositorios es HDFS (Hadoop Distributed File System), un sistema de ficheros distribuido en el que podemos crear diferentes capas a través de las cuales los datos vayan pasando determinados controles de calidad y adaptación a las distintas necesidades de negocio. Sin embargo, se pueden emplear otras tecnologías o una combinación de ellas en función de las distintas capas que se quieran desarrollar.

Las capas más comunes que se pueden encontrar en un data lake son las siguientes:

Data Ingestion

Capa temporal de carga en la que los datos pasan checks básicos antes de ser almacenados en la capa de raw data. Si bien no es necesaria, se puede implementar para llevar a cabo:

• controles básicos de calidad, como posibles filtros según el origen de los datos, descartando fuentes desconocidas
• procesos de encriptación de los datos en caso de requerirse por motivos de seguridad
• registros sencillos de metadata y trazabilidad mediante tags, almacenando el origen de los datos, fecha y hora de carga, el formato y otras características técnicas, su privacidad y nivel de seguridad, algoritmo de encriptación, etc.

Data Storage (Raw Data)

Capa sin esquema establecido donde todos los datos, estructurados o no estructurados, son almacenados sin sufrir adaptaciones. Es una capa en la que se precisa de analistas expertos en data discovery mediante herramientas big data (Hive, Spark, Map Reduce…).

Data Processing (Zona de Confianza)

Una vez que los analistas de datos han realizado data discovery en el raw data, se puede ver la necesidad de procesar y adaptar determinados sets de datos para alojarlos en una capa de uso recurrente. En esta capa pueden tener lugar procesos avanzados de data quality, integridad y otras adaptaciones para disponer de una capa de confianza de exploración de datos a la que tengan acceso otros usuarios.

Data Access (Zona de Consumo)

Esta es una capa más avanzada donde, finalmente, los datos se ponen a disposición de analistas de negocio. Estos analistas podrá generar informes y análisis para responder a preguntas de negocio y afianzar la toma de decisiones.

Siendo estas capas opcionales, cada organización puede definir su propia estrategia a la hora de implantar un data lake. Sin embargo, al margen del número de capas que se opte por implantar, siempre existe una estrategia común básica: almacenar todos los datos de la organización con independencia de que tengan uso en la actualidad o no, dejándolos disponibles para posibles futuras necesidades no detectadas en el momento de desarrollar el data lake.
De esta manera, a medida que surjan nuevas necesidades de negocio los datos irán pasando de la capa raw data a capas más avanzadas, dejando nuevos sets de datos a disposición de los usuarios de negocio.
Es por ello, que un data lake es un repositorio de datos vivo y en constante evolución, adaptado para escalar de forma flexible en función del negocio y su propia evolución.

¿Esta estrategia de gestión de datos tendrá éxito? La pregunta del millón, pues hasta la fecha son muchas las iniciativas basadas en este tipo de arquitecturas que han fracasado.

La respuesta fácil es que su éxito vendrá determinado en gran medida por aplicar una correcta gestión y gobernanza del sistema basada en el empleo de los metadatos, definiendo políticas, procedimientos y roles que marquen qué personas o departamentos de la compañía son responsables de mantener la calidad de los datos, su seguridad, su acceso, de gestionar los permisos al sistema, etc. Aquí nos adentramos en el mundo del Gobierno del Dato que, por evitar caer en el error de simplificarlo y no darle la importancia que tiene, merece un artículo independiente para poder abordarlo correctamente. Pero, sin lugar a dudas, de la correcta implantación del plan de gobierno dependerá el futuro éxito del Data Lake.

En próximas entradas profundizaremos en otros aspectos que rodean la elaboración de un data lake, así como en el componente técnico, en las políticas de gobierno del dato, la trazabilidad y la metadata, el ciclo de vida del dato, seguridad y privacidad, etc.

…by Víctor Dertiano

En BI Geek, empresa tecnológica centrada en Business Intelligence, Big Data & IA, apostamos por un nuevo modelo de consultoría orientado a hacer accesibles las soluciones informacionales y de tratamiento de datos para cualquier tipo de empresa.