XGBOOST & Hadoop/YARN (II): Ejemplo

En la anterior entrada vimos cómo instalar la librería XGBOOST sobre CentOS con soporte HDFS. Bien, en ésta trataremos de ver su ejecución a través de algún ejemplo, eso sí, sin entrar a valorar el resultado o si se puede mejorar el modelo, variables, etc, simplemente se trata de demostrar la funcionalidad de poder ejecutar la librería XGBOOST en modo distribuido.

DMLC-YARN.JAR
Lo primero que deberemos hacer es crear el paquete dmlc-yarn.jar necesario para la ejecución de XGBOOST en modo distribuido, YARN.

     cd /usr/local/xgboost/dmlc-core/tracker/yarn/
     ./build.sh // NO preocuparse por los warnings.

     ls -al dmlc-yarn.jar // Debemos comprobar que se crea el fichero dmlc-yarn.jar
     rw-r--r-- 1 root root 21292 dic 16 13:39 dmlc-yarn.jar

Ejemplo

Ejemplo de cómo ejecutar XGBOOST en modo YARN con los conjuntos de datos almacenados previamente en HDFS. Además, el modelo resultante también será salvado en el HDFS.

Nota: El ejemplo mostrado a continuación fue ejecutado bajo el usuario root, totalmente desaconsejable su uso, pero así que cada uno lo adapte a su entorno ;)

1) Creo la estructura de directorios necesarios para el ejemplo en el HDFS:

     hadoop fs -mkdir /user/root/xgboost

     hadoop fs -mkdir /user/root/xgboost/data

     hadoop fs -mkdir /user/root/xgboost/data/train

     hadoop fs -mkdir /user/root/xgboost/data/test

     hadoop fs -mkdir /user/root/xgboost/model

     hadoop fs -chmod 777 /user/root/xgboost/model

2) Cargo los siguientes datasets de ejemplo que vienen, por defecto, con XGBOOST.

     hadoop fs -put /usr/local/xgboost/demo/data/agaricus.txt.train /user/root/xgboost/data/train/

     hadoop fs -put /usr/local/xgboost/demo/data/agaricus.txt.test /user/root/xgboost/data/test/

3) Creo la configuración necesaria para llevar a cabo el ejemplo.

     export LD_LIBRARY_PATH=/usr/hdp/2.4.2.0-258/usr/lib/

     vim /usr/local/xgboost/demo/distributed-training/hdfs.conf

          # General Parameters, see comment for each definition

          # choose the booster, can be gbtree or gblinear

          booster = gbtree

          # choose logistic regression loss function for binary classification

          objective = binary:logistic

          # Tree Booster Parameters

          # step size shrinkage

          eta = 1.0

          # minimum loss reduction required to make a further partition

          gamma = 1.0

          # minimum sum of instance weight(hessian) needed in a child

          min_child_weight = 1

          # maximum depth of a tree

          max_depth = 3

          # Task Parameters

          # the number of round to do boosting

          num_round = 2

          # 0 means do not save any model except the final round model

          save_period = 0

          # The path of training data

          data = "hdfs://namenode01.domain.com/user/root/xgboost/data/train"

          # The path of validation data, used to monitor training process

          eval[test] = "hdfs://namenode01.domain.com/root/xgboost/data/test"

          model_dir = "hdfs://namenode01.domain.com/user/root/xgboost/model"

          # evaluate on training data as well each round

          eval_train = 1

¡¡¡Importante!!! Incluir en el path del HDFS el FQDN de nuestro NameNode principal o bien el del grupo si hemos configurado la alta disponibilidad.

4) Ahora ya sí, se puede proceder a ejecutar el ejemplo:

/usr/local/xgboost/dmlc-core/tracker/dmlc-submit --cluster yarn --num-workers 2 /usr/local/xgboost/xgboost /usr/local/xgboost/demo/distributed-training/hdfs.conf

2016-12-16 13:43:19,708 INFO start listen on 192.168.4.245:9091

16/12/16 13:43:21 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable

16/12/16 13:43:22 WARN shortcircuit.DomainSocketFactory: The short-circuit local reads feature cannot be used because libhadoop cannot be loaded.

16/12/16 13:43:23 INFO impl.TimelineClientImpl: Timeline service address: http://namenode01.domain.com:8188/ws/v1/timeline/

16/12/16 13:43:23 INFO client.RMProxy: Connecting to ResourceManager at namenode01.domain.com/192.168.4.245:8050

16/12/16 13:43:24 INFO dmlc.Client: jobname=DMLC[nworker=2]:xgboost,username=root

16/12/16 13:43:24 INFO dmlc.Client: Submitting application application_1481716095353_0075

16/12/16 13:43:24 INFO impl.YarnClientImpl: Submitted application application_1481716095353_0075

2016-12-16 13:43:29,410 INFO @tracker All of 2 nodes getting started

2016-12-16 13:43:33,723 INFO [13:43:33] [0] test-error:0.016139 train-error:0.014433

2016-12-16 13:43:33,904 INFO [13:43:33] [1] test-error:0.000000 train-error:0.001228

2016-12-16 13:43:34,253 INFO @tracker All nodes finishes job

2016-12-16 13:43:34,253 INFO @tracker 4.84310793877 secs between node start and job finish

Application application_1481716095353_0075 finished with state FINISHED at 1481888615119

5) Comprobar la existencia del modelo recién creado. El nombre del fichero, por defecto, sigue el patrón <num_rounds>.model siendo <num_rounds> el valor establecido para dicha variable en el fichero de configuracion.

     hadoop fs -ls /user/root/xgboost/model

     Found 1 items

     -rw-r--r-- 2 yarn root 1501 2016-12-16 13:43 /user/root/xgboost/model/0002.model

El modelo puede ser cargado posteriormente en R, Python o Julia.

XGBOOST & Hadoop/YARN (I)

Este primer tutorial trata de explicar los pasos necesarios para desplegar la librería XGBOOST sobre CentOS con soporte HDFS, y más concretamente sobre un clúster Hadoop / YARN, pues pese a existir la "Installation Guide" en su página principal sobre cómo hacerlo, ésta 'sólo' cubre los sistemas operativos Ubuntu/Debian, Windows y OSX.

Entorno

Antes de pasar a realizar cualquier tipo de acción, me gustaría detallar cual es el entorno sobre el que voy a trabajar y desplegar la librería XGBOOST,

• CentOS 6.7
• Hortonworks Data Platform (HDP) v.2.4.2 => Hadoop v2.7.1

Requisitos

G++ >= 4.6

Decir que CentOS 6.7 dispone de un compilador GCC y G++ bastante 'desactualizados' en sus repositorios oficiales, por lo que recurrí al siguiente procedimiento para la instalación de una versión 'más reciente' y superior incluso a la requerida:

     yum install wget git -y // En caso de no disponer previamente de estos paquetes

     cd /etc/yum.repos.d

     wget https://people.centos.org/tru/devtools-2/devtools-2.repo

Instalamos a continuación los siguientes paquetes:

     devtoolset-2-gcc.x86_64

     devtoolset-2-gcc-c++.x86_64

     devtoolset-2-gcc-plugin-devel.x86_64

     devtoolset-2-binutils.x86_64

     devtoolset-2-binutils-devel.x86_64

Una vez instalados, comprobar la versión desplegada:

     /opt/rh/devtoolset-2/root/usr/bin/gcc -v

     …

     gcc version 4.8.2 20140120 (Red Hat 4.8.2-15) (GCC)

Python v2.7

Además, en CentOS 6.7, por defecto, el Python incluido en los repositorios suele ser el de la versión 'obsoleta' 2.6.6, por lo que también deberemos actualizarla para poder trabajar posteriormente con la librería XGBOOST. Las versiones aceptadas por XGBOOST son Python 2.7 o superior, o Python 3.4 o superior.

En mi caso vamos a recurrir a la versión 2.7.6 de Python:

     yum -y install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel

     cd /opt

     wget --no-check-certificate https://www.python.org/ftp/python/2.7.6/Python-2.7.6.tar.xz

     tar xf Python-2.7.6.tar.xz

     cd Python-2.7.6

     ./configure --prefix=/usr/local

     make && make altinstall

¡¡¡Importante!!! Usar altinstall en lugar de install porque sino acabaremos con dos versiones diferentes de Python instaladas en nuestro sistema y ambas nombradas Python.

Tras este tipo de instalación convivirán en nuestro sistema ambas versiones:

     python -V

     Python 2.6.6

     python2.7 -V

     Python 2.7.6

Pip 2.7

Para facilitar las futuras instalaciones de paquetes de Python, es aconsejable también actualizar la versión de Pip.

     wget https://bitbucket.org/pypa/setuptools/downloads/ez_setup.py

     /usr/local/bin/python2.7 ez_setup.py

     /usr/local/bin/easy_install-2.7 pip

Comprobamos su correcto funcionamiento gracias a la instalación del paquete argparse que será necesario posteriormente para ejecutar y obtener la ayuda del comando xgboost.

     pip2.7 install argparse

Java

Debido a la instalación de la suite HDP de Hortonworks ya dispondremos de una versión de Java instalada en nuestro clúster, pero no viene mal repasar y asegurarse de su correcta instalación y configuración de las variables de entorno, $JAVA_HOME y $PATH.

[XGBOOST]
XGBOOST con soporte HDFS

Una vez cumplidos con los requerimientos, podemos pasar a construir la librería compartida de XGBOOST sobre CentOS con soporte HDFS.

     cd /usr/local
     git clone --recursive https://github.com/dmlc/xgboost

     cd xgboost

     cp make/config.mk ./config.mk

     vim config.mk // Descomentar las siguientes líneas y modificar su contenido de acuerdo a:

          export CC=/opt/rh/devtoolset-2/root/usr/bin/gcc

          export CPP=/opt/rh/devtoolset-2/root/usr/bin/cpp

          export CXX=/opt/rh/devtoolset-2/root/usr/bin/c++

          USE_HDFS = 1

     cd dmlc-core/

     cp make/config.mk config.mk

     vim config.mk // Descomentar las siguientes líneas y modificar su contenido de acuerdo a:

          export CC=/opt/rh/devtoolset-2/root/usr/bin/gcc

          export CPP=/opt/rh/devtoolset-2/root/usr/bin/cpp

          export CXX=/opt/rh/devtoolset-2/root/usr/bin/c++

          USE_HDFS = 1

     cd /usr/local/xgboost

     make clean_all
     make -j4

Para comprobar que se ha construido la librería satisfactoriamente, deberemos asegurarnos que se ha generado el archivo libxgboost.so, en nuestro caso:

     ls /usr/local/xgboost/lib/libxgboost.so

     -rwxr-xr-x 1 root root 2374684 dic 15 16:48 lib/libxgboost.so

Una vez finalizada su construcción satisfactoriamente, deberemos editar el fichero dmlc-submit para que use la versión 2.7 de Python en lugar de la 2.6. Para ello bastará con modificar la primera línea de dicho fichero:
     vim /usr/local/xgboost/dmlc-core/tracker/dmlc-submit

          #!/usr/bin/env python2.7

Problema hdfs.h / libdmlc.a

En un primer intento a la hora de construir la librería, me surgió el error que podéis observar más abajo. Realmente el fallo no se debe a la falta del archivo o libreria libdmlc.a. Observando con detenimiento un poco más arriba del comentado error, detecté otro fallo "hdfs.h: No existe el fichero o el directorio" el cual desencadena el error final.

Problema:
     In file included from src/io.cc:16:0:
     src/io/hdfs_filesys.h:10:18: fatal error: hdfs.h: No existe el fichero o el directorio
     #include <hdfs.h>
     …
     c++: error: dmlc-core/libdmlc.a: No existe el fichero o el directorio
     make: *** [lib/libxgboost.so] Error 1
     make: *** Se espera a que terminen otras tareas....

Solución: Me bastó con buscar la librería hdfs.h en el sistema y modificar la definición de la siguiente línea dentro del fichero de configuración dmlc.mk:
     vim /usr/local/xgboost/dmlc-core/make/dmlc.mk

          HDFS_INC_PATH=/usr/hdp/2.4.2.0-258/usr/include

Por útlimo, volvemos a ejecutar los comandos necesarios para construir la librería compartida de XGBOOST.

     make clean_all

     make -j4


[+Info] Para ver un ejemplo de su ejecución en modo YARN: XGBOOST & Hadoop/YARN (II): Ejemplo

[YARN] Error "java.io.ioexception couldn't set IO streams"

Esta semana me he topado con un problema en un cliente a la hora de lanzar numerosos procesos o aplicaciones de Spark. Todas ellas ejecutadas bajo modo YARN. La primera parte de dichas apps se ejecutaban y finalizaban para bien o para mal transcurrido un cierto tiempo, pero alcanzado un punto y sin saber el por qué, muchos de los nuevos trabajos que lanzaba finalizaban inmediatamente y de manera errónea. En un principio la única causa era la falta de recursos.

Esto no tenía lógica alguna, pues en caso de no haber recursos suficientes, los trabajos deberían quedarse en estado ACCEPTED y una vez el YARN fuera capaz de asignárselos pasar al estado RUNNING, vamos, quedar encolados, no morir directamente. Además, un simple top en los servidores o gracias a nuestra herramienta de monitorización demostraba la 'incoherencia' del mensaje.

Indagando más en los logs de la aplicación de Spark, para una mejor comprensión y visualización me apoyo en Livy, the REST Spark Server, llegué a observar el siguiente error: "java.io.ioexception couldn't set io streams". Ya tenía algo más de donde poder tirar.

Lo primero que hice fue revisar la configuración del usuario con el que se ejecutan los jobs o aplicaciones de Spark en cuanto a lo que respecta al uso o límites establecidos para el uso de recursos:

  # ulimit -a

  core file size          (blocks, -c) 0

  data seg size           (kbytes, -d) unlimited

  scheduling priority             (-e) 0

  file size               (blocks, -f) unlimited

  pending signals                 (-i) 63238

  max locked memory       (kbytes, -l) 64

  max memory size         (kbytes, -m) unlimited

  open files                      (-n) 1024

  pipe size            (512 bytes, -p) 8

  POSIX message queues     (bytes, -q) 819200

  real-time priority              (-r) 0

  stack size              (kbytes, -s) 8192

  cpu time               (seconds, -t) unlimited

  max user processes              (-u) 1024

  virtual memory          (kbytes, -v) unlimited

  file locks                      (-x) unlimited

¡Y voilà! En seguida algo llamó mi atención: max user processes (-u) 1024. Valor establecido demasiado bajo.

Traté de configurar dicho valor en "caliente", pero... quedó descartado:

  # ulimit -u 65536

  bash: ulimit: max user processes: no se puede modificar el límite: Operación no permitida

¡Ah! Y no aplica el intentarlo con sudo ;)

Tocaba pues, configurar los valores adecuados a través del fichero correspondiente. Bien, existen dos opciones:

1) /etc/security/limits.conf - Fichero de propiedades general.

2) /etc/security/limits.d/<userName>.conf - Fichero de propiedades relacionadas únicamente, o al menos debería ser así, con el usuario <userName>.

Básicamente estos ficheros sirven para controlar, limitar y/o repartir los recursos del sistema en caso de estar éste compartido entre diferentes usuarios y/o aplicaciones, evitando así que por ejemplo uno haga un uso excesivo de CPU viéndose perjudicado el resto de usuarios del sistema. Algo que en un entorno BigData con Hadoop y demás herramientas analíticas o de procesamiento, va a ser de lo más normal ;)

Si abrimos el primer fichero, veremos que se nos explica un poco la sintaxis del mismo.

  ...

  #Each line describes a limit for a user in the form:

  #

  #<domain>        <type>  <item>  <value>

  ...

  #        - nproc - max number of processes // para el caso que estamos tratando

  ...

Para un mejor entendimiento y/o administración o por una simple manía mía, soy partidario de la segunda opción.

Ahora bien, al trabajar sobre una plataforma con Cloudera, ya existía el fichero /etc/security/limits.d/cloudera-scm.conf por lo que para evitar tener que 'pensar' en los valores a establecer, decidí probar copiando dicha configuración a la del usuario correspondiente.

  # sudo cp /etc/security/limits.d/clouderascm.conf /etc/security/limits.d/spark-user.conf

Sino, una configuración posible sería:

  username soft nofile 32768

  username soft nproc 65536

  username hard nofile 1048576

  username hard nproc unlimited

  username hard memlock unlimited

  username soft memlock unlimited

Por último, para que los cambios tuvieran efecto, fue necesario reiniciar la máquina.

Una vez hecho esto, el sistema permitió una mayor carga de trabajo y donde antes daba el error "java.io.ioexception couldn't set io streams" ahora los trabajos eran encolados, estado ACCEPTED.