HistoricalDB/DataLake integrado en Plataforma sobre Presto+MinIO

Motivación

En los 2000 Hadoop se había estandarizado como solución para la creación de DataLakes ya que permitía construir clusters locales con hardware básico para almacenar y procesar estos nuevos datos de forma barata.

Pero el mundo open-source ha seguido evolucionando y en la actualidad con Hadoop es muy difícil conseguir la elasticidad, simplicidad y agilidad en el provisionamiento que otras soluciones basadas en Kubernetes si ofrecen.

Plataforma propone una solución basada en MinIO+Presto como DataLake.

Por un lado tenemos MinIO 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.

Para nuestra implementación DataLake proponemos usar Presto 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.

En nuestro caso Presto es el motor de consultas 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

Ventajas de esta aproximación

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