0

私はAWS上のHive（特にEMR）を調べていました。彼らは2つのオプションを提供しています

  1. 事前に指定された Hive クエリ (ブートストラップで) の実行が評価された後、EMR クラスターが破棄されるアドホック クラスターの生成。
  2. hiveコマンド ライン クライアントを使用してマスターに SSH で接続し、Hive クエリを提供できるインタラクティブ モードで Hive クラスターを生成します。

明らかに、2 番目のオプションでは、明示的に終了するように要求されるまで、クラスターは存続します。

キープアライブ ハイブ クラスタ内のスレーブ ノードの数を変更したいと考えています。の追加と削除をサポートするだけで、単なる追加（削除ではない）をサポートすることをemr faqで読みました。コアノードは HDFS ストレージに貢献しますが、タスクノードは貢献しません。task-nodescore-nodes

実行中のクラスターにコア ノードを追加し、実行中のクエリの数が少なくなったらそれらをスケールダウンしたいと考えています。これを達成する方法はありますか (cloudwatch を使用している可能性があります)?

4

4 に答える 4

5

クエリ数のスケールアップとスケールダウンは、データ量が変化しないため、タスクノード（Hadoopのコンピューティング部分）の数に関連し、コアノード（Hadoopのデータストレージ部分）の数には関連しません。

クエリをスケールアップおよびスケールダウンする場合のデータのリバランスと再配布はお勧めできません。遅すぎて複雑すぎて、実際の利益を得ることができません。

「使用した分だけ支払う」とEMRを構成せずにすばやく起動すると、不要なときにクラスターを強制終了し、必要なときに新しいクラスターを起動するように促されます。EMRでHiveを最適化して、クラスターの起動間でテーブルメタデータを外部MySQL DBに格納し、テーブル定義の欠落や繰り返しを回避できます。

于 2013-02-22T20:41:19.540 に答える
1

データノードもスケールアップすることには、ある程度の価値があります。長時間実行されるクラスターのタスク ノードだけで拡張しすぎると、HDFS のボトルネックが発生する可能性があります (大量の中間データがある場合)。

Qubole を検討したことはありますか? Qubole は、負荷に基づいて自動スケールアップおよびスケールダウンを提供します。ユーザーは、最小および最大のスレーブ ノードでクラスターを構成します。これらは、タスク ノードとデータ ノードの両方になります。

于 2015-09-24T20:00:38.017 に答える
0

ここでのパーティーに少し遅れていることは承知していますが、同様の問題を何度も経験しており、考えられる代替案を 1 つ共有したいと思います。処理中に EMR クラスターのサイズを動的に変更する Java ツールを作成しました。それは誰かを助けるかもしれません。でそれをチェックしてください：

http://www.lopakalogic.com/articles/hadoop-articles/dynamically-resize-emr/

ソースコードは Github で入手できます

于 2016-08-21T21:50:35.927 に答える