流式视频处理架构设计
在LiveVideoStack線上交流分享中，新浪微博視頻平臺架構師曾誠分享了微博大規模視頻處理如何應對多業務場景，大流量，高并發的挑戰。包括利用工作流式計算引擎實現場景動態配置，以及采用流式上傳協議SVE來解決大流量高并發的問題等內容。
文 /?曾誠
整理 /?LiveVideoStack
直播回放:
https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=3ca02ec2b971400189f9176f239b5677
大家好，我叫曾誠，來自新浪微博視頻平臺。新浪微博作為大家熟知的社交媒體平臺，每天有大量豐富的視頻在此平臺傳播，用視頻作為信息傳播的載體已經成為主流。
微博每天新上傳的視頻量超過百萬，播放次數也達到幾十億，面對這個量級，基本可以用大規模視頻處理來形容了。大規模視頻處理不同于傳統意義上的大規模并發處理，因為視頻上傳完畢后，還需要復雜的轉碼，截圖，審核，打水印，質量識別等等。那么本次分享主要是給大家介紹一下微博是如何進行大規模視頻處理的。
?
1. 業務場景和挑戰
1.1業務場景
首先我們來看一下微博的業務場景。
1)?從視頻產品的角度來說：我們有微博視頻，微博故事，酷燃視頻，微博云剪，另外我們還有獨立的app喵嗚視頻，波波視頻等，基本涵蓋了目前能用到視頻的所有場景。
2)?從視頻創作者角度來說：前面的產品矩陣能夠讓不同的創作者找到適合自己的平臺。例如以UGC用戶為主的微博故事，用戶可以拍攝一些有趣的短視頻，記錄身邊發生的事情，它的特點是豎版的短視頻，對清晰度要求非常高，同時能夠添加一些有趣的貼紙，支持在線編輯制作，拍攝完成后可以立刻發出來。微博視頻和酷燃視頻更多是針對PGC的一些嘗試，能夠管理自己的視頻集，支持橫豎版，對視頻質量有更高的要求。另外還有一些針對OGC的媒體用戶，他們需要快速發布視頻到微博中， 對清晰度要求沒有那么高。
3)?從業務流程的角度來說：視頻處理的能力，包括視頻上傳，轉碼的策略，封面圖是用戶自定義還是截取，以及如何進行內容分辨，水印的位置大小，視頻審核是先審后發，還是先發后審，不同產品的特點是不一樣的。最后我們會收集用戶的觀看信息不斷進行改善。
?
1.2挑戰
?
針對微博視頻豐富的業務場景和巨大的流量，對后端視頻處理也提出了更高的要求?
1）?業務場景的多樣化：我們有超過了20個不同的業務方，包括前面提到的微博故事，酷燃視頻，還有媒體直播視頻等業務方，涵蓋了短視頻、長視頻，不同的業務它們的處理流程也不一樣，例如一些業務場景需要視頻上傳完成后立刻發布，一些需要進行廣電審核才能發布，不同的業務方水印也不一樣。針對這些業務場景我們急需要有能夠動態配置，快速接入新的業務的能力。因此，我們設計實現了工作流式計算引擎Workflow ，以針對不同的業務場景實現動態配置。?
2）?大流量高并發：微博MAU已經超過4.5億，每天視頻上傳量也超過百萬，同時微博作為媒體社交平臺，第一屬性還是媒體，很多用戶對于視頻的發布速度有非常高的要求，比如一些熱點視頻，早發出來5分鐘可能在微博上的播放量會有數量級的差距，這種情況下，用戶對視頻的上傳速度和發布速度有了更高的要求。另外，隨著手機等各種拍攝設備的高清化，發布的視頻文件也越來越大，在網絡條件一定的條件下，視頻上傳發布的時間也越來越長。針對這種需求場景?，我們設計實現了一整套的流式上傳處理協議SVE，能夠確保視頻在上傳的過程中，后端進行多分辨率輸出的轉碼。
3）?擴展的高效性：由于上傳的每個視頻都需要有多個不同分辨率和協議的輸出，每天需要處理的視頻任務達到億級，如何快速的進行任務調度，讓所有的計算資源能夠均衡的分配，同時在一些視頻上傳高峰時期，能夠進行橫向動態擴展，這些都是我們要考慮的問題。因此我們設計和實現了一整套流式資源調度系統來解決資源調度和擴展的問題。
?
2. 流式視頻處理架構
?
面對我們遇到的挑戰，前面已經提出了三種相對有針對性的解決方案，那么這些解決方案如何相互配合工作的呢？
客戶端可以選擇視頻上傳的協議，協議有兩種，Binary和Sve，不同的協議， workflow處理起來會有一些差別，在最后通知Transcode。其實整個流程看起來并不復雜， 重點在于每一塊內部的設計和靈活性。
客戶端選擇上傳協議，可能要根據自己的實際情況來選擇，每種協議有自己的優缺點。流式上傳協議需要確保整個工作流的完整性，實時性，出現問題要能夠及時發現和處理，并且要靈活可配置。流式資源調度系統更多的是去解決轉碼資源調度不均衡，SVE協議使用后，任務數成幾何增長帶來的調度問題，這三個部分其實是有相關性的。
?
2.1工作流式引擎設計思想
?
工作流式引擎設計思想的目標包括：1. 管理好任務依賴關系，能夠靈活的為不同業務配置不同的模板。2. 可視化配置，能夠隨時查看工作流執行的進度情況。3. 任務類型盡可能豐富，每個任務的工作相對獨立。4. 具有一定的容錯性，并且能夠進行錯誤處理。
根據以上內容可以將目標劃分為四個部分：DAG的調度框架，Task任務劃分，以及業務工作流（Biz Workflow），最后是對賬系統(Check Bill)。
?
DAG調度框架
上圖中是一個有向無環圖，從任意頂點出發無法經過若干條邊回到該點，學過數據結構應該都能夠了解它的原理。我們依照有向無環圖的原理設計了自己的DAG的調度框架。創建完DAG以后，調度會自動從入度為零的節點進行拓撲遍歷，直到無后續節點存在。但是每個節點開始執行都是有條件的，在沒有前置節點時，需要一些外部的調用或者事件來觸發該節點，要是有前置節點，那么需要它前置節點都已經執行完畢，這時候該節點會自動執行，并且一直向后拓撲，直到碰到不符合執行條件的節點，然后繼續等待觸發。
DAG調度框架中每個Task節點有個非常重要的原則， 必須是單一可執行，它依賴于前后上下文的信息，但是不依賴于他們的資源，或者是內部的一些能力等等。
?
Biz?Workflow
Biz ?Workflow是我們業務處理的真實流程。這里列出了一些Task節點的能力，每個Task都有四種狀態：未開始，正在進行中，執行成功，執行失敗。四種狀態可以相互轉化，其中，未開始只有兩種情況會變成正在執行中，第一，無前置節點，必須被事件觸發，事件可以是接口調用，或者收到MCQ消息等。第二，有前置節點，但必須所有的前置節點都執行成功才會觸發，這個是由DAG調度框架控制，每次改變Task節點狀態時，調度框架都會遍歷整個DAG，看是否有滿足條件的節點需要執行。正在執行的節點最終也會變成執行成功或者執行失敗，在整個過程中，如果有節點執行失敗，整個Workflow最終不會執行完畢。
?
Check Bill?System
?
前面的工作流中已經提到，如果有節點失敗，整個工作流會執行失敗，為了確保整個流程的正常運轉，我們設計和實現了對賬系統，它在整個工作流引擎中是非常重要的一部分。
對賬系統包括5個模塊：1.節點信息搜集，2.定時輪詢檢查，3.重新任務發起，4.探測預警，5.可視化。
1. 節點信息搜集：每個任務節點在改變狀態的時候都會上報自己的信息，包括任務id，當前狀態等。
2. 定時輪詢檢查：每隔一段時間都會檢查任務的執行時間，如果該任務超過一定的時間閾值，則認為該任務失敗。
3. 重新任務發起：根據前面的檢查，發現任務失敗，會檢查失敗的TASK節點，并重新發起任務，并標記重試次數。
4. 探測預警：一旦達到一定的重試次數，會向管理員發送預警，進入人工干預。
5. 可視化：很直觀的發現任務失敗的原因，并進行實時處理。
?
GOP
GOP是兩個關鍵幀之間的片斷，因為I是完整的畫面，PB是預測幀。簡單的說就是我們將視頻進行切割，如果按GOP（兩個I幀）去切的話，最終出來的視頻是可以單獨播放的。基于這個原理特性，我們設計實現了一套完整的流式上傳協議SVE。
?
2.2 流式上傳協議（SVE）
SVE（Streaming Video Engine）協議最核心的部分是視頻的并行處理，也就是所謂的邊傳邊轉碼。
圖中展示了兩種上傳協議效率對比：第一種是普通的二進制分片上傳，需要等待最后一片上傳完畢才發起transcode，整個流程需要等待的時間包括視頻上傳時間和轉碼時間。第二種是邊傳邊轉碼，每個上傳的分片按照GOP進行切割，上傳完成后可以進行單獨轉碼，整個流程的時間為視頻上傳時間加上最后一個分片的轉碼時間。相比之下，如果切分文件大小一定的條件下，文件越大，SVE協議的效率越高，大文件的處理時間基本等于上傳時間，效率提高非常明顯。
?
按照上述的方式我們設計實現了整套的SVE（Streaming Video Engine）協議框架。
SVE（Streaming Video Engine）協議在實現上相比Binary上傳協議要復雜多，同時需要客戶端能夠支持GOP切分，對轉碼的任務調度能力要求也非常高。
圖中展示了兩種不同視頻上傳協議的架構圖：
Binary上傳協議架構：按協議等比例切割文件，切割后的文件為二進制，不包含視頻頭，在上傳完成后，通知Trans Center即可，Trans Center會啟動一個Runner任務，該Runner先去Storage下載整個視頻，然后進行轉碼，最后將轉碼完畢的視頻上傳到Storage中。
SVE上傳協議框架：客戶端需要按照GOP進行文件切割，服務端將每個分片存入Temp Storage，同時通知Trans Center啟動一個Runner任務去處理該分片，處理的過程包括下載GOP分片，轉碼（多個分辨率），上傳轉碼后的分片到Temp Storage，當所有的分片都上傳完畢時，Trans Center啟動一個Runner任務，將所有的轉碼后的視頻分片下載下來，合成一個完整視頻，上傳到Storage。
使用SVE上傳協議要解決兩個問題：
第一：客戶端必須能夠支持這個協議，也就是能夠按照GOP的方式對視頻進行切割，通常手機客戶端容易去實現，pc端實現起來比較復雜。
第二：轉碼的任務調度能力要求非常高，假設上傳視頻需要轉出四個分辨率，按照SVE協議，假如一個視頻被切割成100個片段，需要轉碼的視頻任務就是400個，最后還需要將這些片段下載下來，合并成一個文件，如何快速的將任務分配到合適的轉碼機器也是一個挑戰。
?
Transform?for?Parallel
?
在一些場景下，如果客戶端不支持SVE（Streaming Video Engine）協議，同時上傳的視頻非常大，也能在服務端通過切割視頻，進行并行轉碼，提高轉碼效率。
上圖是服務端實現視頻并行轉碼的流程圖，在視頻上傳完畢后，通過GOP切分，將視頻切割成音頻和一批小視頻，并且將這些小視頻分發到不同的機器上，最后達到并行轉碼的效果。
雖然這種方式沒有客戶端實現SVE協議的效率高，但如果上傳文件是非常大的視頻，對于整體效率的提升還是非常明顯。
?
SVE協議是將視頻分解成一個個小視頻進行并行轉碼，這也帶來一個問題，轉碼任務數量成幾何增長，對于轉碼任務如何調度，如何分配資源提出了更高的要求。下面我們介紹一下轉碼調度設計的兩種方式：pull模式和push模式。
?
Pull模式轉碼調度：整個系統分為三個部分，任務隊列（Task Queue），調度中心（Trans Center），任務處理機（Agent/Runner）。
任務隊列（Task Queue）：任務隊列是為了區分任務的優先級而設立的，不同的業務，不同的階段，優先級都不一樣，調度中心進行統一調度，特殊情況下也可以人為干預
調度中心（Trans Center）：消費任務隊列，統一放在任務池中，記錄每個任務執行的機器信息和結果信息，任務完成時通知業務方。
任務處理機（Agent/Runner）：處理機可以認為是一臺單獨的物理機器，上面會部署一個Agent服務，多個Runner服務。一個Runner服務就是一個轉碼任務，包括了原始視頻下載，水印下載，轉碼，轉碼后視頻上傳，結果通知center等。Runner服務結束后會告知Agent服務，并結束掉自己的進程。通常會根據機器的配置Runner的最大個數，Agent服務是管理自己機器的Runner個數，一旦發現沒有達到最大數量，就會去Trans Center拉取任務，獲取到任務后，Trans Center會將任務和Agent機器ip綁定，等待任務結束的通知。
?
Pull模式的優點：實現起來簡單，可以快速的把任務派發下去，能夠快速的水平擴展，但需要注意center和底層資源的壓力。
Pull模式的缺點：計算資源調度分布不均衡，每個任務需要的計算資源是不一樣的，單純用個數去控制容易造成大文件轉碼耗時較高。
2.3 Push模式的轉碼調度框架
Push模式轉碼調度包括三個部分：隊列（三種隊列），調度中心（Scheduler），執行器（Executor）。
隊列（Queue）：我們設計實現了三種隊列。Task Queue作為任務優先級隊列，優先級越高，越能更早的被分配下去。Executor Queue 是機器空間度優先級隊列，根據機器的配置設置slot，一個slot代表一個計算資源，slot越大，說明空閑度越高，優先級也就越高。Running Queue是執行中的隊列，可以表示哪些任務正在執行中，一旦執行完畢，會從隊列中移除，為了防止部分Executor出現宕機，后臺會有定時任務輪訓，發現超時的任務，會將任務重新放入Task Queue。
調度中心（Scheduler）：統一管理和調度資源，從Task Queue中拿到優先級最高的任務，從Executor Queue中拿到空間度最大的機器，將這個任務和機器綁定后放入Running Queue，并通知Executor開始執行，這樣任務就下發下去了。
執行器（Executor）：每個執行器可以認為是一臺物理機器，負責執行具體的轉碼任務，除了執行任務以外，每隔一段時間要向注冊中心發送心跳，心跳的內容包括slot信息，機器的狀態等，注冊中心會根據機器的狀態調整機器在Executor Queue中的優先級，如果一段時間注冊中心沒有收到心跳，會將機器移除。
?
Push模式的優點：能夠實時監控整個集群的資源，并且將優先級最高的任務派發給最空閑的機器，讓計算資源最大化
Push模式的缺點：實現起來比較復雜
?
2.4 上傳分片優化
前面講到的協議都涉及到分片上傳，但更多的關注點在于上傳后如何處理，如果提高效率，其實視頻分片上傳的速度和成功率對于整體的效率提升影響也是非常大的。
上圖左邊是在不同分片大小下，iphone，Android，pc三端的上傳速度對比，可以發現，分片越大，上傳速度越快。由于我們底層使用的是TCP協議，TCP協議需要經歷三次握手建立連接，滑動窗口的慢啟動的過程，這個過程速度是很慢的，如果分片過小，當滑動窗口剛剛打開，數據就傳送完畢，會導致建立連接和慢啟動在整個過程中占用時間比例過多，因此分片越大，速度也就越快。
上圖右邊是在不同分片大小下，iphone，Android，pc三端的上傳成功率對比，可以發現，分片越大，成功率越低。由于文件越大，對于網絡的要求越高，同等網絡條件下，傳輸的時間越長，出現失敗的概率也就越大。
LiveVideoStackCon 2019北京 音視頻技術大會 初版日程現已上線，掃描圖中二維碼或點擊【閱讀原文】了解大會最新日程。
總結
以上是生活随笔為你收集整理的流式视频处理架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LiveVideoStackCon 20
- 下一篇： 若5G的速度不够：那6G和16K是必然么