Almacenamiento tipo volume/bucket compatible con HDFS y S3
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.
Lo primero una pequeña composición de lugar
Hace unos meses empezamos a probar unos PCs que se suelen usar para jugar que tienen las siguientes características
- Atermiter-placa base Dual X99 con XEON E5 2011 V3 * 2
- 128 GB RAM
- 1 SSD NVM de 500 GB
- 2 SSD SATA de 1 TB
- 1 GeForce 1030 (2GB)
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
- hadoop (3.2.2)
- zookeeper (3.7.0)
- tez (0.10.0)
- spark (3.1.1)
- hive (3.1.2)
- ozone (1.1.0)
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
- Como KEY el id de la serie, el año/mm/dd/HH
- 3600 qualifieres para almacenar los datos de cada segundo de la serie
- Y en cada rowykey/qualifier, usando appends, todas las medidas de la serie que se produzcan
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
- HBase
- Submarine
- Zeppelin
- etc..
Y ahora ya … Ozone
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.
- ¿Qué son?
- ¿Para que se usan?
Estas dos preguntas se pueden contestar leyendo las páginas de los proyecto, de donde se ha obtenido la siguiente descripción.
- Ozone: Ozone is a scalable, redundant, and distributed object store for Hadoop. Apart from scaling to billions of objects of varying sizes, Ozone can function effectively in containerized environments such as Kubernetes and YARN.
- Iceberg: Apache Iceberg is an open table format for huge analytic datasets. Iceberg adds tables to Trino and Spark that use a high-performance format that works just like a SQL table.
- Submarine: Cloud Native Machine Learning Platform
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).
- Ozone: Serie de 14 videos explicando la arquitectura, los componentes etc..
- Iceberg: Resumen de cómo funciona Iceberg
Una vez que hemos visto qué es ozone vamos a presentar sus servicios principales
- OM: Ozone Manager, es el equivalente al NameNode pero con la diferencia de que ozone separa en dos las responsabilidades del Namenode (gestión del namespace y gestión de las replicas/bloques).
- SCM: Storage Container Manager, es el responsable de la gestión de los bloques y de los cierres de los containers (el concepto de container no es del docker en este caso, es el de conjunto de bloques que se gestionan como una única entidad desde el punto de vista de su estado)
- S3Gateway: Es un gateway que expone una interfaz rest compatible con S3 y que por tanto permite a ozone exponer su información como si de un endpoint tipo S3 se tratara
- Recon: Es el servicio central para management and monitoring
- CSI: Container storage interfaz, para proveer almacenamiento a los orquestadores de containers/docker tipo yarn, K8s, mesos etc.. En este caso no lo hemos montado todavía
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
- OM, SCM, S3Gateway, Recon en el nodo master
- Datanode en los slaves, y en el caso que nos ocupa también en el master para tener 3 datanodes
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
- Es compatible con las aplicaciones que usan hdfs, por tanto se podría usar ozone con hive, spark, hbase etc..
- Es compatible con s3, por lo que se debería poder usar para almacenar las tablas de iceberg
- Ofrece una interfaz CSI compatible con yarn, para la gestión del aprovisionamiento de los contenedores de yarn
