200 ノードの mapreduce ジョブがあり、実行中の削減ジョブが 3 つしか残っていない場合、マスターと実行中のジョブを含む 3 つを除くすべてのノードをオフにしても安全ですか? さらに、交換が必要な不良ノードの場合に備えて、さらにいくつかの可能性がありますか?
この質問に対する答えが「はい」の場合、emr がほとんどのノード ノードを使用していないときに自動的にオフにしないのは奇妙です。
EMR は Hadoop 上の非常に薄いレイヤーであることに注意してください。Amazon のファブリックで分散計算を行っている場合、Hadoop や Map/Reduce とはまったく似ていない特定のニーズに合わせてカスタマイズされたものを使用すると、非常に効率的になります。Hadoop で多くの負荷の高い作業を行っている場合は、多くの場合、独自のクラスターを使用するか、少なくともクラウド内に専用のクラスターを使用する方が適切です (そうすれば、データはローカル ディスク上で既にスライスされており、出力を永続化するだけで済みます)。ローカルディスク）。EMR の主な利点は、迅速で汚れがなく、AWS の他の部分 (S3 など) にうまく接続できることです。
最近、ほとんど終了したジョブがいくつかありましたが、いくつかの削減が残っています。使用されていないノードが稼働したままになるため、コストがかかっていると思います。
特に実行時間に関しては、間違いなくコストがかかります。なぜ完了時間がそれほど均一でないのかを心配することから始めます。
私が考えることができるこれらの問題があります：
-- データはいつ S3 にコピーされますか? reduce の実行に関してノードが使用されていない場合でも、S3 へのコピーにノードが必要になる可能性はありますか? その場合、私の質問への答えは、基本的にノードをオフにしても安全ではないということです
ジョブの出力を参照している場合、ジョブ構成の出力パスとして S3 がある場合、特定のタスクからのデータは、タスクが終了する前に S3 に書き込まれます。
-- 3 つのジョブのうちの 1 つが失敗した場合はどうなりますか? マスター/ジョブ コーディネーターは、それを別のノードに再割り当てする必要があります。どのボックスが稼働しているかを追跡でき、遮断されたボックスに誤って割り当てられない限り、安全だと思います。
うーん... それよりも少し複雑です... 新しいノードにジョブが割り当てられると、どこかからデータを取得する必要があります。それは通常、最初にデータを生成したマッパーからのものです。それらが存在しない場合は、マップ タスクを再実行する必要があります (または、ジョブが失敗する可能性が高くなります)。通常、マップ出力の複製係数は 1 であるため、これは完全に妥当なシナリオです。これは、Hadoop ジョブの「% 完了」が逆行するいくつかの理由の 1 つです。マッパーは 100% から <100% に戻ることさえあります。
これに関連して: レデューサー ジョブの段階によっては、フィードされるすべてのマップ出力をまだ受け取っていないことが考えられます。明らかに、その場合、間違ったマッパーを殺すことは致命的です。
オフラインの TaskTracker のみのノードと、TaskTracker + DataNode サービスを実行しているノードの違いを強調することが重要だと思います。後者を 2 つ以上削除すると、HDFS でブロックが失われますが、これは通常、仕事にとっては良いことではありません (仕事を分散する以外の目的で HDFS を実際に使用しない場合を除きます)。一度にいくつかのノードを切り離してから、リバランサーを実行して HDFS を「奨励」し、すべてのブロックのレプリケーション ファクターを最大 3 に戻すことができます。もちろん、これによりネットワーク トラフィックとディスク I/O がトリガーされます。残りのタスクを遅くします。
tl;dr: ノードを強制終了する際に問題が発生する可能性があります。S3 に出力を書き込む完了したタスクは、JobTracker がタスクの完了を通知されるまでにすべての出力を完全に書き出すと確信できますが、マップ タスクについては同じことが言えません。ローカル ディレクトリに出力し、非同期でデータをレデューサーに転送します。すべてのマップ出力がターゲット レデューサーに転送されたとしても、レデューサーが失敗した場合 (または、投機的実行が別のノードでタスクのスピンアップをトリガーした場合) は、Hadoop がそれらに頼る可能性が高いため、これらの他のノードが本当に必要になります。再割り当てされたレデューサーの入力データ用。
-- クリス
PS これは、実際には EMR 以外の Hadoop セットアップにとっても大きな問題点になる可能性があります (必要以上に長いノードに料金を支払う代わりに、膨大な計算時間とともに、実行できる作業があるときにノードがアイドル状態になっているように見えます)。ノード障害による損失)。原則として、問題を回避するための秘訣は次のとおりです。タスクのサイズをかなり一貫して 1 ～ 5 分の範囲に保ち、投機的実行を有効にします (ノードのパフォーマンスが一貫していない EMR の世界では非常に重要です)、レプリケーション係数を維持します。特定のジョブで予想されるノード損失をはるかに上回っています (ノードの信頼性に応じて、1 日のジョブ実行で 400 ノードを超えると、レプリケーション ファクター 4 について考え始めます)。古いジョブがまだ終了している間に新しいジョブを開始できるようにするジョブスケジューラを使用します（最近ではこれが通常デフォルトですが、Hadoop 0.20 IIRC で導入されたまったく新しいものでした）。mapout ディレクトリに SSD を使用するなどのクレイジーなことも聞いたことがあります (SSD はすべての書き込みからすぐに消耗する可能性がありますが、その障害シナリオは Hadoop ジョブにとって壊滅的ではない傾向があります)。