Hadoop 의 성능 테스트 및 변조

Hadoop 테스트
무 리 를 지어 건설 하면 만사 가 다 잘 되 는 것 이 아 닙 니까?만약 에 공부 하거나 실험 만 한다 면 충분 한 것 같 지만 생산 환경 이 부족 합 니 다. 왜냐하면 우 리 는 아직 군집 에 대해 테스트 를 하지 않 았 기 때문에 우리 가 기대 하 는 것 에 도달 할 수 있 습 니까?
1.1 쓰기 테스트
128 M 파일 100 개 쓰기 테스트

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 100 -fileSize 128MB

1, 2. 읽 기 테스트
128 파일 100 개 읽 기 테스트

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 100 -fileSize 128MB

1.3 테스트 데이터 삭제
테스트 데 이 터 는 삭제 해 야 하 며 생산 에 가 져 갈 수 없습니다.

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean

1.4 Sort 로 MapReduce 평가
1) RandomWriter 를 사용 하여 랜 덤 수 를 만 들 고 노드 마다 10 개의 Map 작업 을 실행 하 며 맵 마다 약 1G 크기 의 바 이 너 리 랜 덤 수 를 생 성 합 니 다.

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar randomwriter random-data

2) sort 실행

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar sort random-data sorted-data

3) 검증 결과

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar testmapredsort -sortInput random-data -sortOutput sorted-data

하하, 제 컴퓨터 가 힘 이 안 돼 서 직접 보 여 드릴 수가 없어 요. 업그레이드 해 야 할 것 같 아 요.빅 데이터 구덩이 에 들 어가 기로 한 학생 들 은 컴퓨터 를 높 게 배치 해 야 한다. 그렇지 않 으 면 가 져 갈 수 없다.
2. Hadoop 성능 개선
클 러 스 터 테스트, 기대 에 부합 되 지 않 으 면 성능 개선 에 들 어가 야 합 니 다.
2.1 MpaReduce 의 최적화
MapReduce 실행 효율 의 병목 은 두 가지 측면 에서 1. 컴퓨터 성능 의 영향, 예 를 들 어 CPU, 메모리 크기, 디스크, 네트워크 지연 등 이다.2. IO 측 최적화 상황 1) 데이터 경사 문제 2) Map 과 Reduce 의 개수 설정 상황 3) Map 소모 시간 이 너무 길다 4) 작은 파일 이 너무 많다 5) Spill 과 Merge 횟수 가 너무 많다 등등
우리 가 MapReduce 에 대한 최 적 화 는 크게 6 가지 측면 1) 데이터 입력 2) Map 단계 3) Reduce 단계 4) IO 전송 5) 데이터 경사 6) 매개 변수 변조 이다.
2.1.1 데이터 입력
예 를 들 어 작은 파일 을 통합 하면 작은 파일 에 대량의 MapTask 가 생 긴 다 는 것 을 알 기 때문에 우 리 는 MR 작업 을 수행 하기 전에 작은 파일 을 먼저 통합 할 수 있다.
기본 적 인 상황 에서 TextInputformat 이 작업 에 대한 절편 체 제 는 파일 계획 에 따라 절편 을 자 르 는 것 입 니 다. 파일 이 아무리 작 아 도 하나의 단독 절편 이 있 고 하나의 maptask 에 맡 깁 니 다. 만약 에 대량의 작은 파일 이 있 으 면 대량의 maptask 가 발생 합 니 다. 처리 효율 과 저 하 는 CombineTextInputFormat 으로 바 꾸 어 입력 단자 의 대량의 작은 파일 문 제 를 해결 할 수 있 습 니 다.
2.1.2 지도 단계
1. Spill 횟수 를 줄 이 는 것, 즉 넘 치 는 쓰기 횟수: io. sort. mb 및 sort. spill. percent 매개 변수 값 을 조정 하여 Spill 을 촉발 하 는 메모리 상한 선 을 확대 하고 Spill 횟수 를 줄 여 디스크 IO 를 감소 합 니 다.
2. Merge 횟수 감소: io. sort. factor 인 자 를 조정 하여 Merge 의 파일 수 를 늘 리 고 Merge 의 횟수 를 줄 여 MR 처리 시간 을 단축 합 니 다.
3. Map 이후 업무 논리 에 영향 을 주지 않 는 전제 에서 Combine 을 먼저 진행 하여 IO 를 줄 일 수 있다.
2.1.3 감소 단계
1. Map 과 Reduce 개수 의 설정: 두 개 는 너무 적 게 설정 할 수도 없고 너무 많이 설정 할 수도 없습니다.너무 적 으 면 Task 대기, 처리 시간 연장;너무 많 으 면 맵, Reduce 작업 간 경쟁 자원 으로 인해 처리 시간 초과 등 오류 가 발생 할 수 있 습 니 다.
2. Map, Reduce 공존: slowstar. completedmaps 인 자 를 조정 하여 맵 을 어느 정도 실행 한 후에 Reduce 도 실행 하기 시작 하여 Reduce 의 대기 시간 을 줄 입 니 다.
3. Reduce 사용 회피: Reduce 는 데이터 세트 를 연결 할 때 대량의 네트워크 소모 가 발생 하기 때문이다.
2.1.4 IO 전송
1) 데이터 압축 2) SequenceFile 바 이 너 리 파일 사용
2.1.5 데이터 경사
무엇이 데이터 경사 입 니까?쉽게 말 하면 대량의 똑 같은 키 가 파 티 션 에 의 해 한 파 티 션 에 배정 되 어 '한 사람 이 힘 들 어 죽 고 다른 사람 이 한가 로 워 죽 는' 상황 을 초래 한 것 이다.
해결 방법: 1) 사용자 정의 파 티 션, 즉 Partition, 지정 파 티 션 전략 2) 키 를 재 설계 합 니 다. 예 를 들 어 map 단계 에서 키 에 무 작위 값 을 추가 하면 무 작위 값 이 있 는 키 는 같은 노드 에 대량으로 나 눌 기회 가 없 을 것 입 니 다. reduce 단계 에 이 르 러 무 작위 값 을 제거 합 니 다.3) Combine 을 사용 합 니 다. Combinner 는 map 단계, reduce 이전의 중간 단계 입 니 다. 이 단계 에서 같은 key 데 이 터 를 선택적으로 합병 할 수 있 습 니 다. local reduce 라 고 볼 수 있 고 reduce 에 맡 길 수 있 습 니 다. 이렇게 하면 좋 은 점 이 많 습 니 다. 즉, map 단 이 reduce 단 에 보 낸 데 이 터 량 (네트워크 대역 폭 감소) 을 줄 일 수 있 습 니 다.맵 엔 드 와 reduce 엔 드 사이 의 shuffle 단계 의 데이터 추출 수량 (현지 화 디스크 IO 속도) 해결 방법 도 위 에서 말 한 것 뿐만 아니 라 구체 적 으로 도 실제 상황 에 따라 야 합 니 다.
2.1.6 변조 파라미터
1) 다음 매개 변 수 는 사용자 자신의 MR 프로그램 에서 설정 하면 적 용 됩 니 다 (mapred - default. xml)
설정 매개 변수
매개 변수 설명
mapreduce.map.memory.mb
MapTask 에서 사용 할 수 있 는 자원 상한 선 (단위: MB) 은 기본적으로 1024 입 니 다.MapTask 가 실제 사용 하 는 자원 이 이 값 을 초과 하면 강제 적 으로 죽 습 니 다.
mapreduce.reduce.memory.mb
ReduceTask 에서 사용 할 수 있 는 자원 상한 선 (단위: MB) 은 기본적으로 1024 입 니 다.ReduceTask 가 실제 사용 하 는 자원 이 이 값 을 초과 하면 강제 적 으로 죽 습 니 다.
mapreduce.map.cpu.vcores
모든 MapTask 에서 사용 할 수 있 는 최대 cpu core 수, 기본 값: 1
mapreduce.reduce.cpu.vcores
ReduceTask 마다 사용 할 수 있 는 최대 cpu core 수, 기본 값: 1
mapreduce.reduce.shuffle.parallelcopies
모든 Reduce 는 Map 에서 데 이 터 를 가 져 오 는 병렬 수 입 니 다.기본 값 은 5
mapreduce.reduce.shuffle.merge.percent
Buffer 의 데이터 가 얼마나 많은 비율 에 이 르 렀 는 지 디스크 에 쓰기 시작 합 니 다.기본 값 0.66
mapreduce.reduce.shuffle.input.buffer.percent
Buffer 크기 는 Reduce 가 사용 할 수 있 는 메모리 의 비율 을 차지 합 니 다.기본 값 0.7
mapreduce.reduce.input.buffer.percent
버퍼 의 데 이 터 를 저장 할 메모리 의 비율 을 지정 합 니 다. 기본 값 은 0. 0 입 니 다.
2) YARN 이 시작 되 기 전에 서버 설정 파일 에 설정 해 야 유효 합 니 다 (yarn - default. xml)
설정 매개 변수
매개 변수 설명
yarn.scheduler.minimum-allocation-mb
응용 프로그램 Container 에 할당 할 최소 메모리, 기본 값: 1024
yarn.scheduler.maximum-allocation-mb
응용 프로그램 Container 에 할당 할 최대 메모리, 기본 값: 8192
yarn.scheduler.minimum-allocation-vcores
모든 Container 가 신청 한 최소 CPU 핵 수, 기본 값: 1
yarn.scheduler.maximum-allocation-vcores
모든 Container 가 신청 한 최대 CPU 핵 수, 기본 값: 32
yarn.nodemanager.resource.memory-mb
Containers 에 할당 할 최대 물리 적 메모리, 기본 값: 8192
3) Shuffle 성능 최적화 의 핵심 매개 변 수 는 YARN 이 시작 되 기 전에 설정 해 야 합 니 다 (mapred - default. xml)
설정 매개 변수
매개 변수 설명
mapreduce.task.io.sort.mb
Shuffle 의 링 버퍼 크기, 기본 100 m
mapreduce.map.sort.spill.percent
링 버퍼 넘 치 는 한도 값, 기본 80%
4) 잘못 사용 한 관련 매개 변수 (MapReduce 성능 최적화)
설정 매개 변수
매개 변수 설명
mapreduce.map.maxattempts
각 Map Task 의 최대 재 시도 횟수 입 니 다. 재 시도 매개 변수 가 이 값 을 초과 하면 Map Task 가 실 패 했 습 니 다. 기본 값: 4.
mapreduce.reduce.maxattempts
Reduce Task 당 최대 재 시도 횟수 입 니 다. 재 시도 매개 변수 가 이 값 을 초과 하면 Map Task 가 실 패 했 습 니 다. 기본 값: 4.
mapreduce.task.timeout
Task 시간 초과, 항상 설정 해 야 하 는 매개 변수 입 니 다. 이 매개 변 수 는 한 Task 가 일정 시간 동안 들 어가 지 않 으 면 새로운 데 이 터 를 읽 지 않 고 출력 데이터 도 없 으 면 이 Task 가 Block 상태 에 있다 고 생각 합 니 다. 걸 렸 을 수도 있 고 영원히 걸 릴 수도 있 습 니 다. 사용자 프로그램 이 영원히 차단 되 어 종료 되 지 않 는 것 을 방지 하기 위해 서 입 니 다.이 시간 초과 (단위 밀리초) 를 강제로 설 정 했 습 니 다. 기본 값 은 600000 입 니 다.프로그램 이 모든 입력 데 이 터 를 너무 오래 처리 할 경우 (예 를 들 어 데이터 베 이 스 를 방문 하고 네트워크 를 통 해 데 이 터 를 끌 어 올 리 는 등) 이 매개 변 수 를 크게 조정 하 는 것 을 권장 합 니 다. 이 매개 변 수 는 너무 작 으 면 자주 발생 하 는 오류 알림 은 "AttemptID: attempt 14267829456721 123456 m 000224 0 Timed out after 300 secs Container killed by the applicationMaster" 입 니 다.
질문
왜 HDFS 는 작은 파일 을 무서워 합 니까?HDFS 에 있 는 모든 파일 은 NameNode 에 색인 을 만들어 야 하기 때문에 이 색인 크기 는 약 150 byte 이 고 대량의 작은 파일 이 있 을 때 많은 색인 파일 이 생 성 되 지만 메모리 에 제한 이 있 습 니 다. 또한 색인 파일 이 너무 크 면 색인 조회 효율 이 떨 어 집 니 다.
그래서 작은 문서 문 제 는 생산 환경 에서 반드시 주 의 를 끌 어야 하 는 문제 이다.해결 방법 은 작은 파일 이 생기 거나 작은 파일 에 대한 통합 을 줄 이 는 것 입 니 다. 구체 적 으로 다음 과 같은 몇 가지 방법 이 있 습 니 다. 1) 데이터 수집 시 작은 파일 이나 작은 데 이 터 를 큰 파일 로 합성 하여 HDFS 를 업로드 합 니 다.2) 업무 처리 전에 HDFS 에서 MapReduce 프로그램 을 사용 하여 작은 파일 을 통합 합 니 다.3) MapReduce 처리 시 CombineTextInput Format 을 사용 하여 효율 을 높 일 수 있다.