私の問題では、100 TB のデータを処理する必要があります。このデータセットの各ファイルは約 1 MB で、定義した 10,000 を超える異なる「グループ」のうち最大 3 つに属することができます。ファイルのすべてのグループをまとめて処理する必要があり、グループ内には数個から数百個のファイルが存在する可能性があります。そのようなグループが何万もあるので、これは MapReduce の有力な候補であると考えています。
Hadoop のようなものを使用して、このジョブをセットアップする方法が 2 つ考えられます (おそらく他にもあります)。
マップのみ: グループごとにファイルをアーカイブするため、分割とその後のマッピングはグループ レベルで行われます。すべてのマップ ジョブにはグループ全体があるため、それ自体で処理を行うことができ、reduce ジョブは必要ありません。しかし、このソリューションにはいくつかの問題があります。まず、ファイルは最大 3 つのグループに存在できるため、グループごとにアーカイブすると、Hadoop のレプリケーション ファクターに加えて、ストレージのオーバーヘッドが 3 倍になる可能性があります。さらに、このようにデータをアーカイブすると、ファイルを異なる方法で処理する他のアプリケーションで使用できなくなります。
Reduce-only : 私が理解しているように、このパラダイムは単純な「アイデンティティ」マッパーとデータ集約型のレデューサーを意味します。このソリューションでは、ファイルはディスク上に順不同で保存され、マッパーは処理する一連のファイルを受け取ります。次に、マッパーはファイルをメモリ (少なくともそのヘッダー情報) に読み取って、ファイルが属するグループを特定し、(グループ、ファイル) のペアを出力して削減します。レデューサーは、グループの処理を担当します。ただし、この方法を使用すると、データの局所性の利点が失われたり、データ トラフィックが多すぎてネットワークが滞ったりするのではないかと心配しています。
両方の方法は有効ですか? もしそうなら、どちらが好ましいでしょうか？具体的には、Map のみのソリューションの長所と短所はかなりよく理解していますが、Reduce のみのソリューションは理解していません。「データ ローカル」リデュース ジョブがどのようなものか、またはリデュース タスクで「重労働」を行うのが悪い習慣と見なされているかどうかはわかりません。