MapReduce/YARN 工作原理
MRv1 的架构
执行任务的过程:
- client 向 JobTracker 发出一个任务请求
- JobTracker 与 NameNode 联合将 Map 和 Reduce 任务分发到离它所处理的数据 DataNode 尽可能近的TaskTracker 上的可用槽中
- Map 和 Reduce 任务执行时,TaskTracker 会周期性的报告任务的状态给 JobTracker
MRv1 存在的问题
- JobTracker 是 Map-reduce 的集中处理点,存在单点故障。
- JobTracker 完成了太多的任务,造成了过多的资源消耗,当 map-reduce job 非常多的时候,会造成很大的内存开销,潜在来说,也增加了 JobTracker fail 的风险
- 在 TaskTracker 端,以 map/reduce task 的数目作为资源的表示过于简单,可用槽的划分机制会造成只有 map或 reduce 时的资源浪费
总而言之,JobTracker肩负了资源管理和作业控制等两部分工作,这样造成了JobTracker负载过重。从设计的角度来说,未能将资源管理相关功能和应用程序相关功能分开,造成了扩展性、资源利用率和多框架支持存在不足,难以支持多种计算框架
MRv2/YARN 的架构
MRv2 的基本设计思想是将JobTracker的资源管理和作业控制(作业监控、监控)分拆成两个独立的进程 ResourceManager 和 ApplicationMaster。让资源管理和具体的应用程序无关,它只负责整个集群的资源(内存、CPU、磁盘)管理,而作业控制进程则是与应用程序相关的模块,负责任务切分、任务调度和容错,且每个作业控制进程只负责管理一个作业。
组成:
- ResourceManager(RM) 是一个全局的资源管理器,负责整个系统的资源管理和分配。它的主要构成:可插拔的调度器(YarnScheduler,调度器根据容量、队列等限制条件(如每个队列分配一定的资源,最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序)和应用程序管理器(Applications Manager, 负责维护已提交应用的状态)
- NodeManager(NM) 是每个节点上的资源和任务管理器,一方面,它会定时地向 RM 汇报本节点上的 资源使用情况和各个 Container 的运行状态;另一方面,它接收并处理来自 AM 的 Container 启动 / 停止等各种请求
- ApplicationMaster(AM) 负责与 RM 调度器协商以获取资源(用 Container 表示),负责和与 NM 通信以启动 / 停止容器。监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务
- Container 是 YARN 中的资源抽象,它封装了某个节点上的多维度资源,如内存、 CPU、磁盘、网络等,当 AM 向 RM 申请资源时,RM 为 AM 返回的资源便是用 Container 表示的。YARN 会为每个任务分配一个 Container,且该任务只能使用该 Container 中描述的 资源。需要注意的是,Container 不同于 MRv1 中的 slot,它是一个动态资源划分单位,是 根据应用程序的需求动态生成的,使用了轻量级资源隔离机制 Cgroups 进行资源隔离。
提交作业过程:
大概有三个阶段:
Job submission
- Job Client 向 RM 提交执行 job 申请,
- Client 想 RM 提交执行 job 申请,RM 接受 job 请求,生成Application ID,返回 job id、staging 工作目录等信息给 Client
- Client 把运行job 所需的 jar包以及配置文件和划分的输入文件等拷贝到staging 工作目录(hdfs:///tmp/xxx/yarn-staging/jobId)(多副本)(submitApplication())
- Client 提交任务到 RM
Job initialization - RM 把job转交给 YARNScheduler
- RM 让 NM 启动一个 AM
- AM 初始化 job
- AM 向 HDFS 获取文件块
- AM 向 RM 申请分配资源
- AM 向 NM 申请启动Container,NM 会启动一个 YarnChild
- YarnChild 向 HDFS 获取 jar 包等
YarnChild 启动 MapTask/ReduceTask - Map/Reduce任务完成, 然后向ResourceManager注销AppMaster进程。
Ref: