Spark 프로젝트 실전 - 실제 프로젝트 에서 흔히 볼 수 있 는 최적화 점 - 더 많은 자원 배분 과 병행 도 조절

1. 더 많은 자원 배분
(1) 어떤 자원 을 분배 합 니까?executor、cpu per executor、memory per executor、driver memory。
(2) 어디서 이런 자원 을 분배 합 니까?우리 가 생산 환경 에서 spark 작업 을 제출 할 때 사용 하 는 spark - submit 셸 스 크 립 트 에서 대응 하 는 인 자 를 조정 합 니 다.

/usr/local/spark/bin/spark-submit \
--class cn.spark.sparktest.core.WordCountCluster \
--num-executors 3 \    executor   
--driver-memory 100m \    driver   （    ）
--executor-memory 100m \      executor     
--executor-cores 3 \      executor cpu core  
/usr/local/SparkTest-0.0.1-SNAPSHOT-jar-with-dependencies.jar \

(3) 얼마나 조절 하면 가장 큰 편 인가요?
첫 번 째: Spark Standalone 모드.클 러 스 터 에 Spark 클 러 스 터 를 만 들 었 습 니 다. 우 리 는 모든 기계 가 당신 에 게 사용 할 수 있 는 메모리 가 얼마나 있 는 지, cpu core 가 얼마나 있 는 지 알 아야 합 니 다.그러면 설정 할 때 이 실제 상황 에 따라 모든 spark 작업 의 자원 분 배 를 조절 합 니 다.예 를 들 어 당신 의 모든 기 계 는 4G 메모리, cpu core 2 개, 기계 20 대 를 사용 할 수 있 습 니 다.그리고 20 개의 executor 가 있 습 니 다. 그러면 모든 executor 는 4G 메모리, 2 개의 cpu core 입 니 다.
두 번 째: Yarn 모드.그렇다면 spark 작업 이 제출 할 자원 대기 열 에 자원 이 얼마나 있 는 지 살 펴 봐 야 합 니 다.500 G 메모리, 100 cpu core;그리고 50 개의 executor 가 있 으 면 executor 당 평균 10G 메모리, cpu core 2 개 입 니 다.
하나의 원칙 은 당신 이 사용 할 수 있 는 자원 이 얼마나 큰 지 가능 한 한 최대 크기 로 조절 하 는 것 입 니 다 (executor 의 수량, 몇 십 개 에서 수백 개 까지 다 릅 니 다. executor 메모리, executor cpu core)
(4) 왜 자원 을 조절 한 후에 성능 이 향상 되 었 습 니까?
우 리 는 Spark Context 가 우리 의 계산 자 를 대량의 task 로 자 르 고 응용 프로그램의 executor 에 제출 하여 실행 할 것 이라는 것 을 알 고 있다.그러면:
첫 번 째: executor 추가.만약 executor 수량 이 비교적 적다 면 병행 할 수 있 는 task 수량 이 비교적 적 다 는 것 은 우리 의 응용 프로그램의 병행 집행 능력 이 매우 약 하 다 는 것 을 의미한다.예 를 들 어 executor 가 3 개 있 고 executor 마다 cpu core 가 2 개 있 으 면 동시에 실행 할 수 있 는 task 는 6 개 입 니 다.6 개가 실 행 된 후에 다음 6 개의 task 를 바 꿉 니 다.executor 수량 이 증가 하면 병행 할 수 있 는 task 수량 도 많아 진 다 는 뜻 이다.예 를 들 어 원래 6 개 였 는데 지금 은 10 개, 심지어 20 개, 100 개 를 병행 할 수 있다.그렇다면 병행 능력 은 이전 보다 수 배수 10 배 높 아 졌 다.해당 성능 (실행 속도) 도 수 배 ~ 수 십 배 높아진다.
두 번 째: 모든 executor 의 cpu core 를 증가 시 키 는 것 도 실행 병행 능력 을 증가 시 킵 니 다.원래 20 개의 executor, 각각 2 개의 cpu core.병행 할 수 있 는 task 수 는 40 개의 task 입 니 다.현재 모든 executor 의 cpu core 는 5 개 로 증가 했다.병행 할 수 있 는 task 수 는 100 개의 task 입 니 다.실행 속도 가 2.5 배 올 랐 다.
세 번 째: 모든 executor 의 메모리 양 을 증가 합 니 다.메모리 양 을 증가 한 후 성능 향상 에 다음 과 같은 세 가지 가 있 습 니 다.
a. RDD 에 cache 를 해 야 한다 면 더 많은 메모리 가 더 많은 데 이 터 를 캐 시 할 수 있 고 더 적은 데 이 터 를 디스크 에 쓰 거나 디스크 에 쓰 지 않 을 수 있 습 니 다.디스크 IO 를 줄 였 습 니 다.
b. shuffle 작업 에 있어 reduce 단 은 끌 어 온 데 이 터 를 저장 하고 취 합 할 메모리 가 필요 합 니 다.메모리 가 부족 해도 디스크 에 기록 합 니 다.만약 executor 에 더 많은 메모 리 를 분배 한 후에 디스크 에 쓸 필요 도, 심지 어 는 디스크 에 쓸 필요 도 없 는 데이터 가 더 적다.디스크 IO 를 줄 여 성능 을 향상 시 켰 습 니 다.
c. task 의 실행 에 많은 대상 을 만 들 수 있 습 니 다.메모리 가 작 으 면 JVM 메모리 가 가득 차 서 GC, 쓰레기 회수, minor GC, full GC 가 빈번 할 수 있 습 니 다.(속도 가 느리다).메모리 가 커지 면 더 적은 GC 를 가 져 오고 쓰레기 수 거 는 속도 가 느 려 지고 속도 가 빨 라 지 는 것 을 피한다.
2. 병행 도 조절
병행 도: 사실은 Spark 작업 에서 각 stage 의 task 수량 을 말 하 는데 이것 은 Spark 작업 의 각 단계 (stage) 에서 의 병행 도 를 나타 낸다.
병행 도 를 조절 하지 않 아 병행 도가 너무 낮 으 면 어떻게 되 나 요?
현재 spark - submit 스 크 립 트 에 있다 고 가정 하면 spark 작업 에 충분 한 자원 을 분배 합 니 다. 예 를 들 어 50 개의 executor, 각 executor 는 10G 메모리 가 있 고 각각 executor 는 3 개의 cpu core 가 있 습 니 다.
그러나 task 는 100 개의 task 를 설정 하거나 설정 하지 않 았 습 니 다.그러면 50 개의 executor 는 executor 마다 3 개의 cpu core 가 있 습 니 다. 즉, 응용 프로그램 이 모든 stage 가 실 행 될 때 총 150 개의 cpu core 가 병행 할 수 있 습 니 다.그러나 현재 100 개의 task 만 있 습 니 다. 평균 적 으로 배정 하고 모든 executor 는 2 개의 task 에 배정 합 니 다. 그러면 동시에 실행 되 는 task 는 100 개 에 불과 합 니 다. 모든 executor 는 2 개의 task 만 병행 합 니 다.executor 마다 남 은 cpu core 가 낭비 되 었 습 니 다.
당신 의 자원 은 충분히 분배 되 었 지만 문 제 는 병행 도가 자원 과 일치 하지 않 아서 당신 이 분배 한 자원 이 모두 낭비 되 었 다 는 것 입 니 다.
어떻게 병행 도 를 합 리 적 으로 설정 합 니까?
합 리 적 인 병행 도 설정 은 클 러 스 터 자원 을 완전히 합 리 적 으로 이용 할 수 있 을 정도 로 충분히 설정 해 야 합 니 다.예 를 들 어 위의 예 를 들 어 총 150 개의 cpu core 가 모여 150 개의 task 를 병행 할 수 있 습 니 다.그러면 애플 리 케 이 션 의 병행 도 를 최소 150 으로 설정 해 야 클 러 스 터 자원 을 효과적으로 이용 하여 150 개의 task 를 병행 할 수 있 습 니 다.또한 task 가 150 개 로 증가 하면 동시에 실행 할 수 있 고 모든 task 가 처리 해 야 할 데 이 터 를 줄 일 수 있 습 니 다.예 를 들 어 총 150 G 의 데 이 터 를 처리 해 야 합 니 다. 만약 에 100 개의 task 라면 모든 task 는 1.5G 의 데 이 터 를 계산 합 니 다.현재 150 개의 task 를 병행 하여 실행 할 수 있 으 며, task 마다 1G 의 데 이 터 를 처리 하면 됩 니 다.
간단 한 이치 입 니 다. 병행 도 를 합 리 적 으로 설정 하면 클 러 스 터 컴 퓨 팅 자원 을 충분히 이용 할 수 있 고 모든 task 가 처리 해 야 할 데이터 양 을 줄 일 수 있 습 니 다. 마지막 으로 전체 Spark 작업 의 성능 과 운행 속 도 를 향상 시 키 는 것 입 니 다.
(1) task 수량 은 적어도 Spark application 의 총 cpu core 수량 과 같 게 설정 되 어 있 습 니 다 (가장 이상 적 인 상황, 예 를 들 어 총 150 개의 cpu core, 150 개의 task 를 배정 하여 함께 실행 되 었 습 니 다. 거의 같은 시간 에 실 행 될 뻔 했 습 니 다)
(2) 공식 적 으로 추천 합 니 다. task 수량 은 spark application 총 cpu core 수량의 2 ~ 3 배 로 설정 합 니 다. 예 를 들 어 150 개의 cpu core 는 기본적으로 task 수량 을 300 ~ 500 으로 설정 해 야 합 니 다.
실제 상황 은 이상 적 인 상황 과 달리 어떤 task 는 빨리 실 행 됩 니 다. 예 를 들 어 50s 가 끝나 면 어떤 task 는 1 분 반 늦게 실 행 될 수 있 습 니 다. 그래서 만약 에 task 수량 이 cpu core 수량 과 똑 같이 설정 되면 자원 의 낭 비 를 초래 할 수 있 습 니 다. 예 를 들 어 150 개의 task, 10 개 를 먼저 실 행 했 고 나머지 140 개 는 아직도 실 행 됩 니 다.하지만 이 럴 때 10 개의 cpu 코어 가 한가 해 지면 낭비 가 된다.그러면 task 수량 이 cpu core 총수 의 2 ~ 3 배로 설정 되면 하나의 task 가 실 행 된 후에 다른 task 는 바로 보충 할 수 있 습 니 다. cpu core 가 한가 하지 않도록 하 는 동시에 spark 작업 운행 의 효율 과 속 도 를 최대한 향상 시 켜 성능 을 향상 시 킬 수 있 습 니 다.
(3) Spark Application 의 병행 도 를 어떻게 설정 합 니까?

SparkConf conf = new SparkConf() //
        .setAppName(Constants.SPARK_APP_NAME_SESSION) //
        .setMaster("local") //
        .set("spark.default.parallelism", "10"); //      ，       cpu   2~3 。