カスケード/スカルディングがマップ側の評価を最適化する方法についての通知があります 。彼らはいわゆる部分集計を使用しています。コンバイナーよりも実際に良いアプローチですか?いくつかの一般的な Hadoop タスク (単語数など) でのパフォーマンスの比較はありますか? もしそうなら、hadoop は将来これをサポートしますか?
2 に答える
実際には、コンバイナーを使用するよりも、部分的な集約の方がより多くの利点があります。
コンバイナが役立つケースは限られています。また、コンバイナーは、リデュースの数ではなく、タスクに必要なスループットの量を最適化します。これは、重要なパフォーマンス デルタにつながる微妙な違いです。
大規模な分散ワークフローでの部分集計には、はるかに幅広い使用例があります。また、部分集計を使用して、ワークフローに必要なジョブ ステップの数を最適化できます。
例は、部分的な集計を使用するhttps://github.com/Cascading/Impatient/wiki/Part-5に示されています。そのプロジェクトの GitHub でのコード コミット履歴を振り返ると、以前はとが使用されていたため、さらに削減されました。CountBy
SumBy
GroupBy
Count
特定のタイプの集計に適しています。カスケード集計は、何を集計できるかに関して、もう少し柔軟です。 カスケードサイトから(強調鉱山):
カスケードは、いわゆる MapReduce コンバイナーをサポートしていません。コンバイナーは、マッパーとリデューサー間の IO を削減するという点で非常に強力です。Map 側でいくつかの値を計算し、それらを Reducer で組み合わせることができるのに、すべての Mapper to data を Reducer に送信するのはなぜですか。ただし、コンバイナーは 'sum' や 'max' などの連想関数と可換関数のみに制限されています。そして、機能するためには、Map タスクから発行された値をシリアライズして並べ替え (デシリアライズして比較)、再度デシリアライズして操作する必要があります。コンバイナーは、CPU を交換して IO を増やします。
カスケードは、Map 側で部分集計を実行し、Reduce 側でもそれらを結合するメカニズムを提供することにより、異なるアプローチをとります。しかし、Cascading は、値を (しきい値まで) キャッシュすることによって、メモリと IO ゲインを交換することを選択します。このアプローチは、不要なシリアル化、逆シリアル化、および並べ替えの手順をバイパスします。また、連想関数や可換関数だけでなく、任意の集計関数を実装できます。