面向鐵路客運(yùn)大數(shù)據(jù)的客流分析研究及應(yīng)用

羅明

（中國(guó)鐵路武漢局集團(tuán)有限公司信息技術(shù)所，湖北武漢 430071）

0 引言

信息技術(shù)在鐵路運(yùn)輸生產(chǎn)、經(jīng)營(yíng)管理和客戶服務(wù)等領(lǐng)域廣泛應(yīng)用，系統(tǒng)規(guī)模越來(lái)越大，承載的關(guān)鍵業(yè)務(wù)越來(lái)越多［1］。從客運(yùn)角度看，海量的客運(yùn)數(shù)據(jù)存儲(chǔ)在關(guān)鍵系統(tǒng)中，而關(guān)鍵系統(tǒng)的數(shù)據(jù)大多采用小型機(jī)上安裝大型商用數(shù)據(jù)庫(kù)的方式存儲(chǔ)，當(dāng)前數(shù)據(jù)庫(kù)在面對(duì)海量數(shù)據(jù)場(chǎng)景下，對(duì)吞吐量、可擴(kuò)展性和可用性等關(guān)鍵特征提出更高要求。如何利用虛擬化和分布式等技術(shù)提升大數(shù)據(jù)的存儲(chǔ)速率和分析能力，以解決傳統(tǒng)數(shù)據(jù)庫(kù)的性能瓶頸、昂貴的產(chǎn)品價(jià)格和售后服務(wù)、擴(kuò)展性有限等問(wèn)題［2］，是相關(guān)部門(mén)面臨的重要課題。在此，從鐵路客運(yùn)業(yè)務(wù)產(chǎn)生的海量數(shù)據(jù)入手，研究如何從客運(yùn)大數(shù)據(jù)中深度挖掘客流數(shù)據(jù)主要指標(biāo)，提出構(gòu)建分布式客運(yùn)數(shù)據(jù)存儲(chǔ)平臺(tái)的方案，并利用該平臺(tái)建立數(shù)據(jù)的多維度關(guān)聯(lián)，實(shí)時(shí)分析中國(guó)鐵路武漢局集團(tuán)有限公司（簡(jiǎn)稱武漢局集團(tuán)公司）和九大方向的客座率、列車密度表等指標(biāo)，為客流預(yù)測(cè)提供依據(jù)。

1 鐵路信息系統(tǒng)數(shù)據(jù)庫(kù)現(xiàn)狀分析

在鐵路行業(yè)，其核心的關(guān)鍵信息系統(tǒng)數(shù)據(jù)庫(kù)解決方案大多采用小型機(jī)上安裝大型商用數(shù)據(jù)庫(kù)的方式，例如客票系統(tǒng)采用Sybase 數(shù)據(jù)庫(kù)，調(diào)度管理系統(tǒng)采用Oracle數(shù)據(jù)庫(kù)。武漢局集團(tuán)公司為了更高效、更穩(wěn)定地管理信息系統(tǒng)，將重要信息系統(tǒng)數(shù)據(jù)庫(kù)整合并集中管理，例如確報(bào)、車號(hào)和18 點(diǎn)統(tǒng)計(jì)等系統(tǒng)會(huì)共有1 套小型機(jī)加Oracle數(shù)據(jù)庫(kù)。目前這些關(guān)鍵信息系統(tǒng)采用中間件+數(shù)據(jù)庫(kù)的傳統(tǒng)“煙囪式”架構(gòu)，隨著數(shù)據(jù)量的猛增，其響應(yīng)速度和可靠性下降，在業(yè)務(wù)應(yīng)用時(shí)存在多種問(wèn)題［3］。有些系統(tǒng)為了提高響應(yīng)時(shí)速，將歷史數(shù)據(jù)刪除或轉(zhuǎn)存到其他位置，造成數(shù)據(jù)丟失。數(shù)據(jù)是信息化的核心，上述做法既對(duì)本系統(tǒng)日后數(shù)據(jù)分析造成困難，也給數(shù)據(jù)間的共享和融合帶來(lái)困難。

對(duì)比其他行業(yè)，例如銀行業(yè)，已經(jīng)開(kāi)始探索微服務(wù)和分布式技術(shù)架構(gòu)。微服務(wù)體系的拆分對(duì)數(shù)據(jù)庫(kù)存儲(chǔ)提出了極大挑戰(zhàn)，如果還使用傳統(tǒng)數(shù)據(jù)庫(kù)，其存儲(chǔ)與計(jì)算能力均會(huì)因?yàn)槲⒎?wù)容器數(shù)量的上升而受到較大影響［4］。因此，無(wú)論是從單個(gè)信息系統(tǒng)的發(fā)展還是構(gòu)建數(shù)據(jù)中心，分布式的數(shù)據(jù)庫(kù)架構(gòu)都是發(fā)展方向，鐵路行業(yè)也必將會(huì)經(jīng)歷從傳統(tǒng)數(shù)據(jù)庫(kù)向分布式數(shù)據(jù)庫(kù)轉(zhuǎn)型的過(guò)程。

2 鐵路客運(yùn)數(shù)據(jù)現(xiàn)狀分析

2.1 客運(yùn)相關(guān)信息系統(tǒng)

客運(yùn)數(shù)據(jù)存在于多個(gè)業(yè)務(wù)系統(tǒng)，每個(gè)系統(tǒng)的存儲(chǔ)方式、側(cè)重角度及基礎(chǔ)字典均不同，其中客運(yùn)營(yíng)銷庫(kù)的數(shù)據(jù)內(nèi)容最全，客運(yùn)精密統(tǒng)計(jì)數(shù)據(jù)最為準(zhǔn)確，財(cái)務(wù)部門(mén)使用的運(yùn)營(yíng)成本核算數(shù)據(jù)也是客運(yùn)分析重要組成部分。

在客運(yùn)營(yíng)銷庫(kù)中，客票數(shù)據(jù)種類多、涵蓋范圍廣，可以查詢或計(jì)算得到列車的全車次、始發(fā)站車次、定員等信息，但是列車售票信息不全，不含退票和車補(bǔ)信息，所以票價(jià)收入和發(fā)送人均有一定誤差。

計(jì)劃統(tǒng)計(jì)部（簡(jiǎn)稱計(jì)統(tǒng)部）有列車票價(jià)收入的精密數(shù)據(jù)，包含退票和車補(bǔ)信息。與計(jì)統(tǒng)部交接可獲取列車售票的精密數(shù)據(jù)，包含詳細(xì)售票記錄表和站名字典表。但在售票記錄表中，存儲(chǔ)的是列車票面車次，沒(méi)有與全車次或者始發(fā)車次進(jìn)行關(guān)聯(lián)，而且站名字典和營(yíng)銷庫(kù)中也不盡相同。

列車成本數(shù)據(jù)則需從財(cái)務(wù)部獲取，列車成本由中國(guó)國(guó)家鐵路集團(tuán)有限公司按月分類別清算到鐵路局集團(tuán)公司，每趟車還需要對(duì)所有成本進(jìn)行合并計(jì)算，財(cái)務(wù)部按月提供指定列車本月成本數(shù)據(jù)。

2.2 客運(yùn)多業(yè)務(wù)系統(tǒng)數(shù)據(jù)關(guān)聯(lián)

針對(duì)上述3個(gè)數(shù)據(jù)來(lái)源，首先在營(yíng)銷庫(kù)中獲取列車的詳細(xì)基礎(chǔ)信息，使用存儲(chǔ)過(guò)程分析計(jì)統(tǒng)部的精密數(shù)據(jù)，將票面車次與全車次、始發(fā)站車次建立起關(guān)聯(lián)。對(duì)于列車成本數(shù)據(jù)，同樣適用存儲(chǔ)過(guò)程，將按月的列車成本按照始發(fā)站車次匹配到每日開(kāi)行的趟車上，將3種數(shù)據(jù)有效關(guān)聯(lián)后實(shí)現(xiàn)任意時(shí)間段內(nèi)列車開(kāi)行收入分析?？瓦\(yùn)多業(yè)務(wù)系統(tǒng)的數(shù)據(jù)關(guān)聯(lián)，可打通客票數(shù)據(jù)間的壁壘。

2.3 傳統(tǒng)數(shù)據(jù)庫(kù)存儲(chǔ)問(wèn)題

營(yíng)銷庫(kù)中的日常列車開(kāi)行數(shù)據(jù)表均為標(biāo)準(zhǔn)的結(jié)構(gòu)化數(shù)據(jù)，使用Oracle進(jìn)行存儲(chǔ)。但該表數(shù)據(jù)量龐大，售票信息從2017年6月開(kāi)始，數(shù)據(jù)量就達(dá)到2億多條，存在查詢速度慢、可靠性不高等問(wèn)題。針對(duì)此問(wèn)題，使用Oracle分區(qū)表技術(shù)，將數(shù)據(jù)按時(shí)間自動(dòng)分區(qū)，同時(shí)建立分區(qū)索引，數(shù)據(jù)的查詢性能提高了20倍以上。

計(jì)統(tǒng)部的精密數(shù)據(jù)使用txt 文檔進(jìn)行接口，通過(guò)專門(mén)安全的FTP 服務(wù)器傳遞。采用Sql Loader 技術(shù)將該數(shù)據(jù)加載到Oracle 數(shù)據(jù)庫(kù)中，一次可對(duì)多個(gè)表進(jìn)行裝入，而且提供了加載日志，便于分析。輔助技術(shù)為Windows腳本工具和Windows的定時(shí)任務(wù)。

財(cái)務(wù)部的成本數(shù)據(jù)使用excel 進(jìn)行傳遞，數(shù)據(jù)量較小，且交互頻率較低，使用手工導(dǎo)入方式。

可以看出，在面對(duì)大數(shù)據(jù)量的統(tǒng)計(jì)分析計(jì)算時(shí)，傳統(tǒng)數(shù)據(jù)庫(kù)可以利用分區(qū)表、索引等方式提高查詢效率，但仍存在查詢速度慢、對(duì)復(fù)雜查詢處理需提前計(jì)算等問(wèn)題，同時(shí)在硬件投入方面，將數(shù)據(jù)存儲(chǔ)在小型機(jī)上，如果想進(jìn)一步提高計(jì)算性能已不太可能，或者代價(jià)非常高。如果存儲(chǔ)時(shí)間超過(guò)5年，在數(shù)據(jù)統(tǒng)計(jì)分析時(shí)，基本就無(wú)法進(jìn)行實(shí)時(shí)分析了。

在進(jìn)行客運(yùn)大數(shù)據(jù)分析項(xiàng)目時(shí)，采用傳統(tǒng)數(shù)據(jù)庫(kù)，遇到爆發(fā)的海量請(qǐng)求時(shí)系統(tǒng)不能迅速響應(yīng)，例如節(jié)假日旅客按客流方向按車次實(shí)時(shí)分析等。另外，設(shè)備采購(gòu)和運(yùn)維成本高昂，小型機(jī)設(shè)備與中間件分別采購(gòu)、運(yùn)維分開(kāi)，導(dǎo)致整體費(fèi)用高。因此在進(jìn)行大數(shù)據(jù)分析等項(xiàng)目時(shí)，應(yīng)逐步將數(shù)據(jù)庫(kù)從傳統(tǒng)Oracle數(shù)據(jù)庫(kù)向分布式數(shù)據(jù)庫(kù)進(jìn)行轉(zhuǎn)型。

3 構(gòu)建分布式客運(yùn)數(shù)據(jù)存儲(chǔ)平臺(tái)

分布式數(shù)據(jù)庫(kù)不同于小型機(jī)架構(gòu)體系，是基于X86服務(wù)器為底層架構(gòu)設(shè)計(jì)的，系統(tǒng)在設(shè)計(jì)時(shí)充分考慮高可用、分布式、容災(zāi)等問(wèn)題?；赬86 的服務(wù)器集群，隨著數(shù)據(jù)量的增加可以實(shí)現(xiàn)無(wú)縫擴(kuò)容，擁有強(qiáng)大的擴(kuò)展能力［5］。構(gòu)建分布式客運(yùn)數(shù)據(jù)存儲(chǔ)平臺(tái)，重點(diǎn)解決如何使用虛擬化平臺(tái)合理規(guī)劃資源，降低硬件開(kāi)銷，提高數(shù)據(jù)庫(kù)利用率和數(shù)據(jù)存儲(chǔ)速率：一是利用既有設(shè)備構(gòu)建基于X86服務(wù)器的虛擬化平臺(tái)；二是安裝Greenplum 數(shù)據(jù)庫(kù)（DB），完成分布式數(shù)據(jù)庫(kù)安裝；三是將核心系統(tǒng)Oracle數(shù)據(jù)遷移至Greenplum DB，建立數(shù)據(jù)清洗規(guī)則，定時(shí)導(dǎo)入；四是通過(guò)數(shù)據(jù)鉆取將粗粒度數(shù)據(jù)向細(xì)粒度數(shù)據(jù)轉(zhuǎn)換，數(shù)據(jù)在維度的不同層次間變化，從上層降到下一層，將匯總數(shù)據(jù)拆分到更細(xì)節(jié)的數(shù)據(jù)，加快查詢與存儲(chǔ)速率。

3.1 構(gòu)建基于Vmware的虛擬化平臺(tái)

在安裝Vmware 虛擬化平臺(tái)前，先準(zhǔn)備硬件環(huán)境。利用機(jī)房閑置的4臺(tái)惠普DL580 G7服務(wù)器，2臺(tái)萬(wàn)兆交換機(jī)，每臺(tái)服務(wù)器增加1 塊960 GB SSD 固態(tài)硬盤(pán)作為數(shù)據(jù)緩存，每臺(tái)服務(wù)器配6塊2 TB HDD硬盤(pán)做數(shù)據(jù)盤(pán)，配1 塊600 GB HDD 硬盤(pán)做系統(tǒng)盤(pán)，每臺(tái)服務(wù)器增加2個(gè)光纖通道HBA卡，滿足搭建環(huán)境需要。

Vmware 的虛擬化平臺(tái)采用Vmware vSphere+vSAN的解決方案。首先利用vSAN 軟件對(duì)存儲(chǔ)進(jìn)行分布式處理，在vSphere 集群主機(jī)中構(gòu)建vSAN 存儲(chǔ)層，同時(shí)存儲(chǔ)通過(guò)vSAN 進(jìn)行管理。再利用vSphere 搭建虛擬化平臺(tái)，可以最大程度地利用服務(wù)器的資源，降低數(shù)據(jù)中心的硬件成本。平臺(tái)搭建完成后可通過(guò)管理軟件進(jìn)行配置管理（見(jiàn)圖1）。

圖1 Vmware虛擬化平臺(tái)管理界面

3.2 搭建分布式數(shù)據(jù)庫(kù)

在分布式數(shù)據(jù)庫(kù)的選型上，項(xiàng)目組在最早階段也搭建了1 套Hadoop 數(shù)據(jù)存儲(chǔ)系統(tǒng)，Hadoop 是一個(gè)生態(tài)系統(tǒng)，泛指使用這種基礎(chǔ)平臺(tái)進(jìn)行分布式計(jì)算和海量數(shù)據(jù)分析處理的一組項(xiàng)目［6］。但因需要接入的信息系統(tǒng)全部是結(jié)構(gòu)化數(shù)據(jù)，導(dǎo)入到Hadoop 系統(tǒng)中實(shí)際計(jì)算效率還不及Oracle數(shù)據(jù)庫(kù)，盡管它也能很方便地?cái)U(kuò)展計(jì)算單元和存儲(chǔ)單元。經(jīng)過(guò)討論和對(duì)比，最終選擇了大規(guī)模并行處理（MPP）數(shù)據(jù)庫(kù)，考慮到開(kāi)源和易用性等多方面因素，并參考了阿里巴巴使用Greenplum 替換之前Oracle RAC 的成功經(jīng)驗(yàn)，選擇Greenplum DB 作為分布式數(shù)據(jù)庫(kù)的技術(shù)選型。

MPP 數(shù)據(jù)庫(kù)本質(zhì)上依然是一個(gè)關(guān)系型數(shù)據(jù)庫(kù)，其原理是將任務(wù)并行地分散到多個(gè)工作節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)的磁盤(pán)存儲(chǔ)系統(tǒng)和內(nèi)存系統(tǒng)均不與其他節(jié)點(diǎn)共享，屬于Share-Nothing 模式［7］，而Oracle RAC 數(shù) 據(jù) 庫(kù)屬 于Share-Everything 模式。Greenplum 是一種基于PostgreSQL 的分布式數(shù)據(jù)庫(kù)，采用Share-Nothing 模式，其中主機(jī)、操作系統(tǒng)、存儲(chǔ)、內(nèi)存都是屬于獨(dú)占模式，不存在共享。Greenplum 屬于關(guān)系型數(shù)據(jù)庫(kù)集群方式，由多個(gè)獨(dú)立的數(shù)據(jù)庫(kù)服務(wù)組合而成，因?yàn)槠浠赬86服務(wù)器，所以價(jià)格低廉，在開(kāi)放平臺(tái)的同時(shí)，可提供強(qiáng)大的海量數(shù)據(jù)處理能力和并行數(shù)據(jù)計(jì)算能力。MPP數(shù)據(jù)庫(kù)主要是為了解決大問(wèn)題而提出的并行計(jì)算，而不是對(duì)高并發(fā)的請(qǐng)求。其特點(diǎn)總結(jié)如下：（1）支持海量數(shù)據(jù)存儲(chǔ)和計(jì)算；（2） 支持主流的SQL 語(yǔ)法；（3）有方便的維護(hù)工具，學(xué)習(xí)方便；（4）擴(kuò)展性好，提供分布式事務(wù)處理能力。

在搭建好的虛擬化平臺(tái)上安裝10 臺(tái)虛擬機(jī)，安裝Red Hat Linux 操作系統(tǒng)，每5 臺(tái)虛擬機(jī)搭建1 個(gè)Greenplum 集群，共建立2 個(gè)Greenplum 集群。其中1 個(gè)集群對(duì)應(yīng)IP 地 址10.102.5.195-199，其中10.102.5.195 為Master 主機(jī)，剩余4 個(gè)為Segment 主機(jī)。通過(guò)PgAdmin對(duì)Greenplum 數(shù)據(jù)庫(kù)進(jìn)行訪問(wèn)，PgAdmin 管理界面見(jiàn)圖2。

圖2 PgAdmin管理界面

3.3 數(shù)據(jù)遷移與清洗

在安裝完Greenplum 后，需要將以前存儲(chǔ)在Oracle的數(shù)據(jù)存儲(chǔ)在Greenplum 數(shù)據(jù)庫(kù)中。對(duì)數(shù)據(jù)管理所采取的方案為：從生產(chǎn)系統(tǒng)、消息隊(duì)列（MQ）報(bào)文或文件傳輸協(xié)議（FTP）文件中提取的數(shù)據(jù)先存儲(chǔ)在Oracle 數(shù)據(jù)庫(kù)中，Oracle存儲(chǔ)近期和未來(lái)時(shí)間的數(shù)據(jù)，近期的時(shí)間段根據(jù)各業(yè)務(wù)系統(tǒng)產(chǎn)生數(shù)據(jù)量的大小決定，Greenplum 數(shù)據(jù)庫(kù)定義為存儲(chǔ)歷史和分析后數(shù)據(jù)，增加入庫(kù)時(shí)間戳，保證數(shù)據(jù)的回溯性。

Greenplum 數(shù)據(jù)加載主要包括insert、copy、外部表、gpload、web external table 等5 種方式。其中insert和copy 是串行，外部表gpfdist 和gpload 工具是并行方式。

（1）Insert 這種加載方式和其他數(shù)據(jù)庫(kù)SQL 語(yǔ)法一樣，但是效率最差，只適合加載極少數(shù)數(shù)據(jù)，需要通過(guò)master 節(jié)點(diǎn)操作。Copy 方式比SQL 方式效率大大提升，但是數(shù)據(jù)依然需要通過(guò)master節(jié)點(diǎn)，無(wú)法實(shí)現(xiàn)并發(fā)高效數(shù)據(jù)加載。

（2）為了提高數(shù)據(jù)導(dǎo)入效率，Greenplum 引入外部表。外部表基于gpfdist 工具（類似于Oracle 的sqlldr 工具），其最突出的優(yōu)勢(shì)是支持?jǐn)?shù)據(jù)并發(fā)加載。所謂外部表，就是在數(shù)據(jù)庫(kù)中只有表定義、沒(méi)有數(shù)據(jù)，數(shù)據(jù)都存放在數(shù)據(jù)庫(kù)之外的數(shù)據(jù)文件。Greenplum 利用外部表執(zhí)行正常的增刪改操作，而外部表支持在節(jié)點(diǎn)上并發(fā)執(zhí)行g(shù)pfdist 的導(dǎo)入程序。外部表需要指定gpfdist 的IP和端口，還要有詳細(xì)的目錄地址，文件名支持通配符匹配，可以編寫(xiě)多個(gè)gpfdist 地址，但是總數(shù)不能超過(guò)總的segment 數(shù)量，否則會(huì)報(bào)錯(cuò)，因此Greenplum 執(zhí)行效率高。

（3）gpload是Greenplum使用可讀外部表和GP并行文件服務(wù)gpfdist裝載數(shù)據(jù)的1個(gè)命令包裝，其允許通過(guò)使用配置文件的方式設(shè)置數(shù)據(jù)格式等來(lái)創(chuàng)建外部表定義。通過(guò)按照YAML 格式定義的裝載說(shuō)明配置文件，然后執(zhí)行insert、update、merger操作，將數(shù)據(jù)裝載到目標(biāo)數(shù)據(jù)庫(kù)表中。

項(xiàng)目組使用gpload方式成功上傳pt_history的1個(gè)月數(shù)據(jù)（1300萬(wàn)行記錄），下載30 s左右，上傳120 s。

3.4 數(shù)據(jù)鉆取

客票系統(tǒng)的售票信息在不斷地發(fā)生變化，更新頻率非常高，對(duì)數(shù)據(jù)庫(kù)的更新也會(huì)非常頻繁，而客票系統(tǒng)的歷史售票記錄則不會(huì)再發(fā)生變化，更新基本上不會(huì)發(fā)生，數(shù)據(jù)操作需求很低。面對(duì)這種情況，采用實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)分開(kāi)處理，當(dāng)天及以后的客票數(shù)據(jù)存儲(chǔ)在實(shí)時(shí)表中，昨天及以前的客票數(shù)據(jù)存儲(chǔ)在歷史表中。實(shí)時(shí)表的數(shù)據(jù)量基本上是固定的（最多30 d），并且不受歷史數(shù)據(jù)的影響，可以進(jìn)行快速的增刪改查等操作。歷史表的數(shù)據(jù)量非常大（目前存儲(chǔ)了3年），并且會(huì)不斷累積，利用分布式數(shù)據(jù)庫(kù)可進(jìn)行快速查詢、統(tǒng)計(jì)。在歷史數(shù)據(jù)分析中，通過(guò)數(shù)據(jù)鉆取將粗粒度數(shù)據(jù)向細(xì)粒度數(shù)據(jù)轉(zhuǎn)換，數(shù)據(jù)在維度的不同層次間變化，從上層降到下一層，將匯總數(shù)據(jù)拆分到更細(xì)節(jié)的數(shù)據(jù)，以加快查詢與存儲(chǔ)速率。將售票信息通過(guò)車次、方向、線路、客座率等多個(gè)維度進(jìn)行分析并存儲(chǔ)，每個(gè)統(tǒng)計(jì)分析的結(jié)果都會(huì)加上時(shí)間戳，為之后的客流分析和預(yù)測(cè)打好基礎(chǔ)。

4 客流分析研究及應(yīng)用

在分布式客運(yùn)數(shù)據(jù)存儲(chǔ)平臺(tái)上開(kāi)展客運(yùn)數(shù)據(jù)分析研究，可實(shí)現(xiàn)數(shù)據(jù)的展示、查詢功能以及節(jié)假日客流情況分析，客流分析系統(tǒng)界面見(jiàn)圖3。在終端展示方面，可同時(shí)采用大屏顯示和電腦版分析2種形式。按照車次、列車交路、發(fā)行方向等方面進(jìn)行客座率統(tǒng)計(jì)、分析，形成一定的決策分析結(jié)果，為客車的加開(kāi)、加掛、縮編等工作提供信息支持；通過(guò)對(duì)清明節(jié)、勞動(dòng)節(jié)、暑期、端午節(jié)、中秋節(jié)、國(guó)慶和元旦等節(jié)假日的客流進(jìn)行統(tǒng)計(jì)、分析，以大屏形式展示武漢局集團(tuán)公司的客流情況；通過(guò)掌握集團(tuán)公司、車務(wù)段、車站在各時(shí)間段的發(fā)送和到達(dá)信息，為客運(yùn)高峰期的預(yù)警提供信息支持；通過(guò)掌握集團(tuán)公司發(fā)往各省的客流情況和從各省到達(dá)集團(tuán)公司的客流情況，進(jìn)一步了解旅客的出行方向，為客運(yùn)方向的規(guī)劃提供信息支持［8］。其主要分析指標(biāo)和功能如下：

（1）列車密度表：對(duì)列車的上車、下車、車內(nèi)人數(shù)做到精確掌握，為調(diào)整席位的預(yù)售區(qū)間提供信息支持。

（2）列車客座率：對(duì)列車的定員、里程、編組做到精確掌握。

（3）列車正晚點(diǎn)：對(duì)列車的正晚點(diǎn)情況可全面掌握。

（4）九大方向的客座率：對(duì)武廣、漢宜、漢十等重點(diǎn)線路進(jìn)行分析，挖掘出上座率高和上座率低的車次，為客運(yùn)運(yùn)營(yíng)提供信息支持，例如：如果后面的區(qū)間客座率低，是否應(yīng)提前返程。

（5）擔(dān)當(dāng)交路客座率：挖掘出客座率高的交路，分析是否重聯(lián)以進(jìn)一步提高客運(yùn)能力；挖掘出客座率低的交路，分析是否用單組的方式，以減小客運(yùn)成本。

（6）車站發(fā)送、到達(dá)預(yù)警：對(duì)車站的發(fā)送、到達(dá)情況，按照時(shí)段、車次進(jìn)行預(yù)警，武漢站已初步實(shí)現(xiàn)了站臺(tái)預(yù)警。

（7）集團(tuán)公司發(fā)送、到達(dá)分析：各省之間的客流情況、每日發(fā)送人統(tǒng)計(jì)、擔(dān)當(dāng)列車的對(duì)數(shù)。

（8）客流預(yù)測(cè)：根據(jù)歷史數(shù)據(jù)，采用ARIMA 乘積季節(jié)模型對(duì)節(jié)假日的客流進(jìn)行預(yù)測(cè)。

（9）實(shí)現(xiàn)部分大屏展示：駕駛艙界面匯總客運(yùn)的關(guān)鍵數(shù)據(jù)，已在調(diào)度所大屏進(jìn)行展示；大屏輪播界面可展示客運(yùn)的重要指標(biāo)，已在客運(yùn)部的大屏進(jìn)行展示。

圖3 客流分析系統(tǒng)界面

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

面對(duì)海量客運(yùn)數(shù)據(jù)，找到與客流相關(guān)的關(guān)鍵指標(biāo)，形成一定的決策分析結(jié)果，用于指導(dǎo)客運(yùn)組織是本項(xiàng)目研究的初衷。通過(guò)構(gòu)建分布式數(shù)據(jù)存儲(chǔ)平臺(tái)，實(shí)現(xiàn)了在有限硬件條件下大數(shù)據(jù)量的實(shí)時(shí)分析，為數(shù)據(jù)的預(yù)測(cè)提供基本計(jì)算來(lái)源［9］。利用大數(shù)據(jù)技術(shù)，在客流數(shù)據(jù)分析和挖掘方面進(jìn)行研究，通過(guò)數(shù)據(jù)鉆取將粗粒度數(shù)據(jù)向細(xì)粒度數(shù)據(jù)轉(zhuǎn)換，數(shù)據(jù)在多個(gè)維度上進(jìn)行分析和存儲(chǔ)，并在此基礎(chǔ)上研究客流相關(guān)的9 類關(guān)鍵指標(biāo)［10-11］。隨著歷史數(shù)據(jù)的增長(zhǎng)和系統(tǒng)功能的增加，尚有許多內(nèi)容需要研究。目前該平臺(tái)系統(tǒng)還處于驗(yàn)證和完善階段，分布式數(shù)據(jù)存儲(chǔ)平臺(tái)的穩(wěn)定性也需進(jìn)一步驗(yàn)證。