8-2 Hadoop Yarn 在小米的实践.pdf

1、HADOOP YARN HADOOP YARN 在小米的实践在小米的实践涂瑜 计算平台-高级软件开发工程师|工作经历小米 计算平台-高级软件开发工程师 主要负责大数据离线资源调度的开发与维护知乎 计算平台-高级软件开发工程师 曾负责知乎高并发网关建设，大数据存储与离线资源调度服务的开发与维护|个人简介个人对大数据计算存储，网络，高并发编程相关领域感兴趣0101调度优化实践调度优化实践0303Yarn Yarn 扩展性与其他优化扩展性与其他优化0202资源优化实践资源优化实践0404Yarn Yarn 元仓建设元仓建设目录目录 CONTENT|最大规模节点数集群数量最大规模队列数集群现状20+6

2、K+1K+|调度优化实践调度优化实践请01|问题修复-节点资源更新导致调度卡顿问题|-队列资源异步批量更新异步批量更新，节点上报不直接触发资源更新问题描述-节点资源变动导致长时间更新资源更新-与调度线程持有同一把锁-队列数过多导致情况加剧解决方案1.使用 legacyMergeSort -Djava.util.Arrays.useLegacyMergeSort=true2.调度线程使用深拷贝队列数据进行调度过程的计算|问题修复-Global Scheduler 多线程调度崩溃问题描述-RM 因调度线程崩溃导致长时间 hang 住不做任何调度TimSort自反性：x，y 的比较结果和 y，x 的

3、比较结果相反传递性：xy,yz,则 xz对称性：x=y,则 x,z 比较结果和 y，z 比较结果相同解决方案 YARN-10178-仲裁线程根据分配结果修改子队列资源配额-调度线程队列排序不整体加锁不整体加锁，导致资源变动-打破 TimSort 数据要求，导致调度线程异常崩溃分析问题描述-调度分配获取队列 ResourceLimit 时，Resources.min 基于 DRF 只考虑了主导资源，导致调度线程通过超过队列 max capacity 资源申请-仲裁线程严格判断各项资源，导致大量的 Failed to accept this proposal 失败，严重影响调度性能|问题修复-Re

4、sourceLimit 计算逻辑导致调度性能问题解决方案 YARN-11083-通过 RponentwiseMin 返回各项资源限制的最小值跳过 userlimit 计算逻辑 -背景 内部场景不需要队列级别多用户之间的资源隔离机制 大量无效计算，导致调度效率不高 -优化手段 配置加载时，基于队列 minimum-user-limit-percent,userlimit-factor 计算是否关闭 userlimit 计算，节省大量计算逻辑单次分配多个 container -背景 调度链路在队列数较多时产生大量排序工作 集群规模较大时，可以接受放弃一定的队列公平性来提升集群的调度性能 -优化手段

5、 调度尝试选择出子队列之后，尝试分配多个 container 以提升单位时间分配的 container 数量|性能优化|性能优化效果 通过 SLS 压测工具，CPS 3k+-5k+60%左右的性能提升 userlimit 大概有 30%左右的提升 单次分配 2 个 container 大概有 30%左右的提升资源优化实践请02|弹性调度弹性资源default资源节省资源离线集群资源运行曲线期望的资源使用方式|AppAppAppApp00:0012:0000:0012:0000:00App弹性资源时间低优不适合弹性高优适合弹性作业筛选根据以下两个维度对历史作业进行筛选时间维度：作业运行时长、是否

6、与节点下线时间重合优先级维度：高优、默认、低优作业配置将筛选出来的作业，通过内部的作业提交工具，把 Label 表达式的配置统一设置，用户无感知节点下线时间节点下线时间弹性调度作业筛选|弹性调度方案细节思考点|-AM AM 避开弹性节点类不稳定资源-Label|表达式 开发标签或表达式支持 label1|label2 配置，作业可使用两类资源-Remote Shuffle Service shuffle 数据不落本地盘，避免 shuffle 数据丢失带来的任务重算-Graceful Decomission 节点下线前预先做 graceful decomission，尽量保证作业的稳定性更详细方