2

私は私のチームと一緒に、多くの入力 (1 日のログファイル) を取り、いくつか (現在は 4、将来的にはおそらく 10) の map-reduce ステップ (Hadoop & Java) の後に有用な出力を生成する小さなアプリケーションで作業しています。 .

このアプリの部分的な POC を実行し、4 つの古いデスクトップ (私の Hadoop テスト クラスター) で実行しました。私が気付いたのは、パーティショニングを「間違って」行うと、水平スケーリングの特性が認識できないほど破壊されるということです。1 つのノード (たとえば 20 分) でのテスト実行と 4 つのノードすべてでのテスト実行を比較すると、75% (または少なくとも >70%) の高速化 (約 5または6分)。

map-reduce スケールを水平方向に作成する一般的な原則は、パーティションが可能な限り独立していることを確認することです。私の場合、デフォルトのハッシュパーティショナーを使用しただけなので、各ステップのパーティショニングを「間違って」行ったことがわかりました。これにより、レコードは次の map-reduce ステップで別のパーティションに移動します。

可能な限り多くのレコードを同じパーティションに保持する (つまり、カスタム パーティショナーを構築する) ことができれば、処理速度が向上し、スケーリングが大幅に向上することを期待しています (まだ試していません)。

上記のケースでは、この解決策を手作業で見つけました。私は仕事に行く車の中でこれについて一生懸命考えて、何が悪いのかを推測しました.

皆さんに質問です: - このような問題を検出するために利用できるツールは何ですか? - 従うべきガイドライン/チェックリストはありますか? - 「パーティションをジャンプしたレコードの数」などを測定するにはどうすればよいですか?

提案 (ツール、チュートリアル、本など) は大歓迎です。

4

2 に答える 2

0

小さなファイルの問題が発生していないことを確認してください。Hadoop はレイテンシーではなくスループットを重視して最適化されているため、多数のログ ファイルを 1 つの大きなシーケンス ファイルに結合すると、hdfs に保存された多くの個別のファイルよりもはるかに高速に処理されます。このようにシーケンス ファイルを使用すると、個々のマップのハウスキーピングに必要な余分な時間がなくなり、タスクが減り、データの局所性が向上します。しかし、そうです、いくつかのレデューサーが不均衡な量の作業で過負荷にならないように、マップ出力がレデューサーに適切に分散されていることが重要です。

于 2010-07-08T02:33:32.207 に答える
0

Netbeans/Eclipse 用の Karmashpere (以前は Hadoop Studio として知られていた) プラグイン ( http://karmasphere.com/Download/download.html ) をご覧ください。Hadoop ジョブの検出とテスト実行に役立つ無料バージョンがあります。
私はそれを少しテストしましたが、有望に見えます。

于 2010-08-04T22:23:00.277 に答える