1

4つのコアノードを使用しています..

ハイブを使用してテーブルでクエリを実行しています。

さまざまなクエリが容量を使用しているようです。

私のテーブルは、8 つの整数フィールドと約 1000 行で構成されています。

フォームのクエリ

tbl から avg(col1-col2) を選択します。tbl から count(*) を選択します。私が試した他のすべてのクエリは生成されています

レデューサーの数=1、マッパーの数=1

set mapred.reduce.tasks=4; を使用してみました。

しかし、うまくいきません。

最も奇妙なことは、mapred.job.tracker=local を使用すると、ローカル ノード自体で 1 つのマップと 1 つのリデュースを使用すると、タスクが 2 倍速く終了することです。

1 つを除くすべての reduce/map スロットは常に開いています。

容量を追加しても実行時間が少しでも改善されないのはなぜですか? データ サンプルが小さすぎて、容量を増やしても問題がなく、マッピングと削減をローカライズすることで実際に時間が改善されますか?

4

1 に答える 1

2

単一のマッパーを取得する理由は、テーブルが非常に小さいためです。1000行のテーブルは、HDFSブロックサイズよりもはるかに小さい1つのファイルであると想定しています。100 万行以上のテーブルを試してみると、複数のマッパーが使用されていることがわかります。この質問への回答には、マッパーの数を選択する方法に関する詳細情報が含まれています。

単一のレデューサーを取得する理由は、2 つの組み合わせです。まず、(Hive 用の) 少量のデータを処理しているため、最終的に 1 つのレデューサーになります。次に、一部のクエリ ( などCOUNT(*) FROM some_table) には 1 つのレデューサーが必要です (こちらの質問を参照してください) 。

ジョブをローカルで実行する方が高速である理由がよくわかりました。1000 行のテーブルは、クエリのロジックをテストするには最適ですが、実行時間などを決定するには適していません。ローカルではなくクラスターで Hive を実行すると、GB 単位のデータが得られてはじめて、パフォーマンスが向上する可能性があります。Hive は、少なくとも数十 GB のクエリに到達するまでは、間違いなく「仕事に適したツール」ではありません。

于 2013-05-29T13:32:16.497 に答える