Seguimos hoy con la anterior entrada ¿Qué es un Data Lake? hoy

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 motivos como estos:

• 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 2000s Hadoop tenía mucho sentido ya que permitía construir clústers 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, 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. MinIO puede desplegarse en On-Premise y en Cloud y funciona sobre Kubernetes.

MinIO 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.

Presto es un motor de consultas SQL distribuido open-source y 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.

Presto es un motor de consulta ANSI-SQL, 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.

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, …
• 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.