Configuración de Talend y de Spark submit ¿qué diferencia hay?

Configuración de Talend y de Spark submit ¿qué diferencia hay?

  • Petros Nomikos
    I have 3 years of experience with installation, configuration, and troubleshooting of Big Data platforms such as Cloudera, MapR, and HortonWorks. I joined Talend in 2014, and prior to Talend I held positions as manager of technical support, and project manager for data warehouse implementations. In my current role, I assist companies in understanding how to implement Talend in their Big Data Ecosystem.

En mi artículo anterior, «Talend y Apache Spark: un manual técnico», presenté las equivalencias entre las tareas de Talend Spark y Spark Submit. En este texto me gustaría seguir evaluando las configuraciones de Talend Spark con Apache Spark submit. En primer lugar, veremos cómo establecer correspondencias entre las opciones de la pestaña de configuración de Apache Spark en la tarea de Talend Spark, y qué puede utilizar como argumentos en Spark submit y analizaremos su uso. Empecemos.

Diferencias de comandos

Al ejecutar una tarea de Apache Spark (como uno de los ejemplos de Apache Spark ofrecidos por defecto en el clúster de Hadoop utilizado para verificar que Spark funciona como debería) en su entorno utiliza los siguientes comandos:

export HADOOP_CONF_DIR=XXX./bin/spark-submit  --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode client  --executor-memory 5G --num-executors 10 /path/to/examples.jar 1000

Los dos comandos resaltados arriba configuran el directorio desde el que nuestra tarea de Spark submit leerá los archivos de configuración del clúster. Luego emitimos nuestro comando de Spark submit, que ejecutará Spark en un clúster de YARN en modo cliente, utilizando 10 ejecutores y 5 G de memoria para que cada uno ejecute nuestra tarea de ejemplo de Spark.

Ahora veamos cómo se ejecuta esta misma tarea de ejemplo de Spark en Talend. Cuando ejecutamos una tarea de ejemplo de Spark (como la anterior) en Talend, toda la información de configuración de Spark se introduce en la siguiente pestaña dentro de la de ejecución:

Figura 1

Esto suscita una serie de preguntas. ¿Qué correspondencia existe entre la información que introducimos en Talend y la que introducimos en el terminal para ejecutar una tarea de Spark? ¿Cómo sabemos cuántos ejecutores y cuánta memoria hemos solicitado? ¿Y la resolución de problemas técnicos? Daremos respuesta a todas estas preguntas en nuestro artículo.

Antes de seguir, me gustaría presentar algunas opciones de Spark submit que utilizaremos a lo largo del artículo. Según la documentación de Apache Spark, estas son algunas de las opciones más habituales que puede enviar a un script de Spark submit:

--class: Este el punto de entrada principal para su aplicación de Spark.

--master: En esta opción especifica si su Spark Master es un Spark autónomo o si va a utilizar Spark en YARN.

--deploy-mode: Como dijimos en mi artículo anterior, esto se refiere a las dos modalidades de YARN diferentes de las que dispone y enumera cómo se desplegará su controlador de Spark.

--conf: En esta opción enviará más configuraciones de Spark que desea que su tarea utilice, como por ejemplo «spark.executor.userClassPathFirst=true».

--application-jar: Esto se refiere a la ruta en la que ha ubicado su código compilado de Spark que Apache Spark ejecutará.

--application-arguments: En esta opción enviará cualquier argumento que sea específico de su código Spark.

A continuación, veamos cómo se utilizan las opciones anteriores en una tarea de Talend Spark. Observará que en la pestaña Spark Configuration debajo de la pestaña de ejecución las distintas opciones que puede configurar aparecen clasificadas lógicamente en las siguientes categorías:

  1. Cluster Version (Versión del clúster)
  2. Configuration (Configuración)
  3. Authentication (Autenticación)
  4. Tuning (Ajuste)
  5. Spark History (Historial de Spark)

Cluster Version (Versión del clúster)

Empecemos por una de las primeras opciones que le aparecen en la tarea de Talend en la categoría Versión del clúster. Se trata de la opción «Spark Mode».

En esta opción puede especificar si su Spark Master está en YARN o si utilizará un Spark autónomo (standalone). Esta opción se corresponde con «--deploy-mode» que hemos descrito antes para las opciones de Spark submit, además de con «--master». Por ejemplo, si selecciona Spark Mode como «YARN Client» en Talend, esto equivaldrá a especificar en Spark submit «--master yarn --deploy-mode client». Ahora si se selecciona el modo Autónomo (Standalone) en la casilla desplegable, Talend le pedirá que introduzca la información de la URL de su Spark Master como lo haría en el Spark submit. Esto equivaldrá al envío del siguiente argumento en Spark submit, que es «--master spark://127.0.0.1:7077».

Configuration (Configuración)

En Talend tenemos la categoría «Configuration», que solicita la siguiente información:

En el primer conjunto de casillas, Talend nos pide que demos información sobre el administrador de recursos, la dirección del programador, la dirección del historial de tareas y el directorio de pruebas.

Al usar Spark submit toda esa información se inyecta en nuestra tarea de Spark por medio de HADOOP_CONF_DIR. Podemos configurarlo como variable de entorno antes de ejecutar nuestro script de Spark submit o bien configurarlo como variable de entorno permanente en /etc/environment o /etc/profile. Conviene mencionar también que todas estas variables de entorno también se configuran en un script de shell de entorno al que recurren las tareas Spark al ejecutarse a través de Spark submit. El nombre de ese archivo es spark-env.sh y siempre está ubicado en el directorio «/etc/spark/conf» de los hosts de Spark. Aquí tenemos un ejemplo de cómo es este archivo de configuración del clúster:

En la próxima casilla, nos pregunta si queremos definir el directorio principal de Hadoop, puesto que a veces se necesita desde las tareas de Spark. En las tareas de Spark submit esta información también se envía de la misma manera, pero el nombre de la variable de entorno es HADOOP_HOME. En una tarea de Talend Spark, las casillas cumplen la misma función que el archivo «spark-env.sh» para el script de Spark submit, que extrae esos valores a tiempo de ejecución de su tarea de Spark.

Para terminar con la categoría de configuración de Spark Configuration en Talend, la última opción que le aparece define el nombre del host o la dirección de IP del controlador de Spark. Se trata de una opción útil cuando el sistema desde el que se ejecuta la tarea de Spark utiliza IP internas y externas o se producen incidencias con la resolución del nombre del host que podrían causar problemas cuando el maestro y los ejecutores de Spark intenten volver a conectarse al controlador de Spark.

Por defecto, si esta opción no se especifica, intentará utilizar el nombre de host local y resolverá su dirección de IP. Como decíamos en la publicación anterior, Talend ahora utiliza el modo cliente de YARN para que el controlador de Spark se ejecute siempre en el sistema desde el que se inicia la tarea de Spark. Ahora, en la comparación con las opciones que ofrece Spark submit, esto se especificaría utilizando «--conf» y luego indicaríamos el siguiente par clave/valor: «spark.driver.host=127.0.0.1». Con esto terminamos la correlación de opciones del submenú de configuración de la pestaña Spark Configuration.

Authentication (Autenticación)

En la categoría de autenticación se nos da la opción de seleccionar el método de autenticación que utilizará nuestro clúster de Hadoop:

Si no marcamos nada en esta categoría, nuestra tarea dará por hecho que el clúster utilizará una autenticación simple e intentará conectar con nuestro clúster de Hadoop usando el nombre de usuario que indiquemos allí. En el caso de Spark submit, esta información se indicará en la configuración de Spark para aplicaciones que estemos enviando.

Si seguimos y marcamos la opción de «Use Kerberos authentication» (Usar autenticación Kerberos), nos pedirá que añadamos la siguiente información:

Los dos primeros campos son los nombres de entidad de seguridad de servicio que utiliza el administrador de recursos y el servicio de historial de tareas. Si no está marcada la opción de usar una «keytab» o tabla de claves, cuando la tarea se ejecute buscará la memoria caché Kerberos de tickets en el sistema bajo el que se esté ejecutando y buscará en la caché concreta del usuario que inició la tarea los tickets Kerberos válidos para usar.

Si está marcada la opción «keytab», tendrá que indicar qué keytab se utilizará junto con el nombre de entidad de seguridad del usuario para el que se emita. De esta forma cuando empiece la tarea generará un ticket de Kerberos a partir de esa keytab para el principal que la tarea utilizará. En el caso de Spark submit, en su aplicación enviaría la configuración de Spark que estableció en el código en el que se utilice Kerberos a efectos de autenticación. Antes de ejecutar por Spark submit, ejecutaría el comando kinit de Kerberos para generar un ticket si no utiliza ninguna keytab, o si se utiliza una keytab puede o bien ejecutar el comando kinit con las alertas necesarias para utilizar una keytab para la generación de tickets o en su código de aplicación de Spark que especifique para iniciar sesión desde la keytab.

Tuning (Ajuste)

Pasemos a la categoría de «Tuning» (Ajuste) de Talend, que ofrece la opción «Set tuning properties» (Configurar propiedades de ajuste), que por defecto no aparece nunca marcada. Cuando «Set tuning properties» (Configurar propiedades de ajuste) está marcada, se nos saluda automáticamente con las siguientes opciones:

Veamos a qué equivalen todas estas opciones en Spark submit.

La primera opción es «Set application master tuning properties»(Configurar las propiedades de ajuste maestras de la aplicación), que permite a un usuario configurar la cantidad de memoria y el número de núcleos que el maestro de aplicaciones de YARN debería utilizar.

La finalidad de la instancia del maestro de aplicaciones de YARN es efectuar la negociación de los recursos desde el administrador de recursos y luego comunicarse con los administradores de nodo para hacer el seguimiento del uso de recursos y ejecutar contenedores. Si esta opción no está configurada, por defecto se asignará al maestro de aplicaciones de YARN 512 m y 1 núcleo. Buscando la equivalencia al envío como opción a Spark submit, utilizaríamos la opción «--conf» y luego le enviaríamos los dos siguientes pares de clave/valor: «spark.yarn.am.memory=512m,spark.yarn.am.cores=1».

También podemos establecer varios ajustes más, como el número de ejecutores, la cantidad de memoria en cada ejecutor, núcleos por ejecutor y también la cantidad de memoria general que puede asignarse por ejecutor en las próximas opciones.

Los valores por defecto son 1 g por memoria de ejecutor, 1 núcleo por ejecutor, el overhead de memoria por ejecutor por defecto será del 10 % de la memoria del ejecutor utilizada, con un mínimo de 384 m y se solicitarán 2 ejecutores. Como equivalencia de cómo se enviaría en Spark submit como opción, tenemos dos formas distintas de ejecutar. Una es utilizar como lo hemos hecho en el ejemplo anterior el comando de Spark submit de arriba: «--executor-memory 5G --num-executors 10» o podemos enviarlos mediante la opción «--conf» y luego usar los siguientes pares de clave/valor: «spark.executor.instances=2, spark.executor.cores=1, spark.executor.memory=2, spark.yarn.executor.memoryOverhead=384m».

La próxima opción que vemos disponible nos pregunta sobre la asignación de recursos de YARN:

Las opciones que tenemos son Auto (Automática), Fixed (Fija) y Dynamic (Dinámica), pero ¿qué significan? Spark nos ofrece la posibilidad de elegir cómo queremos que se asignen los ejecutores.

Si lo dejamos en Auto, vemos que la opción para determinar la cantidad de ejecutores que mencionamos antes desaparece, puesto que utilizará el valor por defecto asignado por YARN, que como dijimos es de 2 ejecutores. Si lo pasamos a Fixed, veremos que se nos da la opción de fijar la cantidad de ejecutores que queremos que nuestra tarea solicite. La última opción es Dynamic, que nos da la posibilidad de utilizar el mecanismo que proporciona Spark para ajustar dinámicamente los ejecutores asignados a nuestra tarea de Spark según lo que necesitemos en el tiempo de ejecución. Esto significa que nuestra aplicación, mientras se esté ejecutando, podría solicitar más ejecutores, si los necesitara, y liberarlos y devolverlos a YARN cuando no los utilice. Veremos que, cuando está seleccionada esta opción, presenta la siguiente configuración:

Ahora podemos seleccionar cuántos ejecutores solicitaremos a YARN en un primer momento y luego podemos especificar los ejecutores mínimos que puede tener la tarea y la cantidad máxima, dependiendo de la carga de trabajo de nuestra tarea cuando la ejecutemos en Spark. Para escoger la opción dinámica en Spark submit, deberá utilizar la opción «--conf» y luego los siguientes pares de clave/valor: «spark.dynamicAllocation.enabled=true, spark.shuffle.service.enabled=true». Según la documentación de Spark (https://spark.apache.org/docs/1.6.1/job-scheduling.html#dynamic-resource-allocation target="_blank"), se requieren esas dos propiedades para usar esta funcionalidad.

Si pasamos a la categoría de ajuste de la pestaña Spark Configuration de Talend, la próxima casilla es «Set Web UI port». Si lo selecciona, le da la opción de indicar un puerto, que por defecto es «4040». El propósito de esta opción es que, cuando se está ejecutando su aplicación de Spark, el controlador de Spark arranca una IU web que puede emplearse para hacer el seguimiento de su tarea Spark en ejecución e inspeccionar la ejecución de la tarea. Si esta opción no está seleccionada, seguirá su camino, empezará con el puerto por defecto mencionado antes y seguirá aumentando de número de puerto hasta que encuentre uno abierto. Esta opción se utilizaría normalmente si usted sabe que el puerto 4040 no está disponible en el sistema donde está ejecutando su tarea de Spark y quiere especificar un puerto en concreto, en lugar de que la aplicación de Spark intente encontrar un puerto abierto. En cuando a configurar esta opción en Spark submit, deberá utilizar la opción «--conf» y luego el siguiente par de clave/valor: «spark.ui.port=4041».

La próxima opción que tenemos disponible para seleccionar es «Broadcast Factory» (Fábrica de difusión) y vemos que para esta nos ofrecen varias opciones:

¿Qué hace esta «Broadcast Factory»? La responsabilidad de difusión en las aplicaciones de Spark consiste en difundir variables entre los ejecutores de su clúster. La idea es que la variable pueda distribuirse de forma rápida y eficiente en lugar de que lo haga todo un único nodo. Como hemos visto, en este caso nos dan tres opciones a elegir. La primera opción es Auto (Automática), que utiliza los valores por defecto. La segunda y tercera opción nos permiten seleccionar entre usar Torrent o HTTTP como fábrica de difusión. En Spark submit esto se enviaría con la opción «--conf» y luego usaríamos el siguiente par clave/valor «spark.broadcast.factory=org.apache.spark.broadcast.TorrentBroadcastFactory» si no queremos que se utilice el valor por defecto, que suelen ser Torrent.

La última opción que nos dan de la categoría Ajuste es personalizar el serializador de Spark que utilizaremos:

La importancia de la serialización en Spark, como se recoge en la documentación de Spark (https://spark.apache.org/docs/latest/tuning.html#data-serialization), consiste en serializar los datos entre ejecutores para aumentar el rendimiento en un entorno distribuido. Por defecto, si esta opción no está seleccionada, Talend configurará la serialización a utilizar como serialización Kryo, que se considera la más eficiente. Si queremos usar la misma opción idéntica en Spark submit, utilizaríamos la opción «--conf» y luego indicaríamos el siguiente par clave/valor: «spark.serializer=org.apache.spark.serializer.KryoSerializer». Si no se especifica esta opción en Spark submit, se usará el serializador de Java por defecto y, si se utiliza Spark SQL Thrift Server, por defecto escogerá Kryo.

Spark History (Historial de Spark)

Pasemos a continuación a la última categoría: «Spark History» (Historial de Spark). Si habilitamos el registro en Spark, veremos que se nos dan las siguientes opciones:

Cuando tenemos habilitado el Registro de incidencias, se nos da la opción de indicar un directorio en HDFS en el que el servidor de Spark History podrá leer los archivos de historial de tareas e indicar la dirección del servidor History. En Spark submit, para habilitarlo, tendrá que enviar los siguientes pares de clave/valor a la opción «--conf» y configurarlos, en concreto: «spark.eventLog.enabled=true,spark.eventLog.dir=hdfs://namenode_host:namenode_port/user/spark/applicationHistory,spark.yarn.historyServer.address=http://spark_history_server:history_port».

Configuración adicional

Ahora que hemos repasado todas las categorías de la pestaña Spark Configuration, veremos que nos quedan tres posibles opciones. La primera es el «directorio “scratch” de Spark». Esta opción especifica el directorio scratch que se empleará en el disco local de su sistema, en el que se inicia la tarea de Spark mientras su aplicación se ejecuta. Si usáramos Spark submit, utilizaríamos «--conf» y luego enviaríamos «spark.local.dir=/tmp». Si no indicamos nada, por defecto se utiliza el directorio /tmp.

La próxima opción se emplea para activar puntos de verificación en Spark. Esto da a nuestra tarea de Spark la capacidad de recuperarse desde un punto concreto en el tiempo de producirse un fallo. Cuando está activada, observaremos que da la oportunidad de indicar un directorio bien en el sistema de archivos local bien en HDFS para ir guardando a medida que progresa la tarea. Si quisiéramos habilitarlo en Spark submit, tendríamos que seguir los pasos indicados en la documentación de Spark en nuestro código de Spark. En la documentación de Spark se nos da un ejemplo, que encontrará en esta página (https://spark.apache.org/docs/1.6.0/streaming-programming-guide.html#checkpointing).

La última opción son Advanced Properties (Propiedades avanzadas). En esta opción podemos añadir cualquier propiedad de Spark que deseemos enviar en nuestra aplicación en un par de clave/valor. Es lo mismo que haríamos usando Spark submit, pero en ese caso se enviarían en la opción «--conf».

Por cierto, si analiza más de cerca su clúster de Hadoop y uno de los nodos de Spark Gateway, observará que muchas de las selecciones por defecto mencionadas ya aparecen indicadas en un fichero específico llamado spark-defaults.conf que se utilizará al ejecutar Spark submit. Encontrará este archivo en «/etc/spark/conf». Si abre el archivo verá que contiene la mayoría de las propiedades de las que hemos hablado. Igualmente, podrá anularlas como he sugerido, enviándolas como opciones en su Spark submit. He aquí un ejemplo:

Conclusión

Talend ofrece todas las opciones diferentes que permiten configurar su aplicación de Spark y facilita la elección mediante casillas y menús desplegables para poder indicar las opciones que desea utilizar y los valores por defecto que se utilizarán. Le animo a echar un vistazo a las distintas opciones de ajuste de sus tareas de Talend Spark y se dará cuenta de lo fácil que resulta configurarlas y optimizarlas para su entorno.

Referencias

https://spark.apache.org/docs/latest/submitting-applications.html

https://spark.apache.org/docs/1.6.0/streaming-programming-guide.html#checkpointing

https://spark.apache.org/docs/latest/tuning.html#data-serialization

https://spark.apache.org/docs/1.6.1/job-scheduling.html#dynamic-resource-allocation

Join The Conversation

0 Comments

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *