Ingesta de Datos en un Data Lake

En este artículo exploraremos las herramientas y mejores prácticas y para llevar a cabo una eficiente ingesta de datos en un Data Lake, permitiéndote almacenar y procesar grandes volúmenes de información de manera escalable y flexible.

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

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. Si tienes dudas sobre las distintas arquitecturas de un Data Lake, tenemos un artículo donde te lo explicamos.

¿Qué es la Ingesta de Datos en un Data Lake?

La primera etapa de toda arquitectura de datos es la conexión de nuestros sistemas (Data Lake) con todas las fuentes de datos disponibles. Un Data Lake se caracteriza por almacenar los datos ingestados provenientes de todas las fuentes de datos de la organización, en crudo, para posteriormente aplicar las operaciones necesarias, de cara a obtener insights de esos datos.

Si quieres saber más sobre cómo es un Data Lake, te dejamos nuestro artículo sobre principales componentes del Data Lake

La capa de ingesta se compondrá de todos aquellos procesos que aseguren el volcado de datos, así como su mantenimiento. Procesos como consultas SQL, llamadas a APIs, volcado de archivos via FTP a un Storage, así como la aplicación de políticas de seguridad, de Data Governance, procesos de autogestión y optimización de costes.

Hay que ingestar los datos correctamente, y acorde a las buenas prácticas. De lo contrario, el acceso futuro, y nuevas evoluciones pueden repercutir en serias dificultades en el escalado de la solución, pues la reorganización y reprogramación de los procesos es muy costoso.

Ingesta de datos desestructurados

La ingesta de datos desestructurados en un Data Lake implica la incorporación y almacenamiento de información que no sigue un esquema predefinido o estructurado, como documentos, archivos de texto, imágenes, audio, videos y otros tipos de datos no tabulares.

Lo normal sería almacenarlo en un Storage en cloud. Guardar cada archivo como un objeto, un blob, dentro de una jerarquía de directorios. Esto aplicaría particularmente si los datos son pesados y compactos, como video, audio, imágenes o archivos autocontenidos. En el caso de tener cierta relación en los datos, como por ejemplo un JSON, que no deja de ser un diccionario, puede resultar interesante ingestarlo directamente en una solución NoSQL como MongoDB.

En este artículo tienes más en detalle el formato de datos a almacenar en función de tus datos

Tipos de fuentes de datos a ingestar

Lo primero será identificar cuáles son nuestras fuentes de datos, qué posibilidades tenemos de ingesta, y en qué formatos vamos a guardar la información.

1. Aplicaciones. Aquí comienza el ciclo de vida del dato, pues la mayoría de los datos se generan aquí, que es donde se producen las interacciones con los clientes. Cuando hablamos de aplicaciones, nos referimos tanto a web, como móvil, como otro tipo de software empresarial que recoja información sobre los puntos de venta.
   • Bases de datos. Las aplicaciones vuelcan su información en una base de datos, ya sea SQL, NoSQL, en la nube u on premise. Después necesitaremos procesos automáticos de ingesta o consultas desde el propio Data Lake.
   • Logs. Útil tanto para análisis y detección de bugs, como para monitoreo y alertas. Normalmente se usa para alertar en caso de error en la aplicación.
   • Huella digital. Se podría incluir en el apartado de logs, aunque hay aplicaciones específicas como Google Analytics que permiten recoger la traza digital de los clientes (y potenciales), por donde navega, cuánto tiempo, navegador que emplea, origen de la conexión, etc.
2. Bases de datos. Cualquier base de datos interna de la empresa donde haya datos transaccionales o se use para consultas y desarrollo de analítica, probablemente sea susceptible de ingestarse en el Data Lake. Si se trata de datos ya trabajados, hay que ser precavido ya que no estaríamos ingestando el dato como tal en crudo.
3. Devices. Todo lo que tenga que ver con IoT, sensores y dispositivos que generen datos en real time, o que tengan una base de datos mediante la que podremos ingestar la información en batches. Si hablamos de información en tiempo real, lo ideal es que, o bien el dispositivo esté conectado a algún servicio en la nube (si tiene red), o lo haga a través de un gateway que sí tenga esa conexión.
4. Redes Sociales. Todas las redes sociales tienen una API para poder acceder a esos datos. Estas APIs funcionan también en real time, por lo que podremos tener analíticas y sistemas de monitorización con pocos minutos de decalaje.
5. Archivos en un servidor. Suele ser muy habitual cuando se comparte información entre departamentos o entre empresas, que se use un Storage o un servidor corporativo para transferir archivos de datos. Si las ingestas son periódicas, merecerá la pena tener un proceso automatizado para ingestar esos datos en el lago.
6. Fuentes externas. Desde APIs de terceros como Google Maps, a servicios de limpieza de datos, machine learning o bases de datos en crudo.
7. Clouds. Los recursos de la empresa estarán o bien on premise o bien en una nube concreta. Particularmente si la empresa es de gran tamaño, es probable que haya sedes o departamentos que trabajen con varios proveedores cloud, y por tanto, haya que interconectarlos, o migrar procesos.
8. On premise. Toda fuente de datos local que no se vaya a subir a la nube, ya sea un Data Lake, DWH, discos y servidores locales.

Es fundamental realizar un estudio preliminar de las fuentes de datos de la organización, y tener claro un orden prioritario de ingesta, pues la cantidad de fuentes puede ser muy grande y seguro que no todas son críticas.

Si quieres saber más sobre los tipos de bases de datos que hay en el mercado, aquí tienes nuestro artículo donde te describimos todos las las opciones que tienes para almacenar tus datos

Formato de datos en destino

Se trata de un punto crítico en la ingesta, pues un formato de datos que no se adapte bien a la arquitectura, tendrá que ser modificado o parcheado en un futuro. Podríamos tener problemas de sobrecostes, incluso de incompatibilidad con las herramientas de explotación, pues éstas no trabajan con todos los formatos.

1. Storage. Se trata del almacenamiento más común. Un Storage en cloud donde ingestaremos todos los datos en crudo. En este punto es fundamental el formato de ingesta y la jerarquía del Storage. El formato va a determinar los tiempos de latencia, explotación y costes, mientras que escoger una buena jerarquía va a ayudar mucho en la asignación de permisos y Data Governance.
2. Distribuido. ¿Almacenaremos los datos en un único archivo, o distribuiremos ese archivo en un Storage distribuido como nos permite el HDFS de Hadoop? Existen otras alternativas al HDFS, SaaS, como Big Query, que nos permiten ingestar datos tabulares en tablas de Big Query de forma distribuida. Supone un ahorro de tiempo, al no tener que preocuparnos de la distribución del archivo ni de la herramienta de explotación, pues está todo integrado.
3. Hot vs Cold. Si ingestamos datos nuevos en un Data Lake, lo normal será usarlos en el corto plazo, por lo que el almacenamiento debería ser hot storage. A no ser que estamos migrando históricos de otros sistemas que no se vayan a utilizar en el corto plazo, y merezca más la pena guardarlos en cold storage, pues la frecuencia de uso será muy baja.
4. NoSQL. Las BBDD NoSQL se caracterizan por ser almacenamientos de datos flexibles y altamente escalables, por lo que si tenemos datos ya sea estructurados como semiestructurados que vayamos a utilizar en el corto plazo, puede resultar una opción interesante.
5. SQL. En principio lo normal es guardar los datos raw en ficheros con formatos de compresión como Avro o Parquet, y después aplicarle transformaciones y estructurarlo. A veces resulta interesante ingestarlo directamente en una BD estructurada y escalable, como sería el caso de Big Query, donde gestionamos tablas en un entorno distribuido.
6. Compresión de los datos. Tenemos la opción de comprimir los datos o no. ¿Esto qué va a implicar? Cuanto más comprimidos, menos ocupan, y por tanto el coste de almacenamiento es menor. Por otro lado, cuanto mayor sea la compresión, mayores serán también las latencias en el procesado, al tener que descomprimir archivos más complejos. Hay que poner ambos factores en una balanza. Formatos interesantes en la compresión de datos serían Avro, ORC o Parquet.

Piensa en cómo se van a explotar los datos, el volumen y el coste del almacenamiento. Esos van a ser los tres factores principales que van a determinar la decisión del formato de almacenamiento de datos en el Data Lake. Recuerda que no todos los datos tienen que compartir una misma fuente en el lago, sino que te puede interesar combinar bases de datos SQL, NoSQL, hot/cold… Al trabajar con la nube, es más sencillo que on premise desplegar y configurar nuevos recursos.

Hot vs Cold Storage

Los proveedores cloud nos ofrecen varias opciones a la hora de almacenar los datos en función de la disponibilidad de los mismo. Si queremos una alta disponibilidad, un acceso inmediato y de alta frecuencia a los datos, estaremos hablando de hot storage. Mientras que si almacenamos los datos en cold storage, tendremos un acceso más lento, pero a cambio el precio del almacenamiento será más económico

Por tanto, tendremos que decidir qué datos queremos en cold storage y qué datos queremos en hot storage. Lo normal es que los datos con un año de histórico se almacenen en hot storage, pues son datos que vamos a utilizar en los análisis del día a día, mientras que datos con mayor antigüedad pueden servir para análisis puntuales, o auditorías, y por lo tanto serían susceptibles de ir al cold storage. Si que es cierto que datos de más de un año se utilizan mucho para comparativas, pero normalmente es el dato agregado, y no el transaccional, por lo que te puedes guardar en hot storage el dato agregado para las comparativas.

Métodos de Ingesta de Datos

Una vez tenemos ya identificadas las fuentes de datos y el cómo las vamos a ingestar, veamos los streams de información, es decir, las formas que tenemos de llevar a cabo estas operaciones.

1. FTPs programados. FTP es un protocolo de comunicación que se utiliza para transferir archivos entre servidores. Podemos programar transferencias periódicas de archivos o mediante un trigger. Su configuración será diferente dependiendo del cloud en el que estemos.
2. Consultas SQL programadas. Si tenemos los datos en origen en una base de datos SQL, basta con tener una serie de queries programadas desde el Data Lake, para traer los nuevos datos.
3. Triggers que disparan procesos. Para esto hace falta un orquestador o un recurso cloud destinado específicamente para correr flujos de procesos. Por ejemplo, podemos tener una llamada a una cloud function desde un código de Python, indicando que ya ha cargado la carga de datos. Esta llamada corre otro código en la cloud function que puede estar en otro lenguaje de programación y que a su vez sirva de trigger para lanzar otro proceso.
4. CDC (Change Data Capture). Es una técnica utilizada en bases de datos para capturar y registrar los cambios realizados en los datos de una tabla en tiempo real. El CDC permite enviar notificaciones en tiempo real sobre los cambios realizados en una tabla, lo que nos permite la integración con los componentes del Data Lake. El uso de CDC para la ingesta en tiempo real ayuda a conservar los recursos y reduce la carga de trabajo de la base de datos. La ingesta en tiempo real es crucial para empresas del sector financiero, dispositivos IoT y el mantenimiento preventivo, en los que la información en tiempo real es vital para la toma de decisiones.
5. Colas de mensajes. Sirve por un lado para datos en real time, como colas de Kafka, o por otro lado tener un sistema de publicación/suscripción escuchando posibles mensajes para despues almacenarlos o desencadenar otros procesos, funcionaría parecido a un trigger.
6. API de la fuente de datos. Si tenemos una fuente de datos con una API REST, podemos atacar sus datos vía HTTP, y para ello nos sirve cualquier lenguaje de programación para realizar las peticiones.
7. Configurar la ingesta en el origen. Otra opción es al revés, en vez de estar pendiente desde el Data Lake, que sea el origen de datos el que proactivamente ingeste los datos, y tenga ya configurada la dirección del Storage del Data Lake donde mandará los datos.
8. Scheduler/cron. Simplemente programar una tarea para que corra cada X tiempo a la misma hora. Esto lo podemos hacer de muchas formas. Las plataformas cloud ya tienen recursos dedicados explícitamente a la programación de procesos. El problema de esto son las dependencias, pues si la base de datos que queremos cargar corre siempre a las 4am, y nuestro schedule está programado para las 6am, ¿qué ocurrirá sis e retrasa la carga a las 10am? Para estos casos se recomienda mejor usar un trigger.
9. Conectores preconfigurados. Antes de programar nada, asegúrate si tu proveedor de Data Lake tiene ya instalados conectores a tus fuentes de datos. Va a suponer un buen ahorro de tiempo y recursos.

No son las únicas formas de programar las ingestas. Tienes muchas maneras de coordinar todas estas piezas y la decisión que tomes irá en función de los costes, habilidades del equipo y tiempo de desarrollo y mantenimiento.

Procesados en la Ingesta de Datos

Uno de los principios de un Data Lake es que se vuelcan todos los datos en crudo, de tal forma que podemos tener un histórico de datos a un precio de almacenamiento económico.

En esta etapa de volcado de datos en crudo a un Data Lake no se suele aplicar ninguna transformación, ni filtro ni agregación a los datos. Esto se hace así por seguridad y protección del dato, de tal forma que podamos seguir toda la traza del dato a la perfección desde que se ingestó, hasta que su uso para un insight concreto.

Lo que sí se podría aplicar en esta primera etapa de ingesta es una capa de privacidad y seguridad de los datos. Esto correspondería más a empresas grandes, por lo que se aplican ciertos filtros para comprobar la privacidad de los datos que se están ingestando, aplicando transformaciones en algunos campos.

Data Governance

Llegamos a las políticas de Data Governance. Este apartado va a variar mucho en función de la empresa, su tamaño, departamentos etc. Hay que establecer ciertas normas para garantizar la integridad, confianza y seguridad de los datos que vayamos a ingestar. Algunas de estas políticas serían:

1. Metadatado. Nos van a servir para combinarlo con un motor de búsqueda. Con los años, los Data Lakes van aumentando de tamaño, por lo que resulta imprescindible tener un buscador para poder navegar entre todas las tablas y fuentes de datos. En el metadatado se recogerá información como el autor, departamento, propósito, fecha ingesta, data owner, tipología o la descripción de los datos.
2. Acceso. Quién tiene acceso a qué información. Se trata de una de las características más importantes de los Data Lakes, y es que hay que implementar unas políticas de privacidad y acceso a los datos que por defecto no existen. Aquí hay muchas maneras de hacerlo, pero por ejemplo se puede establecer una capa de datos generalistas a la que tienen acceso los analistas de datos, y otra capa de datos con los generalistas y los personales, como DNI, nombre y dirección, al que tengan acceso aquellos usuarios del Data Lake que de verdad vayan a usar esa información. Cuanto mayor es la empresa, más foco hay que poner en este tipo de políticas.
3. Filtros de privacidad. Lo normal en la etapa de ingesta es no tocar el dato y volcarlo en el Data Lake directamente en crudo. Ahora bien, es posible por temas regulatorios que en la propia ingesta tengamos que aplicar algún filtro de privacidad para que los usuarios del Data Lake no tengan acceso a información personal. No sería lo habitual, pero en empresas con reguladores por detrás sí que ocurre.

Solo nos vamos a apoyar en estos tres puntos de cara al Data Governance, pues estamos ahora mismo en la etapa de ingesta, y nos centramos únicamente en los datos en crudo que se van a introducir en la empresa.

Mantenimiento de pipelines de Ingesta de Datos

Tendremos que montar ciertos procesos en paralelo a las ingestas y ejecuciones en batch, que sirvan para garantizar la seguridad y calidad de los procesados de los datos. Por ejemplo, serán necesarios procesos para comprobar el uso de los datos, ya que irán creciendo con el tiempo y habrá muchos de ellos que no utilizaremos con tanta asiduidad, y que por tanto tendremos que moverlos al cold storage.

1. Comprobación de uso de datos. Procesos de consulta sobre la frecuencia de uso de alguna tabla o fuente de datos. Aquellas que no se hayan usado en un determinado tiempo, son susceptibles de ser eliminadas, o pasar a almacenamiento en frío. Comprueba siempre las dependencias de otros procesos con esas tablas.
2. Conversión a almacenamiento en frío. Aquellos datos con cierta antigüedad, como por ejemplo más de un año, es probable que se utilicen en análisis puntuales, por lo que tendremos un ahorro en almacenamiento pasándolo a cold storage.
3. Privacidad de los datos. Podemos tener procesos automáticos con los que comprobemos si los datos son DNIs, nombres completos, direcciones, etc… Todo lo que pueda poner en compromiso la seguridad y privacidad de los datos del Data Lake lo podremos adecuar en función de los usuarios que vayan a tener acceso a esos datos. Recuerda que no todos los usuarios deberían tener permisos a todos los datos personales de los clientes. En ocasiones se dividen los datos en capas de privacidad y se otorgan permisos en función de la capa a la que debería tener acceso el usuario.
4. Calidad del dato. Procesos de comprobación de tipos, de nulos, de duplicidades, tanto de filas como de columnas. Estos procesos pueden aplicarse tanto a datos estáticos en el Data Lake, como datos de nueva creación, a modo de testing.
5. Usuarios y permisos. Con el tiempo evolucionan los equipos (más de lo que creemos), se contrata personal externo, hay procesos que necesitan permisos de lectura/escritura en los recursos cloud, por lo que es importante llevar un mantenimiento de los permisos de usuario que se conceden. Empieza creando roles y grupos de usuarios en tu proveedor cloud, de tal forma que sea más sencillo mantener la asignación de permisos.
6. Actualiza la documentación. Una muy buen práctica es documentar los desarrollos en el Data Lake. Desarrollar está muy bien pero la documentación hay que mantenerla pues se introducen piezas nuevas, se sustituyen tecnologías y se evolucionan los programas, por lo que de vez en cuando hay que echar un vistazo a la documentación desarrollada y realizar algunos cambios.

Verás a lo largo de nuestros artículos de arquitectura que muchos de l-os puntos descritos en este apartado son de aplicación en otras capas del data lake, como en los procesos batch o real time.

Principales herramientas para la Ingesta de Datos en un Data Lake

Tendremos secciones en welearndata.com sobre herramientas concretas que sirven tanto para la ingesta como para la orquestación de procesos, pues son dos funcionalidades que van de la mano en un Data Lake. Te presentamos a continuación un resumen de las principales herramientas de ingesta:

Python

Se trata de un lenguaje de programación de propósito general y tenemos soluciones de lo más variadas, desde llamadas HTTP, librerías para SQL a orquestadores como Airflow.

Azure

Cuenta con varios conectores, como Kafka, Log4J, Spark o Synapse Analytics, además de sus principales herramientas de ingesta como Event Hub, IoT Hub y Azure Data Factory.

AWS

Las principales herramientas de ingesta de datos con AWS serían AWS Glue, AWS Snow Family, AWS Kinesis, AWS DataSync o AWS Transfer Family.

GCP

Podemos ingestar datos de forma sencilla mediante conectores Big Query, siempre que las fuentes sean herramientas dentro del ecosistema de Google, como Google Analytics. Si no entran dentro del ecosistema de Google, lo normal es usar Dataproc o Dataflow.

Snowflake

Se trata de una plataforma cloud con una gran cantidad de conectores. Desde archivos planos, integración con servicios en la nube de Azure, AWS y GCP, streaming de datos o ETLs de bases de datos SQL

Informatica

La ingesta de datos se realiza a través de su herramienta principal, llamada Informatica PowerCenter, donde podemos crear un workflow de ingesta desde las distintas clouds públicas o bases de datos, a la plataforma de Informatica.

Databricks

La ingesta de datos se realiza a través de varias opciones que facilitan la captura y carga de datos en el entorno de análisis y procesamiento de big data basado en Apache Spark. Carga de archivos desde los Storage de las distintas clouds públicas, streaming con Apache Kafka, conexiones a bases de datos e integración con otros Data Lakes.

En estas plataformas vas a encontrar herramientas de ingesta automatizadas, pero ten en cuenta que en muchas ocasiones la ingesta automatizada require su tiempo de desarrollo, por lo que hay que cerciorarse de que efectivamente se necesita una ingesta automática, periódica, o de lo contrario pueden valer ingestas manuales puntuales. Evalua bien todas las opciones.

Buenas prácticas en la Ingesta de Datos

Como las posibilidades a la hora de diseñar un Data Lake son múltiples, queremos compartir algunas buenas prácticas que aplican a toda capa de ingesta de datos.

1. Workspaces. Organiza grupos de trabajo, de recursos y proyectos dentro de los proveedores cloud para llevar un orden en las aplicaciones que se desarrollan, permisos que se asignan, cuentas de facturación y despliegue de recursos.
2. Jerarquías. Es importante si trabajamos con un Storage en cloud, que llevemos una jerarquía de directorios coherente, organizada, y que facilite la asignación de permisos en las diferentes ramas de la jerarquía.
3. Nomenclatura. Establece un sistema de nombres de tablas, workspaces, formatos de datos que sean descriptivos, sencillos de utilizar y ahorren tiempo cuando se esté trabajando con los mismo. Unos nombres descriptivos de los datos pueden ahorrar mucho dinero en queries innecesarias. Habrá tablas de históricos, otras que no sean históricos, distintos niveles de privacidad, o que determinen el origen de los datos. Todo esto lo podemos gestionar en los metadatados de los datos.
4. Compresión de datos para ahorro de costes. Todo dato con antigüedad superior al año es susceptible de tener una mayor compresión, pasar a cold storage y ahorrar costes en detrimento de la velocidad en el acceso.
5. Propósito de los datos. Antes de embarcarse en la ingesta de datos, hay que asegurarse de definir correctamente los datos, su propósito, las herramientas que los explotarán, y cómo las herramientas de ingesta trabajarán con los datos. Una buena planificación ayuda a las organizaciones a elegir y diseñar un marco de ingesta escalable en los Data Lakes.
6. Conectores de las plataformas. No reinventes la rueda. Antes de ponerte a programar un conector con una base de datos, comprueba primero si la plataforma con la que trabajas tiene ya un conector diseñado para ese propósito.

Con esto concluimos la primera etapa del camino que seguirán los datos dentro de un Data Lake, es decir, la ingesta de los datos. Lo importante es tener la mayor cantidad de los datos útiles y que se vayan a utilizar, dentro del Data Lake. Con su metadatado y taggeado correspondiente, así como en un formato compatible y accesible a la velocidad demandada por parte de los siguientes sistemas de transformación y consumo de datos.

SIGUIENTE EPISODIO – Te recomendamos que continúes tu travesía por las Arquitecturas de Big Data con nuestro artículo de Procesado de datos Batch en un Data Lake.