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

1.YARN 简介

1.1 YARN 生态圈

YARN (Yet Another Resource Negotiator) 是 Hadoop 集群的资源处理系统，是 Hadoop 生态中十分重要的成员项目。
YARN 在字节跳动的优化与实践

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

  • 最底层是裸金属层， 由很多物理节点组成，每个节点上工作着通用的操作系统。L 9 O A L
  • 次底层是集群资源处理层， YARN 就处在这一层中。
  • 再往上是分布式核算引擎层， MR/Se + E 0 q jpark/Flink 等核算引擎处于这层，为了能让业务同学更加低成本的写核算任务， 各个引擎都支撑 SQL 功用。
  • 再往上是作业, . L B N Q P ] 5保管层，用来提交 ad-hoc 的作业，处理周期性的批处理作业，处理长时间工作的流式作业。
  • 最上层是用户逻辑层，如数据日报，数据分析，模型操练等.

1.2 YARN 架构

YARN 在字节跳动的优化与实践
上图中灰色布景区域是 YARN 的首要架构， 首要包括两种人物：

  • ResourceMG k 2 X v 1 r +anager

    • 整个集群的大脑2 b 8 @ y [ a E (，担任为运用调度资源，处理运用生命周期。
    • 对用户s C F g / W x供应接口，包括命令 F & D @ ^ { g W行接口，API, WebUI 接口。
    • 可以一同存在多个 RM，但同一时间只需一个在作业，RM 之间通过 ZK 选主。

  • NodeManag@ C l S mer

    • 为整个集群供应资源，承受 Container 工作。
    • 处理 Contianer 的工作时生命周期，包括 Localization，资源隔绝，日志聚合等。

YARN 上工作的作业:

  • 在工作时会访问外部的数据服务，常见的如 HDFS，Kafka 等
  • 会在工作完毕后由 YARN 担任将日志上传到 HDFS 中

2.字节跳动对 YARN 的定制

字节跳动的 YARN 是在 16 年从社区当时最新的 2.6.0 版别中 fork 出来的，首要承载着公司内的离线作业/流式作业/模型操练三大场景。 由于9 1 v J公司内的 YARN 服务规划巨大、场景复杂，遇到了各种问8 8 q题，: , T在社区版别没有供应处理方案之前，内部研发同学定制了许] k t k U s多内容来处理具体问题，通过 4 年来上千次的修正，公司内的版别现已跟社区的版别相差较大。

今天给我们介绍一些比较要害的定制，希望能给我们带来0 n o X v 3 Q一些启示。这些要害定制首要包括四个方面：

  • 利用率进步: 包括分配率进步和物理运用率E 1 c L进步。
  • 多种负载场景优化: 包括批处理 / 流式 / 模型操练 三种场景下的体会进步。
  • 稳定性进步: 包括脱节对 HDFS 强依托, Container 分级与驱赶, 非受控 Container 处理。
  • 异地多活: 包括共同的W E M g b ] V W u YARN Client 和 UI 等内容。

2.1 利用率进步

2.1.1 多线程版其他 Fair Scheduler

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

社区原生版其他 FairScheduler 是单线程的，L | W c = #在节点数量较多时，是整Z 8 9体集群最大的瓶~ q | q .颈。

我们通过将 FairScheduler 改造为并发的多线程版别，并将; a A调度器内部的锁拆分为更加细粒度的读锁E O ^ m ) t和写& Y 1 V锁，将调度吞吐进步 7 倍以上，在出产环境中抵达每秒 3K 个H – | % S t W Container 的速度(未触及功用瓶颈)。

2.1.2 考虑节点 DRF 的调度

YARN 在字节跳动的优化与实践
原生的 YARN 在调度时只考虑资源是否满足，常常会出现一个节点 CPU 被打满，但是内存还有剩余的状况。

我们引入节点 DRF(Dominant Resource Fairness)机制，核算每个节点的剩余资源的主资源，当调度的 Task 的主资源与节点的主资源不匹配时，先推迟此次调度，直到必定次数后再放松捆绑。

通过引入这个机制，T d H集群资P $ ! h源的碎片化问题大幅下降，出产环境中可以抵达 CPU 和内存的 24 小时均匀利用率都在 90%以上。

2.1.3 进步单集群规划

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

单个集群的规划越大，就可以有更多的用户和作业运用这个集群，这个集群的利用率也会更高。但是原生的 YARN 在抵达 5K 节点规划时开始出现各种问题，比如说一次简单的切主可能会导致整个X r ( { 5 : b集群雪崩。

我们为进步单集群规划做了一系列的优化。

  • 首要，通过对 YARN 内部事情整理调整，精准的修正了一些事情处理逻辑。
  • 然后，将 NodeManager 节点的心跳机制改为依据 ResourceManager 的压力动态调整。
  • 之后，修正内存单位(int->long)打破单个集群 21 亿 MB 的捆绑
  • 再之后，通过对切主进程进行深度优化, 将切主时间操控在秒级

当然还有许多其它的细f v . g ?节优化不再一一列举，终究的作用是让单个出产集群到M + A达了 2 万节点的规划。

2.1.4 与流式&在线服务混部

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

公司内离线的资源全天都比较紧张，而流式作业和在线服务的资源运用量跟着用户的行为，在时间上有显着的波峰波谷，在清晨时通过混部O h o s u u的办法将流式和在线充裕的资源供应_ q U给离z z W Z [ w Y s线可以全面的进步利用率。

我们通过将 NodeManager 改造为可以依据宿R S _ l g &主机的充裕资源动态的调整的 NM’，来抵达与流式作业和在线服务的B U 5 p $ u混部，为离线供应更多资源的意图。

现q ` ^ 4 t = [在出产环境中H * V { a 3 ` =已有数万台节点进行了混部，混部后将原机器的 CPU 利用率绝对值进步了 20%以上。

2.1.5 Smart Resource : 在工作时/z . | P )重启时调整资源

YARN 在字节跳动的优化与实践
原生的 YARN 中，用户恳求的资源和实践运用的资源常常会出现比较大的偏差, 导致出现很多的资源浪费的状况，为此我们开^ A M : ,发了一整套的资源动态调整方案，可以将恳求的资源调整到接近于实践运用资源的数值。

并且，在^ C l K b . R ) E实践运用中发现，假设资源调整有必要以一个核为最小粒度的话，仍是z ) y ( %会出现很严峻t | o的浪费，比如用户! ^ u g N真实的需@ ) c y求可能是 0.001 个核*1000，原生的 YARN 只能分配 1000 个核，就白白浪费了 999 个核。我们开发了以千分之一核为最小粒度的功用，可以有用的削减资源的浪费。并且千分之一核与资源动态调整结合，可以更加精细化的K F # – X X g调整资源。

2.2 多种负载场景优化

字节跳动的 YARN 承载了公司内的 批处理 / 流式 / 模型操练 三大场景，由于^ Q x T p _ YARN 天然生成是为批处# C | ? 5 | h 9 @理而规划的，许多地方与流式 / 模型操练场景并不匹配，为了给 @ ] [ 2 O W这些场景更好的体会，需求做一些定制作业。

2.2.1 YARN Gang Sched$ A / E ? ) buler 调度器

YARN 在字节跳动的优化与实践
流式作业和操练作业的调度需求与批处理有很大的不同：批处理着重的是高吞吐，而流式/操练类型的作业更加着重低推迟和全局视角。为了补偿原0 L 4 | o生 YARN 在低推迟和全局视角上的缺点，我们开发了一个全新的调度器 Gang Scheduler。

Gang Scheduler 供应了一个 All-or-Nothing (一次全交给T k F M B ~或不交给)的语义，如作业恳求 1000 个 container，那么要么直接X } M ) u @ – v回来 1000 个 container，要么就回来失利，并提示失利的原因。这样可以有用的避免} ] i两个作业都只拿到一半的资源，谁也无法发动的互锁局势。

除此之外，Gang Sc2 F x , u ^ + ^ {heH Q I Gduler 还有个特性是超低推迟， 它可以在毫秒级给出 All-or-Nothing 的结论，这样可以大大缓解流式作业在重启时的 lag 积压问题。

最重要的是，Gang Schf Y [ , 1 g { p (eduler 为流式作业和操练作业供应了全局视角，每个作业可以通过配备自己定制的强捆绑和弱捆绑来抵达全局最优的放置战略。其间，强捆绑是指有必要要满足的条件；弱捆绑是指尽量满足，但确实无法满足时1 2 t u – S [ y y可以承受降级的捆绑。现在支D K [ u撑的强捆绑包括节点特征, 高负载等；支撑的弱捆绑包括：节点特征，高负载，f ] T | 3 z ) U zContainer 打散C E ! b n，Quota 均匀，GPU 亲和性等。

2.2.2 更加精细化的 CPU 运用战略

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

除了敞开 YANR 原生默认支撑的 CGroup 捆绑之A ) ( ; d /外，我们还配备了更加= A K丰盛的 CGroup 处理战略，比如在 share 方式下支撑自定W 3 ; X a V i义的最大值捆绑，支撑绑核，支撑绑 NUMA 节点等. 通过这些办法，给流式作业和操练作业更加灵= 9 U r敏的管控战略，满足不同场景下的隔绝或共[ & # ,享需求。

2.2.3 操练场景下的其它定制

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

关于操练场景，我们还定制了更丰盛的内容。包括：

  • 为了更好的隔绝性，定制了支撑 GPU 和 Ceph 的 Docker
  • 为了更灵敏的资源恳求，定制了带规划的资源值 (传统的 YARN 资源只需个数, 没有规划，比如多少个 CPU，多少 GB 内存，但在u c J y 操练场景下，有时希望有规划，比如当需求两个 GPU 卡时，不止希望随意的两张卡，而是希望要一台机器上两个连号的 GPU 卡，比如卡 0 和卡 1 是连号的，而卡 0 和卡 2 不是连号的。这个场景相同也适用于端口号。)
  • 为了更高效的一同运用 CPU 和 GPU 机器，定制了节点特征功用。

2.2.4 越过高 Load 节点

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

离线批处理场景c $ u g常常会遇到”Fetch Failed”的问题，首要来历是本地的磁盘 IOPS 缺乏，导致 Shuffle Service 卡住，为了缓解这个问题，我们在资源调8 t D度的进程中参加方针主机 LoadAvg 的考虑要素，假设一台机器的 LoadAvg 过高，则暂时越过对其分配新任务. 通过这个机制，x P W ` P将”Fetch Failed”问= l n O . Z N ;题下降了约 40%。

2.3 稳定性优化

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

字节跳动的 YARN 服务规X k _ 0划巨大，在稳定性方面遇到了许多应战，有许多细节方面的优化，在这里由于时间有限，选择几个比较有代表性的优化点跟我们共享一下：

  • 将 HDFS 做成弱依托

    • 关于一般的离线批处理来说，假设 HDFS 服务不可用了，那么 YARN 也没必要持续工作了。但是在字节跳动内部由于 YARN 还一同承载流式作业和模型操练，因而不能容忍 HDFS 毛病影响到 YARN。为此，我们通过将 NodeLabel 存储到 ZK 中，将 Cb ( Y % 1 * J rontainer Log 在 HDFS 的目录初始化和上传都改为异步的办法，脱节了对 HDFS 的强依托。
  • Container 分级与驱赶

    • 某些 Container 的 S 4 B E t磁盘空间占用过高，或许! $ . P C将单机 Load 打得十分高，会比较严峻的影响到其它 Container 的正常工作，为此，我们为 YARN 定制了 Container 分级与驱赶机制。关于可能会严峻影响到其它 Conta_ ? M w *iner 的 Container 会进行自动驱赶。关于被驱赶的作业，可恳求到独立的 Label 中工作。
  • 非受控 Container 的整理机制

    • 由于种种原因，线上总是会出现一些 Container 分明还/ k g h B s m ~在工作，但是现已不受 YARN 的管控。一般是由于不正A 9 e i E 5常的运维操作发生，或许机器自身呈j l 7 , 2 I现毛病导致。关于这些 Container 假设不加操控，不仅会让单机的实践资7 ` | ;源紧张，有时还会形成 Kafka Topic 的重复消费导致线上事端。为此我们在 YARNS A b . 的 NodeManager 中增加了非受控 Container 的整理机制。

2.4 异地多活

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

跟着公司展开迅猛，YARN 也迎来了异地多机房的场景，原生的 YARN 只支撑单集群运用, 对用户的运用形成不便，假设每w b (个集群都孤立的供应给用户的话，会让用户运用起来很困难，为此，我们对异地多活做了一些定制作业：

  • 全球共同的 YARN UI4 # w 5 l F 界面

    • 为一切的 YARN 用户一s 9 b d 8 2致定制了一个 YARN UI 界面，该界面包括全球的一切队伍和用户的K d ( 7 6 F ]作业。
  • 抛弃数据本地性调度推迟等待

    • 当有多个集群时，很难与 HDF1 | 8 r j qS 的数据进行本地性对齐。
    • 机房内网络资源充裕，数据本地性对功用进步不显着，还会导致集群吞吐下降。
  • YARN 安全方式

    • 为了合作多机房容灾，有时需求自动将部分Z , X g F u YARN 集群设置为不调度4 a $ W新任务的安全方式。

3. 未来作业

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

未来我们会持续的优化与流式和在线服务的混部作业，包括：

  • 物理利用率进步
  • 更好的K W q + % v |隔绝
  • 更加可控的杀死率
  • GPU 资源的混部

一同，我们也u 0 N m I I会持续完善 YARN Gang Scheduler，包括：

  • 更加丰盛_ K V的调度谓词
  • 更加低推迟

47 3 J _ ( T W Y L. 团队介绍

根底架构 YARN 团队担任字节跳动公司内部离线/流式/模型操练三大场景的资源处理和调度， 支撑了举荐/数仓/搜索/广告等很多中心业务，处理着在集群规划、调度吞吐能力、资源利用率、业务复杂性等多个方向上都在业界抢先的超大规划集群。

针对公司内的抖音、今天头条等产品重度依托举荐的特征， 团队对调度器进行了深度定制以支撑流式(Flink)操练和 GPU 操练等场景t * d I S t 0 Q， 具有几十项专利技术。一同为了进一步进步集群资源利用率，调度团队现已敞开在离线大规划混部，并且预期在不久后会进一步交融 YARN / K8S 等调度系统。

业务扩张，团队长 ) & T时间在北京/杭州招人N D Y Z | [。简历] t m ^ l f I投递入口: https://joby M a ; 2 i.toutiai M Bo.com/s/KcoXsV

欢迎注重字节跳动技) m } 2 B m d V &术团队