基于鐵路數(shù)據(jù)服務(wù)平臺的電務(wù)專業(yè)數(shù)據(jù)采集、共享及可視化研究

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

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 Kafka分布式消息隊列

2.2.1 Kafka簡介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 告警消息處理流程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 采集與共享方式

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

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

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

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

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

其中，時間格式為：YYYYMMDDHHMI（開始、結(jié)束時間）或YYYYMMDDHHMISS（文件生成時間）。例如，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)題行對應(yīng)的數(shù)據(jù)值，字段間采用逗號分隔。其中，時間類字段的數(shù)據(jù)格式定義為“YYYY-MM-DD h24:mi:ss”。

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

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

3.3.1 RESTful接口簡介

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

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

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

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

3.3.2 RESTful接口調(diào)用

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

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

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

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

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

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

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

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

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

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

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

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

表1 可視化需求分類

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

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

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

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

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

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

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

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

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

5 結(jié)束語

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