謝 飛，魏盛昕，張奕男

（1.卡斯柯信號（成都）有限公司，成都 610083；2.卡斯柯信號有限公司，上海 200071）

隨著我國城市軌道交通迅猛發(fā)展，信號系統(tǒng)的運(yùn)營維護(hù)也朝著自動化、可視化和智能化方面發(fā)展，其獲取的數(shù)據(jù)量呈現(xiàn)指數(shù)級增長且規(guī)模日益龐大，如何處理這些海量數(shù)據(jù)并挖掘其價值已成為業(yè)內(nèi)的一個難題[1]。國內(nèi)各地鐵公司都在探索如何應(yīng)用大數(shù)據(jù)技術(shù)解決在實際運(yùn)維過程中的問題，例如：杜時勇[2]提出了利用大數(shù)據(jù)搭建信號系統(tǒng)線網(wǎng)智能運(yùn)維平臺，楊文軒[3]提出了基于Hadoop 平臺構(gòu)建城軌信號系統(tǒng)健康維護(hù)平臺，但是，目前主要依賴信號系統(tǒng)定制化的監(jiān)測系統(tǒng)實現(xiàn)數(shù)據(jù)存儲與分析，很少直接去分析車載日志，因此，無法對關(guān)鍵信息進(jìn)行深度挖掘，不利于系統(tǒng)安全保障能力的提升。本文旨在構(gòu)建一種能夠?qū)Ａ康男盘栂到y(tǒng)車載日志T+1 離線分析的大數(shù)據(jù)平臺，實現(xiàn)對車載日志的統(tǒng)計分析和高效管理，以便為地鐵公司的日常運(yùn)維與保障工作提供更好的決策支撐。

1 車載日志大數(shù)據(jù)分析平臺需求

1.1 城軌信號系統(tǒng)車載日志特點(diǎn)

（1）缺乏日志數(shù)據(jù)的集中管理

在城市軌道交通建設(shè)過程中，不同線路采用不同廠家的信號系統(tǒng)，存在標(biāo)準(zhǔn)不統(tǒng)一，各線路之間多為隔離狀態(tài)，日志數(shù)據(jù)分散在各個數(shù)據(jù)孤島中，不同線路之間無法進(jìn)行數(shù)據(jù)的交互和統(tǒng)一管理。

（2）日志分析手段落后

當(dāng)信號系統(tǒng)車載設(shè)備或模塊發(fā)生故障時，地鐵公司需要上車拷貝日志，然后通過日志工具對車載日志文件逐個分析，存在效率低下、過程繁瑣等問題。

（3）傳統(tǒng)數(shù)據(jù)庫架構(gòu)無法滿足需求

據(jù)估算，1 條擁有40 列車的線路每天將會產(chǎn)生近1 億條原始數(shù)據(jù)，1 年下來將累積達(dá)到近300 億條的數(shù)據(jù)規(guī)模。在傳統(tǒng)數(shù)據(jù)庫架構(gòu)下，受單機(jī)性能的限制，要處理如此大的數(shù)據(jù)量，已經(jīng)無法滿足用戶快速、及時的查詢需求。

1.2 車載日志大數(shù)據(jù)分析平臺需求

（1）平臺架構(gòu)需考慮支持多線路車載日志數(shù)據(jù)的分析，打破不同線路信號系統(tǒng)之間的數(shù)據(jù)壁壘。

（2）平臺架構(gòu)需考慮支持通過無線網(wǎng)絡(luò)下載車載日志，并自動完成車載日志數(shù)據(jù)的解析與存儲。

（3）平臺架構(gòu)需考慮滿足數(shù)據(jù)大容量、高可用和高擴(kuò)展性的需求[4]。

（4）平臺架構(gòu)需考慮地鐵公司實際運(yùn)維的特點(diǎn)，保證數(shù)據(jù)的處理能夠在規(guī)定時間范圍內(nèi)完成。

（5）平臺規(guī)模與造價需要控制在合理范圍內(nèi)[5]。

2 基于Greenplum的車載日志大數(shù)據(jù)分析平臺設(shè)計

2.1 Greenplum介紹

Greenplum 是基于PostgreSQL 開發(fā)的數(shù)據(jù)庫集群，每個單獨(dú)的節(jié)點(diǎn)都是一個PostgreSQL 數(shù)據(jù)庫，其采用的是Shared-Nothing 架構(gòu)[6]，每一個節(jié)點(diǎn)的CPU、內(nèi)存等資源都是獨(dú)立的，每個節(jié)點(diǎn)都有全部數(shù)據(jù)的其中一部分。在用戶體驗方面，Greenplum 與傳統(tǒng)數(shù)據(jù)庫類似，但在任務(wù)處理上卻有本質(zhì)的區(qū)別[7]，它能將任務(wù)分配給多個節(jié)點(diǎn)服務(wù)器主機(jī)，實現(xiàn)對分布式事務(wù)的高效管理，在金融、保險、證券、通信、航空等領(lǐng)域都有著廣泛的運(yùn)用。

本文選擇Greenplum 搭建車載日志大數(shù)據(jù)分析平臺，主要還考慮到其擁有的一些獨(dú)特優(yōu)勢：

（1）開源項目，其造價低，部署靈活且不受限于硬件環(huán)境和平臺，允許客戶能根據(jù)自身需求選擇最適合的方案，從而降低未來的遷移代價。

（2）關(guān)系型數(shù)據(jù)庫，雖然每天產(chǎn)生的車載日志數(shù)據(jù)量大，但數(shù)據(jù)本身是結(jié)構(gòu)化數(shù)據(jù)，開發(fā)與運(yùn)維人員不需要學(xué)習(xí)很多新的數(shù)據(jù)庫處理技術(shù)，能夠降低人力成本。

（3）支持處理和分析多種數(shù)據(jù)源，包括 Kafka、Hadoop、HIVE、HBase、S3、Gemfire 及各種關(guān)系型數(shù)據(jù)庫和文件等，便于后續(xù)平臺的擴(kuò)展改造。

2.2 平臺架構(gòu)設(shè)計

為了滿足地鐵信號系統(tǒng)中海量車載日志的分析需求，基于Greenplum 的車載日志大數(shù)據(jù)分析平臺主要由數(shù)據(jù)源層、數(shù)據(jù)采集層、數(shù)據(jù)存儲層、數(shù)據(jù)分析層、應(yīng)用展示層構(gòu)成，其平臺架構(gòu)，如圖1 所示。

圖1 基于Greenplum的車載日志大數(shù)據(jù)分析平臺架構(gòu)

2.2.1 數(shù)據(jù)源層

數(shù)據(jù)源層主要由車載數(shù)據(jù)日志單元（DLU）板卡、線路服務(wù)器、線網(wǎng)服務(wù)器及綜合監(jiān)測系統(tǒng)構(gòu)成。DLU 板卡完成對列車所有行車日志的存儲，經(jīng)由車- 地?zé)o線通道把日志文件傳送到線路服務(wù)器，線路服務(wù)器將本地的車載日志文件經(jīng)由FTP 軟件再同步至線網(wǎng)服務(wù)器上。另外，地鐵綜合監(jiān)測系統(tǒng)存儲著列車在線路上運(yùn)行過程中的綜合告警記錄。

2.2.2 數(shù)據(jù)采集層

數(shù)據(jù)采集層主要負(fù)責(zé)對車載日志數(shù)據(jù)的采集、解析以及入庫，其中，車載日志分為ATP 和ATO2種日志。數(shù)據(jù)采集主要分為2 部分：（1）通過FTP方式下載車載日志文件；（2）從Oracle 數(shù)據(jù)庫同步綜合監(jiān)測系統(tǒng)的告警記錄。大數(shù)據(jù)平臺通過FTP 方式從線網(wǎng)服務(wù)器中下載車載日志文件，并對完整的日志文件按照數(shù)據(jù)協(xié)議進(jìn)行解析。解析后的日志數(shù)據(jù)將推送給基于kafka+Zookeeper 的消息中間件，最終這些消息流數(shù)據(jù)將被Greenplum Stream Server（GPSS）消費(fèi)，完成到大數(shù)據(jù)平臺的入庫操作，具體處理流程，如圖2 所示。

2.2.3 數(shù)據(jù)存儲層

數(shù)據(jù)存儲層負(fù)責(zé)對采集處理后的日志數(shù)據(jù)和告警記錄進(jìn)行存儲。大數(shù)據(jù)平臺采用Greenplum 對日志數(shù)據(jù)進(jìn)行存儲管理，采用MySQL 對車載日志文件進(jìn)行FTP 下載記錄管理，采用Oracle 對綜合監(jiān)測系統(tǒng)的告警記錄進(jìn)行管理。

2.2.4 數(shù)據(jù)分析層

數(shù)據(jù)分析層負(fù)責(zé)對大數(shù)據(jù)平臺存儲的日志數(shù)據(jù)和告警數(shù)據(jù)進(jìn)行統(tǒng)計和分析，同時結(jié)合各業(yè)務(wù)主體需求整理出用于運(yùn)維決策和應(yīng)用端展示所需要的統(tǒng)計數(shù)據(jù)。大數(shù)據(jù)平臺在數(shù)據(jù)積累的基礎(chǔ)上，可以應(yīng)用目前機(jī)械學(xué)習(xí)領(lǐng)域中相對成熟的算法挖掘出車載日志中關(guān)鍵設(shè)備或系統(tǒng)模塊的失效原因和故障趨勢。

2.2.5 應(yīng)用展示層

本研究以生態(tài)語言學(xué)理論、建構(gòu)主義理論、ESP理論等為理論依據(jù)，采用調(diào)查、文獻(xiàn)、比較等研究方法，并遵循以下思路開展研究。先調(diào)研分析高職公共英語教學(xué)現(xiàn)狀及其所存弊端，提出其改革需融入EOP的必要性；再分析融入EOP后原高職公共英語教學(xué)生態(tài)失衡產(chǎn)生的失調(diào)現(xiàn)象及不良影響，論證重構(gòu)融入EOP的教學(xué)生態(tài)的可行性；然后明晰改革思路，開發(fā)EOP教學(xué)資源，開展考核學(xué)生英語應(yīng)用能力的多元評價，加強(qiáng)EOP師資建設(shè)，實現(xiàn)高職公共英語教學(xué)生態(tài)再平衡；最后總結(jié)研究成果，并在其他高職推廣。具體研究如下三大內(nèi)容。

應(yīng)用展示層負(fù)責(zé)把數(shù)據(jù)分析層整理出的結(jié)果數(shù)據(jù)，通過PC 端和大屏端向地鐵用戶進(jìn)行展示和應(yīng)用，主要包括列車停站時間、停車精度、緊急制動（EB）、信標(biāo)丟失事件以及無線通信故障事件的統(tǒng)計與分析結(jié)果的展示。

圖2 數(shù)據(jù)采集層處理流程

2.3 系統(tǒng)功能設(shè)計

基于Greenplum 的車載日志大數(shù)據(jù)分析平臺以車載日志和綜合告警記錄中的特定事件（主要涉及停站、EB、信標(biāo)丟失以及無線通信中斷等）進(jìn)行統(tǒng)計分析，其主要功能包括列車停站時間分析、列車停車精度分析、EB 事件統(tǒng)計、信標(biāo)丟失統(tǒng)計和無線通信交叉故障統(tǒng)計。

2.3.1 列車停站時間統(tǒng)計分析

通過ATO 日志對列車停站事件的關(guān)鍵參數(shù)進(jìn)行分析，計算出列車停站過程中的關(guān)鍵指標(biāo)，主要包括列車停站總時長、乘客有效上下客時間、司機(jī)開門響應(yīng)時間、司機(jī)關(guān)門響應(yīng)時間、司機(jī)按發(fā)車按鈕響應(yīng)時間和乘客上下客效率等。根據(jù)列車停站記錄，按照列車、車站等維度按日分別統(tǒng)計出列車和車站的停站超標(biāo)結(jié)果，包括超標(biāo)次數(shù)和超標(biāo)時長。

2.3.2 列車停車精度統(tǒng)計

通過ATO 日志計算出列車每次停車事件發(fā)生時的駕駛模式、停站狀態(tài)（包括正常停、欠停、過停）及停站位置偏差，同時按照列車、車站等維度按日生成列車欠停、過停次數(shù)的統(tǒng)計報表，并提供信息查詢。

2.3.3 EB事件統(tǒng)計

2.3.4 信標(biāo)丟失統(tǒng)計

根據(jù)列車信標(biāo)丟失的標(biāo)記位的變化規(guī)律，從ATO 日志中獲取發(fā)生信標(biāo)丟失事件的信標(biāo)ID、開始時間、結(jié)束時間以及丟失位置。按照列車、車站、區(qū)段等維度，按日生成信標(biāo)丟失發(fā)生次數(shù)的統(tǒng)計報表，同時繪制線路信標(biāo)丟失趨勢圖。當(dāng)某個信標(biāo)丟失事件次數(shù)異常時，能及時提醒用戶進(jìn)行維護(hù)。

2.3.5 無線通信故障統(tǒng)計

結(jié)合車載日志和監(jiān)測系統(tǒng)的告警數(shù)據(jù)，計算出列車每次車載發(fā)生無線通信故障時的中斷時間、恢復(fù)時間、發(fā)生位置及車載故障Modem名稱。按照列車、車站等維度按日統(tǒng)計出無線通信中斷的故障統(tǒng)計次數(shù)并生成報表，繪制出無線通信故障趨勢圖，能夠及時向用戶發(fā)出告警，并提示用戶及時處理故障。

3 基于Greenplum的大數(shù)據(jù)平臺實現(xiàn)

3.1 大數(shù)據(jù)平臺構(gòu)建

為了滿足車載日志的數(shù)據(jù)存儲、數(shù)據(jù)分析以及數(shù)據(jù)查詢的性能要求，并充分考慮到大數(shù)據(jù)平臺的建設(shè)成本，平臺建設(shè)時主要采用了Greenplum、Kafka、Zookeeper 及MySQL 等開源組件，形成一套可按需部署、開源軟件為主的大數(shù)據(jù)平臺。

基于Greenplum 的大數(shù)據(jù)平臺主要由1 個管理節(jié)點(diǎn)和3 個數(shù)據(jù)節(jié)點(diǎn)組成，每個節(jié)點(diǎn)配置為2顆8 核 的Intel 64 bit 處理 器、32 GB 內(nèi) 存及3 塊600 GB SAS 硬盤，每個節(jié)點(diǎn)間使用千兆網(wǎng)絡(luò)連接，Greenplum 版本為5.19，其拓?fù)浣Y(jié)構(gòu)，如圖3 所示。每個數(shù)據(jù)節(jié)點(diǎn)上部署2 個主實例和2 個鏡像實例，各數(shù)據(jù)節(jié)點(diǎn)之間進(jìn)行交叉鏡像配置，提高了集群的可用性[6]。在部署實際的生產(chǎn)環(huán)境時，根據(jù)實際需求可以增加兩臺服務(wù)器，一臺作為大數(shù)據(jù)應(yīng)用展示的Web 應(yīng)用服務(wù)器，另一臺作為存儲車載日志文件的數(shù)據(jù)日志服務(wù)器。

圖3 基于Greenplum的大數(shù)據(jù)平臺拓?fù)浣Y(jié)構(gòu)

在完成大數(shù)據(jù)平臺部署后，通過數(shù)據(jù)采集/解析服務(wù)將線網(wǎng)服務(wù)器中的車載日志數(shù)據(jù)加載到平臺中去。Greenplum 作為一個分布式數(shù)據(jù)庫，數(shù)據(jù)分散在每一個節(jié)點(diǎn)上[8]，而采用列車號作為源數(shù)據(jù)表的主鍵會造成數(shù)據(jù)傾斜問題。因此，該平臺在數(shù)據(jù)分布策略上采用隨機(jī)分布方式。

3.2 大數(shù)據(jù)平臺關(guān)鍵性能指標(biāo)評估

基于Greenplum 的大數(shù)據(jù)平臺的建設(shè)目標(biāo)是必須滿足車載日志T+1 離線分析的要求，主要包括數(shù)據(jù)質(zhì)量和分析速度兩方面，數(shù)據(jù)質(zhì)量必須滿足報表展示的要求；分析速度要求必須滿足地鐵車輛運(yùn)營的時間特點(diǎn)。車載日志離線分析的工作時間可以分為兩個階段，第1 階段列車正常運(yùn)營回庫后到第2 天出車前，即每日晚上23：30—次日5：30，這個階段內(nèi)要完成從列車DLU 板卡到線網(wǎng)服務(wù)器的日志收集工作；第2 階段是列車出庫后到白班上班前，即次日5：30—次日9：00，這個階段為大數(shù)據(jù)平臺的工作時間，共計3.5 h，主要完成從線網(wǎng)服務(wù)器下載日志文件到統(tǒng)計報表生成。

大數(shù)據(jù)平臺對6 列車1 天的車載日志數(shù)據(jù)（約540 個日志文件，共239 MB）從數(shù)據(jù)下載→解析→入庫→清洗→查詢的整個數(shù)據(jù)鏈路的關(guān)鍵性能進(jìn)行了測試，具體測試結(jié)果分析如下。

（1）數(shù)據(jù)下載性能：由于大數(shù)據(jù)平臺與線網(wǎng)服務(wù)器之間采用千兆局域網(wǎng)連接，平均網(wǎng)速約為30 MB/s，通過FTP 傳輸工具完成車載日志測試數(shù)據(jù)下載，實際耗時約20 s，因此日志下載環(huán)節(jié)的耗時可以忽略不計。

（2）數(shù)據(jù)解析性能：大數(shù)據(jù)平臺跑單任務(wù)解析單個日志文件耗時大約35 s，即解析速度為170 條/s。為了縮短解析時間并充分利用平臺的計算資源，可在平臺上同時運(yùn)行40 個解析任務(wù)去解析日志文件，最終完成車載日志測試數(shù)據(jù)的解析實際耗時約為0.8 h。

（3）數(shù)據(jù)入庫性能：日志數(shù)據(jù)入庫采用的是GPSS，其原理是通過外部表的方式實現(xiàn)數(shù)據(jù)高并發(fā)加載到Greenplum 數(shù)據(jù)庫的ETL 工具。在大數(shù)據(jù)平臺上通過GPSS 方式入庫的實測速度約為2 500 條/s，完成車載日志測試數(shù)據(jù)解析入庫實際耗時約為1.8 h。由于數(shù)據(jù)解析的同時會進(jìn)行入庫，因此數(shù)據(jù)入庫總耗時包含了數(shù)據(jù)解析耗時。

（4）數(shù)據(jù)清洗性能：車載日志測試數(shù)據(jù)由原始日志表到中間日志表清洗耗時約為18 min，從中間日志表到統(tǒng)計結(jié)果表清洗耗時約為16 min。從原始日志表到統(tǒng)計結(jié)果表的清洗過程共耗時約為0.57 h。

（5）數(shù)據(jù)查詢性能：對原始日志表、中間日志表和統(tǒng)計結(jié)果表中數(shù)據(jù)量最大的表分別執(zhí)行相同操作的SQL 語句，記錄執(zhí)行時間，其測試結(jié)果，如表1 所示。從數(shù)據(jù)查詢耗時的結(jié)果來看，數(shù)據(jù)查詢階段的耗時可以忽略不計。

表1 大數(shù)據(jù)平臺數(shù)據(jù)查詢結(jié)果

綜上所述，車載日志從下載到報表生成的整個數(shù)據(jù)鏈路耗時等于數(shù)據(jù)入庫時間加上數(shù)據(jù)清洗時間，總共耗時約為2.37 h，小于大數(shù)據(jù)平臺實際要求的最大工作時長3.5 h。因此，本文所搭建的基于Greenplum 的大數(shù)據(jù)平臺完全符合車載日志T+1 離線分析的要求。

4 結(jié)束語

基于Greenplum 的車載日志大數(shù)據(jù)分析平臺具有良好的擴(kuò)展性和實用性，在實際生產(chǎn)部署時，可以根據(jù)日志分析需求增加Segment 節(jié)點(diǎn)數(shù)和硬盤容量，并考慮采用萬兆交換機(jī)和性能更高的處理器。該平臺為解決城市軌道交通信號系統(tǒng)的車載日志分析提供了一種解決方案，彌補(bǔ)了目前城軌信號系統(tǒng)在運(yùn)維管理方面的不足之處，是對今后城軌信號系統(tǒng)向智能化運(yùn)維發(fā)展的一次應(yīng)用探索。