楊東盛，戚小玉，馬小寧，李平，楊連報(bào)

（中國(guó)鐵道科學(xué)研究院集團(tuán)有限公司 電子計(jì)算技術(shù)研究所，北京 100081）

0 引言

電務(wù)系統(tǒng)對(duì)鐵路系統(tǒng)的安全穩(wěn)定運(yùn)行至關(guān)重要。我國(guó)鐵路運(yùn)營(yíng)情況復(fù)雜，電務(wù)系統(tǒng)規(guī)模不斷擴(kuò)大，設(shè)備功能越來(lái)越復(fù)雜，對(duì)保障電務(wù)系統(tǒng)長(zhǎng)期安全、穩(wěn)定運(yùn)行的要求越來(lái)越迫切[1-2]。隨著電務(wù)專(zhuān)業(yè)信息化建設(shè)的深化，新技術(shù)新設(shè)備大量投入，各設(shè)備子系統(tǒng)同步建設(shè)了相關(guān)檢測(cè)、監(jiān)測(cè)系統(tǒng)，產(chǎn)生和存儲(chǔ)了海量數(shù)據(jù)，亟需運(yùn)用大數(shù)據(jù)進(jìn)行深入挖掘分析，優(yōu)化安全生產(chǎn)流程，提升管理效率，更好地服務(wù)于鐵路安全生產(chǎn)。

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

1 電務(wù)專(zhuān)業(yè)數(shù)據(jù)采集共享流程

數(shù)據(jù)服務(wù)平臺(tái)整體架構(gòu)展示了數(shù)據(jù)由數(shù)據(jù)源經(jīng)過(guò)數(shù)據(jù)服務(wù)平臺(tái)采集、處理、存儲(chǔ)、分析再共享的流程（見(jiàn)圖1）。

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

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

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

采用此種數(shù)據(jù)采集方式的優(yōu)勢(shì)主要有：

（1）形成了平臺(tái)外部數(shù)據(jù)源與內(nèi)部數(shù)據(jù)處理的統(tǒng)一邊界，可直接在消息隊(duì)列中判斷數(shù)據(jù)是否符合采集要求，無(wú)需再由數(shù)據(jù)庫(kù)層面控制；

（2）數(shù)據(jù)通過(guò)“總線”方式存入，可實(shí)現(xiàn)并行處理，同一數(shù)據(jù)可以讓共享程序、存儲(chǔ)程序、分析程序同時(shí)消費(fèi)，提高了數(shù)據(jù)的可共享性、可復(fù)用性和處理時(shí)效性；

（3）“總線”型架構(gòu)結(jié)構(gòu)靈活，易于擴(kuò)展，未來(lái)如需在采集端增減接口，只需對(duì)Kafka隊(duì)列進(jìn)行適配，不會(huì)影響其他模塊，改動(dòng)量較小，同時(shí)也節(jié)省了多源數(shù)據(jù)對(duì)接的工作量；

（4）Kafka消息隊(duì)列采用分布式架構(gòu)，可以實(shí)現(xiàn)多節(jié)點(diǎn)的負(fù)載均衡，相對(duì)于單一接口方式單獨(dú)處理，分布式架構(gòu)對(duì)某一接口方式瞬時(shí)大數(shù)據(jù)量有較好的承載能力，提高了采集的穩(wěn)定性和可靠性。

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

采集到數(shù)據(jù)后，平臺(tái)除了使用Flink流處理服務(wù)實(shí)現(xiàn)大量高速的數(shù)據(jù)流處理，還在此過(guò)程中增加了采集數(shù)據(jù)的完整性校驗(yàn)，包括檢查字段是否完整、類(lèi)型是否一致、標(biāo)識(shí)是否唯一等。增加的校驗(yàn)工作進(jìn)一步保障了數(shù)據(jù)的真實(shí)可靠。相較于先存儲(chǔ)再共享的低效率，為實(shí)現(xiàn)高速可靠的數(shù)據(jù)共享，平臺(tái)將校驗(yàn)無(wú)誤的數(shù)據(jù)分為3路同時(shí)處理，實(shí)時(shí)數(shù)據(jù)轉(zhuǎn)換為JSON格式直接送入共享端Kafka隊(duì)列共享，同時(shí)也存入時(shí)序數(shù)據(jù)庫(kù)用于RESTful接口[8]的查詢(xún)，第3路數(shù)據(jù)直接存入HIVE數(shù)據(jù)倉(cāng)庫(kù)用于大數(shù)據(jù)分析。

在數(shù)據(jù)共享中，平臺(tái)也采用了類(lèi)似采集端的“總線”機(jī)制，可為電務(wù)應(yīng)用提供規(guī)范統(tǒng)一、格式標(biāo)準(zhǔn)的數(shù)據(jù)源。其中，實(shí)時(shí)數(shù)據(jù)直接送入共享端的Kafka消息隊(duì)列，應(yīng)用可直接消費(fèi)Kafka中實(shí)時(shí)數(shù)據(jù)；或采用平臺(tái)提供輪循調(diào)取的RESTful接口，支持相對(duì)實(shí)時(shí)的數(shù)據(jù)共享；對(duì)于非實(shí)時(shí)數(shù)據(jù)，平臺(tái)統(tǒng)一使用RESTful接口實(shí)現(xiàn)。

此外，平臺(tái)還支持大數(shù)據(jù)分析結(jié)果的共享使用。應(yīng)用可以授權(quán)對(duì)HDFS/HIVE中數(shù)據(jù)進(jìn)行分析預(yù)測(cè)處理，處理結(jié)果將采用非實(shí)時(shí)RESTful接口方式返回給應(yīng)用。

2 實(shí)時(shí)數(shù)據(jù)采集與共享

2.1 實(shí)時(shí)數(shù)據(jù)采集共享方式

電務(wù)通信、信號(hào)相關(guān)業(yè)務(wù)數(shù)據(jù)具有實(shí)時(shí)性要求高、短時(shí)數(shù)據(jù)量大、可靠性需求高等特點(diǎn)。針對(duì)這些特點(diǎn)，對(duì)數(shù)據(jù)服務(wù)平臺(tái)中的組件與服務(wù)進(jìn)行了合理配置：

（1）對(duì)于實(shí)時(shí)性要求較高的需求，平臺(tái)采用Kafka消息隊(duì)列總線多線程處理，創(chuàng)新性地采用數(shù)據(jù)隨進(jìn)隨出，獨(dú)立線程同步存儲(chǔ)的設(shè)計(jì)，極低延遲的實(shí)時(shí)數(shù)據(jù)流保障了共享端與應(yīng)用接口的響應(yīng)速度。

（2）對(duì)于短時(shí)數(shù)據(jù)量大的需求，平臺(tái)采用分布式負(fù)載均衡配置，并創(chuàng)新使用高效的數(shù)據(jù)包壓縮算法，降低帶寬需求，還特別設(shè)計(jì)了針對(duì)特定數(shù)據(jù)簡(jiǎn)化內(nèi)容中的冗余字段標(biāo)識(shí)方法，進(jìn)一步減小數(shù)據(jù)包大小。

（3）對(duì)于高可靠性保障需求，平臺(tái)針對(duì)電務(wù)專(zhuān)業(yè)設(shè)計(jì)的Kafka分布式隊(duì)列增加了副本數(shù)（利用備份策略實(shí)現(xiàn)即使集群中1臺(tái)Kafka服務(wù)出現(xiàn)異常，其他服務(wù)也可以保障數(shù)據(jù)全量存儲(chǔ)），從而保證數(shù)據(jù)冗余，防止數(shù)據(jù)丟失。同時(shí)，延長(zhǎng)了Kafka消費(fèi)數(shù)據(jù)的有效期，數(shù)據(jù)消費(fèi)后不會(huì)立刻清除，從而保證了時(shí)間冗余，防止無(wú)據(jù)可查。此外，平臺(tái)在流處理過(guò)程中增加了入庫(kù)前的有效字段校驗(yàn)，確保采集共享全流程的高可靠性。

2.2 Kafka分布式消息隊(duì)列

2.2.1 Kafka簡(jiǎn)介

Kafka消息隊(duì)列是一個(gè)分布式流媒體平臺(tái)，它是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)。

Kafka主要有3種功能：一是可以發(fā)布和訂閱消息流，分發(fā)訂閱的消息；二是可以容錯(cuò)的方式記錄消息流，并以文件的方式存儲(chǔ)消息流；三是可以在消息發(fā)布的時(shí)候進(jìn)行處理[9]。Kafka在系統(tǒng)或應(yīng)用程序之間構(gòu)建可靠的用于傳輸實(shí)時(shí)數(shù)據(jù)的管道，對(duì)于鐵路數(shù)據(jù)服務(wù)平臺(tái)形成了一個(gè)數(shù)據(jù)采集共享的總線，所有數(shù)據(jù)先通過(guò)各種方式匯集到Kafka，再通過(guò)Kafka分發(fā)到訂閱它們的應(yīng)用。

實(shí)際使用時(shí)，Kafka通過(guò)不同的主題（topic）對(duì)不同類(lèi)型的數(shù)據(jù)進(jìn)行分區(qū)處理。每個(gè)topic都被編入索引并存儲(chǔ)時(shí)間戳。Kafka對(duì)外提供4種類(lèi)型的接口：

（1）生產(chǎn)者接口。允許應(yīng)用（數(shù)據(jù)源方）將數(shù)據(jù)流發(fā)布到1個(gè)或多個(gè)Kafka topic。

（2）消費(fèi)者接口。允許應(yīng)用（數(shù)據(jù)使用方）將數(shù)據(jù)流發(fā)布到1個(gè)或多個(gè)Kafka topic。

（3）數(shù)據(jù)流接口。將輸入流轉(zhuǎn)換為輸出并生成結(jié)果。

（4）連接器接口。允許構(gòu)建和運(yùn)行可復(fù)用的生產(chǎn)者或消費(fèi)者。

在Kafka中生產(chǎn)者將數(shù)據(jù)發(fā)布到某個(gè)topic中，消費(fèi)者監(jiān)聽(tīng)該topic并可靠地消費(fèi)到數(shù)據(jù)。即生產(chǎn)者在topic中創(chuàng)建數(shù)據(jù)，消費(fèi)者從這些topic中讀取數(shù)據(jù)。為此，Kafka采用分布式設(shè)計(jì)，不同的topic由分區(qū)分隔，并在各節(jié)點(diǎn)之間復(fù)制。數(shù)據(jù)的消息體沒(méi)有固定的格式，而是采用字節(jié)組的形式存儲(chǔ)和傳輸。因此，可以利用它們來(lái)存儲(chǔ)任何希望的格式對(duì)象，如JSON、XML等。

Kafka廣泛使用在實(shí)時(shí)數(shù)據(jù)流水線的開(kāi)發(fā)中，因?yàn)樗梢蕴峁└咚俑呷萘繑?shù)據(jù)傳輸，這種高速數(shù)據(jù)通過(guò)Kafka的實(shí)時(shí)管道傳遞。發(fā)布的數(shù)據(jù)使用任何流平臺(tái)或任何Kafka連接器進(jìn)行訂閱, 然后使用API 將訂閱的數(shù)據(jù)推送到應(yīng)用層使用。

2.2.2 Kafka傳輸?shù)膬?yōu)勢(shì)

Kafka作為一種分布式的發(fā)布訂閱消息系統(tǒng)，其與JMS、RabbitMQ和AMQP等傳統(tǒng)的消息代理不同，具有更高的吞吐量、可靠性和可擴(kuò)展性，可以實(shí)現(xiàn)高速穩(wěn)定的實(shí)時(shí)數(shù)據(jù)處理。主要是由于Kafka具有諸多優(yōu)勢(shì)：高通量（支持每秒數(shù)千條消息的吞吐量）、低延遲（能夠以毫秒級(jí)的極低延遲處理消息）、高容錯(cuò)（分布式設(shè)計(jì)可以抵抗群集中的節(jié)點(diǎn)故障）、高并發(fā)性（允許以高并發(fā)讀取和寫(xiě)入消息）、高耐久性（采用節(jié)點(diǎn)間消息復(fù)制機(jī)制，保證磁盤(pán)上數(shù)據(jù)或消息的持久性）、可擴(kuò)展性（通過(guò)添加額外的節(jié)點(diǎn)不會(huì)導(dǎo)致任何停機(jī)的發(fā)生）、兼顧消息代理功能（可以替代傳統(tǒng)的消息代理將來(lái)自發(fā)布者傳遞協(xié)議的消息轉(zhuǎn)換為接收者傳遞協(xié)議的消息）等。

2.3 通信實(shí)時(shí)告警全流程Kafka傳輸

以通信專(zhuān)業(yè)為例，告警消息采用Kafka消息隊(duì)列方式傳輸，具體處理流程見(jiàn)圖2。

平臺(tái)接收到告警消息后的處理流程如下：

（1）告警發(fā)生后，由通信數(shù)據(jù)源報(bào)送JSON格式的告警消息體到Kafka隊(duì)列通信告警topic中（此時(shí)的消息體中包含告警ID、發(fā)生時(shí)間等基本信息，但由于告警剛剛產(chǎn)生，消息體中不包含派單、告警消除等狀態(tài)信息，即在消息體中相應(yīng)字段數(shù)據(jù)為空）；

圖2 告警消息處理流程

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

（3）平臺(tái)將告警消息體實(shí)時(shí)上傳到共享端Kafka隊(duì)列，訂閱告警消息的應(yīng)用即刻收到告警消息；

（4）平臺(tái)同步將告警消息體解析入庫(kù)；

（5）平臺(tái)將新增告警ID存入告警消息變更表（建立告警消息變更表的目的是方便無(wú)法使用Kafka的應(yīng)用可以通過(guò)RESTful接口得知近期告警消息的新增和變更情況。告警消息變更表記錄最新變更的告警ID和變更類(lèi)型編碼，應(yīng)用查詢(xún)?cè)摫硇略鰞?nèi)容后，可調(diào)用告警消息RESTful接口，獲取變更告警的具體內(nèi)容）。

告警狀態(tài)變更的處理流程如下：

（1）告警狀態(tài)發(fā)送變更后，通信數(shù)據(jù)源將變更消息以XML格式報(bào)送到與之前相同的topic中；

（2）平臺(tái)接收后實(shí)時(shí)上傳狀態(tài)變更消息到共享端Kafka隊(duì)列，應(yīng)用即刻接收到變更消息；

（3）平臺(tái)同步解析狀態(tài)變更消息體，將告警確認(rèn)或派單信息增加到之前插入的數(shù)據(jù)記錄中；

（4）平臺(tái)將變更告警ID和變更狀態(tài)存入告警消息變更表。

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

（1）告警清除后，由通信數(shù)據(jù)源報(bào)送JSON格式的告警清除消息體到相同的topic中；

（2）平臺(tái)將告警清除消息體實(shí)時(shí)上傳到共享端Kafka隊(duì)列，應(yīng)用即刻接收到清除信息；

（3）平臺(tái)通過(guò)消息體中的告警清除ID在數(shù)據(jù)庫(kù)中查找到先前的告警消息，修改記錄中的清除狀態(tài)，添加清除時(shí)間；

（4）平臺(tái)將告警清除變更狀態(tài)存入告警消息變更表。

2.4 RESTful接口輪循獲取最新數(shù)據(jù)

對(duì)于可輪循調(diào)用的RESTful查詢(xún)接口，應(yīng)用可以連續(xù)調(diào)用該類(lèi)接口獲取最新數(shù)據(jù)。支持輪循調(diào)用的RESTful接口采用與非實(shí)時(shí)接口相同的調(diào)用方式，在使用上沒(méi)有差異，其使用的數(shù)據(jù)同樣來(lái)源于Kafka消息隊(duì)列。對(duì)于調(diào)用量較高、較頻繁的輪循接口，平臺(tái)則可采取在獨(dú)立硬件環(huán)境下單獨(dú)部署的方式，以減少與普通非實(shí)時(shí)接口共同部署時(shí)的硬件資源消耗，從而避免影響普通接口的調(diào)用性能。

3 非實(shí)時(shí)數(shù)據(jù)采集與共享

3.1 采集與共享方式

針對(duì)電務(wù)專(zhuān)業(yè)非實(shí)時(shí)數(shù)據(jù)采集量較大、應(yīng)用調(diào)用頻繁、數(shù)據(jù)復(fù)用率高、具有長(zhǎng)期累積分析價(jià)值等特點(diǎn)，平臺(tái)設(shè)計(jì)了數(shù)據(jù)源定時(shí)上傳FTP、平臺(tái)監(jiān)測(cè)文件并更新采集的方式。即對(duì)支持Kafka方式的數(shù)據(jù)源，依然采用與實(shí)時(shí)數(shù)據(jù)采集相同的序列化字節(jié)形式的數(shù)據(jù)包上傳數(shù)據(jù)；對(duì)不支持Kafka的數(shù)據(jù)源，平臺(tái)提供FTP前置服務(wù)器，數(shù)據(jù)源通過(guò)FTP服務(wù)定時(shí)上傳CSV格式的數(shù)據(jù)文件，平臺(tái)解析后將字符串形式的數(shù)據(jù)流送入消息隊(duì)列中。CSV數(shù)據(jù)文件格式則根據(jù)具體數(shù)據(jù)表和業(yè)務(wù)需求的不同，由數(shù)據(jù)服務(wù)平臺(tái)與數(shù)據(jù)源、應(yīng)用三方商定。

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

3.2 接口監(jiān)測(cè)數(shù)據(jù)的FTP方式采集

以接口監(jiān)測(cè)數(shù)據(jù)為例，數(shù)據(jù)通過(guò)FTP方式傳輸主要需要約定文件格式、命名方式、編碼方式、數(shù)據(jù)內(nèi)容、精度等信息。

（1）文件命名及編碼方式。平臺(tái)規(guī)定不同的數(shù)據(jù)源使用不同的FTP用戶(hù)上傳數(shù)據(jù)，并擁有獨(dú)立的根目錄用于上傳。故文件命名不需要區(qū)分?jǐn)?shù)據(jù)源，采用“數(shù)據(jù)分類(lèi)標(biāo)識(shí)-時(shí)間粒度-開(kāi)始時(shí)間-結(jié)束時(shí)間-文件生成時(shí)間.csv” 的格式。

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

（2）文件內(nèi)容。CSV文件內(nèi)容的第1行為列表標(biāo)題行；第2行以后為數(shù)據(jù)行，內(nèi)容為標(biāo)題行對(duì)應(yīng)的數(shù)據(jù)值，字段間采用逗號(hào)分隔。其中，時(shí)間類(lèi)字段的數(shù)據(jù)格式定義為“YYYY-MM-DD h24:mi:ss”。

（3）文件的傳送和處理。各業(yè)務(wù)系統(tǒng)每時(shí)間周期按約定格式生成文件，并向FTP主動(dòng)上傳。每日產(chǎn)生的數(shù)據(jù)文件由平臺(tái)負(fù)責(zé)壓縮存儲(chǔ)，并定期清除。

3.3 RESTful接口共享非實(shí)時(shí)數(shù)據(jù)

3.3.1 RESTful接口簡(jiǎn)介

數(shù)據(jù)服務(wù)平臺(tái)非實(shí)時(shí)數(shù)據(jù)的共享統(tǒng)一由RESTful風(fēng)格的接口提供[10]。其設(shè)計(jì)原則和條件主要包括：

（1）使用唯一的URL（統(tǒng)一資源定位符）來(lái)描述網(wǎng)絡(luò)上的每一個(gè)實(shí)體；

（2）客戶(hù)端通過(guò)一些HTTP協(xié)議中的動(dòng)詞，訪問(wèn)服務(wù)端的URL實(shí)現(xiàn)對(duì)服務(wù)器端資源的操作。表示操作方式的動(dòng)詞有GET、POST、PUT等。

RESTful接口常用于實(shí)現(xiàn)Web應(yīng)用的前后端分離，適合于鐵路數(shù)據(jù)服務(wù)平臺(tái)向應(yīng)用層共享數(shù)據(jù)。

3.3.2 RESTful接口調(diào)用

應(yīng)用可通過(guò)訪問(wèn)平臺(tái)接口URL實(shí)現(xiàn)對(duì)平臺(tái)數(shù)據(jù)的訪問(wèn)。在調(diào)用平臺(tái)提供的RESTful接口時(shí)，需遵循接口消息體格式、壓縮方式等約定。

（1）消息體格式。平臺(tái)接口的請(qǐng)求和響應(yīng)均采用通用的JSON格式。

（2）消息體壓縮。接口的請(qǐng)求體不做壓縮，當(dāng)響應(yīng)消息體≥1 024 Byte時(shí)才會(huì)壓縮（方便較多返回?cái)?shù)據(jù)情況下響應(yīng)消息體傳輸）。

（3）接口權(quán)限認(rèn)證。用戶(hù)按照相應(yīng)的權(quán)限從數(shù)據(jù)服務(wù)平臺(tái)獲取數(shù)據(jù)，接口權(quán)限認(rèn)證采用JWT（JSON Web Token）。

（4）返回?cái)?shù)據(jù)格式。接口返回JSON數(shù)據(jù)包含status、message和data 3部分，status表示返回的狀態(tài)碼，message表示錯(cuò)誤信息，data表示返回?cái)?shù)據(jù)。

除了上述內(nèi)容，為保障接口調(diào)用的可靠性，平臺(tái)還采用如下約定：

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

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

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

（4）接口統(tǒng)一日期時(shí)間數(shù)據(jù)格式為：“YYYYMM-DD h24:mi:ss.SSS”。

4 電務(wù)數(shù)據(jù)可視化展示

鐵路電務(wù)專(zhuān)業(yè)數(shù)據(jù)具有不同的實(shí)時(shí)性響應(yīng)需求。例如，電務(wù)設(shè)備的運(yùn)行情況與運(yùn)輸安全密切相關(guān)，設(shè)備告警信息尤其需要重點(diǎn)關(guān)注，既要關(guān)注實(shí)時(shí)告警，又要對(duì)非實(shí)時(shí)的歷史告警信息進(jìn)行關(guān)聯(lián)性分析展示。此外，列車(chē)位置實(shí)時(shí)數(shù)據(jù)、問(wèn)題庫(kù)統(tǒng)計(jì)、施工、天窗、生產(chǎn)任務(wù)等非實(shí)時(shí)數(shù)據(jù)也是用戶(hù)關(guān)注的內(nèi)容。對(duì)上述數(shù)據(jù)進(jìn)行可視化展示模型設(shè)計(jì)時(shí)，要具體分析各類(lèi)接口的響應(yīng)時(shí)間與數(shù)據(jù)的讀取周期。同時(shí)，對(duì)電務(wù)專(zhuān)業(yè)數(shù)據(jù)可視化需求進(jìn)行簡(jiǎn)單歸類(lèi)，按照關(guān)注點(diǎn)、使用人群、應(yīng)用場(chǎng)景分類(lèi)見(jiàn)表1。

表1 可視化需求分類(lèi)

運(yùn)維監(jiān)測(cè)人員為及時(shí)發(fā)現(xiàn)問(wèn)題，更關(guān)注實(shí)時(shí)數(shù)據(jù)，也就是運(yùn)維監(jiān)測(cè)類(lèi)數(shù)據(jù)，包括告警監(jiān)測(cè)、接口監(jiān)測(cè)、服務(wù)運(yùn)行狀態(tài)監(jiān)測(cè)等數(shù)據(jù)。分析調(diào)查人員比較關(guān)注非實(shí)時(shí)的歷史數(shù)據(jù)，專(zhuān)注分析挖掘數(shù)據(jù)直接的關(guān)聯(lián)關(guān)系，可通過(guò)逐級(jí)下鉆的可視化方式滿足這類(lèi)用戶(hù)的需求。指揮決策人員關(guān)心宏觀指標(biāo)與綜合概覽，可將上述實(shí)時(shí)與非實(shí)時(shí)數(shù)據(jù)可視化后的圖表組合成駕駛艙頁(yè)面，滿足這類(lèi)用戶(hù)需求。

4.1 實(shí)時(shí)數(shù)據(jù)可視化展示

電務(wù)專(zhuān)業(yè)實(shí)時(shí)數(shù)據(jù)中，告警數(shù)據(jù)占較大比例，同時(shí)由于電務(wù)設(shè)備告警與運(yùn)輸安全關(guān)系緊密，這類(lèi)數(shù)據(jù)也是用戶(hù)最為關(guān)注的數(shù)據(jù)之一。在前端頁(yè)面設(shè)置固定時(shí)間進(jìn)行刷新的方式可對(duì)告警數(shù)據(jù)近似實(shí)時(shí)展示，為運(yùn)維人員定位問(wèn)題提供及時(shí)準(zhǔn)確的參考（見(jiàn)圖3、圖4）。

圖3 告警數(shù)據(jù)GIS定位及列表的近似實(shí)時(shí)可視化展示

圖4 告警數(shù)據(jù)線路閃爍的近似實(shí)時(shí)可視化展示

利用地理信息平臺(tái)中的鐵路專(zhuān)業(yè)公用地理信息數(shù)據(jù)、鐵路實(shí)景地理信息數(shù)據(jù)及鐵路三維地理信息數(shù)據(jù)等多源空間信息數(shù)據(jù)，通過(guò)Web Service接口，將鐵塔、基站、站房、直放站、信號(hào)機(jī)、應(yīng)答器等電務(wù)設(shè)備的告警數(shù)據(jù)進(jìn)行綜合展現(xiàn)，為用戶(hù)提供更加直觀高效的展示。

4.2 非實(shí)時(shí)數(shù)據(jù)可視化展示

對(duì)于非實(shí)時(shí)的歷史數(shù)據(jù)，主要從分析的角度，采用先宏觀后微觀的方式進(jìn)行可視化展現(xiàn)。先用折線、柱圖、餅圖等基本組件進(jìn)行宏觀數(shù)據(jù)概況呈現(xiàn)，再通過(guò)下鉆的方式對(duì)明細(xì)數(shù)據(jù)進(jìn)行列表展示（見(jiàn)圖5）。采用vue.js、three.js、svg.js等可視化圖形庫(kù)將電務(wù)專(zhuān)業(yè)數(shù)據(jù)、數(shù)據(jù)服務(wù)平臺(tái)接口調(diào)用情況等數(shù)據(jù)可視化展示在前端頁(yè)面，對(duì)運(yùn)輸生產(chǎn)及智能運(yùn)維具有指導(dǎo)性意義。

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

5 結(jié)束語(yǔ)

基于鐵路數(shù)據(jù)服務(wù)平臺(tái)的電務(wù)數(shù)據(jù)實(shí)時(shí)采集與共享方案實(shí)現(xiàn)了電務(wù)數(shù)據(jù)的采集與共享。采用Kafka消息隊(duì)列技術(shù)、RESTful接口技術(shù)等方法，實(shí)現(xiàn)了通信、信號(hào)相關(guān)專(zhuān)業(yè)數(shù)據(jù)的綜合采集、存儲(chǔ)，并提供標(biāo)準(zhǔn)化的共享接口，提供給電務(wù)應(yīng)用統(tǒng)一使用，實(shí)現(xiàn)了高效率、高可靠性的標(biāo)準(zhǔn)化采集共享流程，為電務(wù)數(shù)據(jù)的集中、一體化展示提供完整的流程方案。同時(shí)，通過(guò)使用電務(wù)數(shù)據(jù)相關(guān)接口，提出電務(wù)數(shù)據(jù)的綜合、集中、一體化的可視化展示方案，利用平臺(tái)采集到的專(zhuān)業(yè)數(shù)據(jù)，實(shí)現(xiàn)綜合、實(shí)時(shí)、豐富的可視化展示。