복붙노트

[HADOOP] Apache Spark : 코어의 수와 집행자의 수

HADOOP

Apache Spark : 코어의 수와 집행자의 수

YARN에서 Spark 작업을 실행할 때 코어 수와 실행자 수의 관계를 이해하려고합니다.

테스트 환경은 다음과 같습니다.

작업은 다음 구성으로 실행되었습니다.

경과 시간 :

놀랍게도 (3) 훨씬 빨랐습니다. 나는 (1) 더 빨리 될 것이라고 생각했다. 왜냐하면 셔플 할 때 집행자 간의 의사 소통이 적을 것이기 때문이다. (1)의 코어 수가 (3)보다 적지 만 코어 2 개가 잘 수행되었으므로 핵심 요소가 아닙니다.

(다음은 pwilmot의 답변 다음에 추가되었습니다.)

자세한 내용은 성능 모니터 화면 캡처는 다음과 같습니다.

그래프는 크게 두 부분으로 나뉩니다.

그래프에서 볼 수 있듯이 (1)은 주어진만큼의 CPU 성능을 사용할 수 있습니다. 따라서 스레드 수가 문제가되지 않을 수도 있습니다.

이 결과를 설명하는 방법?

해결법

  1. ==============================

    1.설명은 cloudera의 블로그에 실린 기사에서 제공되었습니다. http://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-2/

    설명은 cloudera의 블로그에 실린 기사에서 제공되었습니다. http://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-2/

  2. ==============================

    2.Sandy Ryza에 따르면, HDFS 위에 스파크 앱을 돌릴 때

    Sandy Ryza에 따르면, HDFS 위에 스파크 앱을 돌릴 때

    따라서 HDFS I / O 처리량이 좋지 ​​않아 첫 번째 구성이 세 번째 구성보다 속도가 느립니다.

  3. ==============================

    3.나는이 설정으로 직접 해본 적이 없으므로 이것은 추측 일 뿐이므로이 문제를 분산 시스템의 일반 코어 및 스레드로 생각하면 클러스터에 최대 12 코어 (4 * 3 머신) 및 24 스레드 (8 * 3 기계). 첫 번째 두 가지 예에서는 작업에 상당한 수의 코어 (잠재적 인 계산 공간)를 제공하지만 해당 코어에서 실행되는 스레드 (작업)의 수는 너무 제한되어 있으므로 할당 된 처리 능력의 상당 부분을 사용할 수 없습니다 따라서 더 많은 연산 리소스가 할당 되었더라도 작업은 더 느립니다.

    나는이 설정으로 직접 해본 적이 없으므로 이것은 추측 일 뿐이므로이 문제를 분산 시스템의 일반 코어 및 스레드로 생각하면 클러스터에 최대 12 코어 (4 * 3 머신) 및 24 스레드 (8 * 3 기계). 첫 번째 두 가지 예에서는 작업에 상당한 수의 코어 (잠재적 인 계산 공간)를 제공하지만 해당 코어에서 실행되는 스레드 (작업)의 수는 너무 제한되어 있으므로 할당 된 처리 능력의 상당 부분을 사용할 수 없습니다 따라서 더 많은 연산 리소스가 할당 되었더라도 작업은 더 느립니다.

    당신은 당신의 걱정이 셔플 단계에 있다고 언급합니다 - 셔플 단계에서 오버 헤드를 제한하는 것이 좋지만 일반적으로 클러스터의 병렬 처리를 이용하는 것이 훨씬 더 중요합니다. 극단적 인 경우 - 셔플이없는 단일 스레드 프로그램을 생각해보십시오.

  4. ==============================

    4.나는 여기서의 대답이 여기에있는 권고들 중 일부보다 조금 더 간단하다고 생각한다.

    나는 여기서의 대답이 여기에있는 권고들 중 일부보다 조금 더 간단하다고 생각한다.

    나를위한 단서는 클러스터 네트워크 그래프에 있습니다. run 1에서 사용률은 ~ 50 M bytes / s에서 일정합니다. 런 3의 경우, 100 M 바이트 / s 정도의 안정적인 사용률이 배가됩니다.

    DzOrd가 공유하는 cloudera 블로그 게시물에서 중요한 인용문을 볼 수 있습니다.

    그래서, 몇 가지 계산을 해보자. 그것이 사실이라면 우리가 기대하는 성능을 보자.

    작업이 동시성 (스레드 수)에 의해 100 % 제한되면. 우리는 런타임이 스레드의 수와 완벽하게 반비례 할 것으로 기대합니다.

    ratio_num_threads = nthread_job1 / nthread_job3 = 15/24 = 0.625
    inv_ratio_runtime = 1/(duration_job1 / duration_job3) = 1/(50/31) = 31/50 = 0.62
    

    그래서 ratio_num_threads ~ = inv_ratio_runtime, 우리는 네트워크가 제한적인 것처럼 보입니다.

    이 같은 효과는 Run 1과 Run 2의 차이점을 설명합니다.

    효과적인 스레드의 수와 런타임 비교 :

    ratio_num_threads = nthread_job2 / nthread_job1 = 12/15 = 0.8
    inv_ratio_runtime = 1/(duration_job2 / duration_job1) = 1/(55/50) = 50/55 = 0.91
    

    마지막 비교만큼 완벽하지는 않지만 스레드를 잃을 때 성능이 비슷한 수준으로 떨어지는 것을 볼 수 있습니다.

    이제 마지막 비트를 위해 : 더 많은 스레드와 함께 더 나은 성능을 얻는 이유는 무엇입니까? CPU 수보다 많은 스레드?

    병렬 코드 (데이터를 여러 개의 CPU로 나누어 얻음)와 동시성 (단일 CPU에서 작업하기 위해 여러 스레드를 사용할 때 얻을 수있는 것)의 차이점에 대한 좋은 설명은 Rob Pike의 위대한 게시물에서 제공됩니다. 동시성 병렬 처리가 아닙니다.

    짧은 설명은 Spark 작업이 파일 시스템이나 네트워크와 상호 작용할 경우 CPU가 이러한 인터페이스와의 통신을 기다리고 실제로 "작업 중"많은 시간을 소비하지 않는 데 많은 시간을 소비한다는 것입니다. 한 번에 하나 이상의 작업을 처리하는 CPU를 제공함으로써 대기 시간을 줄이고 작업 시간을 단축하고 성능을 향상시킬 수 있습니다.

  5. ==============================

    5.RStudio의 Sparklyr 패키지 페이지에서 제공되는 우수한 리소스를 통해 :

    RStudio의 Sparklyr 패키지 페이지에서 제공되는 우수한 리소스를 통해 :

  6. ==============================

    6.중요한 이유 중 하나는 지역이라고 생각합니다. 입력 파일 크기는 165G이며 파일 관련 블록이 여러 DataNode에 확실하게 분산되어 있으므로 더 많은 집행자가 네트워크 복사를 피할 수 있습니다.

    중요한 이유 중 하나는 지역이라고 생각합니다. 입력 파일 크기는 165G이며 파일 관련 블록이 여러 DataNode에 확실하게 분산되어 있으므로 더 많은 집행자가 네트워크 복사를 피할 수 있습니다.

    executor num 블록을 같게 설정하려고하면 더 빠를 것이라고 생각합니다.

  7. ==============================

    7.Spark Dynamic 할당은 유연성을 제공하고 리소스를 동적으로 할당합니다. 이 최소 및 최대 실행자 수가 주어질 수 있습니다. 또한 응용 프로그램 시작시 실행해야하는 실행 프로그램의 수를 지정할 수도 있습니다.

    Spark Dynamic 할당은 유연성을 제공하고 리소스를 동적으로 할당합니다. 이 최소 및 최대 실행자 수가 주어질 수 있습니다. 또한 응용 프로그램 시작시 실행해야하는 실행 프로그램의 수를 지정할 수도 있습니다.

    같은 내용을 아래에서 읽으십시오.

  8. ==============================

    8.제 생각에는 처음 두 가지 구성에 작은 문제가 있습니다. 스레드와 코어의 개념은 다음과 같습니다. 스레딩의 개념은 코어가 이상적이라면 코어를 사용하여 데이터를 처리하는 것입니다. 따라서 메모리는 처음 두 가지 경우에 완전히 활용되지 않습니다. 이 예제를 벤치 마크하려면 각 머신에 10 개 이상의 코어가있는 머신을 선택하십시오. 그런 다음 벤치 마크를하십시오.

    제 생각에는 처음 두 가지 구성에 작은 문제가 있습니다. 스레드와 코어의 개념은 다음과 같습니다. 스레딩의 개념은 코어가 이상적이라면 코어를 사용하여 데이터를 처리하는 것입니다. 따라서 메모리는 처음 두 가지 경우에 완전히 활용되지 않습니다. 이 예제를 벤치 마크하려면 각 머신에 10 개 이상의 코어가있는 머신을 선택하십시오. 그런 다음 벤치 마크를하십시오.

    그러나 집행자 당 5 개 이상의 코어를 제공하면 i / o 성능에 병목이 생깁니다.

    따라서이 벤치 마킹을 수행하는 가장 좋은 기계는 10 코어를 갖는 데이터 노드 일 수 있습니다.

    데이터 노드 머신 사양 : CPU : 코어 i7-4790 (코어 수 : 10, 스레드 수 : 20) RAM : 32GB (8GB x 4) HDD : 8TB (2TB x 4)

  9. from https://stackoverflow.com/questions/24622108/apache-spark-the-number-of-cores-vs-the-number-of-executors by cc-by-sa and MIT license