Cómo construir un Data Lake

En este artículo te vamos a mostrar cómo crear un Data Lake, cuáles son sus principales componentes, aplicaciones y procesos a desarrollar, así como las buenas prácticas que hay que seguir para su implementación.

Este artículo forma parte de nuestra serie donde te contamos todo lo que necesitas saber para diseñar e implementar Arquitecturas Big Data.

En la introducción a las arquitecturas de Big Data vimos el por qué de estas tecnologías, cuáles eran sus características principales, topologías de Data Lakes, así como los principales profesionales encargados del despliegue, mantenimiento y explotación.

Por sencillez en las explicaciones, para este artículo se va a presuponer que la arquitectura completa es un Data Lake, sin piezas más complejas como Data Mesh o Data Lakehouse, y que el despliegue de recursos se lleva a cabo en cloud.

Los Datos de un Data Lake

Comencemos con los verdaderos protagonistas. Los datos. ¿Cómo son los datos? ¿Cómo son sus fuentes? ¿Por qué procesos/capas pasan los datos dentro de un Data Lake? Son los cimientos para construir un Data Lake

Tipos y formatos de los datos

Esto es lo primero que debes conocer antes de elegir cualquier herramienta de procesado, análisis o almacenaje de datos. Tendrás varias fuentes de datos, y cada una de ellas con su propio formato, protocolo de comunicación y herramienta de explotación. Recuerda que volumen, velocidad y variedad son los tres pilares principales que definen al Big Data.

1. Estructuradas. Son datos organizados en un formato y estructura predefinida, como tablas en bases de datos relacionales o hojas de cálculo. Estos datos se pueden almacenar en sistemas de gestión de bases de datos tradicionales y se pueden consultar utilizando consultas SQL.
2. Semiestructuradas. Son datos que no siguen una estructura rígida, pero tienen una organización o etiquetado, lo que permite una cierta comprensión. Ejemplos de datos semiestructurados son documentos HTML, documentos XML, archivos de registro o archivos JSON. Estos datos se pueden almacenar en bases de datos NoSQL o sistemas de almacenamiento de documentos.
3. Desestructuradas. Son datos que no tienen una estructura definida, y no se pueden organizar fácilmente en tablas o formatos predefinidos. Ejemplos de datos no estructurados son archivos de texto sin formato, archivos de audio, imágenes, videos, correos electrónicos, redes sociales, documentos PDF, etc. Estos datos suelen requerir técnicas especiales de procesamiento y almacenamiento, como almacenamiento de objetos, sistemas de archivos distribuidos o sistemas de indexación y búsqueda de texto completo.

Un aspecto clave que define una arquitectura de Big Data frente a las tradicionales, es que se va a almacenar toda la traza del dato en crudo. Luego tendrá sus procesados, limpieza y volcado en herramientas de BI, pero se conserva el estado original original para poder realizar analíticas históricas, reprocesados o corrección de bugs desde el origen.

La mayor parte de los datos en crudo se van a almacenar en un Storage en Cloud, mediante el cual podremos configurar si los datos los queremos almacenar en frio o caliente, es decir, si queremos datos de baja frecuencia de acceso, pero con un coste reducido vs datos con alta frecuencia, bajas latencias y su coste normal en el storage.

Capas de una Arquitectura Big Data

Cuando se produce una venta desde una página web, se está creando un nuevo dato de ventas, una nueva transacción que se almacenará en la base de datos de la página web. Este dato transaccional se volcará posteriormente en el Data Lake, se procesará para dejarlo listo en un formato de analítica, y lo más probable es que acabe en un dashboard de forma agregada junto con otras transacciones. Este dato será parte de una decisión que provocará más o menos ventas, que serán nuevas transacciones para el Data Lake. Este sería de forma simplificada el ciclo de vida de un dato. Veamos cómo son esos estados/capas por los que pasa.

1. Ingesta. Partimos de la fuente de datos que los genera y se vuelcan directamente en el Data Lake en crudo, sin procesar.
2. Procesado. Se puede repetir varias veces dentro de la arquitectura. Suele haber mínimo dos procesados que implican limpieza, transformación y agregación de datos para facilitar la explotación. Existe una limpieza de los datos en crudo para transformarlos en datos explotables para los analistas, y después al menos otro procesado para que los datos acaben en una aplicación de datos, ya sea un dashboard, un informe, un modelo de machine learning o una API que sirva los datos a terceros.
3. Almacenamiento. Siempre que haya un procesado de datos, antes y después tendremos un almacenamiento. Quizá interese guardar los datos de forma estructurada en tablas, no estructurada en objetos, en archivos parquet para optimizar el espacio de almacenaje, o incluso almacenamiento de los datos en frío porque en principio ya no se van a usar.
4. Presentación/Consumo. Después de pasar por una serie de etapas de limpieza y procesado, los datos se utilizan para tomar decisiones, a través de un informe, unos estadísticos, un dashboard interactivo o el output de un modelo de Machine Learning.

Ten en cuenta que no siempre va a pasar por todos estos estados, sino que va a depender del diseño de la arquitectura del Data Lake, complejidad de los procesos, de la cultura del dato y políticas de Data Governance de la empresa.

Procesos y componentes del Data Lake

Una vez vistas las especificaciones de un Data Lake, así como las etapas por donde van a pasar nuestros datos, necesitamos saber qué componentes habrá que desarrollar para poder construir nuestro Data Lake.

Procesos con los datos

En estos procesos habrá que desarrollar aplicaciones/scripts/plantillas de recursos cloud, con los que realizamos de un modo u otro un tratamiento de datos. Ya sea para copiarlos, eliminarlos, limpiarlos, almacenarlos, analizarlos o monitorizarlos.

1. Ingesta/Copia. ¿Qué formas tenemos de realizar los volcados? Lo más sencillo es que tengamos en el Data Lake un conector ya desarrollado, y simplemente tengamos que activarlo. Otras opciones serían consultas programadas a bases de datos, copy paste programado de archivos, triggers o eventos, consultas SQL, etc.
2. Batch. Se trata de todos los procesados de datos programados y automatizados que se encargan de realizar una ETL sobre un conjunto grande de datos. Pueden ser horarios, diarios, semanales, mensuales o anuales. Estos procesados los podemos encontrar en varios puntos de la arquitectura.
3. Real-time. Se trata de un sistema de captación de mensajes o eventos, dentro de una ventana temporal, que puede ser de segundos o minutos. Estos mensajes se almacenan en una cola para ser posteriormente procesados y almacenados. Si necesitamos sistemas real-time va a cambiar mucho la arquitectura, pues los procesados tendrán que ser mucho más rápidos y actualizar el pipeline de datos con una mayor frecuencia.
4. Interactivo. Se trata de la analítica del día a día. Consultas a bases de datos, pequeños informes improvisados, preguntas de negocio que tenemos que responder, analíticas previas a modelos o preparación de datos para un nuevo proceso batch.
5. Reporting y BI. Una vez ya están todos los datos limpios y con un formato mucho más amigable que el presente en el volcado, se transformarán y agregarán los datos para obtener información y conocimiento a través de los datos. Ya no manejaremos grandes volúmenes, sino que la idea es presentar KPIs de negocio y gráficas lo más clarificadoras posibles. No solo implica el desarrollo de reportes y dashboards, sino de sistemas de alertas con las que no es necesario realizar un seguimiento de métricas, salvo que nos lo indiquen las alertas, ahorrando tiempo al analista.
6. Ciclo de vida del dato. Existen una serie de procesos a desarrollar que no son tanto destinados a la analítica del propio dato, sino al control y mantenimiento tanto del propio dato como de los recursos que lo explotan y almacenan. Procesos automáticos de comprobación de formatos, de detección de errores o de almacenamiento en frío de datos antiguos.

Procesos que no implican movimiento de datos

En un Data Lake no todo es trabajar con el dato, sino que hay una serie de tareas y metodologías de trabajo que son clave para su correcto funcionamiento y mantenimiento.

1. Data Governance. Se trata de un conjunto de políticas, procesos y controles establecidos para garantizar la calidad, integridad, seguridad y cumplimiento normativo de los datos almacenados en el Data Lake. El objetivo principal del Data Governance en un Data Lake es asegurar que los datos sean confiables, precisos y estén disponibles para su uso de manera apropiada por parte de los diferentes usuarios y aplicaciones. Esto implica establecer reglas claras sobre la captura, almacenamiento, acceso, procesamiento y eliminación de datos, así como definir roles y responsabilidades para su gestión
2. Despliegue de recursos: se establecen políticas de puestas en producción y despliegues de recursos para facilitar la actualización e integración de los nuevos componentes de la arquitectura. Para ello existen plantillas de despliegue de recursos, que permiten replicar mediante código los recursos desplegados, garantizando la consistencia y reproductivilidad. Es lo que se conoce como IaaC, Infrastructure as Code.
3. Documentación y formación. No se trata de un punto a incluir únicamente en una arquitectura Big Data, sino de unas buenas prácticas que hay que seguir en todo proyecto profesional. Se realizan muchos desarrollos, y los empleados van y vienen, por lo que es importante que su conocimiento se quede en la empresa. Otro punto importante es la formación de los equipos. Se tata de tecnologías nuevas, y los empleados tienen que conocer su potencial y aprender a usar las herramientas. Son servidores compartidos por lo que es importante saber usarlos para no acaparar todo el cómputo o para que no lleguen facturas millonarias.
4. Metodología de trabajo. Es muy recomendable llevar un estándar de buenas prácticas, de código, herramientas de desarrollo y metodología de trabajo en todos los equipos. Va a facilitar mucho el flujo de información, el despliegue de recursos, revisiones de código y adaptabilidad de los empleados.
5. Scrum. Se trata de un marco de trabajo ágil utilizado en la gestión de proyectos, especialmente en el desarrollo de software. Se basa en la colaboración, la flexibilidad y la entrega iterativa de productos o servicios.
6. Alertas y monitoring. Sistema de procesos, alertas, dashboards o lanzamiento de mails automáticos que permiten llevar a cabo un seguimiento del flujo de datos del Data Lake. Esto permite una detección temprana de los fallos y corrección con el mínimo de impacto.

Todas estas serían las áreas de acción que tendremos que ir evolucionando poco a poco para crear un Data Lake productivo. Comenzando en la ingesta y acabando con documentación y procesos de limpieza y mantenimiento automatizados del Data Lake.

Aplicaciones con los datos

No perdamos el foco de para qué queremos todo esto. ¿En qué vamos a emplear todos estos datos y procesos? Veamos algunos ejemplos de aplicaciones de datos que se vayan a beneficiar del Data Lake.

1. Modelos Machine Learning. Modelos predictivos entrenados con un histórico de datos. Sirve por ejemplo para realizar proyecciones de ventas, de stock de tiendas, anticipación de impago en bancos o detección temprana de fallos en maquinaria.
2. Dashboards de BI. Es lo más habitual. Tener un Dashboard montado que vaya enganchado a una base de datos, y que con cada actualización de la base de datos, se actualicen todas las cifras del dashboard. Esto ya existía antes, pero con las nuevas herramientas de Big Data podemos tener más volumen y contar con el dato desagregado al máximo (transacción) en el propio dashboard.
3. ETLs de preparación a BD. Transporte y procesado de datos que va de una BD a otra BD. Normalmente en estos procesos se persigue simplificar el dataset y facilitar el posterior análisis.
4. ETLs de presentación de datos. Transporte y procesado de datos de una BD a una herramienta de BI. Estas ETLs suelen programarse en el propio lenguaje de la herramienta de BI.
5. Aplicaciones de búsqueda de datos. A medida que el Data Lake va escalando y aumentando en volumen de datos, resulta cada vez más complicado buscar datos concretos, por lo que el taggeado de datos y las aplicaciones que funcionan a modo de buscador, facilitan mucho ese trabajo y evita que los empleados tengan duplicidades de procesos para crear datasets, que en realidad ya existían.
6. Auditorias. Si trabajamos para una telco o un banco, que son empresas con un regulador por detrás, es muy habitual que haya auditorías con las que se justifique la actividad de la empresa. Un Data Lake facilita mucho las cosas al tener toda la trazabilidad y replicabilidad del dato.
7. API REST de datos. Es posible que hayamos desarrollado un código de limpieza de datos, o un modelo de machine learning que queramos que utilicen otros servicios de la arquitectura IT de la empresa, como por ejemplo su página web o su app. Para ello habrá que diseñar una API REST para comunicar dicho servicio con el resto de componentes.
8. Automatización de procesos. Seguro que había una gran cantidad de informes y procesado de datos que se hacían manualmente antes de la llegada del Data Lake. Es muy común migrar este tipo de procesos a otros más automatizados.

Bloques de herramientas

Ya sabemos qué es un Data Lake, qué especificaciones necesitamos para montarlo y cuáles son los procesos y tratamientos de los datos. Para llevar a cabo todo esto, necesitaremos una serie de recursos de IT:

1. Cloud. Todos los recursos que despleguemos, ya sea bases de datos, SaaS para reporting, herramientas de procesado de datos… lo más habitual es que lo despleguemos en uno o varios proveedores cloud, para asegurar la disponibilidad, seguridad, escalado y accesibilidad de los datos. Por tanto, todos los recursos que se listan a continuación, deberían caer dentro del paraguas del cloud, a no ser que por seguridad y cultura de la empresa, se opte por una solución híbrida u on premise.
2. Storage. Son necesarios sistemas de almacenamiento. Vamos a almacenar datos en crudo, logs, tablas, objetos, archivos, audios, fotos o vídeos, y por tanto tendremos diferentes almacenamientos en función del tipo de datos, disponibilidad, consistencia y volumen.
3. Lenguaje de programación para procesos batch. Es necesario uno o varios lenguajes que tengan una muy buena integración en las plataformas cloud, que sean open-source, cuenten con una gran comunidad, librerías estándares de data science y de propósito general, es decir, que los podamos usar para procesamiento masivo, para montar una API, un modelo de Machine Learning, etc… que sea multipropósito. Un lenguaje que se encaja muy bien es Python.
4. Lenguaje de programación para análisis interactivo. Lenguajes de programación como Python son muy fáciles de aprender, pero programar requiere dedicarle un tiempo. Hay tareas de consulta a BBDD que resultan mucho más sencillas de implementar en SQL. No obstante, para análisis de datos o desarrollo de modelos de ML con previsión de poner en producción, resulta interesante realizar el desarrollo en aquel lenguaje que se vaya a usar después en la máquina productiva.
5. Herramientas de reporting. Son herramientas de analítica y de diseño de dashboards interactivos y reportes en Excel o pdf. Algunas como Power BI, Tableau, Qlik Sense o incluso librerías de Python que desarrollan informes en cuestión de segundos. Tampoco podemos olvidarnos de la IA, puesto que cada vez está más integrada en este tipo de herramientas para mejorar la experiencia de usuario y realizar consultas a los datos en lenguaje natural.
6. Gestor de pipelines, jobs y procesos batch. Se trata de todas las herramientas destinadas a la automatización y puesta en producción de pipelines de datos. Desde orquestadores como Airflow, a gestores de jobs de Spark como Dataproc o herramienta SaaS para el desarrollo de pipelines de datos como Azure Data Factory.
7. Automatización y despliegues. Se trata de herramientas orientadas a la puesta en producción de software. Pipelines de despliegue, testing automatizados o planes de contingencia, facilitan mucho las subidas de software a producción.
8. Notebooks de analítica. Son programas interactivos desarrollados para Python que permiten ejecutar pequeñas porciones de código, sin necesidad de correr ni compilar todo un script, y con la ventaja de que exista un contexto donde se almacenan todas las variables que se vayan ejecutando en el notebook.
9. Gestión y metodología de trabajo. Lo habitual es trabajar con metodologías ágiles en proyectos de IT, y el desarrollo de una arquitectura Big Data no va a ser menos. Se establecen roles, sprints, dailys… y para ello nos apoyamos en herramientas para montar tableros canvas de scrum, backlog de tareas, seguimiento de tareas, sistemas centralizados de documentación e integración con herramientas de control de versiones.
10. Control de versiones. No se entiende el desarrollo de software sin un sistema de control de versiones. Dado que el Data Lake pertenece más a sistemas, que desarrollo de software, resulta interesante desplegar los recursos mediante plantillas IaaC, en vez de mediante la interfaz gráfica del proveedor cloud. De esta forma llevamos un mayor control de las versiones de las puestas en pro de software y podemos reproducir los despliegues de recursos desplegados meses atrás.

Buenas prácticas para la construcción de un Data Lake

Hasta ahora te hemos presentado cómo sería un Data Lake genérico, y los componentes que tendría. No obstante, cada Data Lake es un mundo, por lo que tendrás que desarrollar una arquitectura completamente diferente para cada cliente. Veamos algunas recomendaciones y buenas prácticas para ayudarte en el despliegue de la solución.

1. Evitar silos. Cuando el trabajo del Data Lake está muy centralizado, no surge este problema, pero con el aumento de la plantilla y de departamentos que usan los datos, se tiende a formar silos de información provocando inconsistencia en las principales métricas de negocio. Una forma de solucionar esto sería aplicar arquitecturas distintas a las tradicionales, como la de Data Mesh, o Data Lakehouse, siempre acompañadas de políticas de Data Governance.
2. Data Governance. Nos solemos centrar mucho en el desarrollo de aplicaciones y dejamos de lado la documentación, el metadatado, tageado, control y seguridad de los datos. En muchos departamentos de datos hay una o varias personas dedicadas exclusivamente a esta tarea.
3. Uso de herramientas de gestión y metodología de trabajo. Son muy importantes para poder llevar una trazabilidad del trabajo, organizar proyectos de IT entre varios participantes/departamentos y mejorar el rendimiento de los equipos. Herramientas como la suite de Atlassian donde tienes Confluence para la documentación, Bitbucket para el control de versiones, Jira para llevar un seguimiento de los Issues y Trello para el desarrollo de tableros canvas.
4. Innova cuando haya que hacerlo. Ajústate a las necesidades, especificaciones y presupuesto para diseñar la arquitectura. Implementa las innovaciones y tecnologías que de verdad vayan a aportar valor. No por usar Machine Learning, DevOps o Blockchain vamos a tener un mejor Data Lake. Muchas veces nos dejamos llevar por el marketing, las modas o por nuestro conocimiento personal en el trabajo. Piensa objetivamente en lo que hay que montar, en las necesidades de los departamentos, en la empresa… y cíñete a ello.
5. Librerías y herramientas de equipo. Si cada desarrollador tiene un trabajo muy autónomo, es probable que pierdan el tiempo desarrollando algunas piezas de software comunes. Esto provocará tiempos de desarrollo más largos, que las revisiones de las pull-requests sean más lentas y la adaptabilidad de los nuevos empleados también se demore. El desarrollo de una metodología de trabajo, de buenas prácticas de equipo, de compartir conocimiento, de desarrollar herramientas para el equipo u otros departamentos es una inversión de tiempo que compensa en el medio y largo plazo.
6. Seguridad y permisos. Cada usuario tiene un rol y una responsabilidad en la empresa, y no va a ser menos en el tratamiento de los datos. No es lo mismo los permisos que necesita un Data Analyst, que un Machine Learning Engineer contratado como personal externo. Desarrolla políticas de privacidad en la nube, crea grupos de usuarios y concede los permisos y visibilidad estrictamente necesarias para evitar desastres, o fugas de información.
7. Usar almacenamientos fríos. Los datos tienen una caducidad, o al menos en el análisis cortoplacista. Existen diferentes formas de almacenamiento en la nube que determinan la facilidad en el acceso del dato. Estos formatos de almacenamiento tienen costes diferentes, por lo que los datos antiguos que no se van a usar en el seguimiento diario del negocio se pueden guardar en almacenamientos más baratos.
8. Automatización. No todos los procesos que vayas a desarrollar se van a automatizar. Automatizar un proceso requiere dedicarle un tiempo extra, por lo que piensa bien si cada vez que tengas una petición de datos, tendrás luego que automatizar un proceso batch, montar un modelo de Machine Learning, o simplemente responder a una pregunta de negocio, que lo puedes hacer con una simple consulta SQL.
9. Filtra las fuentes de datos. La filosofía de un Data Lake es de ingestar todo lo que se pueda, y luego ya veremos… Si ya sabes que hay fuentes que seguro que no se van a utilizar, no las ingestes y ahorra ese coste de storage y de desarrollo.

Piensa cuidadosamente cada decisión y cada componente a desarrollar, porque como ves no son pocos, y sin unas buenas prácticas, en un futuro puede que la solución implementada no sea la ideal y por tanto haya que recomponer la arquitectura, con los costes que implica un cambio de esa magnitud.

¡Ya tendrías una base lo suficientemente sólida como para diseñar un Data Lake! En los siguientes artículos te contaremos qué es lo que tienes que hacer en cada capa del Data Lake: la ingesta, el procesado, el almacenamiento y el consumo.

SIGUIENTE EPISODIO – Te recomendamos que continúes tu travesía por las Arquitecturas de Big Data con nuestro artículo donde comparamos un Data Warehouse vs Data Lake vs Data Mesh vs Data Lakehourse.