Introducción
Ha seguido Map, Shuffle y Reduce y comprobado una ejecución real de WordCount en modo local. La empresa minorista quiere ahora aplicar la misma regla de conteo a archivos de HDFS, utilizando los servicios de administración de recursos del entorno. La pregunta comercial sigue siendo la misma; cambia la organización del almacenamiento y la ejecución.
YARN administra recursos para las aplicaciones. Su ResourceManager coordina la asignación de recursos, mientras que un NodeManager administra la ejecución en una máquina de trabajo. Cada aplicación enviada tiene un ApplicationMaster que coordina su trabajo y ejecuta el trabajo en contenedores asignados, que son asignaciones de recursos con procesos en su interior. Estos contenedores de YARN no son necesariamente contenedores de Docker.
Enviará el JAR de WordCount preparado, identificará su aplicación real de YARN, examinará su estado completado y sus registros y comprobará los resultados de HDFS. Una segunda ejecución utilizará otra ruta de salida para que la entrada original y el primer resultado sigan disponibles. El laboratorio prepara sus propios datos e inicia los servicios; no necesita los archivos del laboratorio anterior ni conocimientos de programación en Java. Utilice Terminal.
Envíe el algoritmo conocido a YARN
En este paso, preparará la entrada de HDFS y enviará el mismo algoritmo WordCount utilizando el marco YARN configurado.
Comience en su espacio de trabajo local:
cd /home/labex/project
Lea la entrada preparada:
cat /home/labex/project/data/product-words.txt
Son las mismas seis líneas utilizadas para explicar el algoritmo. Los totales esperados siguen siendo folder=3, notebook=4 y pen=4. Cree un directorio de datos originales de HDFS con un directorio padre separado para los resultados:
hdfs dfs -mkdir -p /user/labex/yarn-batch/raw /user/labex/yarn-batch/results
Suba la entrada:
hdfs dfs -put /home/labex/project/data/product-words.txt /user/labex/yarn-batch/raw/product-words.txt
Ya ha aprendido que -put conserva el original local. El directorio raw de HDFS es la entrada del trabajo; results debe permanecer fuera de él para evitar leer salidas anteriores como entradas nuevas.
El JAR de ejemplo y el nombre wordcount no cambian respecto de la ejecución local. Esta vez, omita los ajustes que forzaban el modo local: la configuración instalada utiliza mapreduce.framework.name=yarn y HDFS como sistema de archivos predeterminado. Por tanto, ambos argumentos finales siguientes son rutas de HDFS. El trabajo crea su propio directorio de salida run-1, que no debe existir previamente:
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/yarn-batch/raw /user/labex/yarn-batch/results/run-1
Espere a que termine el comando. Imprime un ID de aplicación enviada, seguido del progreso del trabajo y un mensaje de finalización correcta. Los ID de aplicación y trabajo, los tiempos y el orden del progreso varían. No necesita captar un estado RUNNING instantáneo; las aplicaciones completadas todavía pueden examinarse.
Relacione el comando con las funciones:
El cliente envía la aplicación → ResourceManager asigna recursos
ApplicationMaster coordina el trabajo de MapReduce → NodeManager ejecuta contenedores
Las tareas leen entradas de HDFS → Las tareas escriben resultados en HDFS
Este sigue siendo un entorno de aprendizaje de una sola máquina. Las funciones de YARN son reales aunque sus procesos compartan una máquina. A continuación, solicitará a YARN evidencia directa de que la aplicación finalizó correctamente.
Examine la aplicación completada
En este paso, conservará el ID real de la aplicación y lo utilizará para consultar el estado y los registros agregados.
YARN asigna un ID de aplicación (Application ID) cuando acepta una aplicación. Es diferente de una ruta de HDFS o de un nombre de archivo de resultados. Liste todos los estados de aplicación, incluidas las aplicaciones completadas:
yarn application -list -appStates ALL
Este entorno nuevo tiene una aplicación enviada. Su tipo debería ser MAPREDUCE, su estado FINISHED y su estado final SUCCEEDED. FINISHED por sí solo no demuestra el éxito: el estado final también importa.
Guarde el ID real de la aplicación sin copiar un valor de un ejemplo. La siguiente tubería utiliza grep -o para imprimir únicamente la parte coincidente. En este patrón, [0-9]* coincide con las secuencias de dígitos de un ID de aplicación:
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/application-id.txt
Lea el ID guardado:
cat /home/labex/project/output/application-id.txt
Debería ver una línea que comienza con application_. El resto lo asigna este entorno; no utilice el ID de otro estudiante.
Para insertar ese valor guardado en un comando, $(cat ...) ejecuta cat y sustituye la expresión por su salida. Las comillas dobles mantienen unido el valor sustituido como un solo argumento. Consulte esa aplicación real:
yarn application -status "$(cat /home/labex/project/output/application-id.txt)"
Localice State, Final-State y Application-Type. Espere FINISHED, SUCCEEDED y MAPREDUCE. Guarde el informe:
yarn application -status "$(cat /home/labex/project/output/application-id.txt)" > /home/labex/project/output/application-status.txt
YARN también recopila los registros de los contenedores. El comando logs -applicationId los lee para la aplicación seleccionada. Guarde los registros localmente para poder examinar una parte manejable:
yarn logs -applicationId "$(cat /home/labex/project/output/application-id.txt)" > /home/labex/project/output/application.log
Utilice el comando local tail -n 20 para mostrar las últimas veinte líneas:
tail -n 20 /home/labex/project/output/application.log
Los mensajes exactos de registro varían. Los encabezados de contenedores y los mensajes de tareas relacionan la aplicación con el trabajo que YARN ejecutó realmente. Los registros ayudan a explicar el comportamiento; el estado satisfactorio junto con la salida comercial correcta constituye una evidencia más sólida que una sola línea de registro tranquilizadora. En el próximo laboratorio utilizará estas mismas herramientas de diagnóstico con fallos.
Valide y repita la ejecución sin contaminar la entrada
En este paso, comprobará los datos del resultado, los exportará y repetirá la ejecución en una segunda ruta de salida.
Liste el primer directorio de resultados:
hdfs dfs -ls /user/labex/yarn-batch/results/run-1
El marcador _SUCCESS indica que se completó la salida. Los archivos part-* contienen los conteos. Como antes, utilice un patrón de HDFS entre comillas y ordene los registros para examinarlos de forma estable:
hdfs dfs -cat '/user/labex/yarn-batch/results/run-1/part-*' | sort
Resultado esperado:
folder 3
notebook 4
pen 4
Guarde una exportación local ordenada utilizando la técnica de lectura:
hdfs dfs -cat '/user/labex/yarn-batch/results/run-1/part-*' | sort > /home/labex/project/output/run-1-counts.txt
Antes de la siguiente ejecución, prediga si otra ejecución sobre una entrada idéntica debería cambiar los conteos. No debería hacerlo. Una nueva ruta de salida conserva el primer resultado y evita el error de salida ya existente:
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/yarn-batch/raw /user/labex/yarn-batch/results/run-2
Después de finalizar correctamente, lea y guarde los conteos ordenados de la segunda ejecución:
hdfs dfs -cat '/user/labex/yarn-batch/results/run-2/part-*' | sort > /home/labex/project/output/run-2-counts.txt
Compare las dos exportaciones locales:
diff /home/labex/project/output/run-1-counts.txt /home/labex/project/output/run-2-counts.txt
No debería aparecer ninguna diferencia. Los resultados son directorios hermanos fuera del directorio de entradas originales, por lo que repetir la ejecución no añadió la salida anterior al siguiente lote de entrada. Ahora ha comprobado una aplicación real, sus registros, sus datos de resultado y un comportamiento repetible sin cambiar el algoritmo.
Resumen
Trasladó un algoritmo conocido de conteo de la ejecución local a HDFS y YARN. Identificó una aplicación real de MapReduce, examinó su finalización correcta y los registros de contenedores y comprobó resultados correctos de dos rutas de salida.
El algoritmo no cambió, mientras que sí lo hizo su organización de almacenamiento y administración de recursos. A continuación, aprenderá a distinguir problemas del cliente de fallos de una aplicación ya enviada y a realizar la reparación mínima adecuada.
