YARN是资源管理系统,理论上支持多种资源,目前支持CPU和内存两种资源 YARN产生背景 直接源于MRv1在几个方面的缺陷 扩展性受限 单点故障 难以支持MR之外的计算 多计算框架各自为战,数据共享困难 MR:离线计算框架 Storm:实时计算框架 Spark:内存计算框架 YARN设计目标 通用的统一资源管理系统 同时运行长应用程序和短应用程序 长应用程序 通常情况下,永不停止运行的程序 Service、HTTP Server等 短应用程序 短时间(秒级、分钟级、小时级)内会运行结束的程序 MR job、Spark Job等 YARN基本架构 ResourceManager 整个集群只大数据培训有一个,负责集群资源的统一管理和调度 详细功能 处理客户端请求 启动/监控ApplicationMaster 监控NodeManager 资源分配与调度 NodeManager 整个集群有多个,负责单节点资源管理和使用 详细功能 单个节点上的资源管理和任务管理 处理来自ResourceManager的命令 处理来自ApplicationMaster的命令 ApplicationMaster 每个应用有一个,负责应用程序的管理 详细功能 数据切分 为应用程序申请资源,并进【关注尚硅谷,轻松学IT】一步分配给内部任务 任务监控与容错 Container 对任务运行环境的抽象 描述一系列信息 任务运行资源(节点、内存、CPU) 任务启动命令 任务运行环境 YARN运行过程 YARN容错性 ResourceManager 存在单点故障; 正在基于ZooKeeper实现HA。 NodeManager 失败后,RM将失败任务告诉对应的AM; AM决定如何处理失败的任务。 ApplicationMaster 失败后,由RM负责重启; AM需处理内部任务的容错问题; RMAppMaster会保存已经运行完成的Task,重启后无需重新运行。 YARN调度框架 双层调度框架 RM将资源分配给AM AM将资源进一步分配给各个Task 基于资源预留的调度策略 资源不够时,会为Task预留,直到资源充足 与“all or nothing”策略不同(Apache Mesos) YARN资源调度器 多类型资源调度 采用DRF算法 目前支持CPU和内存两种资源 提供多种资源调度器 FIFO Fair Scheduler Capacity Scheduler 多租户资源调度器 支持资源按比例分配 支持层级队列划分方式 支持资源抢占 YARN资源隔离方案 支持内存和CPU两种资源隔离 内存是一种“决定生死”的资源 CPU是一种“影响快慢”的资源 内存隔离 基于线程监控的方案 基于Cgroups的方案 CPU隔离 默认不对CPU资源进行隔离 基于Cgroups的方案 YARN支持的调度语义 支持的语义 请求某个特定节点/机架上的特定资源量 将某些节点加入(或移除)黑名单,不再为自己分配这些节点上的资源 请求归还某些资源 不支持的语义 请求任意节点/机架上的特定资源量 请求一组或几组符合某种特质的资源 超细粒度资源 动态调整Container资源 运行在YARN上的计算框架 (还有别的) 离线计算框架:MapReduce DAG计算框架:Tez 流式计算框架:Storm 内存计算框架:Spark 离线计算框架:MapReduce 仅适合离线批处理 具有很好的容错性和扩展性 适合简单的批处理任务 缺点明显 启动开销大、过多使用磁盘导致效率低下等 DAG计算框架:Apache Tez DAG计算:多个作业之间存在数据依赖关系,并形成一个依赖关系有向图( Directed Acyclic Graph ),该图的计算称为“DAG计算” 和Mapreduce相比 Tez应用场景 直接编写应用程序 Tez提供了一套通用编程接口 适合编写有依赖关系的作业 优化Pig、Hive等引擎 下一代Hive:Stinger 好处1:避免查询语句转换成过多的MapReduce作业后产生大量不必要的网络和磁盘IO 好处2:更加智能的任务处理引擎 流式计算框架:Storm Storm on YARN(和其他如mapreduce、tez、spartk等都不同,其他计算框架的client) 内存计算框架:Spark 已经形成了自己的生态系统 转载来源作者:IT十年 |
|