データサイエンス設計マニュアル

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 枚のコインを投げて表と裏が同

じ枚数になることはまずない。しかし、キーの頻度がべき乗則分布に従っており、最も頻出するキーが出現

回数に影響することの方が原因としては深刻である。単語の出現頻度計算の問題について考えてみよう。単 ...