En este post vamos a hablar de una propuesta sólida para construir un DataLake open-source sin Hadoop, esta se basa en MinIO + Presto…veamos su propuesta.

Un poco de historia

Hasta hace poco, cuando surgía la necesidad de montar un DataLake siempre nos venía a la mente Hadoop…pero en los últimos tiempos esto ha cambiado.

Echemos la vista atrás y entender cómo han cambiado las cosas. Hadoop surgió a principios de la década de 2000 y se hizo masivamente 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 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 clusters 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 sigue siendo necesario persistir los datos, de modo que Spark se incluía en muchas distribuciones de Hadoop.

Caída de Hadoop

Uno de los motivos es que 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.

Está claro que hay más motivos, y es que con Hadoop es muy difícil conseguir la elasticidad, simplicidad y agilidad en el provisionamiento que otras soluciones basadas en Kubernetes si ofrecen.

MinIO como Object Storage

Por un lado tenemos MinIO (ver post) que es un almacenamiento distribuido que implementa la API de AWS S3. MinIO puede desplegarse en On-Premise y funciona sobre Kubernetes. En la actualidad es una alternativa interesante a los entornos basados en HDFS y al resto del ecosistema Hadoop.

La principal diferencia entre MinIO y HDFS es que MinIO es una Object Storage mientras que HDFS es un File Storage basado en Block Stroage:

El Object Storage basa su almacenamiento en objetos, donde cada objeto se compone de 3 cosas:

• Los datos propiamente dichos. Los datos pueden ser cualquier cosa que se quiera almacenar, desde una foto familiar hasta un manual de 400.000 páginas para construir un cohete.
• 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).

¿Por qué es relevante el Object Storage?

El almacenamiento de objetos se diferencia del almacenamiento de archivos y del almacenamiento de bloques en que guarda los datos en un "objeto" en lugar de en un bloque para formar un archivo. Los metadatos se asocian a ese archivo, lo que elimina la necesidad de la estructura jerárquica utilizada en el almacenamiento de archivos: no hay límite a la cantidad de metadatos que se pueden utilizar. Todo se coloca en un espacio de direcciones plano, que es fácilmente escalable.

Esencialmente, el almacenamiento de objetos funciona muy bien para los grandes contenidos y alto throughput, permite que los datos se almacenen en varias regiones, se escalan infinitamente hasta los petabytes y más allá, y ofrece metadatos personalizables para ayudar a recuperar los archivos.

¿Y en lugar de HIVE? Presto al rescate

Hasta ahora hemos visto que MinIO puede sustituir a HDFS como almacenamiento en nuestro DataLake, pero aún nos falta un motor de consultas SQL al estilo del eterno HIVE.

Para nuestro DataLake proponemos usar Presto (ver post), que es un motor de consultas SQL distribuido open-source y construido en Java, está 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.

Con Presto podemos consultar numerosas fuentes de datos, en nuestro caso los datos almacenados en MinIO, de modo que en lugar de montar HIVE para consultar en formato SQL los datos almacenados en HDFS usaré Presto para consultar los datos almacenados en MinIO. Pero además es que con Presto podré consultar otras fuentes de datos (relacionales, NoSQL,…) de forma directa…permitiendo incluso consultar datos almacenados en HDFS! 😊

Además Presto puede ejecutar sobre Spark, lo que permite aprovechar Spark como entorno de ejecución para las consultas de Presto.

Conclusiones

Veamos las ventajas de construir un DataLake basado en MinIO+Presto vs Hadoop:

• La combinación es más elástica que la típica configuración Hadoop, y si alguna vez has tenido que añadir y quitar nodos a un clúster Hadoop, sabrás a qué me refiero. Se puede hacer, pero no es fácil, mientras que esa misma tarea es trivial en esta arquitectura.
• Con Hadoop si quieres añadir más almacenamiento, lo haces 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 cluster 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. Y eso es bueno, porque tus necesidades de computación y almacenamiento también son elásticas de forma independiente.
• Mantener un cluster Hadoop estable y fiable es una labor compleja, por ejemplo la actualización de un cluster suele implicar la parada del cluster, las actualizaciones continuas son complejas,…
• 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.