소개
소매업체의 배치는 어제 성공했지만 오늘의 명령은 오류를 보고합니다. 메시지를 읽지 않고 반복 실행하면 실제 원인을 놓치거나 데이터를 손상시키는 지름길을 선택할 수 있습니다. 입력 누락, 잘못된 서비스 주소, 처리 태스크 실패에는 각각 다른 대응이 필요합니다.
간단한 진단 순서를 따릅니다. 파일 시스템과 연결을 식별하고, 입력이 존재하고 읽을 수 있는지 확인하고, 출력 경로를 확인한 뒤, 수락된 애플리케이션의 상태와 로그를 살펴봅니다. 클라이언트 측 오류는 애플리케이션이 제출되기 전에 발생할 수 있습니다. 제출된 애플리케이션에는 YARN 식별자가 있으며 그 진단 정보가 추가 증거를 제공합니다.
이 실습에는 표시된 입력 기록을 거부하는 미리 컴파일된 학습용 애플리케이션을 비롯해 여러 실패 상황이 의도적으로 준비되어 있습니다. 무작위 인프라 장애가 아니라 통제된 학습 예제입니다. 증거를 보존하고 다른 입력과 출력 경로로 정상적인 WordCount 실행을 완료합니다. Java 코딩, 서비스 재설치, 포맷이나 광범위한 삭제는 필요하지 않습니다. 모든 실습 데이터는 독립적이며 터미널을 사용합니다.
연결 오류와 입력 오류 진단하기
이 단계에서는 실제 클라이언트 오류를 읽고 잘못된 서비스 주소와 없는 파일을 구분합니다.
로컬 작업 공간에서 시작합니다.
cd /home/labex/project
먼저 구성된 파일 시스템을 다시 확인합니다.
hdfs getconf -confKey fs.defaultFS
hdfs://localhost:9000이어야 합니다. 이제 NameNode가 수신 대기하지 않는 포트 1에 클라이언트가 연결하도록 의도적으로 요청합니다. 아래의 -D 속성은 이번 호출의 연결 재시도를 제한하고 연결 제한 시간을 2,000밀리초로 설정하여 의도한 오류가 오래 걸리지 않게 합니다. 공유 구성을 수정하지는 않습니다.
리디렉션 > file 2>&1은 일반 출력을 로컬 파일에 저장하고 오류 출력도 같은 곳으로 보냅니다. 다음 명령은 실패하는 것이 정상입니다.
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
저장한 오류를 읽습니다.
cat /home/labex/project/output/connection-error.log
연결 실패 또는 거부와 잘못된 주소를 찾으세요. 파일 시스템 목록을 가져오기 전에 발생하는 문제입니다. HDFS를 포맷하거나 서비스를 재설치하지 마세요. 명령이 잘못된 접점에 연결한 것입니다. 기본 경로를 사용하여 구성된 접점으로 돌아갑니다.
hdfs dfs -ls /user/labex/job-diagnostics/data
clean.txt와 rejected.txt가 보여야 합니다. 연결은 작동합니다. 정상 파일 시스템에 없는 파일을 요청하는 것은 다른 문제입니다. 다음 명령은 실패하는 것이 정상입니다.
hdfs dfs -ls /user/labex/job-diagnostics/data/missing.txt > /home/labex/project/output/missing-input.log 2>&1
메시지를 확인합니다.
cat /home/labex/project/output/missing-input.log
지정한 경로가 없다고 보고해야 합니다. 익숙한 읽기 연산으로 의도한 입력을 확인합니다.
hdfs dfs -cat /user/labex/job-diagnostics/data/clean.txt
두 줄은 notebook pen과 notebook folder입니다. 입력 경로를 바로잡으면 파일이 없는 문제가 해결됩니다. 서버 구성 변경으로 해결할 문제는 아닙니다. 오류 로그를 증거로 보관하세요.
기존 출력 경로 알아보기
이 단계에서는 이미 존재하는 출력 디렉터리를 작업이 거부하는 이유를 관찰하고 광범위한 삭제 대신 보존을 선택합니다.
환경 설정 과정에서 이미 사용하기로 한 출력 위치를 나타내는 빈 existing 결과 디렉터리를 준비했습니다. 해당 디렉터리 항목을 확인합니다.
hdfs dfs -ls -d /user/labex/job-diagnostics/results/existing
예제 MapReduce 출력 형식은 새 출력 디렉터리를 직접 생성하는 것을 전제로 합니다. 기존 디렉터리가 있으면 처리 애플리케이션을 수락하기 전에 클라이언트 측에서 거부할 수 있습니다. 다음 명령은 실패하는 것이 정상입니다.
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
저장한 메시지를 읽습니다.
cat /home/labex/project/output/existing-output.log
출력 디렉터리가 이미 있다는 메시지 또는 FileAlreadyExistsException을 찾으세요. 이것은 경로 충돌이며 상품 집계 알고리즘이 잘못되었다는 증거가 아닙니다.
YARN이 수락한 애플리케이션을 나열합니다.
yarn application -list -appStates ALL
이러한 클라이언트 실수로 완료된 처리 애플리케이션이 생겨서는 안 됩니다. 클라이언트가 제출 준비 중 클러스터 서비스에 접속하거나 식별자를 받을 수는 있습니다. 수락된 애플리케이션과 그 상태는 별도의 증거입니다.
이미 잡아 둔 디렉터리를 보존하고 성공할 실행에는 새 출력 경로를 사용합니다. results 전체나 원본 입력을 삭제하는 것은 문제에 필요한 것보다 훨씬 큰 변경입니다.
실제 실패한 애플리케이션 확인하기
이 단계에서는 통제된 학습용 애플리케이션을 제출하고 실제 YARN 식별자와 로그로 실패를 설명합니다.
준비된 controlled-failure.jar는 입력 경로와 새 출력 경로를 받습니다. 매퍼는 BAD_RECORD 표시를 의도적으로 거부합니다. Java 코드를 살펴보거나 수정할 필요는 없습니다. 목적은 수락된 애플리케이션의 태스크 실패를 앞선 클라이언트 오류와 구분하는 것입니다.
먼저 표시가 있는 입력을 읽습니다.
hdfs dfs -cat /user/labex/job-diagnostics/data/rejected.txt
정상 상품 한 줄 뒤에 BAD_RECORD가 들어 있습니다. 같은 의도적 실패를 반복 재시도하지 않도록 학습 작업의 Map 시도 횟수는 한 번입니다. 다음 명령은 실패하는 것이 정상입니다.
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
프롬프트를 기다린 뒤 로그 끝부분을 읽습니다.
tail -n 25 /home/labex/project/output/failed-job.log
이전 상황과 달리 이번 실행에는 제출된 YARN 애플리케이션과 태스크 실패의 증거가 있어야 합니다. 이전 실습과 같은 애플리케이션 목록 패턴으로 실제 ID를 저장합니다.
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/failed-application-id.txt
보고서를 조회하고 저장합니다.
yarn application -status "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application-status.txt
보고서를 읽습니다.
cat /home/labex/project/output/failed-application-status.txt
애플리케이션 식별자, 최종 상태와 진단 내용을 찾으세요. 최종 상태는 FAILED여야 합니다. 이 보고서는 손으로 적은 실패 표시가 아니라 YARN의 증거입니다. 실제로 모인 로그도 읽습니다.
yarn logs -applicationId "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application.log
grep으로 그 안에서 알고 있는 학습용 진단 메시지를 찾습니다.
grep 'Training input rejected' /home/labex/project/output/failed-application.log
메시지는 표시가 있는 기록을 가리킵니다. 일반적인 0이 아닌 명령 결과에서 나아가 애플리케이션 및 태스크 로그로 뒷받침되는 구체적인 설명을 얻었습니다. 모든 실패를 클러스터 재시작의 이유로 삼지 말고 이 증거를 보존하세요.
배치 선택을 수정하고 실행 완료하기
이 단계에서는 정상 입력과 새 출력 디렉터리를 사용하고 증거에 근거한 짧은 진단을 남깁니다.
의도한 보고서 입력은 clean.txt이며 거부된 파일은 학습용 예제였습니다. 원본 둘 다 유지하세요. 새 결과 디렉터리를 사용하여 정상 파일만 대상으로 익숙한 WordCount 예제를 제출합니다.
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
이 명령은 성공적으로 종료되어야 합니다. 입력에는 notebook 두 번, pen 한 번, folder 한 번이 있습니다. 결과를 읽습니다.
hdfs dfs -cat '/user/labex/job-diagnostics/results/successful-run/part-*' | sort
예상 개수는 다음과 같습니다.
folder 1
notebook 2
pen 1
성공한 드라이버 로그에는 애플리케이션 ID가 포함됩니다. sort -u는 정렬하고 같은 ID의 반복 줄을 제거하여 이번 호출의 ID 하나만 남깁니다.
grep -o 'application_[0-9]*_[0-9]*' /home/labex/project/output/successful-job.log | sort -u > /home/labex/project/output/successful-application-id.txt
실제로 성공한 애플리케이션 상태를 확인합니다.
yarn application -status "$(cat /home/labex/project/output/successful-application-id.txt)"
최종 상태는 SUCCEEDED여야 합니다. 앞선 증거를 하나의 로컬 진단 기록으로 모읍니다.
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
선택한 수정 방법을 덧붙입니다. printf는 텍스트를 출력하고 \n은 줄바꿈을 만듭니다. >>는 저장된 증거를 바꾸지 않고 뒤에 추가합니다.
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
이 기록은 오류, 관찰, 조치를 연결합니다. 자신의 접근 범위를 벗어난 서비스 중단이나 플랫폼 장애라면 저장소를 다시 포맷하지 말고 접점과 메시지를 기록하여 문제를 보고하세요. 여기서 배운 문제는 특정 경로나 입력 선택만 바꾸면 충분했습니다.
요약
연결 오류, 입력 누락, 기존 출력 경로 문제를 수락된 YARN 애플리케이션의 태스크 실패와 구분했습니다. 실제 애플리케이션 상태와 태스크 로그로 통제된 거부 상황을 설명하고, 정상 입력과 새 출력 경로로 올바른 배치를 완료했습니다.
과정의 마지막 도전 과제는 이러한 습관을 입력 정리 및 권한과 결합합니다. 이미 연습한 방법으로 새 배치를 독립적으로 완료하게 됩니다.
