朱錦輝

（中國人民解放軍91404部隊 秦皇島 066001）

1 引言

近幾年來，卷積神經(jīng)網(wǎng)絡的崛起推動著視頻流分析應用快速發(fā)展，并造就了高效率、高準確度的視頻流分析水準。監(jiān)控攝像頭被廣泛部署，如部署于商場中、街道上、無人機機身上等。隨著應用范圍的不斷擴大，對視頻流分析的要求也越來越高［1～3］。特別是在智慧軍營中，要求同時對大范圍內(nèi)的大量視頻流進行分析，并且需要及時、準確地得到分析反饋。針對以上問題，本文設計了一項端-邊-云計算架構(gòu)之上的兼顧邊-云間數(shù)據(jù)傳輸時延和邊緣節(jié)點硬件資源受限特性的視頻流分析任務調(diào)度策略 VideoEmbedded［4～7］，根據(jù)視頻流分析請求的特性來進行任務調(diào)度，在保證推理準確度的前提下，提高視頻流分析的實時性，降低整體系統(tǒng)資源占用。同時，本文設計了一套基于Docker容器技術、K8s（Kubernetes）容器編排技術的端-邊-云視頻流分析系統(tǒng)，其具有良好彈性伸縮能力和自動化運營能力。

2 端-邊-云視頻流分析系統(tǒng)構(gòu)建

在端-邊-云計算架構(gòu)中［8～10］，智能服務（如車輛檢測、車色識別等）可部署于邊緣節(jié)點和云節(jié)點上。邊緣節(jié)點的優(yōu)勢是其與移動設備更近，且它們間具有更低的數(shù)據(jù)傳輸延遲和更大的帶寬。在一般負載情況下，視頻流分析應用的連續(xù)性是比較好保證的（實現(xiàn)足夠多的并行化），而應用的實時性更受任務調(diào)度的影響，故本文提出的VideoEmbedded任務調(diào)度策略將以實時性為最優(yōu)化目標。

VideoEdge在第二階段進行請求合并，即對智能服務進行復用。而VideoEmbedded是一階段的，即一開始就對智能服務進行復用。以視頻流車輛信息分析為例（分析任務包括車輛檢測、車色識別、車牌檢測和車牌識別），表1列舉出了與一個請求Qi相關的符號表示。

表1 與請求i相關的符號表示

所以VideoEmbedded對智能服務復用的約束可表示為式（1）～（6）。

需要求的最優(yōu)項為（實時性優(yōu)先）式（7）。

上述的最優(yōu)解問題是一個NP難問題，假設有m個請求，各智能服務有n種不同準確度的智能模型可選，則暴力求解該問題的時間復雜度為O（（m·（m-1）…1）n3）。為降低求解時間復雜度，下面根據(jù)不同請求的不同特性來將該問題簡化以求一較優(yōu)解。

視頻流分析的輸出結(jié)果一般有兩種［11～13］：

1）輸出結(jié)果仍為視頻流，與原視頻流相比，輸出的視頻流可能在編碼方式、色域、分辨率、幀率等方面發(fā)生改變，并且往往是帶有智能信息的。

2）輸出結(jié)果為智能信息結(jié)構(gòu)化數(shù)據(jù)，即將在智能分析過程中所得的智能信息存儲起來。

對于這兩種不同的輸出結(jié)果，做不同的考慮：

1）輸出結(jié)果仍為視頻流的請求，其特點是需要對輸入視頻流進行逐幀智能分析，且最終輸出的視頻流還是要傳輸?shù)皆粕先サ?，因為用戶是通過云來獲取輸出視頻流的。故對這種請求應該將任務優(yōu)先遷移至云上執(zhí)行，因為這樣做能夠節(jié)省邊緣資源。

2）輸出結(jié)果為智能信息結(jié)構(gòu)化數(shù)據(jù)的請求，其特點是需要對輸入視頻流進行抽幀智能分析，同時要傳輸?shù)皆粕先サ闹悄苄畔⒔Y(jié)構(gòu)化數(shù)據(jù)相比于視頻流要小得多。故對這種請求應該將任務優(yōu)先遷移至邊緣節(jié)點上執(zhí)行，因為這樣做能夠節(jié)省邊-云間帶寬。

系統(tǒng)整體架構(gòu)設計將邊緣分為多個區(qū)域，每個區(qū)域都會部署一些Worker節(jié)點，在Worker節(jié)點之上可以按需部署智能服務和其它服務。同樣在云上也會部署Worker節(jié)點，這些Worker節(jié)點由云上的Master節(jié)點統(tǒng)一管理。將所有服務程序都置于Docker容器中運行，啟用多個K8s Master熱備份節(jié)點，在多個K8s Master節(jié)點之上，使用keepalived工具來向外提供虛擬Socket（IP：Port），并使用haproxy工具來保證多個K8s Master節(jié)點間的負載均衡，從而使K8s集群具有較高的可靠性。

對于每個K8s Pod，其只擁有一個Docker容器。圖1使用Deployment控制器來部署智能服務、頁面前端等無狀態(tài)的服務；使用StatefulSet控制器來部署MySQL數(shù)據(jù)庫、Kafka消息隊列等有狀態(tài)的服務。在服務發(fā)現(xiàn)方面，使用ClusterIP類型的Service來在集群內(nèi)部暴露Pod服務，使用NodePort類型的Service來向集群外部暴露Pod服務。

圖1 服務部署

用戶通過Web前端來發(fā)起視頻流實時智能分析請求，也可以發(fā)起對輸出視頻流或智能信息結(jié)構(gòu)化數(shù)據(jù)的檢索等請求，在圖2示例中，在最大化智能服務和邏輯進程中接入視頻流以對其進行智能分析，將智能信息結(jié)構(gòu)化數(shù)據(jù)的輸出結(jié)果發(fā)布至Kafka消息隊列，對于攜帶智能信息的視頻流輸出結(jié)果，將其推給Nginx RTMP服務器。

圖2 任務調(diào)度

3 對比實驗

3.1 實驗設計

如圖3所示，實驗中使用兩臺Atlas200DK組成一個邊緣區(qū)域，使用6臺服務器組成一個私有云（其中代理服務器位于K8s集群之外）。

圖3 實驗環(huán)境

如表2，在智能組件中使用到6種模型——4種檢測模型和兩種分類模型，對于車牌識別，使用HyperLPR；對于對象跟蹤（只在輸出結(jié)果為視頻流時啟用），使用Kalman。為方便闡述，我們分別將準確度和體積分為4個等級（A、B、C和D，準確度遞減，體積遞增），并給每臺Atlas200DK分配8個槽位（以第2節(jié)實驗結(jié)果為依據(jù)），給每張顯卡分配20個槽位（以500 MB顯存為一槽位，每張顯卡預留1～2 GB顯存）。為保證應用的連續(xù)性，限制Atlas200DK、Worker01、Worker02和Worker03上的可使用線程數(shù)分別為7、20、20和32（云服務器的CPU主頻更高）。對于VideoEdge中的主資源需求（Dominant Resource Demand），僅考慮主要的帶寬（邊-云間帶寬以恒定的90.5 Mbits/s來計算，在服務部署時保證負載均衡（以一臺設備上的資源占用百分比為依據(jù)，先優(yōu)先槽位占用的均衡，其次是線程占用）。

表2 智能組件中使用到的模型

如表3，共設計了3組視頻流實時智能分析請求，其中每個請求都需要進行所有的智能分析（車輛檢測、車牌檢測、車牌識別、車色識別）。若輸出結(jié)果為視頻流，則請求的處理幀率為25 FPS，對所有智能組件準確度的要求皆為B；否則請求的處理幀率為1 FPS，針對智能組件準確度的要求，又需進行三組不同的實驗：所有要求皆為B（組合1）、所有要求皆為D（組合2）、分別在720P和1080P請求中一半要求為D一半要求為B（組合3）。實驗中的輸入視頻流幀率為25 FPS，分辨率為1080P/720P，編碼方式為H.264 NV12，其中大部分的幀中只包含1個車輛對象，最多包含兩個車輛對象，且輸入視頻流通過FFmpeg+EasyDarwin對MP4視頻文件推流產(chǎn)生。為方便對比，在VideoEdge中，請求的處理順序為：先處理輸出結(jié)果為視頻流的請求，然后按照輸入視頻流分辨率由高到低和準確度要求由高到低的順序依次處理剩余請求。量化A級別準確度為4，C級別準確度為2。在實時性的度量方面，量化邊緣節(jié)點間和云節(jié)點間的數(shù)據(jù)傳輸時延皆為1，邊緣節(jié)點與云節(jié)點間的數(shù)據(jù)傳輸時延為300。對于分辨率為的視頻流，假設H.264壓縮比為20：1，則可量化其帶寬占用為

表3 視頻流實時智能分析請求

對于智能信息結(jié)構(gòu)化數(shù)據(jù)，量化其帶寬占用為

3.2 實驗結(jié)果與分析

如圖4，VideoEdge以整體準確度為最優(yōu)化目標，在整體準確度方面VideoEmbedded幾乎與之持平。因為VideoEmbedded更傾向于使用輕量級智能模型，所以對于組合2這樣的請求，會優(yōu)先選用輕量級智能模型，從而導致整體準確度稍有下降。同時，這也能夠節(jié)省一定的系統(tǒng)資源（見圖5中的組合2對比）。如圖5，VideoEmbedded的系統(tǒng)整體資源占用始終少于或等于VideoEdge。VideoEmbedded和VideoEdge都會優(yōu)先將輸出結(jié)果為智能信息結(jié)構(gòu)化數(shù)據(jù)的智能分析任務調(diào)度到邊緣區(qū)域執(zhí)行，在請求數(shù)較小的情況下，因為VideoEdge Merge是二階段的，使得有部分任務由于邊緣區(qū)域沒有足夠的資源而被分配至云上執(zhí)行，而Video-Embedded最開始就是從智能組件復用出發(fā)的，這使得這些任務可以全部分配至邊緣區(qū)域中執(zhí)行，提高了組件復用率，從而占用更少的系統(tǒng)資源。這也直接導致了相比于VideoEdge，VideoEmbedded可以占用更少的邊-云間帶寬。如圖6，VideoEmbedded能夠更充分地利用邊緣資源，相比于VideoEdge Merge，能夠節(jié)省12.99%～38.96%的邊-云間帶寬，且能夠穩(wěn)定地保證應用整體的高實時性，如圖7，邏輯進程始終與智能服務處于同一區(qū)域，在4/9的情況下，VideoEmbedded的整體實時性更高。隨著請求數(shù)的不斷增加，即使是使用VideoEmbedded邊緣區(qū)域也因資源有限而無法容納更多的任務，使得大部分的任務被分配至云上執(zhí)行，Video-Embedded和VideoEdge Merge的組件復用率逐漸持平，所占用的系統(tǒng)資源也逐漸持平。

圖4 實驗結(jié)果整體準確度對比

圖6 實驗結(jié)果邊-云間帶寬占用對比

圖7 實驗結(jié)果應用整體實時性對比

4 結(jié)語

本文設計了一項端-邊-云計算架構(gòu)之上的兼顧邊-云間數(shù)據(jù)傳輸時延和邊緣節(jié)點硬件資源受限特性的視頻流分析任務調(diào)度策略VideoEmbedded，根據(jù)視頻流分析請求的特性來進行任務調(diào)度，提高了視頻流分析的實時性，降低整體系統(tǒng)資源占用。實驗證明，相比于VideoEdge，本文提出的VideoEmbedded能更充分地利用邊緣資源，在實時性、系統(tǒng)資源和邊-云間帶寬占用等方面表現(xiàn)更優(yōu)。同時，本文設計了一套基于Docker容器技術、K8s容器編排技術的端-邊-云視頻流分析系統(tǒng)，其具有良好彈性伸縮能力和自動化運營能力。