开发笔记:腾讯云EMR基于YARN针对云原生容器化的优化与实践

导语 | 传统HADOOP生态系统使用YARN管理/调度计算资源&＃xff0c;该系统⼀般具有明显的资源使⽤周期。实时计算集群资源消耗主要在⽩天&＃xff0c;而数据报表型业务则安排在离线计算集群中。离在线业务分开部署的首要问题就是资源使用率低&＃xff0c;消耗成本⾼。随着业务的增⻓和突发的报表计算需求&＃xff0c;为了解决为离线集群预留资源&＃xff0c;腾讯云EMR团队和容器团队联合推出Hadoop Yarn on Kubernetes Pod&＃xff0c;以提⾼容器资源使用率&＃xff0c;降低资源成本&＃xff0c;将闲时容器集群CPU使⽤率提升数倍之多。本文主要介绍HADOOP资源调度器YARN在容器环境中的优化与实践。

一、Hadoop Yarn on Kubernetes Pod 混合部署模式

Hadoop Yarn on Kubernetes Pod 方案提供弹性扩缩容和离在线混合部署两项功能。弹性扩缩容主要聚焦于如何利⽤云原生资源&＃xff0c;快速扩容资源以补充算力。离在线混合部署模式的目的是为了充分使用在线集群的空闲资源&＃xff0c;尽可能减少为离线集群预留空闲资源的频次。

EMR弹性扩缩容模块&＃xff08;yarn-autoscaler&＃xff09;提供按负载和按时间弹性伸缩两种扩缩容方式。对于按负载伸缩&＃xff0c;用户可以对不同指标设置阈值来触发扩缩容&＃xff0c;比如设置Yarn队列中availablevcore、 pending vcore、available mem、pending mem。亦可以使用时间扩缩规则&＃xff0c;按天、按周、按月等规则指定触发。

当弹性规则被触发后&＃xff0c;离在线部署模块获取当前在线TKE集群中可以提供的闲置算力的规格及数量&＃xff0c;调用Kubernetes api创建对应数量的资源&＃xff0c;ex-scheduler扩展调度器确保Pod被创建在剩余资源更多的节点上&＃xff0c;该POD负责启动YARN的服务。

通过该方案&＃xff0c;Yarn的NodeManager服务可以快速部署到POD节点中。但也Yarn原生调度没有考虑异构资源&＃xff0c;由此引发了两个问题&＃xff1a;

1. AM的POD被驱逐&＃xff0c;导致APP失败

在node节点的资源紧缺的条件下&＃xff0c;kubelet为了保证node节点的稳定性&＃xff0c;会触发主动驱逐pod的机制。如果该节点存在AM服务&＃xff0c;则整个Application就要被视为失败&＃xff0c;ResourceManager此时会重新分配AM。对于计算量很大的任务&＃xff0c;Application重跑的代价不可承受。

2. Yarn原生非独占分区资源共享局限性

Yarn的标签分区特性⽀持独占分区&＃xff08;Exclusive&＃xff09;&＃xff0c;非独占分区&＃xff08;Non-exclusive&＃xff09;。 

• 独占分区&＃xff08;Exclusive&＃xff09;&＃xff1a;例如指定独占分区x&＃xff0c;Yarn的container只会分配到该x分区。

• 非独占分区&＃xff08;Non-exclusive&＃xff09;&＃xff1a;例如非独占分区x&＃xff0c;x分区的资源可以共享给default分区。

  只有当指定分区default时&＃xff0c;default上运⾏的Application可以使⽤分区x的资源。

但是在实际使⽤场景中&＃xff0c;⽤户要给各个业务部门分配各自的独占分区资源&＃xff0c;同时会划分出供各部门使用的default分区。default分区资源会比较充足&＃xff0c;业务部门希望能够使用自己的独占分区和同时充分利用default分区资源&＃xff0c;独占分区资源和default分区都不够用的时候&＃xff0c;才会触发弹性扩容&＃xff0c;往属于自己的独占分区中扩容资源。

二、对Yarn改造带来的挑战

对上述feature的开发&＃xff0c;除了需求技术本⾝的难度。还需要考虑到尽可能降低用户存量集群稳定性的影响&＃xff0c;减少用户业务侧改造成本。

• 集群稳定性&＃xff1a;Hadoop Yarn作为大数据系统中的基础调度组件&＃xff0c;如果改动过多&＃xff0c;引发的故障几率就会增大。同时引入的feature,必然需要升级存量集群的Haoop Yarn。升级操作要做到对存量业务集群无感知&＃xff0c;不能影响到当天的业务。

• 业务侧使用成本&＃xff1a;引入的新feature也必须符合原⽣yarn的使用习惯&＃xff0c;方便业务侧用户理解&＃xff0c;同时降低业务侧对代码的改造。

1. AM自主选择存储介质

目前Yarn的社区没有考虑云上异构资源混合部署的特点。在线TKE集群中&＃xff0c;当资源紧张时会对容器进行驱逐。为了避免Appliction重新计算&＃xff0c;浪费资源的现象&＃xff0c;必须提供AM可以指定能否分配到POD 类型资源。

自主选择存储介质中&＃xff0c;使用配置化标识&＃xff0c;由NodeManager通过RPC上报能否将资源提供给AM使用&＃xff0c;ResourceManager通过上报信息决定将Application的AM分配到稳定资源介质中。由NodeManager通过配置化上报信息的好处是显而易见的&＃xff1a;

• 去集中化&＃xff1a;减少ResourceManager处理逻辑。否则&＃xff0c;扩容资源时&＃xff0c;还需将资源信息通过RPC/配置流入到ResourceManager中。如无必要&＃xff0c;勿增实体&＃xff0c;对ResourceManager的改造应该轻量化。

• 集群稳定性&＃xff1a;存量业务集群对Yarn升级后&＃xff0c;需要重启NodeManager, 只需要重启ResourceManager。Yare的高可用特性可保证升级过程对业务无影响。无需重启NodeManager 的原因是&＃xff0c;NM默认将本机资源视为可分配。
  

• 简单易用&＃xff1a;用户可以通过配置⾃由决定任务资源拥有分配AM的权利&＃xff0c;不单单局限POD容器资源。

2. 多标签动态分配资源

Yarn的原生标签设计中&＃xff0c;提交任务时的标签表达式中只能含有单个标签。如果为了提⾼利用率&＃xff0c;同时使用多个分区资源&＃xff0c;就必须将非default分区设置为Non-exclusive特性。标签表达式必须解决如下三个问题&＃xff1a;

• 资源隔离&＃xff1a;分区A设置Non-exclusive后&＃xff0c;资源被其他分区上的APP占用后&＃xff0c;无法及时交换给分区A的App。

• 自由共享资源&＃xff1a;只有default分区才有资格申请Non-exclusive分区资源。

• 动态选择分区资源&＃xff1a;多分区资源共享时&＃xff0c;无法根据分区剩余资源大小选择可用区&＃xff0c;影响任务执行效率。

腾讯云EMR团队通过支持扩展表达式语法&＃xff0c;增加对逻辑运算符表达式的支持&＃xff0c;使App可以申请多个分区资源。同时开发资源统计模块动态统计分区可用资源&＃xff0c;为App分配最合适的分区。

三、实操演练

测试环境&＃xff1a;指定172.17.48.28/172.17.48.17的NodeManager为default分区&＃xff0c;172.17.48.29/172.17.48.26的NodeManager为x分区。

队列设置&＃xff1a;





yarn.scheduler.capacity.root.queues
a,b



yarn.scheduler.capacity.root.accessible-node-labels.x.capacity
100



yarn.scheduler.capacity.root.accessible-node-labels.y.capacity
100




yarn.scheduler.capacity.root.a.accessible-node-labels
x



yarn.scheduler.capacity.root.a.capacity
50



yarn.scheduler.capacity.root.a.accessible-node-labels.x.capacity
100




yarn.scheduler.capacity.root.b.accessible-node-labels
y



yarn.scheduler.capacity.root.b.capacity
50



yarn.scheduler.capacity.root.b.accessible-node-labels.y.capacity
100





1. 规定AM只能分配在172.17.48.28

对另外三个节点的NodeManager节点配置如下配置项:

yarn.nodemanager.am-alloc-disabled &＃61; true


配置后&＃xff0c;提交的Application的AM只能在172.17.48.28节点启动。

2. 使用组合标签

通过mapreduce.job.node-label-expression指定标签表达式&＃xff0c;x||表示同时使用x/default分区。

hadoop jar /usr/local/service/hadoop/share/hadoop/mapreduce/hadoop-mapredu ce-examples-3.1.2.jar pi -D mapreduce.job.queuename&＃61;"a" -D mapreduce.job. node-label-expression&＃61;"x||" 10 10


使用该命令提交后&＃xff0c;观察到Application的container被分配在x/default分区。

四、Hadoop Yarn on Kubernetes Pod 最佳实践

该客户大数据应用和存储跑在Yarn管理的大数据集群&＃xff0c;在生产环境中&＃xff0c;面临诸多问题&＃xff0c;主要体现在大数据的算力不足和在线业务波谷时资源的浪费。如离线计算在算力不足时&＃xff0c;数据准时性无法得到保证&＃xff0c;尤其是当遇到随机紧急大数据查询任务&＃xff0c;没有可用的计算资源&＃xff0c;只能停掉已有的计算任务&＃xff0c;或者等已有任务完成&＃xff0c;⽆论哪种⽅式&＃xff0c;总体任务执行的效率都会大打折扣。

基于Hadoop Yarn on Kubernetes Pod 方案&＃xff0c;将离线任务自动扩容至云上集群&＃xff0c;与TKE在线业务集群混合部署&＃xff0c;充分利用云上波谷时段的闲置资源&＃xff0c;提高离线业务的算力&＃xff0c;并利用云上资源快速的弹性扩容能力&＃xff0c;及时补充离线计算的算力。

通过Hadoop Yarn on Kubernetes Pod ⽅案对客户的在线TKE集群资源使用进行优化后&＃xff0c;集群闲时CPU使用率能提高500%。

在线集群闲时CPU占用

离在线混部后CPU占用

五、总结

本文提出了基于YARN针对云原生容器化的优化与实践&＃xff0c;在混合部署云原生环境中&＃xff0c;极大地提高了任务运行的稳定性&＃xff0c;高效性&＃xff0c;有效提高了集群资源利用率&＃xff0c;节约硬件成本。在未来&＃xff0c;我们会探讨更多大数据云原生场景&＃xff0c;为企业客户带来更多的实际效益。

作者简介

张翮&＃xff0c;腾讯云高级工程师&＃xff0c;目前主要负责腾讯云大数据产品弹性MapReduce的管控相关模块和重要组件Hive的技术研发。向Apache Hive&＃xff0c;Apache Calcite开源项目贡献过代码&＃xff0c;毕业于电子科技大学。

点击文末「阅读原文」&＃xff0c;了解腾讯云弹性 MapReduce更多信息~

腾讯云大数据

长按二维码
关注我们