羅明
(中國鐵路武漢局集團有限公司信息技術所,湖北武漢 430071)
信息技術在鐵路運輸生產、經營管理和客戶服務等領域廣泛應用,系統(tǒng)規(guī)模越來越大,承載的關鍵業(yè)務越來越多[1]。從客運角度看,海量的客運數(shù)據(jù)存儲在關鍵系統(tǒng)中,而關鍵系統(tǒng)的數(shù)據(jù)大多采用小型機上安裝大型商用數(shù)據(jù)庫的方式存儲,當前數(shù)據(jù)庫在面對海量數(shù)據(jù)場景下,對吞吐量、可擴展性和可用性等關鍵特征提出更高要求。如何利用虛擬化和分布式等技術提升大數(shù)據(jù)的存儲速率和分析能力,以解決傳統(tǒng)數(shù)據(jù)庫的性能瓶頸、昂貴的產品價格和售后服務、擴展性有限等問題[2],是相關部門面臨的重要課題。在此,從鐵路客運業(yè)務產生的海量數(shù)據(jù)入手,研究如何從客運大數(shù)據(jù)中深度挖掘客流數(shù)據(jù)主要指標,提出構建分布式客運數(shù)據(jù)存儲平臺的方案,并利用該平臺建立數(shù)據(jù)的多維度關聯(lián),實時分析中國鐵路武漢局集團有限公司(簡稱武漢局集團公司)和九大方向的客座率、列車密度表等指標,為客流預測提供依據(jù)。
在鐵路行業(yè),其核心的關鍵信息系統(tǒng)數(shù)據(jù)庫解決方案大多采用小型機上安裝大型商用數(shù)據(jù)庫的方式,例如客票系統(tǒng)采用Sybase 數(shù)據(jù)庫,調度管理系統(tǒng)采用Oracle數(shù)據(jù)庫。武漢局集團公司為了更高效、更穩(wěn)定地管理信息系統(tǒng),將重要信息系統(tǒng)數(shù)據(jù)庫整合并集中管理,例如確報、車號和18 點統(tǒng)計等系統(tǒng)會共有1 套小型機加Oracle數(shù)據(jù)庫。目前這些關鍵信息系統(tǒng)采用中間件+數(shù)據(jù)庫的傳統(tǒng)“煙囪式”架構,隨著數(shù)據(jù)量的猛增,其響應速度和可靠性下降,在業(yè)務應用時存在多種問題[3]。有些系統(tǒng)為了提高響應時速,將歷史數(shù)據(jù)刪除或轉存到其他位置,造成數(shù)據(jù)丟失。數(shù)據(jù)是信息化的核心,上述做法既對本系統(tǒng)日后數(shù)據(jù)分析造成困難,也給數(shù)據(jù)間的共享和融合帶來困難。
對比其他行業(yè),例如銀行業(yè),已經開始探索微服務和分布式技術架構。微服務體系的拆分對數(shù)據(jù)庫存儲提出了極大挑戰(zhàn),如果還使用傳統(tǒng)數(shù)據(jù)庫,其存儲與計算能力均會因為微服務容器數(shù)量的上升而受到較大影響[4]。因此,無論是從單個信息系統(tǒng)的發(fā)展還是構建數(shù)據(jù)中心,分布式的數(shù)據(jù)庫架構都是發(fā)展方向,鐵路行業(yè)也必將會經歷從傳統(tǒng)數(shù)據(jù)庫向分布式數(shù)據(jù)庫轉型的過程。
客運數(shù)據(jù)存在于多個業(yè)務系統(tǒng),每個系統(tǒng)的存儲方式、側重角度及基礎字典均不同,其中客運營銷庫的數(shù)據(jù)內容最全,客運精密統(tǒng)計數(shù)據(jù)最為準確,財務部門使用的運營成本核算數(shù)據(jù)也是客運分析重要組成部分。
在客運營銷庫中,客票數(shù)據(jù)種類多、涵蓋范圍廣,可以查詢或計算得到列車的全車次、始發(fā)站車次、定員等信息,但是列車售票信息不全,不含退票和車補信息,所以票價收入和發(fā)送人均有一定誤差。
計劃統(tǒng)計部(簡稱計統(tǒng)部)有列車票價收入的精密數(shù)據(jù),包含退票和車補信息。與計統(tǒng)部交接可獲取列車售票的精密數(shù)據(jù),包含詳細售票記錄表和站名字典表。但在售票記錄表中,存儲的是列車票面車次,沒有與全車次或者始發(fā)車次進行關聯(lián),而且站名字典和營銷庫中也不盡相同。
列車成本數(shù)據(jù)則需從財務部獲取,列車成本由中國國家鐵路集團有限公司按月分類別清算到鐵路局集團公司,每趟車還需要對所有成本進行合并計算,財務部按月提供指定列車本月成本數(shù)據(jù)。
針對上述3個數(shù)據(jù)來源,首先在營銷庫中獲取列車的詳細基礎信息,使用存儲過程分析計統(tǒng)部的精密數(shù)據(jù),將票面車次與全車次、始發(fā)站車次建立起關聯(lián)。對于列車成本數(shù)據(jù),同樣適用存儲過程,將按月的列車成本按照始發(fā)站車次匹配到每日開行的趟車上,將3種數(shù)據(jù)有效關聯(lián)后實現(xiàn)任意時間段內列車開行收入分析??瓦\多業(yè)務系統(tǒng)的數(shù)據(jù)關聯(lián),可打通客票數(shù)據(jù)間的壁壘。
營銷庫中的日常列車開行數(shù)據(jù)表均為標準的結構化數(shù)據(jù),使用Oracle進行存儲。但該表數(shù)據(jù)量龐大,售票信息從2017年6月開始,數(shù)據(jù)量就達到2億多條,存在查詢速度慢、可靠性不高等問題。針對此問題,使用Oracle分區(qū)表技術,將數(shù)據(jù)按時間自動分區(qū),同時建立分區(qū)索引,數(shù)據(jù)的查詢性能提高了20倍以上。
計統(tǒng)部的精密數(shù)據(jù)使用txt 文檔進行接口,通過專門安全的FTP 服務器傳遞。采用Sql Loader 技術將該數(shù)據(jù)加載到Oracle 數(shù)據(jù)庫中,一次可對多個表進行裝入,而且提供了加載日志,便于分析。輔助技術為Windows腳本工具和Windows的定時任務。
財務部的成本數(shù)據(jù)使用excel 進行傳遞,數(shù)據(jù)量較小,且交互頻率較低,使用手工導入方式。
可以看出,在面對大數(shù)據(jù)量的統(tǒng)計分析計算時,傳統(tǒng)數(shù)據(jù)庫可以利用分區(qū)表、索引等方式提高查詢效率,但仍存在查詢速度慢、對復雜查詢處理需提前計算等問題,同時在硬件投入方面,將數(shù)據(jù)存儲在小型機上,如果想進一步提高計算性能已不太可能,或者代價非常高。如果存儲時間超過5年,在數(shù)據(jù)統(tǒng)計分析時,基本就無法進行實時分析了。
在進行客運大數(shù)據(jù)分析項目時,采用傳統(tǒng)數(shù)據(jù)庫,遇到爆發(fā)的海量請求時系統(tǒng)不能迅速響應,例如節(jié)假日旅客按客流方向按車次實時分析等。另外,設備采購和運維成本高昂,小型機設備與中間件分別采購、運維分開,導致整體費用高。因此在進行大數(shù)據(jù)分析等項目時,應逐步將數(shù)據(jù)庫從傳統(tǒng)Oracle數(shù)據(jù)庫向分布式數(shù)據(jù)庫進行轉型。
分布式數(shù)據(jù)庫不同于小型機架構體系,是基于X86服務器為底層架構設計的,系統(tǒng)在設計時充分考慮高可用、分布式、容災等問題?;赬86 的服務器集群,隨著數(shù)據(jù)量的增加可以實現(xiàn)無縫擴容,擁有強大的擴展能力[5]。構建分布式客運數(shù)據(jù)存儲平臺,重點解決如何使用虛擬化平臺合理規(guī)劃資源,降低硬件開銷,提高數(shù)據(jù)庫利用率和數(shù)據(jù)存儲速率:一是利用既有設備構建基于X86服務器的虛擬化平臺;二是安裝Greenplum 數(shù)據(jù)庫(DB),完成分布式數(shù)據(jù)庫安裝;三是將核心系統(tǒng)Oracle數(shù)據(jù)遷移至Greenplum DB,建立數(shù)據(jù)清洗規(guī)則,定時導入;四是通過數(shù)據(jù)鉆取將粗粒度數(shù)據(jù)向細粒度數(shù)據(jù)轉換,數(shù)據(jù)在維度的不同層次間變化,從上層降到下一層,將匯總數(shù)據(jù)拆分到更細節(jié)的數(shù)據(jù),加快查詢與存儲速率。
在安裝Vmware 虛擬化平臺前,先準備硬件環(huán)境。利用機房閑置的4臺惠普DL580 G7服務器,2臺萬兆交換機,每臺服務器增加1 塊960 GB SSD 固態(tài)硬盤作為數(shù)據(jù)緩存,每臺服務器配6塊2 TB HDD硬盤做數(shù)據(jù)盤,配1 塊600 GB HDD 硬盤做系統(tǒng)盤,每臺服務器增加2個光纖通道HBA卡,滿足搭建環(huán)境需要。
Vmware 的虛擬化平臺采用Vmware vSphere+vSAN的解決方案。首先利用vSAN 軟件對存儲進行分布式處理,在vSphere 集群主機中構建vSAN 存儲層,同時存儲通過vSAN 進行管理。再利用vSphere 搭建虛擬化平臺,可以最大程度地利用服務器的資源,降低數(shù)據(jù)中心的硬件成本。平臺搭建完成后可通過管理軟件進行配置管理(見圖1)。
圖1 Vmware虛擬化平臺管理界面
在分布式數(shù)據(jù)庫的選型上,項目組在最早階段也搭建了1 套Hadoop 數(shù)據(jù)存儲系統(tǒng),Hadoop 是一個生態(tài)系統(tǒng),泛指使用這種基礎平臺進行分布式計算和海量數(shù)據(jù)分析處理的一組項目[6]。但因需要接入的信息系統(tǒng)全部是結構化數(shù)據(jù),導入到Hadoop 系統(tǒng)中實際計算效率還不及Oracle數(shù)據(jù)庫,盡管它也能很方便地擴展計算單元和存儲單元。經過討論和對比,最終選擇了大規(guī)模并行處理(MPP)數(shù)據(jù)庫,考慮到開源和易用性等多方面因素,并參考了阿里巴巴使用Greenplum 替換之前Oracle RAC 的成功經驗,選擇Greenplum DB 作為分布式數(shù)據(jù)庫的技術選型。
MPP 數(shù)據(jù)庫本質上依然是一個關系型數(shù)據(jù)庫,其原理是將任務并行地分散到多個工作節(jié)點,每個節(jié)點的磁盤存儲系統(tǒng)和內存系統(tǒng)均不與其他節(jié)點共享,屬于Share-Nothing 模式[7],而Oracle RAC 數(shù) 據(jù) 庫屬 于Share-Everything 模式。Greenplum 是一種基于PostgreSQL 的分布式數(shù)據(jù)庫,采用Share-Nothing 模式,其中主機、操作系統(tǒng)、存儲、內存都是屬于獨占模式,不存在共享。Greenplum 屬于關系型數(shù)據(jù)庫集群方式,由多個獨立的數(shù)據(jù)庫服務組合而成,因為其基于X86服務器,所以價格低廉,在開放平臺的同時,可提供強大的海量數(shù)據(jù)處理能力和并行數(shù)據(jù)計算能力。MPP數(shù)據(jù)庫主要是為了解決大問題而提出的并行計算,而不是對高并發(fā)的請求。其特點總結如下:(1)支持海量數(shù)據(jù)存儲和計算;(2) 支持主流的SQL 語法;(3)有方便的維護工具,學習方便;(4)擴展性好,提供分布式事務處理能力。
在搭建好的虛擬化平臺上安裝10 臺虛擬機,安裝Red Hat Linux 操作系統(tǒng),每5 臺虛擬機搭建1 個Greenplum 集群,共建立2 個Greenplum 集群。其中1 個集群對應IP 地 址10.102.5.195-199,其中10.102.5.195 為Master 主機,剩余4 個為Segment 主機。通過PgAdmin對Greenplum 數(shù)據(jù)庫進行訪問,PgAdmin 管理界面見圖2。
圖2 PgAdmin管理界面
在安裝完Greenplum 后,需要將以前存儲在Oracle的數(shù)據(jù)存儲在Greenplum 數(shù)據(jù)庫中。對數(shù)據(jù)管理所采取的方案為:從生產系統(tǒng)、消息隊列(MQ)報文或文件傳輸協(xié)議(FTP)文件中提取的數(shù)據(jù)先存儲在Oracle 數(shù)據(jù)庫中,Oracle存儲近期和未來時間的數(shù)據(jù),近期的時間段根據(jù)各業(yè)務系統(tǒng)產生數(shù)據(jù)量的大小決定,Greenplum 數(shù)據(jù)庫定義為存儲歷史和分析后數(shù)據(jù),增加入庫時間戳,保證數(shù)據(jù)的回溯性。
Greenplum 數(shù)據(jù)加載主要包括insert、copy、外部表、gpload、web external table 等5 種方式。其中insert和copy 是串行,外部表gpfdist 和gpload 工具是并行方式。
(1)Insert 這種加載方式和其他數(shù)據(jù)庫SQL 語法一樣,但是效率最差,只適合加載極少數(shù)數(shù)據(jù),需要通過master 節(jié)點操作。Copy 方式比SQL 方式效率大大提升,但是數(shù)據(jù)依然需要通過master節(jié)點,無法實現(xiàn)并發(fā)高效數(shù)據(jù)加載。
(2)為了提高數(shù)據(jù)導入效率,Greenplum 引入外部表。外部表基于gpfdist 工具(類似于Oracle 的sqlldr 工具),其最突出的優(yōu)勢是支持數(shù)據(jù)并發(fā)加載。所謂外部表,就是在數(shù)據(jù)庫中只有表定義、沒有數(shù)據(jù),數(shù)據(jù)都存放在數(shù)據(jù)庫之外的數(shù)據(jù)文件。Greenplum 利用外部表執(zhí)行正常的增刪改操作,而外部表支持在節(jié)點上并發(fā)執(zhí)行gpfdist 的導入程序。外部表需要指定gpfdist 的IP和端口,還要有詳細的目錄地址,文件名支持通配符匹配,可以編寫多個gpfdist 地址,但是總數(shù)不能超過總的segment 數(shù)量,否則會報錯,因此Greenplum 執(zhí)行效率高。
(3)gpload是Greenplum使用可讀外部表和GP并行文件服務gpfdist裝載數(shù)據(jù)的1個命令包裝,其允許通過使用配置文件的方式設置數(shù)據(jù)格式等來創(chuàng)建外部表定義。通過按照YAML 格式定義的裝載說明配置文件,然后執(zhí)行insert、update、merger操作,將數(shù)據(jù)裝載到目標數(shù)據(jù)庫表中。
項目組使用gpload方式成功上傳pt_history的1個月數(shù)據(jù)(1300萬行記錄),下載30 s左右,上傳120 s。
客票系統(tǒng)的售票信息在不斷地發(fā)生變化,更新頻率非常高,對數(shù)據(jù)庫的更新也會非常頻繁,而客票系統(tǒng)的歷史售票記錄則不會再發(fā)生變化,更新基本上不會發(fā)生,數(shù)據(jù)操作需求很低。面對這種情況,采用實時數(shù)據(jù)和歷史數(shù)據(jù)分開處理,當天及以后的客票數(shù)據(jù)存儲在實時表中,昨天及以前的客票數(shù)據(jù)存儲在歷史表中。實時表的數(shù)據(jù)量基本上是固定的(最多30 d),并且不受歷史數(shù)據(jù)的影響,可以進行快速的增刪改查等操作。歷史表的數(shù)據(jù)量非常大(目前存儲了3年),并且會不斷累積,利用分布式數(shù)據(jù)庫可進行快速查詢、統(tǒng)計。在歷史數(shù)據(jù)分析中,通過數(shù)據(jù)鉆取將粗粒度數(shù)據(jù)向細粒度數(shù)據(jù)轉換,數(shù)據(jù)在維度的不同層次間變化,從上層降到下一層,將匯總數(shù)據(jù)拆分到更細節(jié)的數(shù)據(jù),以加快查詢與存儲速率。將售票信息通過車次、方向、線路、客座率等多個維度進行分析并存儲,每個統(tǒng)計分析的結果都會加上時間戳,為之后的客流分析和預測打好基礎。
在分布式客運數(shù)據(jù)存儲平臺上開展客運數(shù)據(jù)分析研究,可實現(xiàn)數(shù)據(jù)的展示、查詢功能以及節(jié)假日客流情況分析,客流分析系統(tǒng)界面見圖3。在終端展示方面,可同時采用大屏顯示和電腦版分析2種形式。按照車次、列車交路、發(fā)行方向等方面進行客座率統(tǒng)計、分析,形成一定的決策分析結果,為客車的加開、加掛、縮編等工作提供信息支持;通過對清明節(jié)、勞動節(jié)、暑期、端午節(jié)、中秋節(jié)、國慶和元旦等節(jié)假日的客流進行統(tǒng)計、分析,以大屏形式展示武漢局集團公司的客流情況;通過掌握集團公司、車務段、車站在各時間段的發(fā)送和到達信息,為客運高峰期的預警提供信息支持;通過掌握集團公司發(fā)往各省的客流情況和從各省到達集團公司的客流情況,進一步了解旅客的出行方向,為客運方向的規(guī)劃提供信息支持[8]。其主要分析指標和功能如下:
(1)列車密度表:對列車的上車、下車、車內人數(shù)做到精確掌握,為調整席位的預售區(qū)間提供信息支持。
(2)列車客座率:對列車的定員、里程、編組做到精確掌握。
(3)列車正晚點:對列車的正晚點情況可全面掌握。
(4)九大方向的客座率:對武廣、漢宜、漢十等重點線路進行分析,挖掘出上座率高和上座率低的車次,為客運運營提供信息支持,例如:如果后面的區(qū)間客座率低,是否應提前返程。
(5)擔當交路客座率:挖掘出客座率高的交路,分析是否重聯(lián)以進一步提高客運能力;挖掘出客座率低的交路,分析是否用單組的方式,以減小客運成本。
(6)車站發(fā)送、到達預警:對車站的發(fā)送、到達情況,按照時段、車次進行預警,武漢站已初步實現(xiàn)了站臺預警。
(7)集團公司發(fā)送、到達分析:各省之間的客流情況、每日發(fā)送人統(tǒng)計、擔當列車的對數(shù)。
(8)客流預測:根據(jù)歷史數(shù)據(jù),采用ARIMA 乘積季節(jié)模型對節(jié)假日的客流進行預測。
(9)實現(xiàn)部分大屏展示:駕駛艙界面匯總客運的關鍵數(shù)據(jù),已在調度所大屏進行展示;大屏輪播界面可展示客運的重要指標,已在客運部的大屏進行展示。
圖3 客流分析系統(tǒng)界面
面對海量客運數(shù)據(jù),找到與客流相關的關鍵指標,形成一定的決策分析結果,用于指導客運組織是本項目研究的初衷。通過構建分布式數(shù)據(jù)存儲平臺,實現(xiàn)了在有限硬件條件下大數(shù)據(jù)量的實時分析,為數(shù)據(jù)的預測提供基本計算來源[9]。利用大數(shù)據(jù)技術,在客流數(shù)據(jù)分析和挖掘方面進行研究,通過數(shù)據(jù)鉆取將粗粒度數(shù)據(jù)向細粒度數(shù)據(jù)轉換,數(shù)據(jù)在多個維度上進行分析和存儲,并在此基礎上研究客流相關的9 類關鍵指標[10-11]。隨著歷史數(shù)據(jù)的增長和系統(tǒng)功能的增加,尚有許多內容需要研究。目前該平臺系統(tǒng)還處于驗證和完善階段,分布式數(shù)據(jù)存儲平臺的穩(wěn)定性也需進一步驗證。