Llevo bastante tiempo sin escribir nada técnico relacionado con el mundo del la analítica de datos y el bigdata. En zylk hemos seguido trabajando con el ecosistema de apache hadoop (hive, yarn, hdfs etc..) y como siempre también hemos estado siguiendo algunos proyectos de la fundación apache que nos parecen interesante. Entre ellos hay tres que nos gustan especialmente y son:
En este artículo vamos a explicar, brevemente, como hemos montado un laboratorio con el proyecto ozone.
Hace unos meses empezamos a probar unos PCs que se suelen usar para jugar que tienen las siguientes características
En la imagen podemos ver los tres nodos, el primero lo vamos usar de master, y los otros dos de slaves. También podemos ver las GPUs de cada nodo con el comando nvidia-smi, están integradas con pytorch y tensorflow, y con yarn, pero eso es otra historia que ya contaremos cuando hablemos de submarine
Y también podemos ver el detalle de que yarn reconoce el recurso GPU de cada uno de los 3 nodos ( yarn.io/gpu: 3)
En estos nodos, a modo de laboratorio, hemos montado los siguiente productos en sus últimas versiones
Todo gestionado desde servicios systemd de linux. Como ejemplo de una de estas unidades podemos ver el contenido del servicio de namenode del HDFS
Todavía hay algunas cosas que no funcionan adecuadamente (acceso a hive orc desde spark usando tez por ejemplo) pero en su versión preliminar esta arquitectura nos ha servido para levantar sobre containers yarn/docker un hbase siguiendo este proyecto que, aunque obsoleto, da una idea de lo que se puede llegar a hacer con yarn y docker. Cómo montar yarn para que soporte docker y se comporte como un orquestador de contenedores lo explicamos hace varios años ya en este otro post.
Donde podemos ver que el servicio de hbase lleva corriendo 2 días en el cluster
En la siguiente imagen podemos ver el propio cluster de hbase sobre el dominio de despliegue configurado en yarn/docker, en este caso yarn.bigdata.zylk.lab
Como curiosidad, indicar que estamos usando este hbase para unas pruebas de concepto de almacenamiento de series temporales usando
pero eso es otra historia.
La idea de esta arquitectura gneral es poder probar los distintos proyectos que componen el típico ecosistema de bigdata de manera autónoma y poder usar yarn como orquestador de contenedores para levantar en distintas versiones
Dentro de este contexto de laboratorio, los productos típicos ya los conocemos bastante bien ya que son la base de HDP (Hortonworks) y CDP (Clouder) que tenemos en distintos clientes. Pero los tres que he nombrado el principio los queremos analizar con más detalle, ya que creemos que van a ser parte de las nuevas infraestructuras de bigdata.
Estas dos preguntas se pueden contestar leyendo las páginas de los proyecto, de donde se ha obtenido la siguiente descripción.
También es muy interesante ver los siguientes videos que son especialmente didácticos (y yo no soy muy de ver videos, prefiero leer artículos).
Una vez que hemos visto qué es ozone vamos a presentar sus servicios principales
Además luego hace uso de un servicio de datanode que hace las veces de los datanodes de hdfs
Con todo esto podemos levantar, tal como se ha indicado en la introducción los servicios
En la anterior imágen podemos ver el estado del cluster de ozone con sus 3 datanodes, 22 volumenes creados, 203 buckets y 10001001 keys/ficheros. Tiene todas estos buckets porque se ha hecho una primera prueba de stress usando la herramienta freon
Además podemos ver que el s3gateway también está levantado
y que si configuramos el cliente de aws podemos hacer uso del mismo (como no tiene seguridad montada se puede usar cualquier key)
Una vez vista la arquitectura y montado un cluster de tres nodos, para qué lo queremos
