基于時序數(shù)據(jù)庫的信號集中監(jiān)測數(shù)據(jù)存儲和分析

李 暢

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

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

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

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

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

信號集中監(jiān)測系統(tǒng)主要監(jiān)測內(nèi)容為開關(guān)量監(jiān)測、外電網(wǎng)質(zhì)量監(jiān)測、電源屏監(jiān)測、軌道電路監(jiān)測、轉(zhuǎn)轍機監(jiān)測、道岔表示電壓監(jiān)測、電纜絕緣監(jiān)測、電源對地漏泄電流監(jiān)測、電源屏各種輸出電源、集中式移頻監(jiān)測、半自動閉塞電特性監(jiān)測、機房室內(nèi)環(huán)境溫濕度模擬量的監(jiān)測、機房室內(nè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ù)包括電壓、電流、相位角、載頻、頻率、溫度、濕度等均為模擬量可用浮點數(shù)表示。

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

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

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

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

通過計算得到一個中等站每天就能產(chǎn)生高達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ù)據(jù)的特點，關(guān)系型數(shù)據(jù)庫無法滿足對時間序列數(shù)據(jù)大量長期的有效存儲與處理，因此迫切需要一種專門針對時間序列數(shù)據(jù)來做優(yōu)化的數(shù)據(jù)庫系統(tǒng)，即時間序列數(shù)據(jù)庫。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在現(xiàn)場抽取了3 個規(guī)模相似車站但分布采用不同的數(shù)據(jù)存儲方式，通過近半年時間的不間斷運行試驗，對采集存儲約17 億條模擬量數(shù)據(jù)的查詢統(tǒng)計性能比對驗證，采用時序數(shù)據(jù)庫數(shù)據(jù)庫能夠在大數(shù)據(jù)量的綜合查詢分析需求下提供秒級的查詢統(tǒng)計，大大優(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ù)導入和數(shù)據(jù)清洗，把原先存儲在文件數(shù)據(jù)庫或MySql 關(guān)系型數(shù)據(jù)庫中的二進制流數(shù)據(jù)轉(zhuǎn)化為以時間為關(guān)鍵維度的一組列數(shù)據(jù)，并通過列查找、預統(tǒng)計來提高數(shù)據(jù)查詢和分析效率，能夠大大優(yōu)化信號集中監(jiān)測系統(tǒng)的性能，為系統(tǒng)更進一步發(fā)展提供數(shù)據(jù)助力。

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