蒲一超 張 琦 田 琳 周 函 冉 莉 于 沁
(1.上海申通地鐵集團有限公司, 201103, 上海; 2.同濟大學電子與信息工程學院, 200013, 上海;3.上海市信產通信服務有限公司, 200050, 上海)
近年來,隨著互聯(lián)網和物聯(lián)網的發(fā)展,以及數字化車站的建設,地鐵客流管理逐步依賴于新型客流采集技術和特征挖掘手段,如紅外線熱點、Wi-Fi嗅探、手機信令、智能視頻分析及人工智能等,來實現(xiàn)實時、精準地獲取客流數據,逐步建成基于多源數據融合的綜合客流感知計算系統(tǒng)。在眾多客流感知的技術中,視頻識別技術非常重要,其技術成熟、精確度高,且能實時向車站管理人員提供可視化圖像,是地鐵系統(tǒng)客流管理必不可少的技術。一方面,視頻識別技術需要大規(guī)模數據的傳輸、存儲和計算;另一方面,由于地鐵系統(tǒng)對客流分析要求實時性高,所有的業(yè)務流程都需要實時響應。
在地鐵推廣二維碼支付應用之前,地鐵票務系統(tǒng)部署在獨立的內部網絡中,故云平臺技術應用空間較少。隨著地鐵二維碼的方式逐漸普及,云平臺技術在客流分析場景的應用日趨豐富。文獻[1]提出云清分中心和多站點邊緣計算節(jié)點模型,解決地鐵票務系統(tǒng)架構復雜、設備冗余、資源利用率低、功能重復等問題。文獻[2]提出云計算技術在地鐵自動售檢票系統(tǒng)中的具體應用。文獻[3]介紹了呼和浩特地鐵城軌云的視頻存儲系統(tǒng)云服務模式,其實現(xiàn)了云平臺視頻數據的管理、調用等功能。文獻[4]以武漢地鐵為模型,提出一種基于輕量級的人臉識別的智慧地鐵云支付系統(tǒng)構建的方案,有效保證識別效率和準確性。文獻[5]結合地鐵監(jiān)控實際需求,從總體架構、視頻數據流、視頻云存儲等幾個方面介紹了視頻監(jiān)控和云平臺的融合,構建了一套高性能、高安全、高并發(fā)、易運維、易部署的視頻監(jiān)控系統(tǒng)。
除了視頻監(jiān)控和票務系統(tǒng)以外,云技術還應用在地鐵隧道檢測[6]、車輛運維[7]、綜合監(jiān)控系統(tǒng)[8]、智慧運維系統(tǒng)設計[9]等方面??傮w來看,云平臺的理念初步在地鐵系統(tǒng)不同場景進行試點應用,但尚未有針對客流分析場景的云平臺設計。為了實現(xiàn)對大規(guī)??土鲾祿膶崟r獲取和高效分析,本研究基于地鐵客流分析的核心功能需求,設計一套面向地鐵客流分析場景的彈性集群云平臺(以下簡稱“彈性集群云平臺”)。
當前的地鐵客流分析業(yè)務,主要通過采集視頻、閘機、Wi-Fi及手機信令等數據,完成地鐵網絡客流分布計算、客流出行軌跡重建、車站重點區(qū)域客流監(jiān)測和預警,實現(xiàn)單站點客流密度以及全網客流密度分析與預測。地鐵客流分析的業(yè)務場景如圖1所示。
圖1 地鐵客流分析的業(yè)務場景
基于以上地鐵客流分析業(yè)務,彈性集群云平臺應具有以下3個核心功能需求:
1) 多系統(tǒng)并發(fā)處理,計算結果集成進行二次計算。地鐵客流分析依托多源數據展開,故需要在彈性集群云平臺上部署多個計算模塊,并與各模塊的數據源連接;在中心端,需要先將子模塊的計算結果對比整合,再輸出最終的計算結果。該功能的實現(xiàn)要求云平臺具有較強兼容性,且算力滿足并發(fā)計算需求。
2) 能實時完成計算,同時滿足大量數據的存儲及調用需求。在面對突發(fā)大客流時,彈性集群云平臺應均有較快響應速度,能實時計算客流分布并給出應對措施,對其計算的實時性要求很高。此外,視頻監(jiān)控系統(tǒng)已覆蓋城市軌道交通全區(qū)域,故需要被存儲并實時分析的視頻數據數量巨大,對計算量要求也極高。
3) 成本效益最優(yōu)化。地鐵客流存在分布不均、潮汐明顯等特征,因此在做云平臺部署方案時,需要統(tǒng)籌考慮存儲和算力資源,在成本和效益之間盡可能尋找最優(yōu)解。
面向地鐵客流分析場景的彈性集群云平臺,按照“6+2”的技術架構進行建設(見圖2)。其中“6”包括物理基礎設施管理、IaaS(基礎設施即服務)平臺虛擬化設施管理、基礎通用PaaS(平臺即服務)平臺、大數據處理層、能力開放平臺及智慧應用SaaS(軟件即服務);“2”包括系統(tǒng)安全以及系統(tǒng)管理兩部分。根據地鐵客流分析并行計算多,數據監(jiān)測、計算量大及響應時效要求高的需求特性,在PaaS平臺進行容器化設計,實現(xiàn)彈性伸縮。
注:DevOps平臺為開發(fā)-運營維護平臺
2.2.1 自動彈性伸縮能力
彈性伸縮是根據業(yè)務需求和策略,自動調整其彈性計算資源的管理服務,達到優(yōu)化資源組合的服務能力。在業(yè)務量上升時增加計算能力,當業(yè)務量下降時減小計算能力,以此保障業(yè)務系統(tǒng)的穩(wěn)定性和高可用性,同時節(jié)約計算資源成本。
PaaS云平臺通過對應用的資源利用率指標進行實時監(jiān)控,在資源利用率變化時的自動擴容或縮容來保障業(yè)務高峰時段的水平擴展緩解業(yè)務壓力,以及在業(yè)務低谷時候縮減副本以節(jié)約集群資源。
2.2.2 智能負載均衡能力
負載均衡能夠對一個或多個服務進行流量分發(fā)服務,擴展了應用系統(tǒng)對外的服務能力,消除了服務在應用系統(tǒng)的單點故障缺陷,提升了應用系統(tǒng)的可用性。同時通過負載均衡,PaaS平臺可以為應用服務提供一個外部負載入口。
PaaS平臺以路徑配置對象服務的負載均衡,負載均衡配置文件控制應用服務的對外訪問入口,訪問入口支持七層URL(統(tǒng)一資源定位符)形式負載均衡,以及四層IP(網際協(xié)議)+端口形式負載均衡;若用戶未對負載進行定義,將自動生成以項目名+服務名+iPaaS(集成平臺即服務)平臺域名七層負載地址,在負載均衡標簽頁創(chuàng)建的對象就是暴露應用服務的對外訪問地址。
地鐵客流分析場景包含多源數據類型,其中視頻系統(tǒng)包含大量的高清監(jiān)控視頻數據。因此,需要有一套能滿足視頻流并發(fā)性能的存儲系統(tǒng)。為保證足夠的網絡帶寬來滿足海量視頻流的存儲與讀取,以及對數據安全性的考量,本研究采用分布式架構的云存儲,通過聚合云存儲節(jié)點的網絡帶寬、硬盤I/O(輸入/輸出)、CPU計算性能、緩存等存儲部件來滿足視頻周期性存儲的需要。
部署方案一為分布式云部署方案。采用信息中心大公共云資源池+多個云節(jié)點建設,實現(xiàn)客流數據采集與分析。信息中心大公共云資源池:根據實際需求,并考慮錯峰平谷因素推算業(yè)務資源需求模型。業(yè)務發(fā)展前期可先行考慮按照0.1系數建設公共云資源池供邊緣節(jié)點資源錯峰調度復用(存儲不考慮該系數,按實計算),以視頻客流分析模塊為例,如前期每個地鐵站只需要一個16路視頻分析數據結果作為最低配,則中心可暫不考慮預留計算資源;多個云節(jié)點:單節(jié)點部署2臺物理服務器(1主1備),每臺服務器配置2塊GPU(圖像處理單元)卡,支持并發(fā)分析16路高清或標清視頻圖像(25幀)的最小需求。
優(yōu)勢:①增加計算節(jié)點的利用率,減少基礎設施投入,后續(xù)可根據業(yè)務發(fā)展靈活動態(tài)擴展公共資源池資源數量;②統(tǒng)一應用管理,應用通過云PaaS平臺統(tǒng)一管理維護,減少各個節(jié)點應用運維成本。
劣勢:計算和響應高度依賴網絡傳輸效率,對實時計算的響應存在一定延時。
可見,部署方案一更適用于運營規(guī)模確定、傳輸網絡可靠的新建地鐵系統(tǒng)。
部署方案二為邊緣物理計算+中心云部署方案。采用公共云資源池模式+地鐵站專用機房進行建設,地鐵站在各自的地鐵站專用機房內本地完成客流數據的采集與分析。公共云資源池主要部署算力調度平臺、跨站客流分析應用等。邊緣計算的n個站點:單節(jié)點部署平均5臺物理服務器,并配置5臺GPU服務器;中心公共云資源池部署1套PaaS平臺軟件。
優(yōu)勢:①就近部署,隨著業(yè)務需求量的不斷擴大,未來可提供最佳的時延和性能;②采用物理機方式組網,低時延。
劣勢:資源不能共享,基礎資源占用較多,一次性成本投入較高;邊緣節(jié)點物理機的日常管理運維工作量大,后期運維費用較高。
可見,部署方案二更適合未來運營規(guī)模不確定、需要實時計算的新老地鐵并行運營系統(tǒng)。
本研究以上海的地鐵客流分析場景為例,對彈性集群云平臺架構的部署方案進行比選。主要客流分析場景由2類構成:一是基于圖像識別技術實現(xiàn)微觀車站區(qū)域的客流統(tǒng)計;二是基于Wi-Fi嗅探技術實現(xiàn)宏觀網絡層面的客流出行軌跡重建。
研究對象為2020年的上海地鐵,涵蓋415座車站。需基于其能力需求分析,比對不同部署方案的投資成本。
3.3.1 計算能力需求
視頻分析所需GPU資源測算需求如表1所示。
表1 視頻分析算力需求
每GPU單浮點計算能力為8.1 Flops,計算可得每座車站需要7塊GPU卡。視頻分析應用軟件需要16核16 GiB內存,存儲容量需達0.24 TiB。
Wi-Fi分析由每個站點將采集到的數據上傳到中心端后,統(tǒng)一由中心端完成分析。Wi-Fi分析應用軟件需要12核 128 GiB內存,存儲容量0.10 TiB。
3.3.2 存儲能力需求
按目前配置統(tǒng)計,上海每座地鐵車站平均有38個標清攝像頭(日均視頻數據存儲量約為45 GiB),58個高清攝像頭(日均數據存儲量約為65 GiB)。每座車站的Wi-Fi數據量為3 GiB。經統(tǒng)計計算,得到上海的地鐵車站數據存儲能力需求見表2。由表2可得,每座車站視頻數據源的存儲總需求量合計為1 062 TiB。
表2 上海的地鐵車站存儲能力需求
3.3.3 網絡帶寬需求
監(jiān)控視頻的編碼主要采用H.264標準,單個視頻流帶寬約為4~6 Mibit/s(分辨率為720~1 080 p)。由于地鐵車站視頻監(jiān)控設備數量龐大,因此,在考慮視頻分析應用的特點,并平衡算力和網絡帶寬的需求后,應先采用分布式架構對視頻數據進行分站的處理分析,再把計算結果上送至指揮中心。
按照并發(fā)100路視頻流計算,上行網絡的傳輸帶寬為400~600 Mibit/s。
3.3.4 投資成本估算及比較
根據以上需求,按一次性投入及后續(xù)5年的運維成本計算,對不同部署方案的投資成本估算如表3及表4所示。
表3 方案一的投資成本估算
表4 方案二的投資成本估算
由表3及表4可以看出,相比方案二 ,方案一在成本投入上有顯著優(yōu)勢。
彈性集群云平臺架構在以下幾方面能充分匹配地鐵客流分析業(yè)務的相關特征:
1) 支持異構基礎資源。云計算可以構建在不同的基礎平臺之上,即可以有效兼容各種不同種類的硬件和軟件基礎資源。硬件基礎資源主要包括網絡環(huán)境下的三大類設備,即計算類(服務器)、存儲類(存儲設備)和網絡類(交換機、路由器等設備);軟件基礎資源包括單機操作系統(tǒng)、中間件及數據庫等。
2) 支持資源動態(tài)擴展。①支持資源動態(tài)伸縮,實現(xiàn)基礎資源的網絡冗余。即使任一資源節(jié)點異常宕機,也不會導致云環(huán)境中的各類業(yè)務的中斷,更不會導致用戶數據的丟失。②資源動態(tài)流轉。在云平臺下實現(xiàn)資源調度機制,資源可以流轉到需要的地方,從而在提高部分資源利用率的情況下,達到其他資源綠色、低碳的應用效果。
3) 支持異構多業(yè)務體系。在云平臺上,可以同時運行多個不同類型的業(yè)務?!爱悩嫛北硎驹摌I(yè)務不是同一的,不是已有的或事先定義好的,即用戶可以自己創(chuàng)建并定義業(yè)務。
4) 支持海量信息處理。云平臺底層要面對眾多的各類基礎軟硬件資源,云平臺上層要能同時支持眾多的各類異構業(yè)務;對于某一具體業(yè)務,需要面對大量的用戶??梢?云計算面對海量的信息交互,需要有高效、穩(wěn)定的海量數據通信及存儲系統(tǒng)作支撐。
5) 按需分配按量計費。按需分配是云平臺支持資源動態(tài)流轉的外部特征表現(xiàn)。云平臺通過虛擬分拆技術,實現(xiàn)了計算資源的同構化和可度量化,可以根據實際業(yè)務需求,提供小到一臺計算機,多到千臺計算機的計算能力。
在面向地鐵客流分析場景的云平臺架構基礎上,提出了兩個部署方案。其中,分布式云方案能充分實現(xiàn)資源共享且總成本較低,但受制于網絡傳輸可靠度,可能存在計算延時。適用于運營規(guī)模確定,傳輸網絡可靠的新建地鐵系統(tǒng)。邊緣物理計算+中心云方案能充分滿足實時性要求且可擴展性強,但整體成本高,適合未來運營規(guī)模不確定,需要實時計算的新老地鐵并行運營系統(tǒng)。
未來的研究可以針對云平臺設計繼續(xù)深化。考慮引入邊緣計算能力,采用云邊結構處理不同應用場景。邊緣計算聚焦實時、短周期數據的分析,能夠更好地支撐本地業(yè)務的實時智能化處理與執(zhí)行。在進行云端傳輸時通過邊緣節(jié)點進行一部分簡單的數據處理,進而能夠縮短設備響應時間,減少從設備到云端的數據流量。