Introducción
El lote de la empresa minorista se completó correctamente ayer, pero el comando de hoy informa de un error. Repetirlo sin leer el mensaje puede ocultar la causa real o fomentar un atajo destructivo. Una entrada inexistente, una dirección de servicio equivocada y una tarea de procesamiento fallida requieren respuestas diferentes.
Seguirá una pequeña secuencia de diagnóstico: identificar el sistema de archivos y la conexión, comprobar la existencia y la lectura de la entrada, comprobar la ruta de salida y después examinar el estado y los registros de una aplicación aceptada. Un error del cliente puede producirse antes de que se envíe una aplicación. Una aplicación enviada tiene una identidad de YARN cuyos diagnósticos proporcionan más evidencia.
Este laboratorio proporciona deliberadamente varios fallos, incluida una aplicación de entrenamiento ya compilada que rechaza un registro de entrada marcado. Son ejemplos didácticos controlados, no fallos aleatorios de infraestructura. Los conservará como evidencia y terminará una ejecución correcta de WordCount utilizando otras rutas de entrada y salida. No se requiere programar en Java, reinstalar servicios, formatear ni realizar eliminaciones amplias. Todos los ejemplos son independientes; utilice Terminal.
Diagnostique errores de conexión y entrada
En este paso, distinguirá una dirección de servicio equivocada de un archivo inexistente leyendo errores reales del cliente.
Comience en el espacio de trabajo local:
cd /home/labex/project
Primero recuerde el sistema de archivos configurado:
hdfs getconf -confKey fs.defaultFS
Debería ser hdfs://localhost:9000. Ahora pida deliberadamente al cliente que se conecte al puerto 1, donde no escucha ningún NameNode. Las propiedades -D siguientes limitan los reintentos de conexión y establecen un tiempo de espera de conexión de 2.000 milisegundos para esta invocación, manteniendo acotado el error intencional. No modifican la configuración compartida.
La redirección > file 2>&1 guarda la salida normal en un archivo local y envía la salida de error al mismo destino. Se espera que el siguiente comando falle.
hdfs dfs -Dipc.client.connect.max.retries=0 -Dipc.client.connect.timeout=2000 -ls hdfs://localhost:1/user/labex > /home/labex/project/output/connection-error.log 2>&1
Lea el error guardado:
cat /home/labex/project/output/connection-error.log
Busque un fallo o rechazo de conexión y la dirección equivocada. Esto sucede antes de que pueda completarse un listado del sistema de archivos. No formatee HDFS ni reinstale servicios; el comando utilizó el punto de conexión equivocado. Vuelva al punto de conexión configurado utilizando la ruta predeterminada:
hdfs dfs -ls /user/labex/job-diagnostics/data
Debería ver clean.txt y rejected.txt. La conexión funciona. Otro problema diferente es solicitar a ese sistema de archivos saludable un archivo inexistente. Se espera que el siguiente comando falle.
hdfs dfs -ls /user/labex/job-diagnostics/data/missing.txt > /home/labex/project/output/missing-input.log 2>&1
Examine el mensaje:
cat /home/labex/project/output/missing-input.log
Debería informar de que la ruta indicada no existe. Compruebe la entrada prevista con la operación de lectura conocida:
hdfs dfs -cat /user/labex/job-diagnostics/data/clean.txt
Las dos líneas son notebook pen y notebook folder. Una ruta de entrada corregida resuelve un problema de archivo inexistente; cambiar la configuración del servidor no lo resolvería. Conserve los registros de error como evidencia.
Reconozca una ruta de salida existente
En este paso, observará por qué un trabajo rechaza un directorio de salida que ya existe y elegirá conservarlo en lugar de realizar una eliminación amplia.
La preparación ha creado un directorio de resultados vacío existing para representar una ubicación de salida ya reservada. Examine la entrada de ese directorio:
hdfs dfs -ls -d /user/labex/job-diagnostics/results/existing
El formato de salida del ejemplo de MapReduce espera crear un directorio de salida nuevo. Un directorio existente puede provocar un rechazo del cliente antes de que se acepte una aplicación de procesamiento. Se espera que el siguiente comando falle.
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/job-diagnostics/data/clean.txt /user/labex/job-diagnostics/results/existing > /home/labex/project/output/existing-output.log 2>&1
Lea el mensaje guardado:
cat /home/labex/project/output/existing-output.log
Busque un mensaje de directorio de salida ya existente o FileAlreadyExistsException. Se trata de un conflicto de rutas, no de evidencia de que el algoritmo de conteo de productos sea incorrecto.
Liste las aplicaciones aceptadas por YARN:
yarn application -list -appStates ALL
Estos errores del cliente no deberían producir una aplicación de procesamiento completada. Un cliente puede contactar con servicios del clúster u obtener un identificador durante la preparación del envío; una aplicación aceptada y su estado son evidencias separadas.
Conservará el directorio reservado y utilizará una ruta de salida nueva en la ejecución correcta. Eliminar todo results o eliminar la entrada original sería un cambio mucho más amplio de lo que requiere el problema.
Examine una aplicación real fallida
En este paso, enviará una aplicación de entrenamiento controlada y utilizará su identidad real de YARN y sus registros para explicar el fallo.
El archivo controlled-failure.jar preparado acepta una ruta de entrada y una ruta nueva de salida. Su mapper rechaza deliberadamente el marcador BAD_RECORD. No necesita examinar ni editar código Java; el propósito es distinguir un fallo de tarea de una aplicación aceptada de los errores anteriores del cliente.
Primero lea la entrada marcada:
hdfs dfs -cat /user/labex/job-diagnostics/data/rejected.txt
Contiene una línea normal de productos seguida de BAD_RECORD. El trabajo de entrenamiento utiliza un intento de map para que el mismo fallo intencional no se reintente repetidamente. Se espera que el siguiente comando falle.
hadoop jar /home/labex/project/tools/controlled-failure.jar /user/labex/job-diagnostics/data/rejected.txt /user/labex/job-diagnostics/results/failed-example > /home/labex/project/output/failed-job.log 2>&1
Espere al indicador de comandos y después lea el final de su registro:
tail -n 25 /home/labex/project/output/failed-job.log
A diferencia de los casos anteriores, esta ejecución debería tener una aplicación enviada a YARN y evidencia de fallo de tarea. Guarde su ID real utilizando el mismo patrón de listado de aplicaciones del laboratorio anterior:
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/failed-application-id.txt
Consulte y guarde su informe:
yarn application -status "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application-status.txt
Lea el informe:
cat /home/labex/project/output/failed-application-status.txt
Busque la identidad de la aplicación, el estado final y los diagnósticos. El estado final debería ser FAILED; el informe es evidencia procedente de YARN, no una etiqueta de fallo escrita a mano. Lea también los registros agregados reales:
yarn logs -applicationId "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application.log
Utilice grep para encontrar en ellos el diagnóstico de entrenamiento conocido:
grep 'Training input rejected' /home/labex/project/output/failed-application.log
El mensaje señala el registro marcado. Ha pasado de un resultado genérico de comando distinto de cero a una explicación específica respaldada por los registros de la aplicación y de la tarea. Conserve esta evidencia en lugar de tratar cada fallo como un motivo para reiniciar el clúster.
Corrija la selección del lote y complete una ejecución
En este paso, utilizará la entrada limpia y un directorio nuevo de salida y después conservará un breve diagnóstico basado en evidencia.
La entrada prevista para el informe es clean.txt; el archivo rechazado era un ejemplo de entrenamiento. Conserve ambos originales. Envíe el ejemplo conocido de WordCount utilizando únicamente el archivo limpio y un directorio nuevo de resultados:
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/job-diagnostics/data/clean.txt /user/labex/job-diagnostics/results/successful-run > /home/labex/project/output/successful-job.log 2>&1
Este comando debería finalizar correctamente. La entrada tiene dos apariciones de notebook, una de pen y una de folder. Lea el resultado:
hdfs dfs -cat '/user/labex/job-diagnostics/results/successful-run/part-*' | sort
Conteos esperados:
folder 1
notebook 2
pen 1
El registro del proceso controlador correcto incluye su ID de aplicación. sort -u ordena y elimina las líneas idénticas repetidas del ID, dejando el único ID de esta invocación:
grep -o 'application_[0-9]*_[0-9]*' /home/labex/project/output/successful-job.log | sort -u > /home/labex/project/output/successful-application-id.txt
Confirme el estado real de la aplicación correcta:
yarn application -status "$(cat /home/labex/project/output/successful-application-id.txt)"
El estado final debería ser SUCCEEDED. Reúna la evidencia anterior en un registro local de diagnóstico:
cat /home/labex/project/output/connection-error.log /home/labex/project/output/missing-input.log /home/labex/project/output/existing-output.log /home/labex/project/output/failed-application-status.txt > /home/labex/project/output/diagnosis.md
Añada la reparación elegida. printf imprime el texto y \n crea saltos de línea; >> añade contenido en lugar de sustituir la evidencia guardada:
printf '\nRepair: select /user/labex/job-diagnostics/data/clean.txt and use the new /user/labex/job-diagnostics/results/successful-run output. Preserve original inputs and the existing result directory.\n' >> /home/labex/project/output/diagnosis.md
Este registro relaciona error, observación y acción. Ante un servicio no disponible o un fallo de plataforma fuera de su acceso, registre el punto de conexión y el mensaje e informe del problema en lugar de volver a formatear el almacenamiento. Para los problemas enseñados aquí, bastó con elegir una ruta o entrada específica.
Resumen
Distinguió los errores de conexión, las entradas inexistentes y las rutas de salida existentes de un fallo de tarea en una aplicación aceptada por YARN. Utilizó el estado real de la aplicación y los registros de tarea para explicar un rechazo controlado y después completó un lote correcto con una entrada limpia y una ruta nueva de salida.
El desafío final del curso combina estos hábitos con la organización de entradas y los permisos. Le pide completar un lote nuevo de forma independiente utilizando métodos que ya ha practicado.
