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