Trabajando con un Data Lake en la Onesait Platform (parte 3)

Bienvenidos a nuestra tercera entrada sobre Data Lakes y la Onesait Platform. Aunque aun no hemos llegado a este último punto, de momento ya hemos visto qué es un Data Lake y qué beneficios nos aporta, y en qué se diferencia con un Data Warehouse.

Hoy os queremos contar los tipos de Data Lakes que existen, hablaros de Hadoop, y comentaros algunas propuestas Open Source existentes en el mercado.

Hadoop como Data Lake

El Data Lake se asocia a menudo con el almacenamiento de objetos orientado a Hadoop. En este escenario, los datos de una organización se cargan primero en la plataforma Hadoop y, a continuación, se aplican las herramientas de análisis y de minería de datos a los datos que residen en los nodos clúster de Hadoop.

En el núcleo de Hadoop encontramos su capa de almacenamiento, el HDFS (Sistema de archivos distribuidos de Hadoop), que almacena y replica los datos por múltiples servidores, además el ecosistema Hadoop engloba varias herramientas suplementarias, como Hive, Flume, Sqoop y Kafka que ayudan con la ingesta, la preparación y la extracción de datos.

Los Data Lakes de Hadoop pueden montarse localmente o en Cloud mediante plataformas de empresa como Cloudera, Azure HDInsight o GCP DataProc.

Puntos fuertes de un Data Lake sobre Hadoop

Aún hoy en día, montar un Data Lake sobre Hadoop es una opción muy usada por los siguientes motivos:

• Mayor familiaridad entre el equipo técnico.
• Solución Open Source, que hace que su implantación sea económica.
• Más económicos, porque son de código abierto.
• Muchas herramientas disponibles para la integración con Hadoop.
• Fácil de escalar.
• La localidad de los datos permite una computación más rápida.
• Posibilidad de montarlo On Premise o como servicio en las diversas Clouds.

Hadoop en la actualidad

Hadoop fue en su día la opción dominante para los Data Lakes, pero en el cambiante mundo de la tecnología hay otros enfoques más modernos basados en herramientas como Spark o Presto.

Echemos la vista atrás para entender cómo han cambiado las cosas; Hadoop surgió a principios de la década de 2000 y se hizo popular en la década, de hecho, debido a que muchas empresas apostaron por el código abierto, la mayoría de los primeros proyectos BigData y Data Lakes de entonces se basaron en Hadoop.

Hadoop ofrecía 2 capacidades principales:

• Sistema de archivos distribuido (HDFS) para persistir los datos.
• Marco de procesamiento que permite procesar todos esos datos en paralelo.

Cada vez más, las organizaciones comenzaron a querer trabajar con todos sus datos y no sólo con algunos. Y como resultado de ello, Hadoop se hizo popular por su capacidad para almacenar y procesar nuevas fuentes de datos, incluidos los registros de logs, los flujos de clics y los datos generados por sensores y máquinas.

En los dos mil, Hadoop tenía mucho sentido ya que permitía construir clústeres locales con hardware básico para almacenar y procesar estos nuevos datos de forma barata.

Pero el Open Source seguía evolucionado y surgió un marco nuevo: Apache Spark, optimizado para trabajar con datos en memoria y no en disco. Y esto, por supuesto, significa que los algoritmos que se ejecutan en Spark serán más rápidos, pero seguía siendo necesario persistir los datos, de modo que Spark se incluía en muchas distribuciones de Hadoop. Eso funcionaba, pero con el auge de la nube, hay un enfoque mejor para la persistencia de sus datos: el almacenamiento de objetos.

Además de esto, con la compra de Hortonworks por Cloudera (y la de MapR por HP) en esencia podemos decir que ya no existen distribuciones gratuitas de Hadoop, y esto hace que se estén buscando soluciones alternativas en el mundo Open Source.

MinIO y Presto como Data Lake

Comentábamos que en la actualidad se puede montar sobre Spark y un repositorio de objetos. En este punto vamos a describir una alternativa interesante a los entornos basados en HDFS y al resto del ecosistema Hadoop basada en MinIO y Presto.

Concretando esta aproximación, MinIO es un almacenamiento de objetos (Object Storage) distribuido que implementa la API de AWS S3 (de esto os hablamos el lunes pasado). MinIO puede desplegarse en On-Premise y en Cloud y funciona sobre Kubernetes. Además, basa su almacenamiento en objetos, donde cada objeto se compone de 3 conceptos:

• Los datos propiamente dichos. Los datos pueden ser cualquier cosa que se quiera almacenar, desde una foto hasta un manual de 400.000 páginas.
• Una cantidad ampliable de metadatos. Los metadatos son definidos por quien crea el objeto; contienen información contextual sobre lo que son los datos, para qué deben usarse, su confidencialidad, o cualquier otra cosa que sea relevante para la forma en que deben usarse los datos.
• Un identificador único global. El identificador es una dirección que se da al objeto, para que pueda ser encontrado en un sistema distribuido. De este modo, es posible encontrar los datos sin tener que conocer su ubicación física (que podría existir en diferentes partes de un centro de datos o en diferentes partes del mundo).

Y si MinIO puede sustituir a HDFS como almacenamiento en un Data Lake, nos falta un motor de consultas SQL al estilo de HIVE, y aquí es donde entra en juego Presto.

Presto es un motor de consultas SQL distribuido Open Source, construido en Java y pensado para lanzar consultas analíticas interactivas contra un gran número de fuentes de datos (a través de conectores) soportando consultas sobre fuentes de datos que van desde gigabytes hasta petabytes.

También se considera un motor de consulta ANSI-SQL, lo que permite consultar y manipular datos en cualquier fuente de datos conectada con las mismas sentencias, funciones y operadores SQL.

En el Data Lake podemos por tanto usar Presto para consultar los datos almacenados en MinIO.  Además, Presto puede ejecutar sobre Spark, lo que permite aprovechar Spark como entorno de ejecución para las consultas de Presto.

Ventajas de esta aproximación

Esta aproximación tiene numerosas ventajas sobre el montaje de un Data Lake sobre Hadoop:

• La combinación es más elástica que la típica configuración Hadoop, mientras que en Hadoop añadir y quitar nodos a un clúster Hadoop es un proceso completo, en esta aproximación todo ejecuta sobre Kubernetes, lo que nos permite escalar de forma sencilla.
• Computación y almacenamiento independientes: Con Hadoop si se quiere añadir más almacenamiento, se hace añadiendo más nodos (con computación). Si necesitas más almacenamiento, vas a tener más cómputo, lo necesites o no mientras que con la arquitectura de almacenamiento de objetos si necesitas más computación, puedes añadir nodos al clúster Presto y mantener el almacenamiento, de modo que la computación y el almacenamiento no son sólo elásticos, son elásticos de forma independiente.
• Mantenimiento: Mantener un clúster Hadoop estable y fiable es una labor compleja, por ejemplo la actualización de un clúster suele implicar la parada del clúster, las actualizaciones continuas son complejas, etc.
• Reducción de costes: Con esta arquitectura tendremos una reducción del coste total de la propiedad: ya que MinIO apenas requiere gestión, y además el almacenamiento de objetos es más barato.

Como podemos ver, el potencial de MinIO y Presto es enorme. Tanto es así, que hemos incorporado tanto MinIO en la Onesait Platform, de lo que os hablamos el lunes pasado, como Presto, de lo que os hablaremos el próximo lunes.

La semana que viene os hablaremos de los Data Lakes y la nube, y las ventajas que tiene frente a la solución On-Premise más común hasta ahora. ¡Os esperamos!

---

Imagen de encabezado de Philipp Katzenberger en Unsplash

✍🏻 Author(s)