概要
MRv1主要由编程模型(MapReduce API)、资源管理与作业控制块(由JobTracker和TaskTracker组成)和数据处理引擎(由MapTask和ReduceTask组成)三部分组成。
しかしYARN後に表示されます。糸はそうYARN上のMapReduceフレームワークの実装を可能にするために、達成するために、リソース管理モジュールと呼ばれます。ApplicationMasterのみ等完全ジョブ制御モジュールアセンブリ缶機能、プログラミングモデルおよびデータ処理エンジンを含む他の部分を、必要、直接的MRv1元の部品を使用することができます。
2 MRAppMasterで構成
MRAppMaster是MapReduce的ApplicationMaster实现。它使得MapReduce应用程序能够直接执行于YARN之上。在YARN中，MRAppMaster负责管理MapReduce作业的生命周期。包含作业管理、资源申请与再分配、Container启动与释放、作业恢复等。
MRAppMaster主として既にによって成る複数のコンポーネント/サービス下：
ConainterAllocatorは
MapReduceのジョブアプリケーションリソースとして、RMと通信します。
ジョブ記述の各タスクのリソース要件は、5タプルのように記述することができます。
<優先度、ホスト名、容量、容器 、relax_locality>、 局在スラックコンテナデータか否かを、それぞれ、ジョブの優先度、資源の量のリソース（CPUとメモリは現在2つのリソースをサポートして）所望の宿主、
ClientService
ClientServiceはによってインタフェースであります達成MRClientService。MRClientServiceは、クライアントが動作プロトコル（必ずしもRMによって）制御動作（例えば、ジョブを殺すジョブの優先度を変更する、等する）ことにより、ジョブの状態を取得することができる、MRClientProtocol契約を達成しました。
仕事
のMapReduceジョブを表し、JobInProgress機能MRv1は同じです。ジョブの実施状況を監視するための責任。
これは、非同期動作に関連する様々な動作を実行するために、ジョブの状態マシンを維持します。
Task
表示一个MapReduce作业的某个任务。与MRv1中的TaskInProgress功能类似。负责监控一个任务的执行状态。它维护了一个任务状态机。以实现异步执行各种任务相关的操作。
TaskAttempt
表示一个任务执行实例。它的执行逻辑与MRV1中的MapTask和ReduceTask执行实例全然一致。实际上，它直接使用了MRv1中的数据处理引擎，但经过了一些优化。
TaskCleaner
负责清理失败任务或被杀死任务使用的文件夹和产生的暂时结果(统称为垃圾数据),它维护了一个线程池和一个共享队列。异步删除任务产生的垃圾数据。
Speculator
完毕猜測执行功能。当同一个作业的某个任务执行速度明显慢于其它任务时，会为该任务启动一个备份任务。
ContainerLauncher
负责与NM通信，以启动一个Container.当RM为作业分配资源后，ContainerLauncher会将任务执行相关信息填充到Container中。包含任务执行所需资源、任务执行命令、任务执行环境、任务依赖的外部文件等。然后与相应的NodeManager通信，要求它启动Container.
TaskAttemptListener
负责管理各个任务的心跳信息，假设一个任务一段时间内未汇报心跳，则觉得它死掉了。会将其从系统中移除。
JobHistoryEventHandler
负责对作业的各个事件记录日志。
ときMRApMasterの問題。YARNそれは再びノードであり、スケジュールされます。
別の計算を避ける未完成。MRAppMasterは、最初のタスクが完了した復元するために、最後に生成された実行HDFSからログを読み取り、だけにして、まだ実行を完了していないタスクを実行することができます。
三MapReduceclient
MapReduceclient是MapReduce用户与YARN进行通信的唯一途径，通过该client。用户能够向YARN提交作业，获取作业的执行状态和控制作业(比方杀死作业、杀死任务等).MapReduceclient涉及两个RPC通信协议：
1.ApplicationClientProtol
在YARN中，RM实现了ApplicationClientProtocol协议，不论什么client须要使用该协议完毕提交作业、杀死作业、改变作业的优先级等操作。
2.MRClientProtocol
当作业的ApplicationMaster成功启动后，它会启动MRClientService服务，该服务实现了MRClientProtoclo协议，从而同意client直接通过该协议与ApplicationMater通信以控制作业和查询作业执行状态。以减轻ResourceManager负载。
四MRAppMasterワークフロー
依照作业的大小不同。MRAppMaster提供了三种作业执行模式:
本地模式(通经常使用于作业调试，同MRv1一样，不再赘述)、Uber模式和Non-Uber模式。
对于小作业为了减少延迟。可採用Uber模式，在该模式下，全部Map Task和Reduce Task在同一个Container（MRAppMaster所在的Container）中顺次执行；对于大作业。则採用Non-Uber模式，在该模式下，MRAppMaster先为Map Task申请资源。当Ma Task执行完毕数目达到一定比例之后再为Reduce Task申请资源。
对于Map Task而言。它的生命周期为Scheduled->assigned->completed;
而对于Reduce Task而言，它的生命周期为pending->scheduled->assigned->completed.
在YARN之上执行MapReduce作业须要解决两个关键问题：怎样确定Reduce Task启动时机以及怎样完毕Shuffle功能。
为了避免Reduce Task过早启动造成资源利用率低下，MRAppMaster让刚启动的Reduce Task处于pending状态。以便可以依据Map Task执行情况决定是否对其进行调度。
MRAppMaster在MRv1原有策略基础之上加入了更为严格的资源控制策略和抢占策略。
中糸中。複合サービスモデルとしてノードマネージャ。動的ロード・アプリケーションは、この機能の使用を一時的に補助的なサービスを必要とすることに同意するものとし、YARNシャッフルHTTP Severのはそのため、各ノードマネージャの負荷は、起動時に、サービスを占めるようになります。
当用户向YARN提交一个MapReduce应用程序后，YARN 将分两个阶段执行该应用程序：第一个阶段是由ResourceManager启动MRAppMaster;第二个阶段是由MARppMaster创建应用程序。为它申请资源。并监控它的整个执行过程。直到执行完毕。
步骤1 用户向YARN中（RM）提交应用程序，当中包含ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
步骤2 ResourceManager为该应用程序分配第一个Container，ResouceManage与某个NodeManager通信，启动应用程序ApplicationMaster，NodeManager接到命令后，首先从HDFS上下载文件(缓存），然后启动ApplicationMaser。
当ApplicationMaster启动后，它与ResouceManager通信，以请求和获取资源。
ApplicationMasterリソースを取得するために後に、タスクを開始するために、対応するノードマネージャと通信します。
注：1.假设该应用程序第一次在给节点上启动任务。则NodeManager首先从HDFS上下载文件缓存到本地，这个是由分布式缓存实现的。然后启动该任务。
2. 分布式缓存并非将文件缓存到集群中各个结点的内存中，而是将文件换到各个结点的磁盘上，以便运行任务时候直接从本地磁盘上读取文件。
步骤3 ApplicationMaster首先向ResourceManager注冊。这样用户能够直接通过ResourceManage查看应用程序的执行状态，然后它将为各个任务申请资源。并监控它们的执行状态。直到执行结束，即反复步骤4~7。
步骤4 ApplicationMaster採用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
步骤5 一旦ApplicationMaster申请到资源后，ApplicationMaster就会将启动命令交给NodeManager,要求它启动任务。启动命令里包括了一些信息使得Container能够与Application Master进行通信。
步骤6 NodeManager为任务设置好执行环境（包含环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过执行该脚本启动任务（Container）。
步骤7 在Container内执行用户提交的代码，各个Container通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的执行状态，从而能够在任务失败时又一次启动任务。
步骤8 在应用程序执行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前执行状态。
步骤9 应用程序执行完毕后。ApplicationMaster向ResourceManager注销并关闭自己
ファイブMRAppMasterのライフサイクル
MRAppMaster依据InputFormat组件的详细实现（一般是依据数据量切分数据），将作业分解成若干个Map Task和Reduce Task,当中每一个Map Task 负责处理一片Inputsplit数据，而每一个Reduce Task则进一步处理Map Task产生的中间结果。每一个Map/Reduce Task仅仅是一个详细计算任务的描写叙述，真正的任务计算工作则是由执行实例TaskAttempt完毕的。每一个Map/Reduce Task可能顺次启动多个执行实例，比方第一个执行实例失败了，则另起一个新的实例又一次计算，直到这一份数据处理完毕或者尝试次数达到上限。
Job状态机
Job状态机维护了一个MapReduce应用程序的生命周期，即从提交到执行结束的整个过程。一个Job由多个Map Task和Reduce Task构成。而Job状态机负责管理这些任务。Job状态机由类JobImpl实现。
Task状态机
Task维护了一个任务的生命周期。即从创建到执行结束整个过程。
しようとする複数回存在することも課題。各実行の試みが「実行インスタンス」と呼ばれ、タスクのステートマシンは、これらのインスタンスの実装を管理する責任があります。タスクのステートマシンはTaskImplによって実装されています。
注意：1.MRAppMaster为任务申请到资源后，与相应的NodeManager通信成功启动Container。
ことを注意することは、いくつかの点で、タスクの実行例が複数存在してもよく、そして失敗のインスタンスが存在してもよいです。しかし、それはタスクが終了したことを意味し、唯一のインスタンスが成功するがなければなりません。
2. 每一个任务的执行实例数目都有一定上限，一旦超过该上限，才觉得该任务执行失败，当中Map Task执行实例数目上限默认位4,Reduce Task执行实例默认也是 4.一个任务的失败并不一定导致整个作业执行失败，这取决于作业的错误容错率。
TaskAttempt状态机
TaskAttempt状态机维护了 一个任务执行实例的生命周期，即从创建到执行结束整个过程。它由TaskAttempImpl类实现。
在YARN 中，任务实例是执行在Container中的。因此。Container状态的变化往往伴随任务实例的状态变化，比方任务实例执行完毕后。会清理Container占用的空间，而Container空间的清理实际上就是任务实例空间的清理。任务实例执行完后，需向MRAppMaster请求提交终于结果，一旦提交完毕后。该任务的其他实例就将被杀死。
おおよそ以下のような業務実行中のプロセスの概要：
=インスタンスを作成します「MRApMasterのResourceManagerへのアプリケーションリソース=」=「スタートコンテナ（実行インスタンスは）=」結果クリーンアップ」結果を提出=コンテナを獲得し
たときに終了コンテナの実行、MRAppMaster直後にこのResourceManagerから学びました。
さまざまなタスクの実装の例としては、そうでない場合MRAppMasterタスクが死んだ状態になっていると思いますが、定期的にMRAppMasterに進行状況を報告する必要が。それはTA_UPDATEイベントをトリガする各レポートを殺すでしょう。
注：1.MRAppMaster能够由两条路径来得知Conainer的当前执行状态：
a. 通过ResourceManager（MRAppMaster与ResouceManager中维护一个心跳信息)
b. 还有一个是直接通过Task Attempt（每一个Task Attempt与MRAppMaster之间有专用的协议)
2. 这两条路径是独立的，没有先后顺序之分,假设MRAppMaster直接从ResouceManager获取Container执行完毕信息。则任务实例直接从Running转化为SUCCESS_CONTAINER_CLEANUP状态，假设首先从TaskAttempt中获知任务完毕信息。则将首先转化为COMMIT_PENDING状态。然后再转化为SUCCESS_CONTAINER_CLEANUP状态。
当任务运行失败或者被杀死时，需清理它占用的磁盘空间和产生的结果。当Reduce Task远程复制一个已经运行完毕的Map Task输出数据时，可能由于磁盘或者网络等原因，导致数据损坏或者数据丢失。这是会触发一个TA_TOO_MANY_FETCH_FAILURE事件。从而触发MRAppMaster又一次调度运行该Map Task.
シックス・リソース要求と再配分
ContainerAllocator是MRAppMaster中负责资源申请和分配的模块。
ユーザーが送信した後、ジョブが地図タスクに分解され、タスク、のResourceManagerから統一タスクContainerAllocatorアプリケーションモジュールに必要なリソースの責任者を減らして、そしてContainAllocatorがリソースを得れば、各タスクは、ジョブに割り当てられ、さらにに特定の戦略を使用する必要があります。
在YARN中，作业的资源描写叙述能够被描写叙述为五元组:priority,hostname,capabiity,containers,relax_locality分别表示 作业优先级 期望资源所在的host 资源量(当前支持内存与CPU两种资源） 、Containers数目 是否松弛本地化。
例えば：
<10,"node1","memeory:1G,CPU:1",3,true)// 优先级是一个正整数，优先级值越小，优先级越高
ContainerAllocator周期性的通过心跳与ResourceManager通信。以获取已经分配的Contaienr列表，完毕的Container列表、近期更新的节点*+列表等信息，而ContanerAllocator依据这些信息完毕对应的操作。
当用户提交作业之后，MRAppMaster会为之初始化，并创建一系列的Map Task和TaskReduce Task任务，因为Reduce Task依赖于Map Task之间的结果，所以Reduce Task会延后调度。
タスクのステータス物語の記述
地図：scheduled-> assigned->完了
タスク：pending-> scheduled-> assigned->完成した
保留はContainerAllocatorは、リソース要求の収集、送信待機中を表す
リソース要求がRMに送信された予定の識別を。タスクのコレクションが、資源の配分受け取っていない
タスクassignd RMを割り当てられたリソースのコレクション
のcompletは、設定されたタスクが完了している表し
三种作业状态：Failed Map Task ,Map Task,Reduce Task分别赋予它们优先级5 20 10也就是说，当三种任务同一时候有资源请求的时候。会优先分配给Failed Map Task，然后是Reduce Task，最后是Map Task.
假设一个任务执行失败，则会又一次为该任务申请资源
假设一个任务执行速度过慢。则会为其额外申请资源已启动备份任务(假设启动了猜測执行过程）
假设一个节点的失败任务数目过多，则会撤销对该节点的全部资源的申请请求。
注：在大多数数的情况下，RMAppMaster与RM的心跳信息都是空的。即心跳信息不包括新的资源请求信息，这样的心跳信息有一下几个作用：
1. 周期性发送心跳。告诉RM自己还活着
2. 周期性询问RM,以获取新分配的资源和各个Container执行状况。
資源の再配分
MRAppMasterかつては、各タスクに割り当てられたこれらのコンテナを促進し、コンテナが新たに割り当てられた受信します。例えばコンテナ、割り当てステップ：
容器満足仮定すると、新たに受信した満足に含まれる1推論リソース。ResourceManagerコンテナリリース次のハートビートによる通知
有りと仮定すると、ブラックリストに追加されるかどうかを受信ノード容器2推論します。コンテナとの一致を見つける作業、再びタスクのリソースに対して適用されます。同じ時間は、次のハートビートでのResourceManagerコンテナのリリースを知らせる。
3.コンテナの優先度に応じて。タスクの適切な型に割り当てます。
七Contianer開始と解除
当ContainerAllocator为某个任务申请到资源后，会将执行该任务相关的全部信息封装到Container中。并要求相应的节点启动该Container。须要注意的是。Container中执行的任务相应的数据处理引擎与MRv1中全然一致，仍为Map Task和 Reduce Task。
正確にはこのため。完全に互換性のMapReduceプログラムでMRv1手順糸。
ContainerLaunche负责与各个NodeManager通信，已启动或者释放Container。在YARN中。执行的Task所需的所有信息被封装到Container中，包含所需的资源、依赖的外部文件、JAR包、执行时环境变量、执行命令等。ContainerLauncher通过RPC协议ContainerManager与NodeManager通信，以控制Container的启动和释放。进而控制任务的执行(比方启动任务、杀死任务等）。
可能なトリガーストップ/コンテナを殺すいくつかがありますが、一般的には、次のとおりです。
実行するタスクが終了したときに1の推測では、同じデータ入力作業を殺す必要があります。
2.ユーザーは、タスクを殺すために要求を送信します。
ランダムなタスクの実行の終わりに3、YARNコマンドは、対応するリソースがコンテナを占有解放するキルタスクをトリガーします。
エイトは、操作機構を推測します
为了防止运行速度慢的任务拖慢总体的运行进度，使用猜測运行机制，Hadoop会为该任务启动一个备份任务，让该备份任务与原始任务同一时候处理同一份数据，谁先运行完。则将谁的结果作为终于结果。
注：1.每一个任务最多仅仅能有一个备份任务实例
2. [開始時間のバックアップ。十分なマップタスクは、バックアップタスクを開始するかどうかを推定するために、これらのタスクの完了に基づいて、完成された存在であることを確実にするため。
这样的算法的长处是可最大化备份任务的有效率。当中有效率指有效备份任务数与全部备份任务数的比值，有效任务是指完毕时间早于原始任务完毕时间的备份任务(即带来实际收益的备份任务）。备份任务的有效率越高。猜測运行算法越优秀，带来的收益也就越大。
猜測运行机制实际上採用了经典的算法优化方法，以空间换时间，它同一时候启动多个同样的任务处理同样的数据，并让这些任务竞争以缩短数据的处理时间。
八のジョブ回復
从作业恢复粒度角度来看，当前存在三种不同级别的恢复机制，级别由低到高依次是作业级别、任务级别和记录级别。当中级别越低实现越简单，但造成的资源浪费也越严重。
タスクレベルのリカバリ・メカニズムを使用して、現在のMRAppMaster、回復のための基本単位として、そのタスクは、このようなメカニズムは、トランザクションログの回復操作に基づいて完成され、それはちょうど2つのタスクに集中さ：タスクが完了したタスクを完了していません。ジョブの実行中は、MRAppMasterはMRAppMasterが再起動したら、ログからのジョブの実行状態を再開することができ、ログの形式やジョブレコードの状態になります。
当前MRAppMaster的作业恢复机制仅能做到恢复上一次已经执行完毕的任务，对于正在执行的任务。则在前一次MRAppMaster执行实例退出时由ResourceManager强制将其杀死并回收资源。
MRAppMaster採用了开源数据序列化工具Apache Avro记录这些事件。
多くの場合、データ交換とクロス言語RPCアプリケーションの多くをサポートするために使用を通じてアブロは、データのシリアル化システムです。
ナインMRv1シンプルなコントロールとMRv2
MRAppMaster仍採用了MRv1中的数据处理引擎。分别由数据处理引擎MapTask和ReduceTask完毕Map任务和Reduce任务的处理。
MRv2 MRv1との比較
ネッティーを持つMap最後にMRv2桟橋の置換。、エンドユースバッチコピーを減らしてシャッフルし、ソートプラグの
インターフェイスは、新しい、古いものと新しいAPIのプログラミングAPIアプリケーション
、環境およびTaskTracker JobTracker構成YARN（NMからなり、RM）とMRAppMasterによって実行されたときに
データ処理エンジンMapTask /タスクMapTaskを削減/タスクを削減
须要注意的是。YARN并不会改变MapReduce编程模型，它仅仅是应用开发者使用的API。YARN提供了一种新的资源管理模型和实现，用来 执行MapReduce任务。
したがって。最も単純なケースで。（再コンパイルする必要がある）、それはまだ実行することができるように、従来のMapReduceアプリケーション、単により正確に動作パラメータを指定する開発者を許可するYARN。
要約10
実行環境はMapRecuceの糸糸とApplicationMaster、クラスタ内の他のコンピューティング・フレームを実行するような新規な可能を行う場合、クラスタ共有リソースが改善されたリソース利用目的を達成するように、そのようなMapReduceの環境からなります。
手順および無傷の糸で、MRv1モードではなく、独立してMapRedcueの糸を実行します。
