基于鐵路數據服務平臺的電務專業數據采集、共享及可視化研究

楊東盛，戚小玉，馬小寧，李平，楊連報

（中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 100081）

0 引言

電務系統對鐵路系統的安全穩定運行至關重要。我國鐵路運營情況復雜，電務系統規模不斷擴大，設備功能越來越復雜，對保障電務系統長期安全、穩定運行的要求越來越迫切[1-2]。隨著電務專業信息化建設的深化，新技術新設備大量投入，各設備子系統同步建設了相關檢測、監測系統，產生和存儲了海量數據，亟需運用大數據進行深入挖掘分析，優化安全生產流程，提升管理效率，更好地服務于鐵路安全生產。

電務系統數據復雜，種類繁多，實時性要求較高[3]，采用傳統接口方法要實現全專業數據的整合匯集并實現即時共享有較大困難。基于鐵路數據服務平臺[4]的采集和共享方案，利用Kafka分布式消息隊列、RESTful接口、時序數據庫、Flink數據流處理、數據包壓縮等新技術，有效解決了采集共享方式不統一、時效性較低、網絡帶寬受限、大量數據共享延遲等問題，提升了電務各業務功能對數據服務平臺中數據、資源、能力訪問的穩定性、可靠性、時效性。同時，利用數據可視化技術將數據量大、維度復雜的特點通過多種方式進行可視化呈現，提高了數據使用效率，使業務人員能夠直觀地看到數據，便于發現問題和總結經驗[5]。

1 電務專業數據采集共享流程

數據服務平臺整體架構展示了數據由數據源經過數據服務平臺采集、處理、存儲、分析再共享的流程（見圖1）。

圖1 接口采集共享處理流程

在數據采集中，與傳統數據采集直接將多數據源按不同接口方式接入數據庫不同，新方案數據服務平臺采用一種“數據總線”的方式實現數據源端的統一匯集，按需處理。具體方式為：無論數據采集方式、實時性要求如何，所有數據都先由數據源經相應的安全邊界隔離后，接入并存儲至采集端Kafka分布式消息隊列[6-7]中，消息隊列中暫存所有固定格式的序列化數據內容。隨后，數據處理程序作為消息隊列中數據的消費者，從“數據總線”中按需取出數據，再進行校驗、存儲或共享處理。

在這一采集共享流程中，采集端和共享端使用的Kafka分布式消息隊列是一種可以提供高通量、低延遲、高可靠的數據傳輸服務，實時性響應性能滿足現階段電務專業用戶的需求，同時，在采集層滿足電務專業現有各類數據源系統的接口兼容性需求。共享端RESTful風格接口主要用于應用端和平臺的數據交互，其擁有輕量化的設計，使用廣泛且易于實現；FTP/SFTP服務則為普遍使用的文件傳輸協議，方便對數據量大但實時性需求不高的數據進行采集；Socket接口可以在網絡中通過雙向的通信連接實現數據交換，在此可為底層硬件設備傳輸數據提供轉接。

采用此種數據采集方式的優勢主要有：

（1）形成了平臺外部數據源與內部數據處理的統一邊界，可直接在消息隊列中判斷數據是否符合采集要求，無需再由數據庫層面控制；

（2）數據通過“總線”方式存入，可實現并行處理，同一數據可以讓共享程序、存儲程序、分析程序同時消費，提高了數據的可共享性、可復用性和處理時效性；

（3）“總線”型架構結構靈活，易于擴展，未來如需在采集端增減接口，只需對Kafka隊列進行適配，不會影響其他模塊，改動量較小，同時也節省了多源數據對接的工作量；

（4）Kafka消息隊列采用分布式架構，可以實現多節點的負載均衡，相對于單一接口方式單獨處理，分布式架構對某一接口方式瞬時大數據量有較好的承載能力，提高了采集的穩定性和可靠性。

如圖1所示，除數據源直接將數據送入Kafka的方式外，對于不支持Kafka方式的實時數據源，平臺還提供使用Socket接口的數據集成模塊進行數據接入；對于實時性要求不高的數據，平臺提供FTP服務用于此類數據的采集。但無論使用何種接口方式，數據最終都會送入分布式消息隊列中做進一步處理。

采集到數據后，平臺除了使用Flink流處理服務實現大量高速的數據流處理，還在此過程中增加了采集數據的完整性校驗，包括檢查字段是否完整、類型是否一致、標識是否唯一等。增加的校驗工作進一步保障了數據的真實可靠。相較于先存儲再共享的低效率，為實現高速可靠的數據共享，平臺將校驗無誤的數據分為3路同時處理，實時數據轉換為JSON格式直接送入共享端Kafka隊列共享，同時也存入時序數據庫用于RESTful接口[8]的查詢，第3路數據直接存入HIVE數據倉庫用于大數據分析。

在數據共享中，平臺也采用了類似采集端的“總線”機制，可為電務應用提供規范統一、格式標準的數據源。其中，實時數據直接送入共享端的Kafka消息隊列，應用可直接消費Kafka中實時數據；或采用平臺提供輪循調取的RESTful接口，支持相對實時的數據共享；對于非實時數據，平臺統一使用RESTful接口實現。

此外，平臺還支持大數據分析結果的共享使用。應用可以授權對HDFS/HIVE中數據進行分析預測處理，處理結果將采用非實時RESTful接口方式返回給應用。

2 實時數據采集與共享

2.1 實時數據采集共享方式

電務通信、信號相關業務數據具有實時性要求高、短時數據量大、可靠性需求高等特點。針對這些特點，對數據服務平臺中的組件與服務進行了合理配置：

（1）對于實時性要求較高的需求，平臺采用Kafka消息隊列總線多線程處理，創新性地采用數據隨進隨出，獨立線程同步存儲的設計，極低延遲的實時數據流保障了共享端與應用接口的響應速度。

（2）對于短時數據量大的需求，平臺采用分布式負載均衡配置，并創新使用高效的數據包壓縮算法，降低帶寬需求，還特別設計了針對特定數據簡化內容中的冗余字段標識方法，進一步減小數據包大小。

（3）對于高可靠性保障需求，平臺針對電務專業設計的Kafka分布式隊列增加了副本數（利用備份策略實現即使集群中1臺Kafka服務出現異常，其他服務也可以保障數據全量存儲），從而保證數據冗余，防止數據丟失。同時，延長了Kafka消費數據的有效期，數據消費后不會立刻清除，從而保證了時間冗余，防止無據可查。此外，平臺在流處理過程中增加了入庫前的有效字段校驗，確保采集共享全流程的高可靠性。

2.2 Kafka分布式消息隊列

2.2.1 Kafka簡介

Kafka消息隊列是一個分布式流媒體平臺，它是一種高吞吐量的分布式發布訂閱消息系統。

Kafka主要有3種功能：一是可以發布和訂閱消息流，分發訂閱的消息；二是可以容錯的方式記錄消息流，并以文件的方式存儲消息流；三是可以在消息發布的時候進行處理[9]。Kafka在系統或應用程序之間構建可靠的用于傳輸實時數據的管道，對于鐵路數據服務平臺形成了一個數據采集共享的總線，所有數據先通過各種方式匯集到Kafka，再通過Kafka分發到訂閱它們的應用。

實際使用時，Kafka通過不同的主題（topic）對不同類型的數據進行分區處理。每個topic都被編入索引并存儲時間戳。Kafka對外提供4種類型的接口：

（1）生產者接口。允許應用（數據源方）將數據流發布到1個或多個Kafka topic。

（2）消費者接口。允許應用（數據使用方）將數據流發布到1個或多個Kafka topic。

（3）數據流接口。將輸入流轉換為輸出并生成結果。

（4）連接器接口。允許構建和運行可復用的生產者或消費者。

在Kafka中生產者將數據發布到某個topic中，消費者監聽該topic并可靠地消費到數據。即生產者在topic中創建數據，消費者從這些topic中讀取數據。為此，Kafka采用分布式設計，不同的topic由分區分隔，并在各節點之間復制。數據的消息體沒有固定的格式，而是采用字節組的形式存儲和傳輸。因此，可以利用它們來存儲任何希望的格式對象，如JSON、XML等。

Kafka廣泛使用在實時數據流水線的開發中，因為它可以提供高速高容量數據傳輸，這種高速數據通過Kafka的實時管道傳遞。發布的數據使用任何流平臺或任何Kafka連接器進行訂閱, 然后使用API 將訂閱的數據推送到應用層使用。

2.2.2 Kafka傳輸的優勢

Kafka作為一種分布式的發布訂閱消息系統，其與JMS、RabbitMQ和AMQP等傳統的消息代理不同，具有更高的吞吐量、可靠性和可擴展性，可以實現高速穩定的實時數據處理。主要是由于Kafka具有諸多優勢：高通量（支持每秒數千條消息的吞吐量）、低延遲（能夠以毫秒級的極低延遲處理消息）、高容錯（分布式設計可以抵抗群集中的節點故障）、高并發性（允許以高并發讀取和寫入消息）、高耐久性（采用節點間消息復制機制，保證磁盤上數據或消息的持久性）、可擴展性（通過添加額外的節點不會導致任何停機的發生）、兼顧消息代理功能（可以替代傳統的消息代理將來自發布者傳遞協議的消息轉換為接收者傳遞協議的消息）等。

2.3 通信實時告警全流程Kafka傳輸

以通信專業為例，告警消息采用Kafka消息隊列方式傳輸，具體處理流程見圖2。

平臺接收到告警消息后的處理流程如下：

（1）告警發生后，由通信數據源報送JSON格式的告警消息體到Kafka隊列通信告警topic中（此時的消息體中包含告警ID、發生時間等基本信息，但由于告警剛剛產生，消息體中不包含派單、告警消除等狀態信息，即在消息體中相應字段數據為空）；

圖2 告警消息處理流程

（2）平臺接收到告警消息后檢查其完整性和唯一性（將告警ID作為唯一鍵，確認新接收告警是否為告警重復發送，并根據字段值判斷是否滿足格式要求，確保告警真實可靠）；

（3）平臺將告警消息體實時上傳到共享端Kafka隊列，訂閱告警消息的應用即刻收到告警消息；

（4）平臺同步將告警消息體解析入庫；

（5）平臺將新增告警ID存入告警消息變更表（建立告警消息變更表的目的是方便無法使用Kafka的應用可以通過RESTful接口得知近期告警消息的新增和變更情況。告警消息變更表記錄最新變更的告警ID和變更類型編碼，應用查詢該表新增內容后，可調用告警消息RESTful接口，獲取變更告警的具體內容）。

告警狀態變更的處理流程如下：

（1）告警狀態發送變更后，通信數據源將變更消息以XML格式報送到與之前相同的topic中；

（2）平臺接收后實時上傳狀態變更消息到共享端Kafka隊列，應用即刻接收到變更消息；

（3）平臺同步解析狀態變更消息體，將告警確認或派單信息增加到之前插入的數據記錄中；

（4）平臺將變更告警ID和變更狀態存入告警消息變更表。

告警消除的處理流程如下：

（1）告警清除后，由通信數據源報送JSON格式的告警清除消息體到相同的topic中；

（2）平臺將告警清除消息體實時上傳到共享端Kafka隊列，應用即刻接收到清除信息；

（3）平臺通過消息體中的告警清除ID在數據庫中查找到先前的告警消息，修改記錄中的清除狀態，添加清除時間；

（4）平臺將告警清除變更狀態存入告警消息變更表。

2.4 RESTful接口輪循獲取最新數據

對于可輪循調用的RESTful查詢接口，應用可以連續調用該類接口獲取最新數據。支持輪循調用的RESTful接口采用與非實時接口相同的調用方式，在使用上沒有差異，其使用的數據同樣來源于Kafka消息隊列。對于調用量較高、較頻繁的輪循接口，平臺則可采取在獨立硬件環境下單獨部署的方式，以減少與普通非實時接口共同部署時的硬件資源消耗，從而避免影響普通接口的調用性能。

3 非實時數據采集與共享

3.1 采集與共享方式

針對電務專業非實時數據采集量較大、應用調用頻繁、數據復用率高、具有長期累積分析價值等特點，平臺設計了數據源定時上傳FTP、平臺監測文件并更新采集的方式。即對支持Kafka方式的數據源，依然采用與實時數據采集相同的序列化字節形式的數據包上傳數據；對不支持Kafka的數據源，平臺提供FTP前置服務器，數據源通過FTP服務定時上傳CSV格式的數據文件，平臺解析后將字符串形式的數據流送入消息隊列中。CSV數據文件格式則根據具體數據表和業務需求的不同，由數據服務平臺與數據源、應用三方商定。

對于應用層頻繁調用，且同一數據可能多次重復調用的需求，數據服務平臺提供了統一調用形式的RESTful接口實現。平臺將非實時數據接口分為3類，一是與時間相關的時序數據接口，對于這類數據，應用可以通過以數據類型命名的接口，使用編碼、開始時間、截止時間作為參數獲取數據（此類數據采用時序存儲方式，并使用時間字段作為數據表的索引，相對于關系型數據庫，該設計不僅將存儲空間減半，有效降低了I/O讀寫延時，查詢速度也有極大提高）；二是與時間無關的靜態數據接口，此類數據通常為履歷和設備臺賬等基礎信息，應用可以通過輸入表名和SQL查詢語句獲取數據；三是對有特殊需求的應用功能，平臺提供受限使用的通用SQL查詢接口，該接口將SQL語句作為唯一參數查詢數據庫，因此可以實現多表關聯等復雜的查詢功能，為應用提供豐富、靈活的數據獲取方式。

3.2 接口監測數據的FTP方式采集

以接口監測數據為例，數據通過FTP方式傳輸主要需要約定文件格式、命名方式、編碼方式、數據內容、精度等信息。

（1）文件命名及編碼方式。平臺規定不同的數據源使用不同的FTP用戶上傳數據，并擁有獨立的根目錄用于上傳。故文件命名不需要區分數據源，采用“數據分類標識-時間粒度-開始時間-結束時間-文件生成時間.csv” 的格式。

其中，時間格式為：YYYYMMDDHHMI（開始、結束時間）或YYYYMMDDHHMISS（文件生成時間）。例如，2019年1月2日15：02—15：17的信令PRI數據文件命名：PRI-15-201901021502-201901021517-20190102153449.csv。此外所有消息和文件的數據編碼都采用UTF-8編碼方式。

（2）文件內容。CSV文件內容的第1行為列表標題行；第2行以后為數據行，內容為標題行對應的數據值，字段間采用逗號分隔。其中，時間類字段的數據格式定義為“YYYY-MM-DD h24:mi:ss”。

（3）文件的傳送和處理。各業務系統每時間周期按約定格式生成文件，并向FTP主動上傳。每日產生的數據文件由平臺負責壓縮存儲，并定期清除。

3.3 RESTful接口共享非實時數據

3.3.1 RESTful接口簡介

數據服務平臺非實時數據的共享統一由RESTful風格的接口提供[10]。其設計原則和條件主要包括：

（1）使用唯一的URL（統一資源定位符）來描述網絡上的每一個實體；

（2）客戶端通過一些HTTP協議中的動詞，訪問服務端的URL實現對服務器端資源的操作。表示操作方式的動詞有GET、POST、PUT等。

RESTful接口常用于實現Web應用的前后端分離，適合于鐵路數據服務平臺向應用層共享數據。

3.3.2 RESTful接口調用

應用可通過訪問平臺接口URL實現對平臺數據的訪問。在調用平臺提供的RESTful接口時，需遵循接口消息體格式、壓縮方式等約定。

（1）消息體格式。平臺接口的請求和響應均采用通用的JSON格式。

（2）消息體壓縮。接口的請求體不做壓縮，當響應消息體≥1 024 Byte時才會壓縮（方便較多返回數據情況下響應消息體傳輸）。

（3）接口權限認證。用戶按照相應的權限從數據服務平臺獲取數據，接口權限認證采用JWT（JSON Web Token）。

（4）返回數據格式。接口返回JSON數據包含status、message和data 3部分，status表示返回的狀態碼，message表示錯誤信息，data表示返回數據。

除了上述內容，為保障接口調用的可靠性，平臺還采用如下約定：

（1）所有接口參數編碼采用UTF-8編碼方式；

（2）變量名和變量值不區分大小寫（變量值是URL/URI、令牌或密碼的除外），URL/URI區分大小寫；

（3）接口中的GET和PUT操作需具備冪等性，也即執行多次操作和1次操作的影響一致；

（4）接口統一日期時間數據格式為：“YYYYMM-DD h24:mi:ss.SSS”。

4 電務數據可視化展示

鐵路電務專業數據具有不同的實時性響應需求。例如，電務設備的運行情況與運輸安全密切相關，設備告警信息尤其需要重點關注，既要關注實時告警，又要對非實時的歷史告警信息進行關聯性分析展示。此外，列車位置實時數據、問題庫統計、施工、天窗、生產任務等非實時數據也是用戶關注的內容。對上述數據進行可視化展示模型設計時，要具體分析各類接口的響應時間與數據的讀取周期。同時，對電務專業數據可視化需求進行簡單歸類，按照關注點、使用人群、應用場景分類見表1。

表1 可視化需求分類

運維監測人員為及時發現問題，更關注實時數據，也就是運維監測類數據，包括告警監測、接口監測、服務運行狀態監測等數據。分析調查人員比較關注非實時的歷史數據，專注分析挖掘數據直接的關聯關系，可通過逐級下鉆的可視化方式滿足這類用戶的需求。指揮決策人員關心宏觀指標與綜合概覽，可將上述實時與非實時數據可視化后的圖表組合成駕駛艙頁面，滿足這類用戶需求。

4.1 實時數據可視化展示

電務專業實時數據中，告警數據占較大比例，同時由于電務設備告警與運輸安全關系緊密，這類數據也是用戶最為關注的數據之一。在前端頁面設置固定時間進行刷新的方式可對告警數據近似實時展示，為運維人員定位問題提供及時準確的參考（見圖3、圖4）。

圖3 告警數據GIS定位及列表的近似實時可視化展示

圖4 告警數據線路閃爍的近似實時可視化展示

利用地理信息平臺中的鐵路專業公用地理信息數據、鐵路實景地理信息數據及鐵路三維地理信息數據等多源空間信息數據，通過Web Service接口，將鐵塔、基站、站房、直放站、信號機、應答器等電務設備的告警數據進行綜合展現，為用戶提供更加直觀高效的展示。

4.2 非實時數據可視化展示

對于非實時的歷史數據，主要從分析的角度，采用先宏觀后微觀的方式進行可視化展現。先用折線、柱圖、餅圖等基本組件進行宏觀數據概況呈現，再通過下鉆的方式對明細數據進行列表展示（見圖5）。采用vue.js、three.js、svg.js等可視化圖形庫將電務專業數據、數據服務平臺接口調用情況等數據可視化展示在前端頁面，對運輸生產及智能運維具有指導性意義。

圖5 通信告警數據概覽及下鉆詳單的可視化展示

5 結束語

基于鐵路數據服務平臺的電務數據實時采集與共享方案實現了電務數據的采集與共享。采用Kafka消息隊列技術、RESTful接口技術等方法，實現了通信、信號相關專業數據的綜合采集、存儲，并提供標準化的共享接口，提供給電務應用統一使用，實現了高效率、高可靠性的標準化采集共享流程，為電務數據的集中、一體化展示提供完整的流程方案。同時，通過使用電務數據相關接口，提出電務數據的綜合、集中、一體化的可視化展示方案，利用平臺采集到的專業數據，實現綜合、實時、豐富的可視化展示。