隨著多媒體業務越來越多的涌現，每個業務都有不同的差異性特征。各大視頻云廠商遇到的最大挑戰是如何打造多媒體分發網絡，使用最低成本為多業務提供最優質網絡體驗。本次分享邀請到了華為云算法專家——楊昌鵬老師，為我們介紹云邊協同在視頻場景下的探索實踐。

文 / 楊昌鵬

整理 / 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技術挑戰的解決奠定基礎。

以上是我分享的內容，謝謝！

詳情請掃描圖中二維碼或點擊閱讀原文了解大會更多信息。

總結

以上是生活随笔為你收集整理的全域调度：云边协同在视频场景下的探索实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。