Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Introducción

En este trimestre hemos comenzado con esta funcionalidad que continuaremos durante Q3. En el trimestre nos hemos centrado en el despliegue embebido de un cluster Spark junto con Plataforma junto con sus herramientas de visualización de jobs, además de en poder enviar jobs Spark a través de las herramientas de plataforma.

En la próxima release continuaremos trabajando en la integración de otros clusters (pj servicios de diferentes Clouds) y mejoras la integración con plataforma.

Análisis técnico

Elección del cluster de Spark

Spark permite distintos tipos de despliegues para cluster, entre los que tenemos: Standalone, Kubernetes, YARN y Mesos.

En primera instancia daremos la posibilidad de crear un cluster Standalone desplegado en Kubernetes. Esto tiene las ventajas de que tenemos elementos ya definidos como master y workers, pudiendo definir una infraestructura más fácil de gestionar. También nos facilita el acceso a las UIs y logs de cada nodo, ya que cada uno tendrá siempre una única función en el cluster. En futuras versiones añadiremos la posibilidad de conectarnos a Servicios de Spark como los de GCP Databricks, etc.

Versión e imagen de Spark

Vamos a crear una imagen de Spark 3.2.1 con soporte Hadoop 3.2 y AWS S3.

Esta imagen es custom de plataforma, para poder integrar nuestro MinIO como almacén de procesos (jars), facilitando el despliegue y ejecución de procesos Spark desde Plataforma.

Integración de Logs

También integraremos los logs de todos los elementos de Spark (Workers y Master) a Graylog. Para ello se ha añadido un conector UDP que agiliza la recolección de logs que ya teníamos. El resto de módulos podrán ser configurados para usar dicho conector. Esto nos permite ver en una única herramienta todos los logs de Spark.

Unificación de UI y seguridad

Si alguna vez habéis accedido a la UI de Spark, sabréis que cada nodo tiene su propia UI en puertos definidos por el administrador del cluster, lo que hace poder navegar por estas UIs fuera del cluster bastante tedioso (teniendo que abrir puertos, túneles, etc.). Para facilitar el acceso, navegación y uso, desde plataforma vamos a ofrecer acceso a dichas UIs (Master y workers) desde fuera del cluster.

Dado que permitiremos el uso de estas UIs desde plataforma, hemos creado un plugin de seguridad haciendo uso del token oauth generado por plataforma, para que solamente sus usuarios puedan acceder desde el propio ControlPanel.

Ejecución de procesos Spark en plataforma

Para facilitar el lanzamiento de procesos Spark en plataforma nos vamos a apoyar en el uso de MinIO.

Al tener integrada la interfaz de AWS S3, desde nuestro cluster Spark podremos invocar procesos (jars) que estén subidos a un bucket de Minio desde la propia plataforma. Si permitiéramos la ejecución desde consola sería algo similar a este ejemplo: 

./bin/spark-submit \
    --master spark://192.168.1.216:7077 \
    --name spark-pi \
    --deploy-mode cluster \
    --conf spark.hadoop.fs.s3a.access.key=xxxxxx \
    --conf spark.hadoop.fs.s3a.secret.key=xxxxxxxx \
    --conf spark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider \
    --conf spark.hadoop.fs.s3a.endpoint=http://minio:9000 \
    --conf spark.hadoop.fs.s3a.connection.ssl.enabled=false \
    --conf spark.hadoop.fs.s3a.path.style.access=true \
    --class org.apache.spark.examples.SparkPi \
	s3a://administratorbucket/original-spark-examples_2.12-3.2.1.jar

Donde el proceso está almacenado en el object storage de plataforma (MinIO) lo que lo hace accesible a todos los nodos del cluster.

Evidentemente, lanzar los procesos desde consola no es una opción para los usuarios, con lo que crearemos un nuevo módulo SparkLauncher, que nos ofrecerá un recubrimiento a invocaciones Spark desde Java.

Mediante el uso de SparkLauncher vamos a crear una API que nos permita seleccionar el proceso a lanzar (subido a MinIO) y los parámetros más usuales configurables en runtime para Spark (nombre del proceso, uso de recursos, etc.).

Subimos a nuestro repositorio de objetos el JAR a ejecutar:

Lanzamos la ejecución desde la API con la parametrización necesaria:

Y el proceso se lanzará en el cluster:

También tendremos en futuras versiones la posibilidad de configurar el módulo de Notebooks para que lance sus procesos Spark contra el cluster.

¡Esto es solo el principio!

En este Q2 solamente estamos empezando a integrar funcionalidades básicas. La idea es continuar en esta linea, permitiendo más y mejores funcionalidades como:

  • Creación de perfiles de ejecución: Permitir que los administradores asignen perfiles de recursos (ram/cores en workers/executors) y los asignen a los usuarios analytics que lancen los procesos para poder controlar el uso de recursos del cluster.

  • Control del ciclo de vida de procesos Spark: Al estilo de lo que ya está disponible para microservicios, queremos poder ofrecer a los usuarios la posibilidad de gestionar el ciclo de vida de sus procesos Spark, desde su desarrollo (integrándolo en Gitlab), despligue (compilación desde Jenkins), subida a MinIO y ejecución en el propio cluster de Spark, de manera sencilla desde el ControlPanel.

  • Conexión con otros cluster de Spark

  • Integración con Notebooks de plataforma

  • No labels