
378 12 章 ビッグデータ:スケールを追求
プログラミングでも、Spark が Hadoop よりも性能的に大きく進歩した要因の 1 つである。
図 12 -2 は
、3 個の Map と 2 個の Reduce を使って単語の出現頻度を数える MapReduce ジョブの処理の
流れを示したものである。局所的に結合処理が行われているため、入力ファイル内で複数回使われている単
語(この場合は「do」、「be」、「duty」)の出現頻度は、Reduce に放出される前に合計されている。
図 12 -2 は、マッピングの歪みの問題を示している。つまり、個々の Reduce に割り振られた作業量は、自
然に不均衡になる。この単純な例でも、上の Reduce は下の Reduce と比べて単語数にして 33 % 、頻度の数
値にして 60 % 多い。直列(並列処理なし)の実行時間が T のタスクの場合、n 個のプロセッサで完全な並
列処理ができれば、実行時間は T /n で済むはずである。しかし、MapReduce ジョブの実行時間は、最も大
きく、処理に時間がかかる箇所によって決まる。Map の歪みのために、最大のピースは平均サイズよりもか
なり大きくなってしまうことが多い。
たまたまのめぐり合わせは、確かに Map の歪みの原因の 1 つになる。n 枚のコインを投げて表と裏が同
じ枚数になることはまずない。しかし、キーの頻度がべき乗則分布に従っており、最も頻出するキーが出現
回数に影響することの方が原因としては深刻である。単語の出現頻度計算の問題について考えてみよう。単 ...