YARN 在字节跳动的优化与实践 _YARN

本文从利用率提升、多负载场景优化、稳定性提升、异地多活四个方面介绍了字节跳动在四年来对 Hadoop YARN 进行的一系列的优化，以及生产环境中的实践经验。

1.YARN 简介1.1 YARN 生态圈YARN (Yet Another Resource Negotiator) 是 Hadoop 集群的资源管理系统，是 Hadoop 生态中非常重要的成员项目。

文章插图

一般来说，离线生态可以分为五层：

最底层是裸金属层，由众多物理节点组成，每个节点上运行着通用的操作系统。
次底层是集群资源管理层， YARN 就处在这一层中。
再往上是分布式计算引擎层， MR/Spark/Flink 等计算引擎处于这层，为了能让业务同学更加低成本的写计算任务，各个引擎都支持 SQL 功能。
再往上是作业托管层，用来提交 ad-hoc 的作业，管理周期性的批处理作业，管理长时间运行的流式作业。
最上层是用户逻辑层，如数据日报，数据分析，模型训练等.

1.2 YARN 架构

文章插图

上图中灰色背景区域是 YARN 的主要架构，主要包含两种角色：

ResourceManager整个集群的大脑，负责为应用调度资源，管理应用生命周期。对用户提供接口，包括命令行接口， API, WebUI 接口。可以同时存在多个 RM ，但同一时间只有一个在工作， RM 之间通过 ZK 选主。
NodeManager为整个集群提供资源，接受 Container 运行。管理 Contianer 的运行时生命周期，包括 Localization ，资源隔离，日志聚合等。

YARN 上运行的作业:

在运行时会访问外部的数据服务，常见的如 HDFS ， Kafka 等
会在运行结束后由 YARN 负责将日志上传到 HDFS 中

2.字节跳动对 YARN 的定制字节跳动的 YARN 是在 16 年从社区当时最新的 2.6.0 版本中 fork 出来的，主要承载着公司内的离线作业/流式作业/模型训练三大场景。由于公司内的 YARN 服务规模巨大、场景复杂，遇到了各种问题，在社区版本没有提供解决方案之前，内部研发同学定制了许多内容来解决具体问题，经过 4 年来上千次的修改，公司内的版本已经跟社区的版本相差较大。
今天给大家介绍一些比较关键的定制，希望能给大家带来一些启发。这些关键定制主要包括四个方面：

利用率提升: 包括分配率提升和物理使用率提升。
多种负载场景优化: 包括批处理 / 流式 / 模型训练三种场景下的体验提升。
稳定性提升: 包括摆脱对 HDFS 强依赖, Container 分级与驱逐, 非受控 Container 管理。
异地多活: 包括统一的 YARN Client 和 UI 等内容。

2.1 利用率提升2.1.1 多线程版本的 Fair Scheduler

文章插图

社区原生版本的 FairScheduler 是单线程的，在节点数量较多时，是整体集群最大的瓶颈.
我们通过将 FairScheduler 改造为并发的多线程版本，并将调度器内部的锁拆分为更加细粒度的读锁和写锁，将调度吞吐提升 7 倍以上，在生产环境中达到每秒 3K 个 Container 的速度(未触及性能瓶颈) 。
2.1.2 考虑节点 DRF 的调度

文章插图

原生的 YARN 在调度时只考虑资源是否满足，经常会出现一个节点 CPU 被打满，但是内存还有剩余的情况。
我们引入节点 DRF(Dominant Resource Fairness)机制，计算每个节点的剩余资源的主资源，当调度的 Task 的主资源与节点的主资源不匹配时，先延迟此次调度，直到一定次数后再放松约束。
通过引入这个机制，集群资源的碎片化问题大幅降低，生产环境中可以达到 CPU 和内存的 24 小时平均利用率都在 90%以上。
2.1.3 提升单集群规模