Dentro del conjunto de herramientas que AWS ofrece para Big Data, EMR es una de las más versátiles y potentes, poniendo a disposición del usuario un sinfín de opciones de hardware y software con el fin de enfrentar – con todo éxito- cualquier desafío relacionado con el procesamiento de grandes volúmenes de datos.
Sin embargo, un usuario que se encuentra ante la consola de EMR por primera vez encuentra que las opciones se encuentran empaquetadas en una lista -generosa, pero limitada- de configuraciones de software y hardware, y quizás sacar la conclusión -errónea!- de que EMR no tiene lo necesario para la tarea.
Consola Web: Creando un Cluster de EMR
En este artículo nos enfocaremos en estudiar cómo incorporar elementos de software adicionales y/o distintos a los ofrecidos en el paquete de la consola Web, y dejaremos las configuraciones de Hardware y otras opciones para otra oportunidad.
Líder contra Esclavo
Uno de los primeros desafíos para entender cómo incorporar software a EMR es tener claridad acerca de la infraestructura de hardware y software que da soporte a EMR. En términos muy sencillos, existen simplemente dos categorías: Líder y Esclavo (Lider + Esclavos = Cluster).
Map-Reduce es un modelo de programación que se beneficia de la capacidad de “dividir para conquistar”, utilizar cargas de trabajo para los múltiples nodos del clúster, distribuyendo y organizando las tareas de cada nodo de modo que un gran trabajo se vuelve múltiples trabajos pequeños, normalmente más fáciles y rápidos de completar comparados con intentar abordar el trabajo como una unidad.
Modelo programático de EMR
En este modelo cada nodo recibe una carga de trabajo, para trabajar luego en ella, y finalmente entrega un resultado que es consolidado por el nodo líder.
Cluster EMR: Nodo Líder y Nodos Esclavos trabajan en conjunto para resolver el trabajo según algoritmos Map-Reduce
Para que todo esto funcione, el software incorporado en los nodos esclavos debe estar “de acuerdo” con el software del nodo líder, y así poder “conversar” adecuadamente durante la ejecución del trabajo del clúster.
Cuando nos conectamos al clúster, normalmente lo que hacemos es conectarnos al nodo líder, ya través de este llevamos a cabo la ejecución del trabajo. Es en este mismo nodo líder donde podemos tomar control remoto vía SSH, y realizar actividades a nivel de sistema operativo, como -por ejemplo- instalar nuevo software, o alterar la configuración del software ya instalado.
Sin embargo, es imprescindible tener presente que el nodo líder no replica ni distribuye estas modificaciones al resto de los nodos del clúster, por lo que si instalamos una nueva librería -como por ejemplo Boto3- esta sólo estará disponible en el nodo Líder, dejando a los nodos Esclavos incapaces de abordar tareas que requieren de esta librería, y luego cualquier trabajo que la requiera fallará en ejecutarse.
La lección que debemos sacar es muy sencilla: el software se debe instalar y configurar ANTES de que exista el clúster. De lo contrario, los cambios de configuración, y el software instalado, sólo estarán disponibles en el nodo Líder.
¿Cómo? Pues muy simple: con acciones de bootstrap.
arranque
Bueno, puede no resultar tan simple en un comienzo, especialmente si no están acostumbrados a realizar scripts de Bash en Linux. Sin embargo eso es, a grandes características, el único desafío para comenzar a trabajar con EMR y Acciones de Bootstrap.
Las Acciones de Bootstrap son suficientes scripts de Bash para Linux, que automatizan la ejecución de pasos de instalación o manejo de configuración del software instalado y del sistema operativo en general.
Una súper-simplificación de lo anterior es: cada paso que realizaría un humano al mando de una consola de SSH en Linux, es posible llevar a una línea de un script de Bash, que se puede ejecutar de forma automática, sin supervisión humana.
Por ejemplo, para instalar Boto3:
sudo pip install -U
awscli
boto
Luego, esto se convierte en un script de Bash. Llamemos a este archivo install_boto3.sh:
#!/bin/bash
sudo pip install -U
awscli
boto
Y finalmente lo guardamos en S3:
s3://mi_bucket/scripts/install_boto3.sh
Sencillo, ¿verdad?.
Ahora sólo resta referenciar este script en una acción de Bootstrap desde la configuración durante la creación del clúster. Para esto, hay básicamente dos opciones (hay más opciones para lanzar un clúster, pero estas son las dos más utilizadas):
1. Uso de la consola Web
Siguiendo las opciones avanzadas, en el paso 3 de la configuración durante la creación del clúster, abra la sección de Acciones de Bootstrap (Bootstrap Actions)
Aparecerán las opciones para referenciar el guión que ya tenemos en S3:
Y finalmente sólo resta lanzar la creación del clúster, continuando los pasos restantes de configuración.
2. Uso de la CLI de AWS
Esta es la opción más fácil de controlar y ejecutar. Requiere tener la AWS CLI apropiadamente instalada y configurada con nuestra cuenta de AWS. Basta ejecutar con nuestro CLI la siguiente línea de comandos:
aws emr create-cluster
–applications Name=Hadoop Name=Hive Name=Pig Name=Hue Name=Spark Name=Zeppelin
–ec2-attributes ‘{«KeyName»:»mi_cluster»,»InstanceProfile»:»EMR_EC2_Profile»,» SubnetId»:»subnet-XXXXXXXXX»,»EmrManagedSlaveSecurityGroup»:»sg-XXXXXXXXX»,»EmrManagedMasterSecurityGroup»:»sg-XXXXXXXXX»}’
–release-label emr-5.12.0
–log-uri ‘s3n:// aws-logs-XXXXXXXXXXXXXXX-us-east-1/elasticmapreduce/’
–steps ‘[{«Args»:[«spark-submit»,»–deploy-mode»,»cluster»,»–driver-cores «,»1″,»–maximizeResourceAllocation»,»s3://mi_bucket/scripts/mi_script_python.py»],»Tipo»:»CUSTOM_JAR»,
«ActionOnFailure»:»CANCEL_AND_WAIT»,»Jar»:»command-runner.jar»,»Properties»:»»,»Name»:»Mi Programa Spark»}]’ –instance-groups ‘[{«InstanceCount» :4,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»CORE» ,»InstanceType»:
«r4.xlarge»,»Name»:»Core – 2″},{«InstanceCount»:1,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32 ,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»MASTER»,»InstanceType»:
«r4.xlarge»,»Name»:»Master – 1″}]’
–bootstrap-actions ‘[{«Path»:»s3://mi_bucket/scripts/install-boto3. sh»,»Name»:»Instalar Boto3″}]’
–ebs-root-volume-size 50
–service-role EMR_Role
–enable-debugging
–name ‘mi_aplicacion’
–scale-down-behavior TERMINATE_AT_TASK_COMPLETION
–region us-east-1
Cabe resaltar que este comando es una sola línea de texto , que aquí hemos separado en varias líneas para facilitar la lectura.
Hay varios parámetros que son opcionales (ej: –enable-debugging ) y otros que dependen de los recursos de infraestructura de su propia cuenta de AWS (ej: IDs de grupos de seguridad, nombres de perfiles de instancia como “ EMR_EC2_Profile ” y roles de servicio, como –service-role EMR_Role , entre otros).
Puede parecer un tanto difícil de manejar al principio, pero en la práctica es la opción más fácil y rápida de lanzar un clúster, y con el tiempo es fácil acostumbrarse.
3. Recursos Públicos
Como no siempre somos los primeros en enfrentar un problema, la mayoría de las veces es posible encontrar a alguien que haya resuelto el problema antes que nosotros. Y buena parte de esas veces, ese alguien ha sido tan amable de dejar la solución disponible para ser reutilizada. Así es como encontramos scripts de bootstrap para AWS EMR que se pueden utilizar directamente, para lograr ciertos objetivos, como por ejemplo instalar Jupyter Notebook en nuestro clúster de EMR .
El script se actualiza constantemente, y se puede encontrar bajo la ruta de S3:
s3://aws-bigdata-blog/artifacts/aws-blog-emr-jupyter/install-jupyter-emr5.sh
Espero que esta información les resulte útil, y les facilite el acceso a esta genial tecnología de AWS.
Saludos!
marcelo
