YARN, Yet Another Resource Negotiator,另一种资源协调者
YARN是一个资源调度框架,为上层应用提供统一的资源管理和调度
YARN产生背景
1、MapReduce1.x 存在问题
现在讲的MapReduce、Hadoop都是已经2.x的了
下图是旧MapReduce1.x的Hadoop集群架构:
一个 Hadoop 集群可分解为两个抽象实体:MapReduce 计算引擎和分布式文件系统。当一个客户端向一个 Hadoop 集群发 出一个请求时,此请求由 JobTracker 管理。JobTracker 与 NameNode 联合将任务分发到离它所处理的数据尽可能近的位置。然后JobTracker 将 Map 和 Reduce 任务安排到一个或多个 TaskTracker 上的可用插槽中。TaskTracker 与 DataNode一起对来自 DataNode 的数据执行 Map 和 Reduce 任务。当 Map 和 Reduce 任务完成时,TaskTracker 会告知 JobTracker,后者确定所有任务何时完成并最终告知客户作业已完成。
缺点:
由于只有一个JobTracker和NameNode,单一Namenode,单一JobTracker的设计严重制约了整个Hadoop 1.0可扩展 性和可靠性。首先,Namenode和JobTracker是整个系统中明显的单点故障源(SPOF)。再次单一Namenode的内存容量有限,使得Hadoop集群的节点数量被限制到4000个左右,能支持的文件系统大小被限制在10-50PB, 最多能支持的文件数量大约为1.5亿 左右(注,实际数量取决于 Namenode的内存大小)。
JobTracker完成了过多的任务,造成了过多的资源消耗:当MapReduce job非常多的时候,会造成很大的内存开销,也就增加了JobTracker fail的风险
在TaskTracker端,以MapReduce task的数目为资源的表示过于简单,没有考虑到cpu/内存的占用情况,如果两个大内存消耗的task被调度在一起,很容易发生内存溢出错误。
2、资源利用率 & 运维成本
YARN安装没有独立的安装包
YARN是集成在Hadoop安装包里面的
YARN资源调度框架
最新推荐文章于 2022-05-16 22:26:22 发布