vivo 在离线混部探索与实践

数据中心运行的服务可以分为在线服务和离线任务两大类，它们具有不同的资源使用特征。

在线服务是指那些长时间运行、对时延非常敏感的服务，如电商、游戏等，在线服务的资源利用率存在明显的波峰波谷现象，平均利用率较低。离线任务是指那些运行周期短，有容错性，对实时性要求低的服务，如数据转换、模型训练等，离线任务在执行过程中资源利用率很高。

在混部之前，在线和离线都是分开独立部署，机器不共享，无法形成有效的资源互补，这导致数据中心整体资源利用率不高，却要不断购买新机器，造成了资源浪费。

通过混部技术，我们可以将在线和离线部署到同一台物理机上，形成资源互补，提升物理机的资源利用率，降低成本。混部技术最早由谷歌在2015年提出，经过多年的发展，混部技术已经趋于成熟，目前业内利用混部技术可以将数据中心的CPU利用率提升至40%左右 。

vivo在2020年开始调研混部技术，2023年混部平台投入生产，目前我们已经将部分混部集群的CPU利用率提升至25%（最新已达30%）左右。相较业界标杆这还有一定的差距，但随着混部规模的扩大，我们将挑战更高的目标。

2.2 混部差异化资源视图

为了保障混部系统的slo，我们将服务分为三个等级：高、中，低。

不同等级的服务对物理资源如：CPU、内存 使用时有不同的优先级。高优先级服务支持绑定CPU模式，适用对延时非常敏感的在线服务。一般的在线服务可设置为中优先级。离线任务设置为低优先级，通过这样的等级划分，我们很好的实现在线对离线的资源压制和隔离，保障了在线服务质量。

我们所有的混部组件都是以插件方式独立运行，对原生K8s无侵入。我们实现了一个混部调度器，在线和离线统一使用这个调度器，避免了多调度器资源账本冲突的问题。

每台物理机上都会部署一个混部agent，它可以实时采集容器资源使用数据，并根据安全水位线对离线任务进行压制、驱逐等操作。

内核层面我们使用了龙蜥OS，它具备强大的资源隔离能力，可以帮助我们更好的隔离在线、离线资源使用，保障在线服务质量。

我们把混部组件分为管控组件和单机组件两大类。

管控组件主要负责调度和控制，根据vivo业务使用场景，我们对调度器做了一些增强，提供了numa感知、负载感知，热点打散，批量调度等能力。

混部控制器主要提供了一些配置管理能力：如资源画像统计、node slo配置、node扩展资源变更等。

我们为混部建立一套完整的可视化监控体系。

针对在线服务我们提供了：容器资源使用指标，受离线干扰指标、业务混部收益指标等监控能力。

针对离线任务，我们提供了离线可用资源、任务异常状态等监控能力。

在平台层面上我们提供了节点、内核，核心组件的监控，通过这些监控可及时发现平台潜在的风险。

为了简化运维操作，提升运维效率，我们对混部集群搭建和节点扩缩容操作进行了白屏化改服务器托管网造，开发了资源池管理功能，简化了物理机接入流程，运维效率大幅提升。

在运维平台上运维人员可以快速调整混部隔离、水位线等参数，如果发现在线服务受到干扰，运维人员可以一键关闭混部，驱逐离线任务，保障在线服务质量。

通过混部产品能力的建设，我们很好的实现了容器混部能力，但是在实践中我们还是遇到一些新的挑战：相对于普通K8s集群，混部集群中运行着更多的容器，而且离线任务由于生命周期短，容器创建销毁更为频繁，这对K8s apiServer 产生了很大的压力。

所以我们拆分了apiServer ，离线任务使用独立的apiServer ，保障了集群apiServer 负载一直处于一个安全水平。

在大方向的技术选型上，我们选择了 Spark on K8s，在业内，也有一些公司采用了 YARN on K8s的方案。我们也对这两种方案进行过对比。

从业务适用性来说，YARN on K8s 是通用的，可以兼容Hive、Spark、Flink这些引擎，它不需要频繁创建Nodemanager pod，对K8s的压力比较小。这些都是它的优点，但另一方面，Nodemanager ESS服务是对磁盘有容量和读写性能要求的，混部机器磁盘一般难以满足。所以我们要支持不同引擎的remote shuffle service。

如果计算引擎有不同的版本，那么RSS也要支持不同版本，比如Spark2，Spark3。如果你有不同的引擎，不同的版本，很可能一种RSS还满足不了需求。另外Nodemanager需要根据K8s混部节点的剩余资源，动态调整可用的vcore和内存，所以还需要一个额外的组件来做这个事情，这需要较高的改造成本。在资源利用上，NM的资源粒度相对大，自身也会占用一些资源，存在一定的浪费。在资源紧张的情况下，Nodemanager作为整体被驱逐，会影响多个任务。这些是YARN on K8s的劣势。

作为对比，Spark on K8s 劣势有哪些？

首先这个特性在Spark 3.1以上版本才正式可用。Spark on K8s由于会频繁的创建、查询、销毁大量的executor pod，对K8s的调度能力以及master节点会造成比较大的压力。另一方面，它的优势在于只需要能支持spark3.X的RSS，这有较多的开源产品可选择。而且改造成本比较低，不需要额外的组件。资源粒度小，更有利于充分利用集群资源。在资源紧张时，会逐个pod进行驱逐，任务的稳定性会更高。

两方案各有优劣势，为什么我们选择了Spark on K8s？一方面因为Spark3.X是vivo当前及未来2~3年的主流离线引擎，另一方面vivo内部对K8s研发比较深入，能有力支持我们。基于以上原因，我们最终决定使用spark on K8s

在任务跑通、跑顺的第一阶段，我们要解决的是怎么将任务提交K8s集群，同时要求易用性、便利性方面能够达到与on YARN 一致的用户体验。将我们最后采用的方案架构简化一下，就如同这张图所示。

首先，为了降低任务提交的复杂性、避免用户改造任务的成本。我们在任务调度管理平台做到了对原有Spark任务的兼容，通过vivo内部的容器开放API-这个代理层，我们不需要维护额外的K8s client环境，就可以轻松实现任务提交，提交后也能近实时获取任务的状态和日志信息。

另外一个关键点是，我们选用了Spark Operator作为Spark任务容器化的方案。Spark Operator是谷歌基于K8s Operator模式开发的一款的工具，用于通过声明式的方式向K8s集群提交Spark作业。

Spark Operator的方式还有其他优点：

第一个是日志查看，因为Spark Operator方式并没有提供已结束作业的日志查看方式，包括driver和executor日志。在Driver侧，我们通过定期请求容器开放API，能准实时地获取Driver Pod状态与日志。在Executor侧，我们参考了on yarn的方式，Executor Pod结束后，日志上传HDFS，与YARN日志聚合类似。

另一方面，我们也在Spark HistoryServer做了二次开发工作，增加了on K8s方式的日志查看接口。用户查看已完成的Executor日志时，不再请求JobHistory Server，而是请求Spark HistoryServer接口。在体验上做到了基本与yarn一致。

在混部K8s集群，我们也做了三方面能力的加强。

在弹性方面，我们需要做到实时根据混部集群资源闲忙，智能提交至混部集群或者Hadoop集群。在前期我们K8s集群的资源相对Hadoop是小头，通过合理的水位线控制，防止大量任务同时调度到K8s导致饿死。

健壮，就是要保证任务的高可用。

我们建设的能力包括：

目的是在用户任务迁移时做到让用户无感。

在满足业务需求方面，我们支持优先调度本业务的离线任务， 优先满足业务部门的离线任务资源需求；支持只在指定时间段里调度离线任务，支持在出现异常情况下一键终止调度K8s。这些是为了确保在线服务的高可用性，免除在线业务的后顾之忧。

最后，我向大家同步下，当前我们达成的混部效果。