全域调度：云边协同在视频场景下的探索实践

随着多媒体业务越来越多的涌现，每个业务都有不同的差异性特征。各大视频云厂商遇到的最大挑战是如何打造多媒体分发网络，使用最低成本为多业务提供最优质网络体验。本次分享邀请到了华为云算法专家——杨昌鹏老师，为我们介绍云边协同在视频场景下的探索实践。

文 / 杨昌鹏

整理 / LiveVideoStack

大家好，今天我会从云厂商的角度与大家分享一下怎么去做全域调度，本次分享的题目是——全域调度：云边协同在视频场景下的探索实践。

首先自我介绍一下，我本人是视频领域的新手，之前主要的研究方向是云资源相关的调度优化，包括VM调度，容器调度。最近一段时间主要在做视频相关的调度，包括带宽资源的规划和调度相关的算法研究。

本次分享，主要包括以上四个方面，其中核心模块是后三个，接下来，我将为大家一一进行介绍。

#01

全域调度简介

分享的第一部分是全域调度的简介，大家对这个词可能会比较陌生，实际上这是在上周华为TechWave上发布的分布式云的概念，分布式云其实就是一张网，把客户所有不同类的请求全部纳管起来。对客户来讲我们是统一的架构和管理界面，但对我们来说，这里面需要很多的调度技术，全域调度就是里面非常核心的模块。

说到调度，一个友商同事曾说，调度的本质是修路，其实我不太认可。说到调度一定要有两个对象，一个是资源，另一个是业务，这两个东西如果脱离任何一个来讲，都不合适。如果调度的本质是修路的话，那应该还要看你有预算。我们可以先从云厂商的角度来看调度，业务是多样性的，典型的主要包括点播、直播、RTC。每种业务的时延要求、质量以及其承载的规模都是不一致的，同时每种业务采用的基础架构也有不一致性。比如点播的形式，基本采取通过存储上面的Cache来换带宽。直播和RTC都是长连接，做调度时需要注意的是端到端的时延，所以非常不一样。

我们再看资源，资源层也分为两块，其一是计算资源，其二是带宽资源。在视频云上涉及到整个全链路资源，包括端侧，边缘侧，中心节点，公有云。这些资源在算力上明显是由低到高的，同时还会有一些带宽资源，在时延和成本上都是不一致的。所以我们的业务种类有很多，资源种类也有很多。

一个非常朴素的想法是，我们如何实现多业务和多资源的协同匹配，这其实在现实中是有案例的。比如我们的快递网络，一家公司可能有做快的票单，也有做慢的票单，实际上它们也是资源的协调。例如有些线路上，快慢件可以放一辆车上，有些快慢可以放到不同的独享车辆上，这些都是从资源利用率的角度上考虑的。实际上我们云上面临的调整会更大一些，因为我们本身决策的颗粒度和时长会有更高的要求，可能是毫秒级的，同时云上的业务种类众多，使得我们整个调度问题会变得非常复杂。

这个复杂我们可以从两个视角来看，一个是我们的云使用者来看，其实他的诉求是有“变”和“不变”两种。第一个“变”是说，带宽的资源需求量变化是非常大的，比如针对直播这样的场景，晚上带宽的需求量会突然变高。但是我们的用户又希望在带宽发生剧烈变化时，资源是可以及时获取的。在春节时期，带宽资源会有上百T的需求，那如何去应对这种突发的资源请求呢？

另外业务的种类是不同的，不同的业务有对应的SLA要求，甚至同一个产品，例如直播内还有连麦，包括还有新的业务也在逐渐产生。它们在不同场景下对时延的要求不一样，那么我们如何去应对业务种类多样性？

同时我们的业务本身地域上的分布式也是变化的，比如主播跟用户的分布是非常不一致的。典型来讲，我可能在华南地区和华东地区，我的用户分布会比较多，那如何去应对这些客户的不同变化请求？

客户对这种极致体验、低成本、高可靠性的诉求是一致的，他们永远希望云厂商以极低的成本和极致的体验来提供服务。

那从云厂商角度来看，也有两个要求，其一是高质量，我们首先要承诺给客户最优质的的服务，同时在优质服务的前提下，尽量提高资源的复用效率。只有这样，在资源效率提升以后，我们才会和客户进行降价，才会以更低的成本达到我们市场上的竞争力。

上图是从分布式云概念中截取的，分布式云里面涉及的资源有多种，包括华为云核心区，中心Region资源，包括热点区域智能边缘IEC资源，客户机房布置的IES资源等。调度本质问题变成了如何使得供给侧和消费侧尽量的达到最优平衡。这就需要做很好的用户画像，同时要对客户整个计算资源、带宽资源进行提前的规划和预测。

这其实是一个非常复杂的问题，为了方便大家理解，我来举一个电力行业的例子。电力行业是怎么实现的呢？现在电力行业是非常智能的，我们大家用电、发电的循环迭代是非常快的，它其实在每一个环节都做了一系列的优化才会使得整个系统是非常高效鲁棒的。而云面临的挑战也是一样的。

为了做这个设计，我们做了一个全域调度系统，当前的全域调度有三个模块。一个是资源调度模块，主要负责计算资源的调度，里面有CPU内存相关的调度。资源调度我们开源版叫Arktos，在开源版本中，我么提供一系列的基础调度算法，比如说基于时延、地理位置分布等等。当然，内部用的版本会更加高效，能够支持多目标优化求解以及跨端边云协同资源调度。

我们还做了一个流量调度模块，这里主要包含带宽资源规划以及带宽资源调度。带宽资源调度支持地理位置、时延、QoS、成本的调度。

同时我们针对视频边缘场景下AI任务，设计云边协同的推理和训练框架Sedna，后面会具体介绍。

#02

流量调度

下面我们进入流量调度的部分，这和业务本身特征高度相关，是比较难的模块。

对于流量调度来讲，我们的终极目标是如何设计满足多业务、多目标SLA、异构数据特征下的调度引擎。这里的多业务不用多说，云上的业务本身就是多种多样的。多目标指的是给用户感受到的是用户体验，但云厂商看的是成本，这其实是一级指标，这在数学上是很难写出来的，所以会有一系列的二级指标。比如用户体验可以分为首帧时长、卡顿次数等等，成本可以分为回源率、带宽趋势等，这些二级指标从数学上可以优化出来的。

另外整个系统是具有异构特征的，例如用户空间特征，不同地方分布是不一样的，例如流量特征，在不同时间段是有波峰和波谷的，同时每个站点、主播、用户的分布，以及计算资源、带宽资源、网络特征也都是不一样的。所以在这么复杂的系统下，如何去做调度，这其实是非常难的问题。

华为云流量调度当前包含几个核心模块，第一是带宽规划模块，第二是带宽调度模块。这两个模块理解起来比较抽象，我会用一个比较简单的例子来解释。在一个房间内，有两个老人和三个小孩，买了一个蛋糕，这要怎么分呢？那通常老人是不太爱吃甜食的，小孩比较喜欢，所以我会一比四切分开，两个老人一块蛋糕，小孩四分之三的蛋糕，这就是带宽规划。具体到每个老人和小孩分多少蛋糕，这就是带宽调度。

首先根据不同业务的特征，大颗粒度的规划一下，比如直播，晚上带宽量会比较大，而RTC白天的量比较大，因为RTC会支持很多在线教育，那在带宽复用上会有一定的削峰填谷的机会。这里就像是把蛋糕大块分好，把老人的和小孩的区分开，但每个小孩具体拿多少，需要再做实时的决策。

在这个环节，我们其实做了个数学抽象，我们认真研究了不同业务下的问题的特性，不管是直播、RTC还是点播，从数学问题抽象来讲是类似的。可能业务的同学感觉到问题是不一样的，但从数学描述上是一样的，只不过是约束不一样。比如，RTC和直播的区别在哪，RTC的约数就是200毫秒的时延，但直播可以允许是400毫秒，从数学上本质是一样的。所以之前看到同行做了三张网没有协同，这其实是一个非常大的资源浪费，华为云在做的是实现整个资源上的协同，不管点播、直播、RTC，我们在同站点、同带宽上实现了资源环节上的协同。这才能保证在极致的体验下，给客户更低的成本。

带宽调度是一个实时的环节，实时的问题其实是非常BUG的，因为需要很快的决策，但很快决策的结果就是暴力拍规则，规则的缺点是对整个系统的效率上不是最优的。所以我们即使在实时调度模块，我们设计成了双层架构。

系统从架构设计上会有Global模块和Local模块。Global模块收集的信息可以尽量多，求解的速度可以慢一些没关系，但因为是全局视野，所以最后得到的solution里从全局来看是比较优的。随后，把全局最鲁棒的信息，放进Local模块再做详细的调度。举个例子，Global的环节可能选择了五个站点，比如上海地区接入5个cdn，这五个站点是成本和体验上的最优。在Local环节做实时调节权重，这样能够弥补全局环节预测的不准确性。

下面分几个环节介绍流量调度，第一个是带宽的规划。

带宽规划就是解决每个业务应该如何划分带宽，大家知道，点播直播RTC如果共站点会产生一些问题，点播的量很大，峰值时间段突然上升，如果是共站点就会把RTC挤下来，因为RTC是最优质的服务，需要最先保障。举个例子，在高速公路上，类似RTC这种优先级比较高的，一定要设立专用通道，无论何时保证它是最优先的，如果不解决这个问题，就会下降体验。所以我们做了带宽规划，对RTC直播体验专门保障。但这是很困难的，微软NSDI最近的一篇论文显示他们的这块的技术已经落地，其中的求解规模相当大，在数学上非常难求解，尤其是95计费使得整个问题非线性化的。我们在单区域内做了尝试，难点1（上图）整块的求解之后，我们的体验和成本都有很大的提升。

这个问题的难点还体现在，带宽需求本身是动态变化的，提前做需求规划就要做提前预测，时间上可能预测不准，比如什么时候到达峰值，峰值到达多少。目前预测准确率只能达到90%左右。

第二个是接入环节。

接入环节其实是指派问题的变形版，工程上最简单的办法是做就近接入，缺点是也许可以保证一个区域的时延，但不能保证另一个区域的时延，这是组合优化的问题。华为联合香港大学数学系一起对这块做了系统研究，取得了较好的效果，最终能够在全网环境下快速求解。这个问题的难度受几个点影响，比如Areas的1号节点想要接入Nodes的1号、2号、3号……N号节点（上图），历史数据可能有显示接入1号、2号节点的、但没有显示接入N号节点的。这时的做法应该是首先在稀疏数据额下做精准的Qos预测。总体来说，华为在这个问题上有了更好的思路并且已经基本攻克，但是规模还比较小，我们认为这是视频的根技术，或者说核心问题。

第三个环节是回源问题，本质上是路径优化问题。如何系统地解决需要我们将问题拆开来看，除了要找到一条路径之外，还要到一个转发节点。这里普及一个小知识，回源的意思是一个用户请求视频接入之后，发现这里没有流，就要从其它地方将流拉回来，在物流、航空行业也存在这个问题，但它们都具有自己特性。

刚才的三个问题是基础版本问题，但视频调度尤其在和业务高度相关的调度，带宽规划是多业务的，但实时流量调度是针对每个业务的，这其实很像烟囱结构（底层资源共享，顶层感知每个业务特性）。

整个视频的成本来自两个部分，接入成本和回源成本（BTS Costs）。回源降低成本的核心难点是在QoS保障的情况下实现不同特征的流的调度。华为和清华大学一起提出了Aggcast架构来解决该问题。右图是上线后的效果。带宽回源成本降低了30%，同时体验也是更好的状态。

#03

资源调度

资源调度主要指计算资源的调度，在视频云的场景下会遇到很多类似例子，比如离线转码业务希望能用更便宜的资源进行大规模离线转码，可以通过跨AZ调度，采用竞享机器进行离线转码；视频AI模型训练和推理时，会有跨云边资源协同，这需要调度能够跨云边进行调度。

我们做了一个全域资源调度器。当前的开源版本是Arktos，开源链接是https://github.com/CentaurusInfra/arktos。

这里有几个核心模块，底层是Flow Monitor，可以实时监控每个DC上整个资源池的状态，如果资源利用率高可以动态扩容，迁移VM。资源收集器可以收集每个资源池的状态，包括成本、地理位置，拓扑结构信息会全部反馈到央神经大脑（Global Scheduler）。

业务拆解与部署模块是当有多个请求时，迅速决策应该放在什么位置。

Global Scheduler包括两个模块（开源中没有）。第一，资源聚类决策，根据地理位置对分布式云中的计算资源进行聚类，例如客户希望VM服务的是上海地区用户，我们要根据地理位置做出决策；第二，分布式云选择决策，根据聚类结果，针对每个资源组进行打分，最后快速根据打分情况决策VM放置位置和数量。

决策好放置位置后，要进行实时管理和调度，分为三个过程。

第一，资源与性能检测器，可以实时监测整个资源器中资源占用情况；第二，单地域资源管理器，当根据Qos监控发现不满足业务数据时，可以在AZ或者边缘节点上进行资源伸缩的动态决策；第三，多地域资源弹性伸缩器，本地资源也无法满足时可以跨云边调度。在离线转码业务下，实现了时延降低17%的同时降低33%的成本。

#04

云边协同训练/推理

视频上AI任务越来越多，视频在端侧编码后会立刻传到边缘侧，在边缘侧会做许多特性任务包括视频审核、智能封面、智能视觉等一系列AI任务。但是边缘侧计算资源十分有限，随着AI任务越来越多，会面临如何在计算资源有限情况下完成更多AI任务的问题。有一个非常朴素的想法是：边缘侧计算资源有限，那是否可以在边缘侧做推理，云侧做训练。这样做就可以在很大程度上降低资源成本，同时满足客户对带宽及时延的要求，也可以保护数据隐私。其中涉及到的技术有协同推理、增量学习和联邦学习。

华为云边协同推理框架Sedna，正是为了解决云边协同推理和训练开发和部署难的痛点。Sedna整体框架已于KubeEdge AI SIG社区开源，链接为https://github.com/kubeedge/sedna。

Sedna有几个核心部分：第一，Lib库，面向AI开发者和应用开发者，暴露边云协同AI功能给应用；第二，Workers，在云侧和边缘侧执行训练或推理任务；第三，GlobalMgmt，负责跨云边的管理和协同，KubeEdge来做消息协同；第四，LocalController，主要负责本地通用管理，包括模型、数据收集。

Sedna是基于KubeEdge。KubeEdge是Cloud Native Computing Foundation（CNCF）正式开源项目（已晋升孵化阶段），20+公司正在使用，是一个非常活跃的开源计算边缘平台。

KubeEdge是基于k8s的，意味着和云原生高度兼容，同时其可扩展性非常强，采用声明式API，CRD(Custom Resource Definition)，自定义Controller。比起原生k8s有增量优势。我们实现了边云协同，将云的能力延伸到边缘，包括AI协同、数据协同、应用协同、管理协同。KubeEdge易维护，轻量化、插件化边缘框架，离线自治，自动容灾，支持异构硬件，与硬件解耦。

Sedna框架定位为“后端能力”,“被集成”，可集成到不同产品。

面向客户分为两类：

1、AI开发者，如果想使用边云协同服务和功能，可以使用Sedna框架；

2、应用开发者，可以直接使用边云协同AI能力。

Sedna的定位不包括：

1、替代现有的AI框架，如TensorFlow，Pytorch，Mindspore等，我们是可以兼容的，因为Sedna是一个框架；

2、替代现有的边缘平台，如KubeEdge；

3、研究特定领域的算法，如人脸识别，文本识别等。

Sedna当前包含三个模块。

第一，边云协同推理，在边侧资源受限时，如何提升整体推理性能。开发一个AI模型可能有多个版本，低精度版本或者高精度版本，可以通过Sedna把低精度版本布置在边缘侧，把高精度版本布置在中心云侧。当有某个图像识别任务时，通过边缘侧轻量级模型进行推理，如果置信区间比较低，将任务推到中心云大模型，从而实现比较好的整体推理性能。

第二，边云协同增量学习。增量学习和迁移学习比较类似，增量学习是针对小样本和非同分布下的模型，使得整个模型越用越聪明。举个例子，有一个AI任务通过边缘侧模型做推理，发现效果很差，推到中心侧后采用其它方式完成识别任务，完成后继续在中心侧训练后再推到边缘侧。Sedna在这部分支持比较好，易用性强。

第三，边云协同联邦学习，比如在做银行类业务时，它希望数据不出边缘，但同时要做AI训练，就可以采用联邦学习框架，每个边缘侧都是一个模型，训练后将梯度同步到中心侧，中心侧训练后再推到边缘侧。

#05

总结

本次分享主要介绍了三个板块。

1、流量调度：通过流量调度系统，可以支撑多业务、多目标、异构数据特征的调度；

2、资源调度：资源调度可以支持跨AZ的资源调度和云边协同调度；

3、KubeEdge Sedna框架：框架面向AI和业务研发人员，提供边云协同推理、边云协同增量学习和边云协同联邦学习能力，为边云协同AI技术挑战的解决奠定基础。

以上是我分享的内容，谢谢！

详情请扫描图中二维码或点击阅读原文了解大会更多信息。

原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/118004890?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165918469516781683921818%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165918469516781683921818&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-27-118004890-null-null.article_score_rank_blog&utm_term=%E9%A6%99%E6%B8%AFcdn