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.

[Hadoop] Rack Awareness

Rack Awareness / Rack Topology
http://www.slideshare.net/tutorialvillage/hadoop-hdfs-concepts

Los scripts de topología son usados por Hadoop para determinar la localización de los nodos que lo forman. Esta información, a su vez, es usada a la hora de llevar a cabo la replicación de los bloques de datos así como por el JobTracker al asignar tareas a los nodos.

La política por defecto de Hadoop para replicar (factor 3) los bloques a groso modo es la siguiente: Almacena el primer bloque en un nodo, ej. N1 ubicado en el rack1; A continuación replica ese bloque en un nodo diferente a su vez hayado en otro rack, ej. N2 y rack2; La tercera réplica la realiza sobre otro nodo, pero en este caso ubicado en el mismo rack que el primero, ej. N3 y rack1. En el caso de haberse definido un mayor número de réplicas, éstas serán aleatoriamente asignadas a otros nodos.

Rack topology viene a definir cómo físicamente las máquinas están conectadas en racks en nuestro CPD, proporcionando un conocimiento sobre como de cerca o lejos están nuestros nodos, los unos de los otros, hablando siempre en términos de conectividad de red. La comprensión de este punto puede llegar a ser especialmente crítico cuando hablamos o planteamos dominios de fallo en nuestro sistema.

A continuación se muestran los pasos necesarios para implementar esta funcionalidad. Parto de un pequeño clúster de pruebas formado por:

• vlihdp01.domain => NameNode y DataNode
• vlihdp02.domain => DataNode
• vlihdp03.domain => DataNode

HADOOP: home & version

Lo primero será crear un fichero, /opt/hadoop/etc/hadoop/topology.csv, en donde definiremos la relación de nodos que forman nuestro clúster Hadoop con respecto la localización o rack al que pertenecen.

topology.csv

A continuación crearemos un script, 100% personalizable, que a partir del fichero anterior nos devuelva el rack al que pertenece un nodo o lista de nodos pasados como argumentos. Podéis usar el del siguiente enlace ó bien el aquí mostrado a continuación y obtenido del libro Hadoop Operations:

$ vim /opt/hadoop/etc/hadoop/topology.py
#!/usr/bin/python

import sys

class RackTopology:
  # Make sure you include the absolute path to topology.csv.
  DEFAULT_TOPOLOGY_FILE = '/opt/hadoop/etc/hadoop/topology.csv'
  DEFAULT_RACK = '/default-rack'
  def __init__(self, filename = DEFAULT_TOPOLOGY_FILE):
    self._filename = filename
    self._mapping = dict()

    self._load_topology(filename)

  def _load_topology(self, filename):
    '''
    Load a CSV-ish mapping file. Should be
    hostname or IP and the second the rack
    it's discarded. Each field is stripped
    the file fails to load for any reason,
    '''
    try:
      f = file(filename, 'r')

      for line in f:
        fields = line.split(',')

        if len(fields) == 2:
          self._mapping[fields[0].strip()] = fields[1].strip()
    except:
      pass

  def rack_of(self, host):
    '''
    Look up and a hostname or IP address in the mapping and return its rack.
    '''
    if self._mapping.has_key(host):
      return self._mapping[host]
    else:
      return RackTopology.DEFAULT_RACK

if __name__ == '__main__':
  app = RackTopology()

  logFile = open('/tmp/topology.log', 'a')
  for node in sys.argv[1:]:
    rack = app.rack_of(node)
    logFile.write(node + ' => ' + rack + '\n')
    print rack

  logFile.close()

¡Importante! Asegurarse que la variable DEFAULT_TOPOLOGY_FILE quede correctamente configurada con el path completo del archivo anteriormente creado con la topología de nuestros nodos. En mi caso: /opt/hadoop/etc/hadoop/topology.csv

Lo siguiente será darle permisos de ejecución a dicho script:

$ chmod 755 /opt/hadoop/etc/hadoop/topology.py

Podemos realizar una serie de pruebas de su correcto funcionamiento:

$ python /opt/hadoop/etc/hadoop/topology.py vlihdp01.domain

/rack1

$ python /opt/hadoop/etc/hadoop/topology.py vlihdp02.domain

/rack1

$ python /opt/hadoop/etc/hadoop/topology.py vlihdp03.domain

/rack2

$ python /opt/hadoop/etc/hadoop/topology.py vlihdp01.domain vlihdp02.domain vlihdp03.domain

/rack1

/rack1

/rack2

Por último, toca modificar la configuración, core-site.xml, de Hadoop. Para ello añadiremos el parámetro net.topology.script.file.name y estableceremos su valor al path completo del script recien creado:

core-site.xml

Ya sólo quedar comprobar su correcto funcionamiento.

$ hadoop dfsadmin -printTopology
DEPRECATED: Use of this script to execute hdfs command is deprecated.
Instead use the hdfs command for it.

15/11/25 22:55:42 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Rack: /rack1
   10.0.3.11:50010 (vlihdp01.domain)
   10.0.3.12:50010 (vlihdp02.domain)

Rack: /rack2
   10.0.3.13:50010 (vlihdp03.domain)

$ hadoop dfsadmin -report
DEPRECATED: Use of this script to execute hdfs command is deprecated.
Instead use the hdfs command for it.

15/11/25 22:57:53 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Configured Capacity: 144813367296 (134.87 GB)
Present Capacity: 132053340160 (122.98 GB)
DFS Remaining: 132053200896 (122.98 GB)
DFS Used: 139264 (136 KB)
DFS Used%: 0.00%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0

-------------------------------------------------
Live datanodes (3):

Name: 10.0.3.13:50010 (vlihdp03.domain)
Hostname: vlihdp03.domain
Rack: /rack2
Decommission Status : Normal
Configured Capacity: 48271122432 (44.96 GB)
DFS Used: 49152 (48 KB)
Non DFS Used: 4243726336 (3.95 GB)
DFS Remaining: 44027346944 (41.00 GB)
DFS Used%: 0.00%
DFS Remaining%: 91.21%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Xceivers: 1
Last contact: Thu Nov 25 22:57:53 CET 2015


Name: 10.0.3.12:50010 (vlihdp02.domain)
Hostname: vlihdp02.domain
Rack: /rack1
Decommission Status : Normal
Configured Capacity: 48271122432 (44.96 GB)
DFS Used: 49152 (48 KB)
Non DFS Used: 4243742720 (3.95 GB)
DFS Remaining: 44027330560 (41.00 GB)
DFS Used%: 0.00%
DFS Remaining%: 91.21%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Xceivers: 1
Last contact: Thu Nov 25 22:57:54 CET 2015


Name: 10.0.3.11:50010 (vlihdp01.domain)
Hostname: vlihdp01.domain
Rack: /rack1
Decommission Status : Normal
Configured Capacity: 48271122432 (44.96 GB)
DFS Used: 40960 (40 KB)
Non DFS Used: 4272558080 (3.98 GB)
DFS Remaining: 43998523392 (40.98 GB)
DFS Used%: 0.00%
DFS Remaining%: 91.15%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Xceivers: 1

Last contact: Thu Nov 25 22:57:53 CET 2015

[HowTo] Create a Simple Hadoop Cluster with VirtualBox

Entorno Propuesto

Me gustaría compartir con todos vosotros este gran tutorial que publicaron en el blog de Cloudera sobre cómo crear en CentOS un cluster de Hadoop gracias a su propia herramienta, Cloudera, y VirtualBox.

http://blog.cloudera.com/blog/2014/01/how-to-create-a-simple-hadoop-cluster-with-virtualbox/

Este entorno que nos proponen podría llegar a servirnos como un buenísimo entorno de desarrollo o preproducción.

Lógicamente depende un poco de las características de las máquinas que dispongamos, pero yo haría algunas modificaciones:

• Hadoop1: 2 cpu's.
• Hadoop2, Hadoop3 y Hadoop4: 4 GB RAM.
• En caso de ser posible aumentar en todos ellos los espacios en disco, yo me iría a los 80GB, al menos en el Hadoop1.