深入理解百度在离线混部技术 _离线混部技术

1. 什么是在离线混部混部概念中将应用类型分为在线业务和离线业务两种。

在线和离线业务如何划分？在百度内部，我们认为在线业务特点包括但不限于：运行时间长，延时敏感，对稳定向要求较高，服务不稳定业务会立马感知并且带来损失，有明显的波峰波谷，白天高，深夜低，比如广告搜索业务；而离线业务的特点包括但不限于非延时敏感，可重试，运行时间一般较短在几十分钟左右，内部一般为大数据计算，机器学习等服务。

在线业务以搜索为例，白天用户工作学习时查询量会非常大，但是当大部分用户夜间休息时，查询量相对白天就会变得非常小，此时我们就可以引入离线业务。离线业务没有严格的时间要求，随时都能跑，用户关心的是任务能不能跑完，对于什么时候跑完并没有太大的需求，同时如果单机上资源有冲突，此时我们会压制离线业务，甚至会驱逐离线业务，这对用户是无感的，计算平台重新拉起任务，继续计算。

因此，在线型业务和离线业务具备资源互补的特点，从时间上和对资源的容忍度上可以完美的结合到一起。一方面，在线业务的优先级更高，单机和调度层面会优先保障在线的资源，可能会对离线进行压制和驱逐，另一方面，对于离线任务来说，压制和驱逐对用户是无感的，只需要保证任务顺利完成，有很高的容忍度。

简单来说，将在线业务和离线任务混合混部到相同物理资源上，通过资源隔离、调度等控制手段 , 充分使用资源，同时保证服务的稳定性，我们称这样的技术为“混部” 。

2. 资源利用率为何不高？纯在线业务集群的平均利用率普遍不高，百度应用混部技术之前，在线业务集群CPU利用率普遍在20%左右，造成这种现象主要由一下几种原因：2.1 潮汐现象和冗余在线业务在申请资源的时候，一般是按照最高峰值评估资源去申请资源，同时还会上调一些，这就导致了业务对资源预估不准，申请的资源远大于实际使用资源。甚至可能会部署多个副本作为灾备。此时的低峰时利用率就会非常低，导致整体利用率不高。2.2 在离线分池一般来说机房规划的时候有一个非常大的特点，就是离线机房与在线机房分离做规划。举个例子，假如我们在宁夏做一个机房，这个时候肯定会考虑做一个离线机房，因为在线机房需要考虑网民请求地域分布的问题，要获得最好的访问优化体验以及访问速度，势必需要在一些访问热点上去做自己的在线机房规划，比如北京、上海、广州等。而对于离线机房来说不用关心这些，它最在乎的是如何提升计算和储存的资源和基础设施的规模，所以在线业务和离线业务本身的资源需求和特点不一样，资源利用率非常不均衡。常态表现就是在线利用率低，离线利用率高，且常态资源不足。针对以上场景，我们通过在离线混部技术将在离线资源统一资源池，把离线作业部署在在线资源池节点上，充分利用机器资源，达到了提升资源利用率的目的。

3.百度云原生混部详解随着 Kubernetes（以下简称「K8s」）生态的蓬勃发展，百度很多业务已经搭建并且运维了自己的诸多 K8s 集群，同时也遇到了一些问题，比如上面所说的资源利用率不高。我们根据内部积累混部经验对 K8s 进行在离线混部原生化改造，做到了零入侵K8s，可移植，可支持大规模集群。

文章插图

混部系统架构图
3.1 如何做到资源复用？
原生 K8s 基于静态视图分配

文章插图

上图显示了一个节点的 CPU 使用率和分配率，分配率为89%，使用率在0-16点之间都在20%以下，17点开始是用量高峰，在30-40%之间。可以看出 request 和 used 之间有大量的资源处于闲置状态，如果想让这部分资源可以重复利用起来，就需要调度更多的 Pod 上去，但是从 K8s 调度器视角来看，已经没有更多的 CPU 分给 Pod了。

如果部署 request 和 limit 都不填写的 Pod，此时它可以被调度，但是 K8s 针对这种 BestEffort 的 Pod 不会根据用量调度，可能会被调度到一个实际很繁忙的节点上，非但无法起到提升使用率的效果，可能还会加剧节点上服务的延迟。

动态资源视图
针对 K8s 无法根据资源使用量分配资源，我们引入了动态资源视图。