큰 데이터에서 작업을 제출하는 데 문제가있는 사람이 있습니까? 데이터는 압축되지 않은 5-10TB 정도이며, 대략 500K 파일에 있습니다. 우리가 간단한 자바 맵 감속 작업을 제출하려고 할 때, 대부분 getsplits() 함수 호출에 시간 이상을 소비합니다. 그리고 작업 추적기에 나타나려면 여러 시간이 걸립니다. 이 문제를 해결할 수있는 가능한 해결책이 있습니까?큰 데이터의 Hadoop - 작업 제출 시간
제출 서버가 (또는 랩톱 클라이언트) "강력한"방법에 따라 크게 달라질 수 있습니다. getSplits를 더 빠르게 호출하려면 RAM과 CPU를 업그레이드해야합니다.
나는 스왑 문제에 부딪혔다 고 생각한다. 계산은 therfore를 평소보다 몇 배 더 오래 걸린다.
500k 개의 파일이있는 경우 이러한 모든 파일을 찾기 위해 많은 시간을 들여서 나무를 걸러 내고 InputSplits (getSplits 결과) 목록에 할당해야합니다.
답변에서 Thomas가 지적한 것처럼 작업 제출을 수행하는 시스템의 JVM 할당 메모리가 부족하면 JVM에서 가비지 수집을 수행하여 메모리를 찾으려고합니다 이 500K 파일에 대한 스플릿을 빌드하는 데 필요합니다.
이러한 500K 파일이 분할 가능하고 단일 블록 크기보다 큰 경우 파일을 처리하기 위해 더 많은 입력 분할이 발생합니다 (크기가 1GB이고 블록 크기가 1GB 인 파일). 256MB 인 경우 입력 형식 및 파일 압축이 파일 분할을 지원한다고 가정 할 때 기본적으로이 파일을 처리 할 4 개의 맵 작업을 얻습니다. 작업에 해당하는 경우 (작업에 대해 생성 된지도 작업의 수를 보면 500k 이상이 있습니까?) mapred.min.split.size 구성 속성을 현재보다 큰 크기로 수정하면 더 적은 매퍼가 생성되도록 할 수 있습니다 블록 크기 (이전 예에서 1GB로 설정하면 파일을 처리하는 단일 매퍼가 4 개가 아니라는 의미입니다.) 이렇게하면 getSplits 메서드의 성능을 향상시켜 결과적으로 getSplits의 목록이 작아지고 메모리가 줄어들게됩니다.
문제점의 두 번째 증상은 입력 분할을 파일 (클라이언트 측)로 직렬화 한 다음 작업 추적자 끝에서 직렬화 해제 시간을 얻는 것입니다. 500K + 스플릿은 시간이 걸릴 것이고 JVM 메모리 제한이 낮 으면 jobtracker는 비슷한 GC 문제를 갖게됩니다.