基于嵌入式邊緣設(shè)備的端-邊-云視頻流分析系統(tǒng)構(gòu)建*

朱錦輝

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

1 引言

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

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

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

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

表1 與請求i相關(guān)的符號表示

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

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

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

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

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

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

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

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

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

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

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

圖1 服務(wù)部署

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

圖2 任務(wù)調(diào)度

3 對比實(shí)驗

3.1 實(shí)驗設(shè)計

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

圖3 實(shí)驗環(huán)境

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

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

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

表3 視頻流實(shí)時智能分析請求

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

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

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

圖4 實(shí)驗結(jié)果整體準(zhǔn)確度對比

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

圖7 實(shí)驗結(jié)果應(yīng)用整體實(shí)時性對比

4 結(jié)語

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