MapReduce의 참신함은 무엇입니까?

몇 년 전 MapReduce 는 분산 프로그래밍의 혁명으로 호평 을 받았습니다. 또한있어왔다 비판 하지만, 전반적으로 열정적 인 과대 광고가 있었다. 심지어 특허를 받았습니다! [1]

이름은 연상 map과 reduce기능적인 프로그래밍,하지만 난 읽을 때 (위키 백과)

맵 단계 : 마스터 노드는 입력을 가져 와서 작은 하위 문제로 나누고 작업자 노드에 분배합니다. 작업자 노드는 다시이 작업을 수행하여 다단계 트리 구조로 이어질 수 있습니다. 작업자 노드는 더 작은 문제를 처리하고 응답을 마스터 노드로 다시 전달합니다.

단계 축소 : 마스터 노드는 모든 하위 문제에 대한 답변을 수집하여 어떤 방식 으로든 출력을 형성합니다. 원래 해결하려는 문제에 대한 답변입니다.

또는 [2]

MAP의 내부 : [...] MAP은 입력 값을 단어로 나눕니다. [...] MAP은 입력의 각 주어진 키 / 값 쌍을 잠재적으로 많은 중간 키 / 값 쌍과 연관시키는 것을 의미합니다.

REDUCE의 내부 : [...] [REDUCE]는 명령 집계 (예 : 축소)를 수행합니다. 많은 값을 가져 와서 단일 값으로 줄입니다.

나는 도움이되지만 생각할 수 없다이는 분할 및 정복 평범하고 단순하게 (머지 소트의 의미에서)! 그렇다면 MapReduce에 (개념적) 참신함이 있습니까? 아니면 특정 시나리오에서 유용한 오래된 아이디어의 새로운 구현입니까?

1. 미국 특허 7,650,331 : "효율적인 대규모 데이터 처리를위한 시스템 및 방법" (2010)
2. 구글의 MapReduce 프로그래밍 모델 — R. Lämmel (2007)

나는 도울 수 없지만 생각합니다 : 이것은 단순하고 단순하고 분열입니다!

M / R은 분할 및 정복이 아닙니다. 이전 입력의 더 작은 서브 세트에 알고리즘을 반복적으로 적용하지는 않습니다. 파이프 라인 단계가 맵을 대체하고 작업을 줄이는 파이프 라인 (더 간단한 함수의 구성으로 지정된 함수)입니다. 다른 단계는 다른 작업을 수행 할 수 있습니다.

그렇다면 MapReduce에 (개념적) 참신함이 있습니까? 아니면 특정 시나리오에서 유용한 오래된 아이디어의 새로운 구현입니까?

MapReduce는 계산 이론에서 새로운 지평을 열지 않습니다. 문제를 간단한 작업으로 분해하는 새로운 방법을 보여주지는 않습니다. 특정 간단한 분류가 특정 종류의 문제에 실용적임을 보여줍니다.

맵리 듀스 용지의 공헌이었다

1. 특정 문제에 대해 효율적이고 내결함성으로 분배 될 수있는 잘 이해 된 두 직교 연산자의 파이프 라인 평가 : 큰 말뭉치의 텍스트 색인 작성
2. 노드간에 전송되는 데이터 양과 단계별 지연 시간 차이가 전체 대기 시간에 미치는 영향을 보여주기 위해 해당 문제에 대한 맵 축소
3. 계산 중 기계 고장을 자동으로 보상 할 수 있도록 시스템 결함 허용 방법을 보여주는 방법
4. 유용한 유용한 구현 선택 및 최적화 식별

일부 비판은 다음과 같은 수업에 속합니다.

1. "지도 / 축소는 계산 이론에서 새로운 지평을 열지 않습니다." 참된. 원래 논문의 기여는 특정 최적화 세트를 갖춘 잘 이해 된 운영자가 일회성 솔루션보다 더 쉽고 결함에 대한 실제 문제를 해결하는 데 성공적으로 사용되었다는 것입니다.
2. "이 분산 계산은 맵으로 쉽게 분해 및 축소되지 않습니다." 충분히 공평하지만 많은 사람들이 그렇습니다.
3. "n 맵 / 감소 단계의 파이프 라인은 결과가 생성되기 전에 파이프 라인의 감소 단계 수에 비례 한 대기 시간이 필요합니다." 아마 맞습니다. 감속기는 전체 출력을 생성하기 전에 모든 입력을 수신해야합니다.
4. "이 사용 사례에서는 맵 / 축소가 과도합니다." 아마도. 엔지니어가 반짝이는 새 망치를 찾으면 못처럼 보이는 것을 찾는 경향이 있습니다. 그렇다고 망치가 특정 틈새 시장에서 잘 만들어진 도구가 아니라는 의미는 아닙니다.
5. "지도 / 축소는 관계형 DB를 대체하기에 적합하지 않습니다." 참된. 관계형 DB가 데이터 세트로 확장되는 경우 훌륭한 옵션입니다.

편집 (2014 년 3 월) 이후 MapReduce 유형의 계산 모델 알고리즘에 대해 더 많은 노력을 기울였으며 지나치게 부정적이라고 생각합니다. 아래에서 이야기하는 Divide-Compress-Conquer 기술은 놀랍도록 다재다능하며, 사소하고 흥미 롭다고 생각되는 알고리즘의 기초가 될 수 있습니다.

포괄적 인 측면에서 Mike의 계산보다 열등 할 수 있지만 계산 / 알고리즘 이론의 관점에서 볼 때 답을 제시하겠습니다.

흥분되는 이유 : MapReduce 는 병렬 및 순차적 계산을 인터리브합니다. 각 프로세서는 입력의 사소한 청크 (예 : )에 액세스 할 수 있으며 사소한 작업을 수행 할 수 있습니다. 그것은 PRAM 모델과는 매우 다르며 새로운 알고리즘 기법으로 이어질 흥미로운 아이디어처럼 보입니다. 특히, 일부 문제는 몇 번의 (입력 크기에 따라) 계산 계산으로 해결할 수있는 반면, PRAM에서는 시간 내에 사소한 문제를 해결할 수 없습니다 .$O(n^\epsilon)$$o(\log n)$

왜 모델이 약간 실망스러워 하는가 : 라운드 알고리즘 을 얻는데 효과가 있고 다소 새로운 알고리즘 기법 은 다음과 같습니다.$O(1)$

• 문제 인스턴스를 분할 (종종 무작위로)
• 각 파티션에서 일부 계산을 병렬로 수행하고 계산 결과를 컴팩트하게 나타냅니다.
• 컴팩트하게 표현 된 모든 하위 문제 솔루션을 단일 프로세서에 결합하고 계산을 완료하십시오.

이 기술의 매우 간단한 예 : 숫자 의 합을 계산하십시오 . 각 프로세서는 어레이의 를 가지며 해당 부분의 합계를 계산합니다. 그런 다음 모든 합계를 단일 프로세서에서 결합하여 총 합계를 계산할 수 있습니다. 약간 더 흥미로운 연습은 이런 방식으로 모든 접두사 합계를 계산하는 것입니다 (물론 출력은 분산 방식으로 표현되어야합니다). 또는 밀도 그래프의 스패닝 트리를 계산하십시오.$n$$O(\sqrt{n})$$\sqrt{n}$

이제는 이것이 분할 및 정복에 대한 흥미로운 왜곡이라고 생각합니다. 분할 단계 후에 단일 프로세서가 정복 할 수 있도록 하위 문제 솔루션을 압축해야한다는 것이 비결입니다. 그러나 이것은 지금까지 우리가 생각 해낸 유일한 기술인 것 같습니다. 예를 들어 스파 스 연결과 같은 스파 스 그래프 문제에서는 실패합니다. 이것을 스트리밍 모델과 비교하면 Flajolet과 Martin의 독창적 인 샘플링 알고리즘, Misra와 Gries의 결정 론적 페어링 알고리즘, 간단한 스케치 기술의 힘 등과 같은 풍부한 새로운 아이디어가 생겼습니다.

프로그래밍 패러다임으로서 맵 축소는 매우 성공적이었습니다. 저의 의견은 맵 축소를 흥미로운 계산 모델로 간주합니다. 좋은 이론적 모델은 조금 이상합니다. 만약 그들이 현실을 너무 밀접하게 따르는 경우, 다루기 힘들지만, 더 중요한 것은 (머신 러닝에서 용어를 빌리기 위해) 너무 특이한 모델에 대한 이론은 일반화되지 않는다는 것, 즉 다른 모델에서는 유지하지 않는다는 것이 증명되었다. 그렇기 때문에 우리는 가능한 한 많은 세부 사항을 추상화하고 새로운 알고리즘을 생각해내는 데 어려움을 겪고 있습니다. 마지막으로, 새로운 아이디어는 결국 현실 세계로 돌아갈 수 있어야합니다. PRAM은 흥미로운 아이디어로 이어지는 비현실적인 모델이지만 실제 병렬 계산에는 거의 적용되지 않는 것으로 판명되었습니다. 반면 스트리밍은 비현실적입니다. 그러나 실제로 현실에서 사용되는 알고리즘 아이디어에 영감을주었습니다. 보다카운트 분 스케치 . 실제로 스케치 기법은 맵 축소를 기반으로하는 시스템에서도 사용됩니다.

나는 당신에게 전적으로 동의합니다. 개념적인 관점에서 볼 때 실제로 새로운 것은 없습니다. Map / Reduce는 원래 병렬 컴퓨팅에서 데이터 흐름 프로그래밍 모델로 알려져있었습니다. 그러나 실용적인 관점에서 Google이 제안한 Map / Reduce와 그 이후의 오픈 소스 구현으로 인해 Cloud Computing에 연료가 공급되었으며 현재 매우 간단한 병렬 분해 및 처리에 널리 사용됩니다. 물론 복잡한 도메인이나 기능적 분해가 필요한 다른 제품에는 적합하지 않습니다.

나는 당신이 당신의 의견으로 머리에 못을 박았다고 생각합니다.

모든 기능적 언어 맵에서 병렬화 될 수 있다는 것은 사실이 아닙니다 . 언어는 순수 해야합니다 . (저는 Haskell이 유일한 모호한 주류 순수 기능 언어라고 생각합니다. Lisp, OCaml 및 Scala는 모두 순수하지 않습니다.)

엔지니어가 처음 프로세서를 파이프 라인으로 만들었던 시간 공유 이전부터 순수한 코드의 이점에 대해 알고 있습니다. 그러면 어떻게 순수한 언어를 사용하지 않습니까?

정말 정말 정말 어렵습니다. 순수한 언어로 프로그래밍하는 것은 종종 양손을 등 뒤로 묶는 프로그래밍처럼 느껴집니다.

MR이하는 일은 순도 제약을 다소 완화하고 셔플 단계와 같은 다른 부분에 대한 프레임 워크를 제공하여 많은 부분의 문제에 대해 배포 가능한 코드를 작성하는 것이 매우 쉽습니다.

" 의 중요한 하위 부류를 증명합니다"와 같은 대답을 기대하고 있다고 생각합니다. 그것이하는 것은 배포 가능한 것으로 알려진 문제의 클래스가 "쉽게"배포 가능하다는 것을 보여주는 것입니다. 귀하의 의견에 "혁명"이 있는지 여부는 아마도 사전 맵 / 리 듀스에서 분산 코드를 디버깅하는 데 걸린 시간에 달려 있습니다. 세계.$NC=P$