面向地鐵客流分析場景的彈性集群云平臺架構設計及部署方案*

蒲一超 張 琦 田 琳 周 函 冉 莉 于 沁

(1.上海申通地鐵集團有限公司, 201103, 上海; 2.同濟大學電子與信息工程學院, 200013, 上海;3.上海市信產通信服務有限公司, 200050, 上海)

近年來,隨著互聯網和物聯網的發展,以及數字化車站的建設,地鐵客流管理逐步依賴于新型客流采集技術和特征挖掘手段,如紅外線熱點、Wi-Fi嗅探、手機信令、智能視頻分析及人工智能等,來實現實時、精準地獲取客流數據,逐步建成基于多源數據融合的綜合客流感知計算系統。在眾多客流感知的技術中,視頻識別技術非常重要,其技術成熟、精確度高,且能實時向車站管理人員提供可視化圖像,是地鐵系統客流管理必不可少的技術。一方面,視頻識別技術需要大規模數據的傳輸、存儲和計算;另一方面,由于地鐵系統對客流分析要求實時性高,所有的業務流程都需要實時響應。

在地鐵推廣二維碼支付應用之前,地鐵票務系統部署在獨立的內部網絡中,故云平臺技術應用空間較少。隨著地鐵二維碼的方式逐漸普及,云平臺技術在客流分析場景的應用日趨豐富。文獻[1]提出云清分中心和多站點邊緣計算節點模型,解決地鐵票務系統架構復雜、設備冗余、資源利用率低、功能重復等問題。文獻[2]提出云計算技術在地鐵自動售檢票系統中的具體應用。文獻[3]介紹了呼和浩特地鐵城軌云的視頻存儲系統云服務模式,其實現了云平臺視頻數據的管理、調用等功能。文獻[4]以武漢地鐵為模型,提出一種基于輕量級的人臉識別的智慧地鐵云支付系統構建的方案,有效保證識別效率和準確性。文獻[5]結合地鐵監控實際需求,從總體架構、視頻數據流、視頻云存儲等幾個方面介紹了視頻監控和云平臺的融合,構建了一套高性能、高安全、高并發、易運維、易部署的視頻監控系統。

除了視頻監控和票務系統以外,云技術還應用在地鐵隧道檢測[6]、車輛運維[7]、綜合監控系統[8]、智慧運維系統設計[9]等方面?？傮w來看,云平臺的理念初步在地鐵系統不同場景進行試點應用,但尚未有針對客流分析場景的云平臺設計。為了實現對大規?？土鲾祿膶崟r獲取和高效分析,本研究基于地鐵客流分析的核心功能需求,設計一套面向地鐵客流分析場景的彈性集群云平臺(以下簡稱“彈性集群云平臺”)。

1 核心功能需求

當前的地鐵客流分析業務,主要通過采集視頻、閘機、Wi-Fi及手機信令等數據,完成地鐵網絡客流分布計算、客流出行軌跡重建、車站重點區域客流監測和預警,實現單站點客流密度以及全網客流密度分析與預測。地鐵客流分析的業務場景如圖1所示。

圖1 地鐵客流分析的業務場景

基于以上地鐵客流分析業務,彈性集群云平臺應具有以下3個核心功能需求:

1) 多系統并發處理,計算結果集成進行二次計算。地鐵客流分析依托多源數據展開,故需要在彈性集群云平臺上部署多個計算模塊,并與各模塊的數據源連接;在中心端,需要先將子模塊的計算結果對比整合,再輸出最終的計算結果。該功能的實現要求云平臺具有較強兼容性,且算力滿足并發計算需求。

2) 能實時完成計算,同時滿足大量數據的存儲及調用需求。在面對突發大客流時,彈性集群云平臺應均有較快響應速度,能實時計算客流分布并給出應對措施,對其計算的實時性要求很高。此外,視頻監控系統已覆蓋城市軌道交通全區域,故需要被存儲并實時分析的視頻數據數量巨大,對計算量要求也極高。

3) 成本效益最優化。地鐵客流存在分布不均、潮汐明顯等特征,因此在做云平臺部署方案時,需要統籌考慮存儲和算力資源,在成本和效益之間盡可能尋找最優解。

2 彈性集群云平臺的架構設計

2.1 總體架構設計

面向地鐵客流分析場景的彈性集群云平臺,按照“6+2”的技術架構進行建設(見圖2)。其中“6”包括物理基礎設施管理、IaaS(基礎設施即服務)平臺虛擬化設施管理、基礎通用PaaS(平臺即服務)平臺、大數據處理層、能力開放平臺及智慧應用SaaS(軟件即服務);“2”包括系統安全以及系統管理兩部分。根據地鐵客流分析并行計算多,數據監測、計算量大及響應時效要求高的需求特性,在PaaS平臺進行容器化設計,實現彈性伸縮。

注:DevOps平臺為開發-運營維護平臺

2.2 彈性集群云平臺的獨特能力

2.2.1 自動彈性伸縮能力

彈性伸縮是根據業務需求和策略,自動調整其彈性計算資源的管理服務,達到優化資源組合的服務能力。在業務量上升時增加計算能力,當業務量下降時減小計算能力,以此保障業務系統的穩定性和高可用性,同時節約計算資源成本。

PaaS云平臺通過對應用的資源利用率指標進行實時監控,在資源利用率變化時的自動擴容或縮容來保障業務高峰時段的水平擴展緩解業務壓力,以及在業務低谷時候縮減副本以節約集群資源。

2.2.2 智能負載均衡能力

負載均衡能夠對一個或多個服務進行流量分發服務,擴展了應用系統對外的服務能力,消除了服務在應用系統的單點故障缺陷,提升了應用系統的可用性。同時通過負載均衡,PaaS平臺可以為應用服務提供一個外部負載入口。

PaaS平臺以路徑配置對象服務的負載均衡,負載均衡配置文件控制應用服務的對外訪問入口,訪問入口支持七層URL(統一資源定位符)形式負載均衡,以及四層IP(網際協議)+端口形式負載均衡;若用戶未對負載進行定義,將自動生成以項目名+服務名+iPaaS(集成平臺即服務)平臺域名七層負載地址,在負載均衡標簽頁創建的對象就是暴露應用服務的對外訪問地址。

3 彈性集群云平臺的部署方案

地鐵客流分析場景包含多源數據類型,其中視頻系統包含大量的高清監控視頻數據。因此,需要有一套能滿足視頻流并發性能的存儲系統。為保證足夠的網絡帶寬來滿足海量視頻流的存儲與讀取,以及對數據安全性的考量,本研究采用分布式架構的云存儲,通過聚合云存儲節點的網絡帶寬、硬盤I/O(輸入/輸出)、CPU計算性能、緩存等存儲部件來滿足視頻周期性存儲的需要。

3.1 部署方案一

部署方案一為分布式云部署方案。采用信息中心大公共云資源池+多個云節點建設,實現客流數據采集與分析。信息中心大公共云資源池:根據實際需求,并考慮錯峰平谷因素推算業務資源需求模型。業務發展前期可先行考慮按照0.1系數建設公共云資源池供邊緣節點資源錯峰調度復用(存儲不考慮該系數,按實計算),以視頻客流分析模塊為例,如前期每個地鐵站只需要一個16路視頻分析數據結果作為最低配,則中心可暫不考慮預留計算資源;多個云節點:單節點部署2臺物理服務器(1主1備),每臺服務器配置2塊GPU(圖像處理單元)卡,支持并發分析16路高清或標清視頻圖像(25幀)的最小需求。

優勢:①增加計算節點的利用率,減少基礎設施投入,后續可根據業務發展靈活動態擴展公共資源池資源數量;②統一應用管理,應用通過云PaaS平臺統一管理維護,減少各個節點應用運維成本。

劣勢:計算和響應高度依賴網絡傳輸效率,對實時計算的響應存在一定延時。

可見,部署方案一更適用于運營規模確定、傳輸網絡可靠的新建地鐵系統。

3.2 部署方案二

部署方案二為邊緣物理計算+中心云部署方案。采用公共云資源池模式+地鐵站專用機房進行建設,地鐵站在各自的地鐵站專用機房內本地完成客流數據的采集與分析。公共云資源池主要部署算力調度平臺、跨站客流分析應用等。邊緣計算的n個站點:單節點部署平均5臺物理服務器,并配置5臺GPU服務器;中心公共云資源池部署1套PaaS平臺軟件。

優勢:①就近部署,隨著業務需求量的不斷擴大,未來可提供最佳的時延和性能;②采用物理機方式組網,低時延。

劣勢:資源不能共享,基礎資源占用較多,一次性成本投入較高;邊緣節點物理機的日常管理運維工作量大,后期運維費用較高。

可見,部署方案二更適合未來運營規模不確定、需要實時計算的新老地鐵并行運營系統。

3.3 部署方案投資成本的比較

本研究以上海的地鐵客流分析場景為例,對彈性集群云平臺架構的部署方案進行比選。主要客流分析場景由2類構成:一是基于圖像識別技術實現微觀車站區域的客流統計;二是基于Wi-Fi嗅探技術實現宏觀網絡層面的客流出行軌跡重建。

研究對象為2020年的上海地鐵,涵蓋415座車站。需基于其能力需求分析,比對不同部署方案的投資成本。

3.3.1 計算能力需求

視頻分析所需GPU資源測算需求如表1所示。

表1 視頻分析算力需求

每GPU單浮點計算能力為8.1 Flops,計算可得每座車站需要7塊GPU卡。視頻分析應用軟件需要16核16 GiB內存,存儲容量需達0.24 TiB。

Wi-Fi分析由每個站點將采集到的數據上傳到中心端后,統一由中心端完成分析。Wi-Fi分析應用軟件需要12核 128 GiB內存,存儲容量0.10 TiB。

3.3.2 存儲能力需求

按目前配置統計,上海每座地鐵車站平均有38個標清攝像頭(日均視頻數據存儲量約為45 GiB),58個高清攝像頭(日均數據存儲量約為65 GiB)。每座車站的Wi-Fi數據量為3 GiB。經統計計算,得到上海的地鐵車站數據存儲能力需求見表2。由表2可得,每座車站視頻數據源的存儲總需求量合計為1 062 TiB。

表2 上海的地鐵車站存儲能力需求

3.3.3 網絡帶寬需求

監控視頻的編碼主要采用H.264標準,單個視頻流帶寬約為4～6 Mibit/s(分辨率為720～1 080 p)。由于地鐵車站視頻監控設備數量龐大,因此,在考慮視頻分析應用的特點,并平衡算力和網絡帶寬的需求后,應先采用分布式架構對視頻數據進行分站的處理分析,再把計算結果上送至指揮中心。

按照并發100路視頻流計算,上行網絡的傳輸帶寬為400～600 Mibit/s。

3.3.4 投資成本估算及比較

根據以上需求,按一次性投入及后續5年的運維成本計算,對不同部署方案的投資成本估算如表3及表4所示。

表3 方案一的投資成本估算

表4 方案二的投資成本估算

由表3及表4可以看出,相比方案二 ,方案一在成本投入上有顯著優勢。

3.4 地鐵客流分析業務特征的匹配

彈性集群云平臺架構在以下幾方面能充分匹配地鐵客流分析業務的相關特征:

1) 支持異構基礎資源。云計算可以構建在不同的基礎平臺之上,即可以有效兼容各種不同種類的硬件和軟件基礎資源。硬件基礎資源主要包括網絡環境下的三大類設備,即計算類(服務器)、存儲類(存儲設備)和網絡類(交換機、路由器等設備);軟件基礎資源包括單機操作系統、中間件及數據庫等。

2) 支持資源動態擴展。①支持資源動態伸縮,實現基礎資源的網絡冗余。即使任一資源節點異常宕機,也不會導致云環境中的各類業務的中斷,更不會導致用戶數據的丟失。②資源動態流轉。在云平臺下實現資源調度機制,資源可以流轉到需要的地方,從而在提高部分資源利用率的情況下,達到其他資源綠色、低碳的應用效果。

3) 支持異構多業務體系。在云平臺上,可以同時運行多個不同類型的業務。“異構”表示該業務不是同一的,不是已有的或事先定義好的,即用戶可以自己創建并定義業務。

4) 支持海量信息處理。云平臺底層要面對眾多的各類基礎軟硬件資源,云平臺上層要能同時支持眾多的各類異構業務;對于某一具體業務,需要面對大量的用戶?？梢?云計算面對海量的信息交互,需要有高效、穩定的海量數據通信及存儲系統作支撐。

5) 按需分配按量計費。按需分配是云平臺支持資源動態流轉的外部特征表現。云平臺通過虛擬分拆技術,實現了計算資源的同構化和可度量化,可以根據實際業務需求,提供小到一臺計算機,多到千臺計算機的計算能力。

4 結語

在面向地鐵客流分析場景的云平臺架構基礎上,提出了兩個部署方案。其中,分布式云方案能充分實現資源共享且總成本較低,但受制于網絡傳輸可靠度,可能存在計算延時。適用于運營規模確定,傳輸網絡可靠的新建地鐵系統。邊緣物理計算+中心云方案能充分滿足實時性要求且可擴展性強,但整體成本高,適合未來運營規模不確定,需要實時計算的新老地鐵并行運營系統。

未來的研究可以針對云平臺設計繼續深化?？紤]引入邊緣計算能力,采用云邊結構處理不同應用場景。邊緣計算聚焦實時、短周期數據的分析,能夠更好地支撐本地業務的實時智能化處理與執行。在進行云端傳輸時通過邊緣節點進行一部分簡單的數據處理,進而能夠縮短設備響應時間,減少從設備到云端的數據流量。