李 暢

(上海理工大學(xué)光電信息與計(jì)算機(jī)工程學(xué)院，上海 200093)

1 信號集中監(jiān)測系統(tǒng)概述

鐵路信號集中監(jiān)測系統(tǒng)是保證行車安全、加強(qiáng)信號設(shè)備結(jié)合部管理、監(jiān)測鐵路信號設(shè)備運(yùn)用質(zhì)量的重要行車設(shè)備。信號集中監(jiān)測系統(tǒng)利用傳感器技術(shù)、現(xiàn)場總線、計(jì)算機(jī)網(wǎng)絡(luò)通訊、數(shù)據(jù)庫及軟件工程等技術(shù)，通過監(jiān)測并記錄信號設(shè)備的主要運(yùn)行狀態(tài)，為電務(wù)部門掌握設(shè)備的當(dāng)前狀態(tài)和進(jìn)行事故分析提供科學(xué)依據(jù)。同時(shí)，系統(tǒng)還具有數(shù)據(jù)邏輯判斷功能，當(dāng)信號設(shè)備工作偏離預(yù)定界限或出現(xiàn)異常時(shí)，及時(shí)進(jìn)行報(bào)警，避免因設(shè)備故障或違章操作影響列車的安全、正點(diǎn)運(yùn)行,信號集中監(jiān)測系統(tǒng)是鐵路裝備現(xiàn)代化的重要組成部分。

隨著鐵路運(yùn)營里程快速增長，高鐵速度大幅提高，鐵路電務(wù)部門對信號集中監(jiān)測系統(tǒng)的要求也越來越高。主要包含兩方面，一是數(shù)據(jù)存儲的時(shí)間和范圍越來越高，一個設(shè)備的使用周期往往是15 年甚至更長，但現(xiàn)有技術(shù)條件僅能保存1 年左右的數(shù)據(jù)，難以對設(shè)備的全生命周期進(jìn)行分析判斷；二是對現(xiàn)有數(shù)據(jù)的自動分析需求越來越強(qiáng)烈，現(xiàn)有數(shù)據(jù)分析僅做到判斷模擬量是否超限等簡單的比較分析，大量異常情況需要專業(yè)人員瀏覽分析，隨著設(shè)備越來越多，人員越來越緊張的情況一直持續(xù)。將一些業(yè)務(wù)規(guī)則明確、邏輯清晰的診斷分析交由計(jì)算機(jī)系統(tǒng)自動進(jìn)行分析，實(shí)現(xiàn)計(jì)算機(jī)專家診斷功能，這就對數(shù)據(jù)庫存儲系統(tǒng)的數(shù)據(jù)吞吐效率提出了更高要求。

2 信號集中監(jiān)測數(shù)據(jù)特點(diǎn)

信號集中監(jiān)測系統(tǒng)主要監(jiān)測內(nèi)容為開關(guān)量監(jiān)測、外電網(wǎng)質(zhì)量監(jiān)測、電源屏監(jiān)測、軌道電路監(jiān)測、轉(zhuǎn)轍機(jī)監(jiān)測、道岔表示電壓監(jiān)測、電纜絕緣監(jiān)測、電源對地漏泄電流監(jiān)測、電源屏各種輸出電源、集中式移頻監(jiān)測、半自動閉塞電特性監(jiān)測、機(jī)房室內(nèi)環(huán)境溫濕度模擬量的監(jiān)測、機(jī)房室內(nèi)防災(zāi)和異物侵限情況監(jiān)測、車站/調(diào)車場間聯(lián)系電壓監(jiān)測等。由此可以發(fā)現(xiàn)，信號集中監(jiān)測系統(tǒng)的數(shù)據(jù)除開關(guān)量監(jiān)測的對象為開關(guān)量外，其余監(jiān)測數(shù)據(jù)包括電壓、電流、相位角、載頻、頻率、溫度、濕度等均為模擬量可用浮點(diǎn)數(shù)表示。

無論是開關(guān)量還是模擬量數(shù)據(jù)，均有很強(qiáng)的時(shí)間關(guān)聯(lián)性，每個數(shù)據(jù)除了數(shù)據(jù)值本身外都要有一個時(shí)間量。各個數(shù)據(jù)的時(shí)間關(guān)聯(lián)性很強(qiáng)，從數(shù)據(jù)角度上來說，系統(tǒng)就是由一個個時(shí)刻上的數(shù)據(jù)集合構(gòu)成的。

隨著車站、設(shè)備的增多，以及時(shí)間的推移，信號集中監(jiān)測系統(tǒng)記錄存儲的數(shù)據(jù)會越來越多，按照一個中等車站1 000 路模擬量，每125 ms 一個數(shù)據(jù)集合計(jì)算，每天產(chǎn)生的數(shù)據(jù)條數(shù)就高達(dá)24×60×60×1 000/125×1 000=691 200 000 條，經(jīng)過壓縮去重后存儲的數(shù)據(jù)也約300 萬條記錄。雖然系統(tǒng)的數(shù)據(jù)量會隨著車站、設(shè)備的增多，時(shí)間的推移逐步甚至迅速增多，但每種數(shù)據(jù)的格式、類型、關(guān)聯(lián)等不會改變，數(shù)據(jù)維度穩(wěn)定；數(shù)據(jù)雖然會不斷增多，但是寫入量平穩(wěn)，且不會有更新以及單獨(dú)一個點(diǎn)數(shù)據(jù)的刪除操作。

由此可以總結(jié)出信號集中監(jiān)測系統(tǒng)的數(shù)據(jù)有著數(shù)據(jù)量大、寫入操作多、時(shí)間關(guān)聯(lián)性強(qiáng)、數(shù)據(jù)更新少、數(shù)據(jù)維度穩(wěn)定這些特性，系統(tǒng)運(yùn)用上對查詢時(shí)效性要求高。

3 時(shí)序數(shù)據(jù)庫概述

通過計(jì)算得到一個中等站每天就能產(chǎn)生高達(dá)300 萬條的數(shù)據(jù)，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫如oracle 理論單表數(shù)據(jù)記錄條數(shù)無上限設(shè)置，但官方推薦單表數(shù)據(jù)不超過500 萬條記錄，且一旦記錄條數(shù)超過1 億條以后，查詢效率會急速下降；由此可以發(fā)現(xiàn)，針對類似于信號集中監(jiān)測系統(tǒng)這種基于時(shí)間序列數(shù)據(jù)的特點(diǎn)，關(guān)系型數(shù)據(jù)庫無法滿足對時(shí)間序列數(shù)據(jù)大量長期的有效存儲與處理，因此迫切需要一種專門針對時(shí)間序列數(shù)據(jù)來做優(yōu)化的數(shù)據(jù)庫系統(tǒng)，即時(shí)間序列數(shù)據(jù)庫。

時(shí)間序列數(shù)據(jù)庫主要有以下特點(diǎn)。

3.1 數(shù)據(jù)寫入

數(shù)據(jù)會按照指定的時(shí)間間隔進(jìn)行不間斷的寫入，除實(shí)時(shí)寫入外，還有高并發(fā)的寫入，數(shù)據(jù)一旦寫入就無需更新或刪除。

3.2 數(shù)據(jù)讀取

對數(shù)據(jù)庫數(shù)據(jù)的操作以寫入為主，讀取次數(shù)遠(yuǎn)小于寫入次數(shù)，讀取時(shí)往往存在多時(shí)間粒度或指定維度讀取，要求實(shí)時(shí)聚合。

3.3 數(shù)據(jù)存儲

使用列數(shù)據(jù)庫進(jìn)行存儲，不同于行讀取的關(guān)系系統(tǒng)數(shù)據(jù)庫，列式存儲以列為單位進(jìn)行讀取，避免了行式數(shù)據(jù)庫需要先讀取所有的行，再從每一行中讀取需要的列，能夠直接讀取指定維度的列，大大提高檢索效率。

3.4 主流時(shí)序數(shù)據(jù)庫

目前主流的時(shí)序數(shù)據(jù)庫有influxDB、Kdb+、Apache Druid 等幾種，Inf luxDB 的開源版本沒有集群功能，商業(yè)版成本很高，而且著重于時(shí)序數(shù)據(jù)的實(shí)時(shí)、高效存儲，對統(tǒng)計(jì)不友好，且不支持sql；作為混合型數(shù)據(jù)庫，Kdb+對硬件性的要求較高，不適合于目前低性能服務(wù)器搭建集群的思路和方向；Apache Druid 數(shù)據(jù)庫能夠支持嵌套數(shù)據(jù)的列式存儲、具有強(qiáng)大的多維聚合分析能力、實(shí)時(shí)高效的數(shù)據(jù)攝取、具有分布式容錯框架、支持類sql 查詢，雖然在超高維度基數(shù)下可能出現(xiàn)效率降低，但由于信號集中監(jiān)測系統(tǒng)本身數(shù)據(jù)的維度基數(shù)在可控范圍內(nèi)，而且通過開發(fā)可視化運(yùn)維界面降低運(yùn)維復(fù)雜度，因此Apache Druid 是經(jīng)過時(shí)間驗(yàn)證的理論上最適合于集中監(jiān)測系統(tǒng)的時(shí)序數(shù)據(jù)庫。

4 信號集中監(jiān)測系統(tǒng)數(shù)據(jù)存儲現(xiàn)狀

目前國內(nèi)使用的信號集中監(jiān)測系統(tǒng)主要有2006 版和2010 版，兩個版本的集中監(jiān)測系統(tǒng)在服務(wù)器端只存儲了每站的報(bào)警信息和開關(guān)量數(shù)據(jù)，對于模擬量信息則是實(shí)時(shí)向站機(jī)發(fā)送命令進(jìn)行調(diào)取，2006 版的信號集中監(jiān)測系統(tǒng)站機(jī)數(shù)據(jù)以二進(jìn)制的形式存儲在文件系統(tǒng)中，每天、每類設(shè)備一個文件，保存1 年，一個中等站的數(shù)據(jù)即使壓縮存儲后，每個月的數(shù)據(jù)文件占用的磁盤空間也要超過4 G，文件系統(tǒng)頻繁讀寫，容易損壞出錯，造成數(shù)據(jù)丟失；2010 版集中監(jiān)測系統(tǒng)，站機(jī)采用mysql 數(shù)據(jù)庫，模擬量數(shù)據(jù)按日期分區(qū)分表，以二進(jìn)制的形式存儲在longblob 型字段中，通過定時(shí)任務(wù)及時(shí)清理數(shù)據(jù)，blob 類型數(shù)據(jù)由于自身特點(diǎn)，讀寫效率較低，一旦數(shù)據(jù)記錄過多，會嚴(yán)重影響系統(tǒng)響應(yīng)速度，造成系統(tǒng)假死、用戶頻繁發(fā)送請求進(jìn)而引起線程增加導(dǎo)致程序或系統(tǒng)崩潰。

5 基于時(shí)序數(shù)據(jù)庫的存儲設(shè)計(jì)

隨著集中監(jiān)測系統(tǒng)數(shù)據(jù)分析的深入，在2020版信號集中監(jiān)測系統(tǒng)標(biāo)準(zhǔn)中已明確要求服務(wù)器端存儲所有站機(jī)的模擬量數(shù)據(jù)，對數(shù)據(jù)關(guān)聯(lián)分析提出了總體要求并給出了部分分析模型，2006 版和2010版集中監(jiān)測系統(tǒng)既有的數(shù)據(jù)存儲方式在數(shù)據(jù)側(cè)的查詢、統(tǒng)計(jì)分析時(shí)效上已不能滿足新版監(jiān)測標(biāo)準(zhǔn)的需求。

集中監(jiān)測主要模擬量數(shù)據(jù)為信號設(shè)備運(yùn)行的電氣特性，不同類型的采樣周期一般為每秒采集，采集的數(shù)據(jù)類型為電壓、電流、相位角等可記錄為浮點(diǎn)類型的數(shù)據(jù)值。這類數(shù)據(jù)有時(shí)序數(shù)據(jù)的特點(diǎn)，如按照時(shí)間粒度持續(xù)寫入、高并發(fā)的持續(xù)寫入、無更新和刪除操作。結(jié)合集中監(jiān)測的報(bào)警數(shù)據(jù)和記錄曲線數(shù)據(jù)同樣為持續(xù)寫入、無更新和刪除操作，可以判定集中監(jiān)測數(shù)據(jù)非常適用于時(shí)序數(shù)據(jù)庫進(jìn)行存儲。考慮到監(jiān)測開關(guān)量、模擬量數(shù)據(jù)的時(shí)間特性，報(bào)警、動作曲線的統(tǒng)計(jì)需求，設(shè)計(jì)采用具有時(shí)序數(shù)據(jù)庫存儲調(diào)閱性能，同時(shí)能夠提供sql 查詢分析的Apache Druid 數(shù)據(jù)庫作為信號集中監(jiān)測數(shù)據(jù)存儲的工具。使用時(shí)序數(shù)據(jù)庫，除了能夠?qū)崿F(xiàn)信號集中監(jiān)測數(shù)據(jù)全面長期的存儲外，按列存取的方式和預(yù)檢索機(jī)制都能大大提高數(shù)據(jù)利用效率，符合信號集中監(jiān)測系統(tǒng)未來發(fā)展的需要。

目前選用的Apache Druid 時(shí)序數(shù)據(jù)庫有3 大設(shè)計(jì)原則：快速查詢、水平擴(kuò)展、實(shí)時(shí)分析，保證了利用Apache Druid 對集中監(jiān)測數(shù)據(jù)進(jìn)行存儲后能夠有效地支撐上層分析、調(diào)閱模塊對監(jiān)測底層數(shù)據(jù)大吞吐量、快速靈活查詢、分布部署、隨時(shí)擴(kuò)展的需求。

基于目前的集中監(jiān)測數(shù)據(jù)存儲結(jié)構(gòu)，利用Flume+Kafka+Druid 的方式進(jìn)行數(shù)據(jù)匯總，具體方式如下：首先利用Flume 進(jìn)行數(shù)據(jù)采集，實(shí)時(shí)從原有的文件或mysql 數(shù)據(jù)庫中查詢新增數(shù)據(jù)，可根據(jù)車站數(shù)量按需搭建Flume 集群，實(shí)現(xiàn)高效安全的性能擴(kuò)充；Flume 將獲取的數(shù)據(jù)放入對應(yīng)的Kafka 的生產(chǎn)者隊(duì)列中供Druid 進(jìn)行消費(fèi)，同樣，Kafka 也可進(jìn)行集群搭建，通過zookeeper 實(shí)現(xiàn)熱擴(kuò)展和無縫切換；時(shí)序數(shù)據(jù)庫Druid 利用自帶的Kafka indexing service 插件，從對應(yīng)的Kafka 消費(fèi)者隊(duì)列中獲取數(shù)據(jù),按照預(yù)設(shè)的數(shù)據(jù)模型對取出數(shù)據(jù)進(jìn)行清洗后存入數(shù)據(jù)庫，同樣，Druid 集群也能夠進(jìn)行熱擴(kuò)展和遷移；整個框架能夠?qū)崿F(xiàn)前期小成本部署，后期低成本擴(kuò)展的需求。整體數(shù)據(jù)流程如圖1 所示。

圖1 數(shù)據(jù)流圖Fig.1 Data flow diagram

按照時(shí)序數(shù)據(jù)庫數(shù)學(xué)模型的定義，將信號集中監(jiān)測的行數(shù)據(jù)分為3 類，即時(shí)間列、維度列、指標(biāo)列；其中時(shí)間列就是數(shù)據(jù)產(chǎn)生的時(shí)間點(diǎn)，維度列包含車站、設(shè)備類型、設(shè)備名稱、模擬量類型、模擬量序號等，指標(biāo)列為每類設(shè)備包含模擬量對應(yīng)的模擬量值，數(shù)據(jù)存儲設(shè)計(jì)如圖2 所示。

圖2 數(shù)據(jù)模型劃分Fig.2 Data model allocation

為了測試時(shí)序數(shù)據(jù)庫的性能，在實(shí)驗(yàn)室里將一個29 G 的數(shù)據(jù)在Druid 數(shù)據(jù)庫中劃分23 個分區(qū)，共有數(shù)據(jù)記錄6 561 693 704 條；先將數(shù)據(jù)進(jìn)行寫入，再分別對數(shù)據(jù)進(jìn)行日期排序、維度范圍排序、指標(biāo)列差值排序、小時(shí)分組排序等，每個查詢操作執(zhí)行10 次，取平均值得到測試結(jié)果如下：數(shù)據(jù)寫入29 G 數(shù)據(jù)平均耗時(shí)49 973 ms；查詢?nèi)〕銮? 000條記錄，平均耗時(shí)140 ms；根據(jù)一個維度列和時(shí)間范圍、指標(biāo)值查找，平均耗時(shí)70 ms；按照一個維度列分組并計(jì)算指標(biāo)值最大值和最小值之間的差值，平均耗時(shí)14 980 ms；按照一個維度列、小時(shí)分組，并計(jì)算指標(biāo)值的均值，平均耗時(shí)21 810 ms。通過大數(shù)據(jù)量的壓力測試，結(jié)果表明時(shí)序數(shù)據(jù)庫總體上在數(shù)據(jù)存儲和數(shù)據(jù)讀取都非常穩(wěn)定快速。

在現(xiàn)場抽取了3 個規(guī)模相似車站但分布采用不同的數(shù)據(jù)存儲方式，通過近半年時(shí)間的不間斷運(yùn)行試驗(yàn)，對采集存儲約17 億條模擬量數(shù)據(jù)的查詢統(tǒng)計(jì)性能比對驗(yàn)證，采用時(shí)序數(shù)據(jù)庫數(shù)據(jù)庫能夠在大數(shù)據(jù)量的綜合查詢分析需求下提供秒級的查詢統(tǒng)計(jì)，大大優(yōu)于既有的文件和關(guān)系型數(shù)據(jù)庫，從數(shù)據(jù)服務(wù)角度對監(jiān)測分析提供有力支持，具體測試數(shù)據(jù)如表1所示。

表1 數(shù)據(jù)查詢性能比對Tab.1 Comparison of data query performance

6 結(jié)束語

通過數(shù)據(jù)導(dǎo)入和數(shù)據(jù)清洗，把原先存儲在文件數(shù)據(jù)庫或MySql 關(guān)系型數(shù)據(jù)庫中的二進(jìn)制流數(shù)據(jù)轉(zhuǎn)化為以時(shí)間為關(guān)鍵維度的一組列數(shù)據(jù)，并通過列查找、預(yù)統(tǒng)計(jì)來提高數(shù)據(jù)查詢和分析效率，能夠大大優(yōu)化信號集中監(jiān)測系統(tǒng)的性能，為系統(tǒng)更進(jìn)一步發(fā)展提供數(shù)據(jù)助力。

后期通過對系統(tǒng)框架的整體重構(gòu)，通過搭建Druid 集群，將站機(jī)采集的數(shù)據(jù)存儲直接寫入Kafka 消息隊(duì)列，免去Flume 查詢收集環(huán)節(jié)，同時(shí)Druid 集群能夠有效地避免數(shù)據(jù)丟失，提升整體分析性能。