에서 높은 수준의 관점, 두 사람은 큰 차이가 없습니다.
모두 매퍼 ( 스파크 가 ShuffleMapTask의 출력)는 파티션 , 다른 파티션을 다른에 감속기 ( 스파크 레인 감속기는 다음 될 수있다 단계 에서 ShuffleMapTask을 , 그것은있을 수 있습니다 ResultTask ). 감속기 측위한 버퍼 메모리 셔플 측 집계 데이터까지 데이터 집계 좋은 후 ) (줄이거 ( 스파크 이는 후속하는 일련의 동작 일 수있다).
로부터 낮은 수준의 관점 차이는 작지 않다.
하둡 맵리 듀스는 이다 정렬 기반의 (가)에, 결합 () 와 (감소) 기록 해야합니다 정렬 . 이것은이 장점 갖는다 ) (감소 / 결합 이 (유출로 얻을 수 있기 때문에 대용량의 데이터는 입력 데이터를 처리 할 수 매퍼 데이터마다 먼저 정렬 할 감속기 의 셔플 병합 않는 정렬 데이터의 각 부분에 대한 참조). 현재 스파크 기본 선택은 해시 기반 , 보통 해시 맵 올 SHUFFLE 데이터에 의해 수행 집계 사전에 데이터를 정렬하지 않습니다. 당신이 정렬 된 데이터가 필요한 경우에, 당신은 자신과 비슷한 호출 할 필요가 sortByKey () 작동, 당신이 경우 1.1 스파크 사용자가 할 수 spark.shuffle.manager 설정 정렬을 , 데이터를 정렬합니다. 에1.2 스파크 ,에서를 정렬 과 같은 기본 셔플 달성했다.
보기의 구현 관점에서, 두 많은 차이가 있습니다.
하둡 맵리 듀스 명확한 단계로 처리 과정 : 지도 (), 유출, 셔플을 병합 정렬의 감소 () 등이있다. 임무의 각 단계에서, 절차 형 프로그래밍의 사상에 따른 함수의 각 단계에 의해 달성 될 수있다. 에서 스파크 , 거기에 그러한 기능을 명확 단계 만 차이가 없습니다 단계 및 일련의 변화를 () 소위, 유출, 병합, 집계 및 기타 작업에 내재 필요 () 변환 한다.
우리가하면 지도 최종 파티션 데이터, 프로세스는 지속적인 데이터라고 쓰기 셔플 그동안, 감속기는 데이터 읽기 집계 언급 프로세스 데이터 읽기 셔플을 . 그런 다음 스파크 , 문제는 어떻게되고 작업이 논리적 또는 물리적 실행 그림에 가입 셔플 쓰기 및 읽기 셔플 처리 로직을? 그리고이 개 매우 효율적으로 처리 로직은 어떻게 달성해야 하는가?
쓰기 셔플 가 데이터 순서를 필요로하지 않기 때문에, 쓰기 셔플 작업은 간단하다 : 데이터 파티션이 좋은, 그리고 지속성이다. 한편으로 지속되는 이유는, 장애 허용을위한 또 다른 한편으로는, 메모리 저장 압력을 감소시킨다.