En este Q2 estamos trabajando para integrar un cluster Spark en plataforma.
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 procesoso 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 (lo subirá a MinIO) y los parámetros más usuales configurables en runtime para Spark (nombre del proceso, uso de recursos, etc.).
También tendremos 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