스파크 클러스터가 작은 데이터로 확장되지 않습니다

Question

현재 선형 회귀 (스파크 ML)의 벤치 마크가있는 작은 클러스터 (3 개의 노드가 32 개의 CPU 및 128GB 램)에서 Spark 2.1.0을 평가 중입니다. 필자는 매개 변수 계산 (시작, 데이터로드 등을 포함하지 않음) 시간 만 측정하고 다음 동작을 인식했습니다. 작은 데이터 세트 0.1 Mio - 3 Mio 데이터 포인트의 경우 측정 된 시간은 실제로 증가하지 않고 약 40 초 정도입니다. 300 Mio 데이터 포인트와 같은 더 큰 데이터 세트의 경우에만 처리 ​​시간이 최대 200 초가되었습니다. 따라서 클러스터는 작은 데이터 집합으로는 확장되지 않습니다.

필자는 로컬 PC의 작은 데이터 세트를 10 명의 직원과 16GB RAM 만 사용하는 클러스터와 비교했습니다. 클러스터의 처리 시간은 3 배 더 큽니다. 이것은 SPARK의 정상적인 동작으로 간주되며 통신 오버 헤드로 설명 할 수 있습니까? 아니면 내가 잘못하고있는 것입니까 (아니면 실제로 회귀가 아닌 선형 회귀입니까?)?

클러스터는 독립 실행 형 클러스터 (원사 또는 메소 스가 없음)이고 벤치 마크는 90 인 작업자와 함께 제출되며 각각 1 코어 및 4GB 램이 있습니다.

스파크 제출 : ./spark-submit --master의 불꽃을 : // 서버 : 7077 --class 벤치 마크 --deploy 모드 클라이언트 --total - 집행 - 코어 90 --executor 메모리 4g - num-executor 90 .../Benchmark.jar pathToData

Answer 1

최적의 클러스터 크기 및 구성은 데이터 및 작업의 성격에 따라 다릅니다. 이 경우, 직감이 정확하다고 생각합니다. 클러스터의 크기 (코어 및 집행자)의 초과 오버 헤드 때문에 작은 데이터 세트에서 완료하는 데 시간이 너무 많이 걸리는 것으로 보입니다.

데이터 크기를 두 자리만큼 증가 시키면 처리 시간이 5 배 늘어납니다. 클러스터 설정을 위해 최적의 크기로 데이터를 증가시키고 있습니다.

스파크는 많은 양의 데이터를 처리하기위한 훌륭한 도구이지만, 데이터가 적합하면 단일 컴퓨터에서 단일 프로세스를 실행하는 데 경쟁력이 없습니다. 그러나 데이터가 단일 시스템에 들어 가지 않는 디스크 기반의 다른 분산 처리 도구보다 훨씬 빠릅니다.

저는 연설에서 몇 년 전 Spark가 자전거를 경주하는 기관차와 같은 비유를 말했습니다. - 짐이 가벼운 경우 자전거가 승리 할 것이고, 가속하는 것이 더 민첩하지만 무거운 짐으로 기관차는 속도를 높이려면 시간이 걸릴 수 있지만 결국에는 더 빨라질 것입니다. (나는 스피커 이름을 잊어 버릴까 두렵다.하지만 그것은 런던의 카산드라 모임에 있었고 연사는 에너지 분야의 회사 출신이었다.)

Answer 2

@ ImDarrenG의 평가 및 일반적으로 기관차/자전거 유추에 동의합니다. 이와 같은 데이터의 소량

, 나는 강하게 당신이 당신의 300M 같은 것을 할 필요 특히 (각 노드에 데이터 집합을 방송 전체 데이터 세트 및

B)를 캐싱)

를 추천 할 것입니다 행 테이블 조인을 작은 데이터 세트에 연결)

또 다른 고려해야 할 사항은 파일 수 (캐시되지 않은 경우)입니다. 분리 할 수없는 파일 하나를 읽는 경우 1 코어 만 수행 할 수 있기 때문입니다. 그러나 해당 파일 세트를 캐시하면 (적절하게 병합 또는 재분할) 성능이 저하됩니다. onger는 디스크에 바인딩되거나 행을 직렬화합니다.