基于時序數據庫的信號集中監測數據存儲和分析

李 暢

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

1 信號集中監測系統概述

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

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

2 信號集中監測數據特點

信號集中監測系統主要監測內容為開關量監測、外電網質量監測、電源屏監測、軌道電路監測、轉轍機監測、道岔表示電壓監測、電纜絕緣監測、電源對地漏泄電流監測、電源屏各種輸出電源、集中式移頻監測、半自動閉塞電特性監測、機房室內環境溫濕度模擬量的監測、機房室內防災和異物侵限情況監測、車站/調車場間聯系電壓監測等。由此可以發現，信號集中監測系統的數據除開關量監測的對象為開關量外，其余監測數據包括電壓、電流、相位角、載頻、頻率、溫度、濕度等均為模擬量可用浮點數表示。

無論是開關量還是模擬量數據，均有很強的時間關聯性，每個數據除了數據值本身外都要有一個時間量。各個數據的時間關聯性很強，從數據角度上來說，系統就是由一個個時刻上的數據集合構成的。

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

由此可以總結出信號集中監測系統的數據有著數據量大、寫入操作多、時間關聯性強、數據更新少、數據維度穩定這些特性，系統運用上對查詢時效性要求高。

3 時序數據庫概述

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

時間序列數據庫主要有以下特點。

3.1 數據寫入

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

3.2 數據讀取

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

3.3 數據存儲

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

3.4 主流時序數據庫

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

4 信號集中監測系統數據存儲現狀

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

5 基于時序數據庫的存儲設計

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

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

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

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

圖1 數據流圖Fig.1 Data flow diagram

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

圖2 數據模型劃分Fig.2 Data model allocation

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

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

表1 數據查詢性能比對Tab.1 Comparison of data query performance

6 結束語

通過數據導入和數據清洗，把原先存儲在文件數據庫或MySql 關系型數據庫中的二進制流數據轉化為以時間為關鍵維度的一組列數據，并通過列查找、預統計來提高數據查詢和分析效率，能夠大大優化信號集中監測系統的性能，為系統更進一步發展提供數據助力。

后期通過對系統框架的整體重構，通過搭建Druid 集群，將站機采集的數據存儲直接寫入Kafka 消息隊列，免去Flume 查詢收集環節，同時Druid 集群能夠有效地避免數據丟失，提升整體分析性能。