まず、糸は何ですか？
ApacheのHadoopのYARN（もう一つの資源交渉 、 別のリソースコーディネーター）は新しいHadoopのエクスプローラ、それは上側のリソース管理とスケジューリングのための統一されたアプリケーションを提供ユニバーサルリソース管理システムであり、その導入がありますクラスタは、資源の利用、一元管理やデータ共有の面で大きなメリットをもたらしています。
第二に、背景
1.MRv1アーキテクチャ：
2.MRv1（Hadoop1.0）は様々な制限があります。
（1）乏しいスケーラビリティ：でMRv1に、jobTrackerもスケーラビリティHadoopクラスタを制限する二つの機能、リソース管理、ジョブ制御を有しています。
（2）低い信頼性:: MRv1マスター/スレーブ構成を使用して、それがガイドに失敗したら、失敗マスターの一点が、そこであります
誘導されたクラスタ全体が使用できません。
（3）リソースの低利用率は：パーティションのサイズに基づいてリソーススロットの分割方法は、多くの場合、ノードのリソース利用率をもたらすが高すぎる、または低すぎる、まだあまりにも粗い、スロットにHadoopのマップスロットとスロットを削減は2つである、とさせません他がアイドル状態のときでも、それらの間で共有、多くの場合（この時間はスロットアイドルを削減し、このようなジョブはちょうどのみ地図タスクを実行します提出したときのように）スロットリソースの制約につながります。
（4）のみリソース隔離機構JVMを使用することに基づく効果的なリソースの分離機構を導入しないように、このアプローチは、同じノード上のタスク間の干渉を引き起こす可能性があり、このようなCPUではなく、分離などのリソースの多くは、あまりにも粗いままであります深刻。
（5）は、複数のコンピューティングフレームワークをサポートすることができない：効果的嵐、スパークおよび他のコンピューティングフレームワークをサポートすることができません。
3.YARNの改善
（1）、フレームモードの計算クラスタを変更する各フレームのリソース共有モードを算出します
リソースの利用率を向上させ、共有モードのことができ、クラスタ管理者の一元管理のほんの数を必要とし、クラスタ間でリソースのスケジューリングをしない、コスト削減を。
リソース管理及び制御動作：（2）は、主にHadoop 1.0 JobTrackerに2つの機能を実行します。クラスタサイズが大きすぎる場面では、JobTracker圧力が、重すぎるYARNデザインので、リソース管理やジョブ制御が分離されています。三つの部分のResourceManager、ApplicationMaster、ノードマネージャの置換JobTracker。
第三に、主な利点
1.が大幅に（今のResourceManagerである）JobTrackerリソースの消費を低減し、かつ分散状態プログラムの各ジョブのサブタスク（タスク）を監視できるように、より安全に、より美しく。
、で新しい糸2. ApplicationMasterは変更部分であり、ユーザは、プログラミングモデルのより多くの種類が、Hadoopクラスタを実行できるようにすることを、自分のAppMst異なるプログラミングモデルを書くことができます。
リソースの前記発現メモリユニットに、より合理的にするために以前よりも残っているスロットの数。
4.ApplicationMasterは、元のJobTracker、のResourceManager ASM制御健康ApplicationMasterの仕事の健全性を監視するタスクを想定して、問題が発生した場合、それはその（ApplicationMaster）を再起動します。
YARN 5.Containerが使用リソース隔離アセンブリは、スケジュールおよび制御リソースを使用することができます。コンテナは、リソース割当部は、パッケージ資源ノードの複数の内部寸法です。
第四に、糸の基本的なアーキテクチャ
1.ResourceManager（RM）：
全体的なリソース管理・配信システムの責任（1）スケジューラと、アプリケーション・マネージャ（アプリケーションマネージャ）ASM二つの部分を含みます。
（2）スケジューラは、純粋なスケジューラは資源配分のための唯一の責任です。
（3）ASM：①ApplicationMasterを起動するアプリケーションを提出し、②AMを開始し、あなたが失敗したとき③AMの動作を監視、AMはそれを再起動します。
2.NodeManager（NM）：
（1）各ノードのリソースとタスクマネージャ
（2）詳細な機能（ネクサス）：①RMに応じて、各ノードのコンテナのリソース使用状況と動作を報告するタイミング、②要求AM（様々なタスク）コンテナの受信を開始し、停止。
3.ApplicationMaster（AM）：
（1）あたりのアプリケーションAM
（2）特定の機能：①RMへのリソース要求は、②開始し、通信タスクNMを停止し、③すべてのタスク、リソース、および再アプリケーションの稼働状況を監視し、タスクが失敗した場合、タスクを再起動してください。
4.Container：
リソースの糸抽象化は、資源単位が割り当てられる、請求かかる等のコンテンツ、CPUなどの多次元包装資源ノード、..
五、糸ジョブスケジューリングプロセス
（：ApplicationMasterプログラム起動コマンドAM、アプリケーションを含む）は、アプリケーション起動要求に送ら1.clientのRM
2.RMコンテナ・アプリケーションを割り当てられ、対応するNM、NMと通信コンテナにAMに対応するアプリケーションを起動するために必要。
3.AM RMに登録を開始した後、ユーザーは、RMから直接アプリケーションを実行のステータスを表示することができます。
RM 4.AMはに適用すると、ポーリングによってリソースを受信します
対応NMと通信するためのリソースへの5.AM要求後、NMは、タスクを開始するために必要。
環境6.NM良いタスクは、スクリプトを実行して、タスクを開始するためのスクリプトを書くために、タスクのために（などの環境変数、JARパッケージを含む）タスクの開始コマンドを実行する必要が設定した後。
タスクが失敗した場合は、タスクを再起動することができますので、AM自身の動作条件にRPCプロトコルを送信することにより7.各タスク、状況は、タスクAMを追跡することができます。
タスクが完了すると8、AMは、ログアウトしてRMに自分自身を閉じます。
六、糸フォールトトレランス
障害の1.RM単一点
このResourceManagerプライマリノードに障害が発生したバックアップノードは、ノードが仕事を続けるように切り替えられます。
2.NM
（1）タスクが失敗し、RMはAMを伝えるのタスクを失敗します。
（2）AMは、タスクの失敗を処理する方法を決定します。
午前3時
AMを再起動する責任RM（1）AMに障害が発生した後
内部の作業の問題に対処する（2）AMのフォールトトレランス
（3）RMはタスクがすでに再起動後に再実行しなくて、実行されて保存されます。
七、YARNスケジューラ
糸リソーススケジューラは、最も重要な要素の一つとなるプラグインユーザは、必要に応じて実装さスケジューラを所有できるようにインタフェース仕様のセットを定義で、。糸はFIFO、来る容量スケジューラ（デフォルト）[内部のデフォルトのタスク実行キューはFIFO方式}であるとフェアスケジューラの3つの一般的なリソーススケジューラ、もちろん、ユーザは、インターフェース仕様に応じて、新しいリソーススケジューラ、および簡単なを書くことができますコンフィギュレーションそれ稼働。
1.リソーススケジューリングモデル：
二重資源スケジューリング・モデルを用いて（1）糸は：第一の層に、個々 ApplicationMasterにリソースを割り当てるためのResourceManagerリソーススケジューラは、第2層に、ApplicationMasterはさらに、内部の様々なタスクにリソースを割り当てます。ここでは、リソーススケジューラの主な関心事は、第一層のスケジューリングの問題されるスケジューリング戦略に関しては、第二の層は、完全にユーザアプリケーション自身に任されています。
（2）糸はプルベース通信モデルの使用：アプリケーションにリソースを割り当てるリソーススケジューラを、それが直ちに対応ApplicationMasterを押すのではなく、一時的にバッファに入れ、定期ApplicationMaster待っハートビートは、イニシアチブを取ります。
2.リソーススケジューリングプロセス
3.リソース保証メカニズム
（1）増分リソース割当：リソースアプリケーションが保証アプリケーションに一時的にできない場合、優先度は、アプリケーションのニーズを満たすために、アプリケーションのための空きリソースの累積放出されるまで、ノード上のリソースを予約。このリソース割り当ては、予備リソースは、クラスタリソースの使用率を減らし、資源の無駄になります。
（2）糸用い増分リソース割り当てメカニズムを、この機構は無駄であるが、飢餓現象を引き起こさないであろう。（アプリケーションが永続的にリソースを占有していないと仮定すると、それは時間の期間にわたって消費されているリソースを解放します）。
4.横取り機構
（1）リソーススケジューラは、各待ち行列を提供することができるリソースの最小量とリソースの最大量のリソースが不足しているリソースの最小量であることを特徴とします、
各キューを保証するために必要なリソースの量、およびリソースの最大量の下では極端な例では、リソースの使用がキューを超えることはできませんです。
プリエンプションが発生した理由（2）は、「最小限のリソース」という概念に全くによるものです。一般的には、リソースの利用率を向上させるために、リソース
スケジューラ（含む容量スケジューラとフェアスケジューラ）一時的に割り当てられたリソースが軽い負荷の高いキューキューにロードされます（キューがすべてのリソースを必要としないとき、すなわち、そのリソースはハードではないことを確認するためのリソースの最小量は、それが満たしていません最小リソースの量が、一時的に
無料のリソースは、）他のリソースのキューに割り当てる必要が負荷がスケジューラ前に提出した光キュー突然受信した新たなアプリケーションの場合にのみ
キューに属してさらにリソースがそれに割り当てられています。。しかし、リソースがこの時点別のキューで使用中の可能性があるため、スケジューラが待機する必要があります
通常、不確実な待ち時間の期間を要し、これらのリソース「原状回復」、に他のキューリソースの解放後。防止するためにすべき
、プログラムに長すぎる待っているいくつかの時間のためのディスパッチャ待機後に発見されたリソースは、リソースのプリエンプションをリリースされていない場合。
5.Capacity Shedule
単位キューにリソースを分割し、各キューは同時に、各ユーザは、リソースの誤用を防止するために、一定の限度にリソースの使用を設定することができ、リソースの上限のある最小割合を確保するように設定することができます。キューがリソースを残りしている場合は、残りのリソースは、他のキューに一時的に共有することができます。
（1）が備わっています。：容量保証、柔軟性、リースの様々な（サポート複数のユーザーと実行のクラスタを共有する複数のアプリケーション）、セキュリティ、動的なリソース更新
（2）サブキュー：
①ネストされたキューすることができ、各キューは、サブキューがあります。
②ユーザーは、キューだけ（リーフキュー）の底に申請書を提出することができます
③各キューの最小値と最大容量。
④スケジューラキューは常に最安現在のリソース使用量を選択し、資源の配分されます。
