城市軌道交通綜合監控系統大規模全景數據并發控制及存儲技術

鄧 敏 于 洋

(南京軌道交通系統工程有限公司， 210019， 南京∥第一作者， 高級工程師)

1 綜合監控系統面臨的數據處理問題

近年來，城市軌道交通綜合監控系統逐漸向全自動化、智慧化方向發展。由于監控點數量倍增、場景聯動更加頻繁，對綜合監控系統的實時、歷史數據處理能力提出了更高要求。傳統的綜合監控系統受制于實時數據庫和歷史數據庫的容量及處理性能，只能通過部分采樣、過濾等方式處理或存儲部分數據，無法處理和存儲系統的全景數據，其實時數據的處理能力、對突發事件的反應速度、對歷史數據的分析能力受到了嚴重影響。

城市軌道交通綜合監控系統需要采取措施實時處理和存儲大規模的全景數據，以解決以下問題：

1) 城市軌道交通綜合監控系統集成或互聯了機電設備、電力監控、信號等子系統。在全自動運行模式下，其監控范圍新增了在線運行列車設備數據，數據總規模預計達到百萬級，傳統的內存式實時庫容量模式無法很好地滿足要求。

2) 全自動運行模式下歷史數據大幅增加，在對其的增加、刪減、修改、查詢中，傳統的關系數據庫(如ORACLE、MYSQL)出現明顯的性能瓶頸。

3) 綜合監控系統的性能瓶頸主要在于全線設備狀態更新引起的數據實時處理和存儲。一般情況下，1條城市軌道交通線路具有20多個甚至要多的車站，在雪崩、阻塞等工況下全線設備實時狀態變化速度可能達到每秒十幾萬次。傳統的綜合監控系統對數據的實時處理和存儲能力達不到全自動運行模式對數據實時處理和存儲能力的要求。

2 綜合監控系統數據處理的應對措施

2.1 邏輯數據與物理存儲處理分離的分布式系統

采用邏輯數據與物理存儲處理相分離模式，邏輯數據按照車站進行劃分，物理節點按照域進行劃分。采用按域劃分的分布式系統，1個域節點可以包括幾個車站的數據，1個車站的數據也可以存儲在幾個域節點中。一般情況下，1個域只處理和存儲1個車站(或車輛段)的數據，如圖1所示。

圖1 分布式系統架構示意圖

2.1.1 采用按域劃分的分布式系統

傳統的軌道交通綜合監控系統在運營控制中心(OCC)的實時數據庫中存儲整條線的設備信息，所有車站設備的實時狀態變化都需通過網絡傳到OCC實時數據庫后再進行處理和存儲。這種模式下系統的總容量及處理性能受到限制，嚴重影響了對監控點的數據處理及對突發事件的響應速度。采用按域劃分的分布式系統，不需要集中存儲和處理整條線的設備狀態，OCC實時數據庫與歷史數據庫只需要處理和存儲OCC的數據，車站數據都在各自的域內進行處理和存儲，從而解決了監控點總容量和每秒處理能力受限的問題，提高了系統性能。

2.1.2 邏輯數據與物理存儲處理相分離

邏輯數據按照車站進行劃分，物理節點按照域進行劃分；每個域各自組成1個局域網，域內的數據傳輸只在局域網內進行傳輸；跨域通信通過域間的光纖通信網絡進行傳輸。

2.1.3 系統服務注冊與服務查詢

各個域的實時數據庫、歷史數據庫和其它服務模塊(如數據代理服務)通過服務注冊方式向系統管理模塊進行注冊；系統管理模塊負責提供系統所有模塊的信息查詢服務。

2.1.4 數據更新與訪問

傳統綜合監控系統的性能瓶頸在于前置機向實時數據庫更新設備狀態變化數據。采用按域劃分的分布式系統后，綜合監控系統的前置機一般情況下只向本域的實時數據庫更新設備狀態信息。只有在特殊情況下，前置機才會通過數據代理服務向其它域更新設備狀態數據。

客戶端訪問數據代理服務首先通過域號確定該數據是否屬于本域。若屬于本域，則轉發至本域相應服務；若不屬于本域，則根據域號和服務類型向系統管理查詢相關信息，并把請求轉發至相應域。例如，當OCC的客戶端訂閱或查詢車站設備實時狀態時，可通過OCC中心域的數據代理服務直接訪問車站的實時數據庫，實時獲取車站設備狀態信息。

2.1.5 系統全冗余

采用全冗余技術避免單點故障引起的系統不可用問題，冗余范圍包括客戶端之間、服務器之間、前置機之間、網絡設備之間等。同域客戶端互為備份，用戶根據角色分配權限登錄客戶端并使用權限所允許的功能。只要角色相同，用戶登錄任一同域客戶端，均能執行相同功能的操作。服務端采用按模塊劃分的主備冗余技術，實時數據庫、歷史數據庫、數據代理服務、系統管理等均采用雙機熱備。前置機與接入的子系統/設備間采用分布式冗余技術：前置機根據要接入的系統部署多臺設備，與前置機相連接的子系統/設備則采用雙網冗余技術。客戶端、服務器、前置機等通過網絡設備接入隔離的雙網。

2.2 基于大規模并發控制技術的實時數據庫

如圖2所示，采用多級緩存、多路徑數據訪問、一致性散列算法、半搶占式動態優先級任務調度、動態策略控制等大規模并發控制技術，開發集數據更新、訂閱發布、信息查詢等功能于一體的實時數據庫，以提升系統的實時數據存儲容量與處理性能。

圖2 實時數據庫的結構示意圖

2.2.1 多級并發處理

采用并發多級數據處理、多級緩存和消息隊列等技術，加快實時數據處理的速度。

2.2.2 多路徑數據訪問

實時數據存儲采用鍵值對方式。為了加快數據訪問的速度，可采用多路徑訪問方式。根據訪問目的不同采用不同的組織形式，如：單點數據訪問時采用“拉鏈哈希+紅黑樹”方式，按站點或子系統類型批量訪問時采用“層次樹+鏈表”方式。實際的數據結點同時掛接在多條訪問路徑中，通過多條路徑均可訪問。實時數據庫數據結點的組織結構如圖3所示。

圖3 實時數據庫數據結點的組織結構圖

當數據單點訪問時，通過哈希計算結合紅黑樹查詢可以直接定位結點位置；當按站點或子系統類型訪問多個數據時，首先根據站點或子系統類型通過單點訪問模式確定位置，然后根據層次樹結構順序訪問多個數據。

如圖4所示，數據單點訪問量在10萬點以內時，大多數情況下只需要進行1次比對，比對次數極少出現超過3次的情況；數據單點訪問量在100萬點以內時，通常只需要1～2次比對即可準確定位，比對次數極少出現超過5次的情況。

圖4 數據單點訪問時的比對次數

2.2.3 一致性散列算法

采用一致性散列算法技術，系統中若增加了站點數據，并不影響系統對既有數據的處理。相同的設備狀態信息在一致的通道上進行處理，以保持數據的前后一致性。

2.2.4 半搶占式動態優先級任務調度

在任務執行過程中對監測點實施監測，若發現低優先級任務占用了過多資源，系統會暫停低優先級任務，轉而執行高優先級任務。任務的優先級可根據時間、系統當前狀況進行動態調整。

2.2.5 變化上傳與數據全召相結合

前置機實時采集系統各設備的狀態和信息。當設備的狀態和信息發生變化時，前置機會將信息上傳至實時數據庫。若設備的狀態和信息沒有變化，前置機也會按照要求定時把所有設備狀態上傳至實時數據庫中。

2.2.6 訂閱發布和主動查詢相結合

在訂閱發布模式下，當前置機更新設備狀態信息時，實時數據庫根據所訂閱信息，向客戶端推送設備狀態變化信息，從而減少了信息查詢時間，加快了操作響應速度。

用戶可在客戶端通過信息查詢方式主動查詢實時數據庫信息，并對一定量的設備狀態進行全召，以獲取當前設備狀態。

2.2.7 動態策略控制

動態策略控制包括靜態更新發布策略、實時動態影響因素、動態更新發布策略、動態策略控制執行模塊(數據預處理模塊、信息發布模塊)等。系統根據靜態更新發布策略和實時動態影響因素生成動態更新發布策略。系統基于動態更新發布策略，由數據預處理模塊實時控制數據的更新，由信息發布模塊實時控制數據的發布。數據更新與發布的結果將反饋至實時動態影響因素庫中，并影響接下來的實時數據更新和發布。動態策略控制能夠應對異常工況下大并發量數據的更新和發布，其實時動態影響因素如圖5所示。

圖5 基于動態策略控制的實時動態影響因素圖

2.3 基于數據特性的時序型歷史數據庫

綜合監控系統關注的數據帶有明顯的時間特征。因此，采用并發多級處理、冷熱分區、結構化合并樹(LSM)、順序寫入等大規模數據存儲技術，開發集高速寫入、高速讀取等功能于一體的時序型歷史數據庫技術，可以提升綜合監控系統的歷史存儲容量和歷史數據讀寫能力。時序型歷史數據庫的結構如圖6所示。

2.3.1 時序數據結構

城市軌道交通綜合監控系統所存儲的數據都具有時間特性。系統根據時間順序存儲數據，且需要滿足全線所有設備歷史狀態信息的實時寫入，這對數據寫入的性能要求非常高。傳統綜合監控系統的關系數據庫無法滿足這一要求，需采用以時間戳為標志的時序數據結構，對綜合監控系統的歷史數據進行存儲和處理。

圖6 時序型歷史數據庫的結構示意圖

2.3.2 多級并發處理

采用多路數據處理、多級緩存、多路排序壓縮等處理操作，以應對數據的高速寫入要求。在多路數據處理過程中，通過預寫日志來保證在異常情況下數據不丟失。

2.3.3 冷熱分區

采用多級冷緩存和熱緩存技術將數據保留在內存中，用以加速數據的高速寫入和高速查詢。其中，冷緩存數據只能進行查詢，不能進行更新操作；多路查詢不需要競爭條件，可同時查詢。數據只能寫入熱緩存。當數據達到一定數量后，熱緩存將轉變為冷緩存，不再接受寫入操作，此時系統將重新創建熱緩存來接收寫入數據。

2.3.4 結構化合并樹

冷緩存和熱緩存的數據采用結構化合并樹技術，按照時間戳進行組織，多棵樹可以在內存中合并成一棵大樹，為順序寫入和讀取創造條件。

2.3.5 順序寫入和讀取

綜合監控系統的歷史數據需要長時間存儲在磁盤、磁帶庫等設備上，因而磁盤、磁帶庫等設備的順序讀寫性能要求比隨機讀寫性能要求高得多。熱緩存的數據達到一定數量后，熱緩存轉變成冷緩存，然后把冷緩存數據順序寫入存儲設備。歷史數據庫通過全量、增量、差異備份和恢復等技術保證歷史數據安全。

3 性能模擬測試

3.1 模擬測試場景

在實驗室進行綜合監控系統的科研項目性能模擬測試。綜合監控系統的網絡結構和OCC客戶端的HMI(人機界面)如圖7所示。模擬測試的場景如下：

1) 模擬線路：1條具有1個OCC、1個車輛段、1個停車場和22個車站的地鐵線路。

2) 單個節點模擬設備總點數為110萬，全線模擬設備總點數為2 750萬。

3) 測試所用服務器和工作站均采用物理機。其中：OCC的服務器采用HPE ProLiant DL560 Gen10；OCC工作站采用聯想揚天A8000t；車站服務器采用曙光I620-G20；車站工作站采用聯想ThinkCentre M8500T-N085。

4) 網絡采用光纖雙環網。

5) 1個域的實時數據庫和歷史數據庫只處理和存儲1個車站/車輛段的數據。

6) 通過設置死區等機制來判斷模擬數據是否發生變化。

圖7 綜合監控系統的網絡結構圖

3.2 單節點系統性能

1) 實時數據庫：容量達到110萬點，更新性能達到32萬點/s，查詢性能達到28萬點/s。

2) 歷史數據庫：寫入性能達到26萬條/s，讀取性能達到9萬條/s。

3) 系統響應時間：50 ms(從前置機接收到狀態變化起到車站客戶端HMI監控畫面發生變化止)。

3.3 全線系統性能

1) 實時數據庫：總容量達到2 750萬點，更新能力達到630萬點/s，查詢性能達到580萬點/s。

2) 歷史數據庫：寫入能力達到560萬條/s，讀取能力達到160萬條/s。

3) 系統響應時間：80 ms(從前置機接收到狀態變化起到OCC客戶端HMI監控畫面發生變化止)。

4 結語

傳統的城市軌道交通綜合監控系統受制于系統的容量及處理性能，監控點的數據處理和存儲以及對突發事件的反應速度均受到嚴重影響。通過采用大規模全景數據并發控制及存儲技術，提升了對全景數據的實時處理能力和歷史存儲能力，可滿足全自動運行模式下對綜合監控系統性能的要求。實驗室模擬測試結果表明，此技術已可滿足二線城市的城市軌道交通線網綜合監控系統關于系統容量和性能方面的需求。此外，由于大規模全景數據并發控制及存儲技術采用了分布式架構，理論上可通過增加硬件設備和提高網絡帶寬等措施進一步提升綜合監控系統的容量和性能，從而滿足更大規模的城市軌道交通線網對綜合監控工程的要求。