基于混合式架構城市軌道交通大數(shù)據(jù)平臺與運營決策應用
2019-04-01 12:43:52張銘
計算機應用與軟件 2019年2期
關鍵詞：系統(tǒng)
張 銘
(中國鐵道科學研究院集團有限公司電子計算技術研究所 北京 100081)
0 引 言
近年大城市軌道交通快速進入規(guī)模化和網(wǎng)絡化格局，為日常生產(chǎn)調(diào)度、運營、管理服務的各類信息系統(tǒng)快速積累了大量的數(shù)據(jù)資源，陸續(xù)建設了數(shù)據(jù)中心或信息中心，對大數(shù)據(jù)技術和數(shù)據(jù)資源效益的挖潛日益重視[1-4]。目前城市軌道交通部分企業(yè)采用了傳統(tǒng)數(shù)據(jù)倉庫一體機的模式，以北京、廣州、深圳為代表，圍繞線網(wǎng)運營業(yè)務建立數(shù)據(jù)結(jié)構和主題域，該模式以數(shù)據(jù)資源的存儲為目標。但隨著硬件設備、軟件版本的更新?lián)Q代，須同步更新歷史數(shù)據(jù)管理方式，且難以適應于不斷變化和彈性擴展的應用需求，投資成本高，逐步顯現(xiàn)出它的劣勢。隨著大數(shù)據(jù)和云計算技術的探索應用，文獻[5-6]總結(jié)了基于Hadoop各項大數(shù)據(jù)技術及應用創(chuàng)新。池亞平等[7]研究了大數(shù)據(jù)平臺海量監(jiān)控數(shù)據(jù)的存儲效率改進方法。李敏等[8]就物聯(lián)網(wǎng)環(huán)境下的數(shù)據(jù)時空特性提出了異構大數(shù)據(jù)處理的時效性改進模型，這些為大數(shù)據(jù)平臺的建設和應用優(yōu)化提供了借鑒。一些新建和規(guī)劃數(shù)據(jù)中心的軌道交通企業(yè)，如上海、南京、重慶，采用了新型的大數(shù)據(jù)平臺技術，如基于MPP(Massively Parallel Processor)架構、基于虛擬化共享硬件的方式，基于Hadoop大數(shù)據(jù)平臺模式，均不同程度地兼顧了遠期硬件擴容的投入，以及數(shù)據(jù)挖掘、商務智能方面應用的靈活擴展性。
針對城市軌道交通數(shù)據(jù)資源在業(yè)務、生產(chǎn)、經(jīng)營、管理、服務方面的差異性，將數(shù)據(jù)運用于不同應用場景的需求，本文提出建立基于混合式架構的大數(shù)據(jù)平臺模式，以可擴展、自適應、可定制為目標導向，深化平臺的系統(tǒng)架構、數(shù)據(jù)架構、分層管控機制，并在運營管理與決策支持中加以運用，為運營信息化基礎大數(shù)據(jù)平臺提供一套實用的綜合解決方案。
1 運營信息化業(yè)務數(shù)據(jù)特征分析
1.1 數(shù)據(jù)類型多樣與時空特性
城市軌道交通運營信息化類系統(tǒng)作為企業(yè)數(shù)據(jù)資產(chǎn)的基礎數(shù)據(jù)源，根據(jù)業(yè)務歸屬和關聯(lián)關系劃分為生產(chǎn)類、管理類、業(yè)務類、線網(wǎng)級管理與基礎平臺類四種類型。具體如下：
1) 生產(chǎn)信息化系統(tǒng)，包括信號ATS、通信、綜合監(jiān)控ISCS、電力PSCADA、火災報警FAS、環(huán)控BAS、自動售檢票AFC、清分中心ACC等系統(tǒng)[9]，主要服務于日常的生產(chǎn)調(diào)度與安全保障。
2) 辦公管理信息化系統(tǒng)，包括辦公自動化、人力資源管理、財務管理、合同管理、檔案管理等系統(tǒng)。
3) 運營業(yè)務信息化系統(tǒng)，包括票務管理、站務管理、乘務管理、資產(chǎn)管理、運營計劃管理、施工調(diào)度、維修管理等系統(tǒng)。
4) 線網(wǎng)級管理與基礎平臺系統(tǒng)，包括線網(wǎng)指揮中心、線網(wǎng)應急處置、信息發(fā)布等，以及統(tǒng)一認證、門戶網(wǎng)站、BIM系統(tǒng)等。
產(chǎn)生的數(shù)據(jù)類型包括結(jié)構化數(shù)據(jù)、非結(jié)構化數(shù)據(jù)、半結(jié)構化數(shù)據(jù)，例如存儲于關系型數(shù)據(jù)庫的數(shù)據(jù)表，視頻監(jiān)控的多媒體數(shù)據(jù)，接口傳輸?shù)奈募悢?shù)據(jù)等，需要配置不同的存儲模式和空間與之相適應。實時數(shù)據(jù)存儲時間要求不一，如歷史報警、突發(fā)事件等數(shù)據(jù)需要長期保存，而常規(guī)視頻數(shù)據(jù)一般存儲15～30日，接口文件一般存儲0.5～1年。數(shù)據(jù)的時空差異性決定了統(tǒng)一數(shù)據(jù)資源管理需要因地制宜，結(jié)合業(yè)務和數(shù)據(jù)本身的特性制定策略。
1.2 數(shù)據(jù)處理的復雜性
根據(jù)各類業(yè)務系統(tǒng)數(shù)據(jù)的時效性差異，數(shù)據(jù)采集時間和方式也不同，包括實時數(shù)據(jù)(采集周期1 s以內(nèi))、近線數(shù)據(jù)(5 min以內(nèi))、離線數(shù)據(jù)(小時、日、周不等)、隨機數(shù)據(jù)(一般不固定時間，數(shù)據(jù)產(chǎn)生時自行抽取或推送)。接口方式包括專用的接口協(xié)議或通信機制，如Modbus TCP/IP協(xié)議，文件消息隊列(Message Queue)方式、FTP文件傳輸、報文、Web service等，實現(xiàn)用于數(shù)據(jù)表交換的監(jiān)控數(shù)據(jù)靜態(tài)點、狀態(tài)點、監(jiān)測點、控制點，及客流文件、多媒體數(shù)據(jù)等的獲取，再根據(jù)業(yè)務特點統(tǒng)一清洗、抽取、加載為可共享的數(shù)據(jù)形式存儲。
1.3 應用面廣與數(shù)據(jù)多重交互
共享數(shù)據(jù)資源經(jīng)過整合后為各種業(yè)務系統(tǒng)調(diào)用，同時各系統(tǒng)之間存在數(shù)據(jù)交互，如調(diào)度監(jiān)控系統(tǒng)為運營管理和應急處置系統(tǒng)提供設備報警的數(shù)據(jù)，及時預防災害或處理大型故障；資產(chǎn)管理系統(tǒng)為物資管理、維修管理系統(tǒng)提供統(tǒng)一的編碼；統(tǒng)一認證和門戶系統(tǒng)為各類業(yè)務系統(tǒng)提供統(tǒng)一的企業(yè)用戶名錄和角色保障數(shù)據(jù)同步更新。分析性數(shù)據(jù)為指標統(tǒng)計、效益核算、成本分析、線路規(guī)劃及建設后評估等提供決策依據(jù)。
2 運營信息大數(shù)據(jù)平臺的構建
2.1 混合式架構的數(shù)據(jù)平臺框架
平臺定位于建立面向多用戶的信息集中共享、資源高效利用的軌道交通數(shù)據(jù)服務和綜合信息管理平臺，實現(xiàn)統(tǒng)一采集、長期存儲、統(tǒng)計分析、數(shù)據(jù)挖掘的功能。根據(jù)各種業(yè)務的數(shù)據(jù)共享和使用需求，首先搭建定制化的基礎數(shù)據(jù)平臺，基于數(shù)據(jù)倉庫MPP架構、大數(shù)據(jù)Hadoop架構及關系型數(shù)據(jù)結(jié)構混合的數(shù)據(jù)管理模式，實現(xiàn)分級分類的數(shù)據(jù)共享。構建總體規(guī)劃的分層體系，即數(shù)據(jù)采集層、數(shù)據(jù)融合層、技術組件層、分析模型層、應用訪問層的五層系統(tǒng)架構。如圖1所示。
圖1 運營信息大數(shù)據(jù)平臺的層次架構
(1) 數(shù)據(jù)采集與融合層 完成各類系統(tǒng)基礎數(shù)據(jù)和設備級系統(tǒng)數(shù)據(jù)的接入，包括與車站層、線路層、車輛段、控制中心等系統(tǒng)的接口，與外部信息的邊界安全防護，保障實時、非實時數(shù)據(jù)的采集和處理。按照實時庫、非實時的業(yè)務主題數(shù)據(jù)、公共數(shù)據(jù)對象抽取，并根據(jù)結(jié)構化、非結(jié)構化數(shù)據(jù)類型區(qū)分存儲周期和更新機制。
(2) 技術組件與分析模型層 將通用的組件和工具形成資源模型庫，將工作流、接口標準化、微服務、流計算、數(shù)據(jù)發(fā)布、單元建模、畫面組件等通用組件集以調(diào)用模式統(tǒng)一管理，并封裝便捷的調(diào)用接口。將單元業(yè)務應用包劃分為最小單元，進行多維度分析和業(yè)務流程建模，濃縮和匯聚主要的業(yè)務單元，成為信息化系統(tǒng)調(diào)用的最直接資源庫。
(3) 業(yè)務應用訪問層 作為日常生產(chǎn)、管理、經(jīng)營、企業(yè)資源利用等方面數(shù)據(jù)服務的系統(tǒng)工具，實現(xiàn)信息流轉(zhuǎn)和辦公支撐，構建標準、安全、高效的信息共享模式。面向車站、線路、線網(wǎng)各級別的系統(tǒng)，覆蓋城市軌道交通數(shù)據(jù)資源需求的各個業(yè)務面。
2.2 數(shù)據(jù)流規(guī)劃與分級存儲
數(shù)據(jù)處理系統(tǒng)作為大數(shù)據(jù)平臺的核心，通過對業(yè)務數(shù)據(jù)的有效集成，滿足對海量數(shù)據(jù)的存儲、管理和使用需要，需根據(jù)業(yè)務類型進行數(shù)據(jù)流規(guī)劃與存儲機制的設計，如圖2所示。
圖2 混合式數(shù)據(jù)管理模式及數(shù)據(jù)流
數(shù)據(jù)資源歸納為以下四種類型：
(1) 實時數(shù)據(jù)庫 用于采集實時數(shù)據(jù)，設計快速提取和計算服務模塊，將獲取的實時數(shù)據(jù)標準化處理后轉(zhuǎn)入實時監(jiān)控的可視化展示，如設備狀態(tài)實時監(jiān)控。
(2) 關系型數(shù)據(jù)庫 設置一定存儲空間的關系型數(shù)據(jù)庫，用于多元業(yè)務流程及可擴展應用的數(shù)據(jù)管理和事務型分析的應用，如資產(chǎn)、維修、調(diào)度管理等。
(3) 基于MPP架構的數(shù)據(jù)倉庫 設置基于主題域和元數(shù)據(jù)管理的數(shù)據(jù)倉庫，圍繞定向型業(yè)務定義數(shù)據(jù)結(jié)構，如歷史報警綜合查詢、多維統(tǒng)計、客流預測、仿真回放，并統(tǒng)一進行數(shù)據(jù)質(zhì)量、數(shù)據(jù)治理、數(shù)據(jù)模型、數(shù)據(jù)維護管理。利用數(shù)據(jù)倉庫的數(shù)據(jù)分析能力支持運營效果評估和運營仿真應用。
(4) 基于Hadoop架構的大數(shù)據(jù)應用庫 將所有采集的數(shù)據(jù)匯總存入，非結(jié)構化數(shù)據(jù)獨立管理，并定義索引用于智能檢索。采用分布式Kafka消息隊列的方式采集數(shù)據(jù)后，定制可擴展的存儲邏輯單元管理，為長期數(shù)據(jù)存儲擴容提供條件，運用處理、查詢、讀取的各類工具集管理數(shù)據(jù)，為業(yè)務系統(tǒng)提供數(shù)據(jù)服務，如客流預測、云管理等。
2.3 數(shù)據(jù)采集與計算服務標準化
傳統(tǒng)的數(shù)據(jù)共享方式，經(jīng)過數(shù)據(jù)采集后直接存儲，為業(yè)務系統(tǒng)提供數(shù)據(jù)時呈現(xiàn)出松散、繁雜的原始特征。由于城市軌道交通專業(yè)眾多，數(shù)據(jù)內(nèi)容和類型多樣，所以數(shù)據(jù)經(jīng)采集后處理的方式對數(shù)據(jù)分發(fā)的時效性、根據(jù)時間片存儲數(shù)據(jù)的同步性和一致性等都會產(chǎn)生影響。而接口采集的數(shù)據(jù)一般都是現(xiàn)場設備狀態(tài)及系統(tǒng)運行數(shù)據(jù)，實際業(yè)務需要呈現(xiàn)的數(shù)據(jù)，往往要根據(jù)數(shù)據(jù)形式進行數(shù)學運算和邏輯判斷。未經(jīng)過以業(yè)務需求為出發(fā)點處理的數(shù)據(jù)，使用的效率低，而為了單一業(yè)務需求涉及多個數(shù)據(jù)表的訪問和關聯(lián)，對系統(tǒng)的負載和數(shù)據(jù)讀取的效率均產(chǎn)生不利影響。
針對這一問題，為大數(shù)據(jù)平臺的數(shù)據(jù)采集模塊設計基于數(shù)據(jù)實時計算的快速標準化的數(shù)據(jù)處理方法。數(shù)據(jù)采集后即做快速處理，以最小通用單元的形式，為業(yè)務系統(tǒng)提供便捷、可直接應用的數(shù)據(jù)單元。通過設定統(tǒng)一的數(shù)據(jù)處理模板，將單元數(shù)據(jù)的業(yè)務需求歸納并加以屏蔽，經(jīng)過實時計算和解析為標準化的基礎數(shù)據(jù)單元，可大幅減輕在大規(guī)模數(shù)據(jù)接入后處理過程的繁雜性，提高數(shù)據(jù)的應用效率。并進一步引入統(tǒng)一的數(shù)據(jù)模型、制定報警處理規(guī)則等方式，將不同專業(yè)系統(tǒng)的業(yè)務流程歸一化。從實時數(shù)據(jù)接入后進行標準化處理過程規(guī)劃、實時計算處理原則、功能、性能保障角度對數(shù)據(jù)處理服務設計，確保數(shù)據(jù)的業(yè)務適用性、實效性和可靠性。主要包括三個階段：數(shù)據(jù)提取，數(shù)據(jù)計算及服務、自動分析與報警服務。
2.3.1 數(shù)據(jù)提取服務
數(shù)據(jù)提取模塊包括：專業(yè)數(shù)據(jù)、時間數(shù)據(jù)提取。從消息中間件獲取數(shù)據(jù)采集層提供的實時數(shù)據(jù)，如設備狀態(tài)、客流監(jiān)測數(shù)據(jù)，經(jīng)數(shù)據(jù)提取過濾的時間數(shù)據(jù)，根據(jù)表達式進行實時計算，并將計算結(jié)果推送給報警管理業(yè)務功能和實時可視化監(jiān)控模塊，嚴格區(qū)分各自接收的專項數(shù)據(jù)內(nèi)容。
數(shù)據(jù)采集層定義Producer(接口甲方)，計算服務模塊定義為Consumer(接口乙方)。如果有請求信息，數(shù)據(jù)采集層接收則為Consumer(接口甲方)，計算服務模塊則為Producer(接口乙方)。例如監(jiān)控系統(tǒng)的數(shù)據(jù)載入按每條地鐵線路創(chuàng)建二個通道(Topic)，為多副本單分區(qū)形式。以客流數(shù)據(jù)計算服務為例說明計算方法如下。
(1) 初始化定義。定義過程(DatalogicWorker)：周期性地向數(shù)據(jù)計算服務模塊提供客流數(shù)據(jù)，包括：進出站客流、斷面客流、各類客流數(shù)據(jù)排名、各類客流數(shù)據(jù)報警狀態(tài)。流程如下：
定義數(shù)據(jù)提取任務(Job)：每個數(shù)據(jù)提取任務實現(xiàn)不同數(shù)據(jù)的提取，定義過程(PassengerFlowLogicJob)，該任務用于提取進出站客流、區(qū)間客流。具體業(yè)務邏輯在private static void GetPassengerFlowData()方法中實現(xiàn)。計算邏輯如下：
var pfstmeList=PassengerFlowDataCollection.GetInstance().GetPassengerFlowStation();
foreach(var pfsm in pfstmeList)
{
PfstmeMaps.Add(ConvetTools.LongTryParse(pfsm.Stationid.Trim()+pfsm.Flowtype), pfsm);
//作為字典Key，標示客流狀態(tài)
PfstmeMaps.Add(ConvetTools.LongTryParse("10000"+pfsm.Stationid.Trim()+pfsm.Flowtype),pfsm);
}
(2) 將數(shù)據(jù)提取服務(ScheduleService)注冊為系統(tǒng)服務。
(3) 定義數(shù)據(jù)提取服務的啟動、停止方法，并在啟動方法中初始化所有數(shù)據(jù)提取任務。
定義過程(Periodic)：周期性的向數(shù)據(jù)計算服務提供所需的時間數(shù)據(jù)，包括：當前時間(到s級，每隔10 s更新一次)、當日運營時間(到min級，每日更新一次)。
首先定義時間數(shù)據(jù)提取與發(fā)送機制：
private void StartEtlAction(SqlEtlInfo sqlEtlInfo, string timeRequest)
{
var config=sqlEtlInfo.DatabaseTypeConnQuery;
if(config.Trim().Length<1) return;
var sqlconfig=JsonHelper.DeserializeJsonToList
var sqlTimeRequest=sqlconfig.Where(s=>s.TimeRequest.ToLower()==timeRequest.ToLower());
foreach(var item in sqlTimeRequest)
{
var type=GetDbType(item.DatabaseType);
try
{
using(var db=SugarDao.GetInstance(type, item.DatabaseConn))
{
var datast=db.SqlQuery
//System.Diagnostics.Debug.WriteLine(string.Join(";",
//datast));
var sendData=string.Join(";", datast);
ServiceProvider.GetService
ActiveMqWorker.Send(sendData);
log.Info(＄"Send to MQ:{sendData}");
}
}
catch(Exception ex)
{
ExceptionHelper.HandleException(ex);
}
}
}
再經(jīng)初始化，將時間數(shù)據(jù)提取服務添加到服務容器。
2.3.2 數(shù)據(jù)計算服務
將各類數(shù)據(jù)調(diào)取需求歸納為統(tǒng)一、可識別的表達式模板，轉(zhuǎn)換為數(shù)據(jù)表定義，對應不同的列形成機器識別的數(shù)據(jù)類目，并進一步對應到數(shù)據(jù)計算過程中。
定義過程(Bridge)：接收數(shù)據(jù)提取服務模塊發(fā)送的數(shù)據(jù)，實時計算相關的表達式，并將計算結(jié)果推送至消息中間件或報警管理服務。流程如下：
(1) 服務啟動入口；
(2) 將服務添加到服務容器內(nèi)；
(3) 啟動數(shù)據(jù)計算服務；
(4) 數(shù)據(jù)分發(fā)。
具體計算過程包括：
初始化：
public void InitialzeResultExpDict(DbType dbType, string connStr, BlockingCollection
{
try
{
resultDict.Clear();
ExpressionWithTagsDict.Clear();
SugarDao.MySqlConnString=connStr;
using(var db=SugarDao.GetInstance(dbType, connStr))
{
var expsList=db.Queryable
Parallel.ForEach(expsList, exp=>
{
NetCal(exp, blockingCollection);
ExpDict.TryAdd(exp.ConfigID.ToString(), exp);
});
}
}
catch(Exception ex)
{
Trace.TraceError(ex.ToString());
ExceptionHelper.HandleException(ex);
}
}
//表達式計算過程
var exp=new Expression(expitem.Expression);
exp.EvaluateParameter+=delegate(string name, ParameterArgs args)
{
if(NameTagsDict==null‖!NameTagsDict.ContainsKey(name)) return;
args.Result=ReactiveTagsDict[NameTagsDict[name]].Value;
};
var reactiveResultExpression=Reactive.Expression
{
var rtn=new object();
try
{
rtn=exp.Evaluate();
}
catch(Exception ex)
{
Trace.TraceError(ex.ToString());
ExceptionHelper.HandleException(ex);
}
return rtn;
});
reactiveResultExpression.Subscribe
(getResult=>
{
expitem.Value=getResult();
blockingCollection.TryAdd(expitem);Trace.TraceInformation(＄"blockingCollection.Count={blockingCollection.Count}");
}
);
resultDict.TryAdd(expitem, reactiveResultExpression)。
2.3.3 數(shù)據(jù)自動分析報警服務
引入大數(shù)據(jù)的處理模式解決報警數(shù)據(jù)存儲、綜合報警分析等的擴展性和穩(wěn)定性問題，設計全新架構的統(tǒng)一報警服務模塊。定義統(tǒng)一的分析報警的數(shù)據(jù)模型，將不同專業(yè)系統(tǒng)的報警點信息制定統(tǒng)一格式整理，屏蔽了各種專業(yè)特征對數(shù)據(jù)形式、格式、表達式的專有性，編譯為標準識別的數(shù)據(jù)編碼，劃分出是否報警的標準，自動推送至客戶端。
此外，構建計算服務平臺架構中，數(shù)據(jù)提取模塊屬于邊緣計算層，將部分數(shù)據(jù)處理過程前置，以便提升處理效率，減輕數(shù)據(jù)計算模塊的負荷，從而為各類應用系統(tǒng)的請求提供更快的響應。利用緩存機制，將數(shù)據(jù)提取獲得的目標數(shù)據(jù)對象，根據(jù)時間戳，通過數(shù)據(jù)變化形式的對比邏輯，將最終需求的數(shù)據(jù)進行過濾。將處理的中間過程設置監(jiān)聽機制，對數(shù)據(jù)的變化按照閾值評判方法作出取舍，保障了目標數(shù)據(jù)內(nèi)容的控制和篩選。
3 大數(shù)據(jù)平臺的運營決策應用
大數(shù)據(jù)的運用貫穿城市軌道交通全生命周期的全過程，對規(guī)劃、建設、管理起著重要的決策支撐作用，體現(xiàn)在規(guī)律挖掘、預測、預警與調(diào)控等多個方面[10]。
3.1 平臺遞階管控策略
從企業(yè)信息化綜合數(shù)據(jù)管理角度，圍繞共享數(shù)據(jù)的核心，將結(jié)構化數(shù)據(jù)、數(shù)據(jù)倉庫、基于Hadoop平臺的數(shù)據(jù)管理平臺化，匯集城市軌道交通企業(yè)的管理、生產(chǎn)、運營、經(jīng)營、維護、資源等的數(shù)據(jù)，對資源占用、存儲、數(shù)據(jù)規(guī)劃和配置策略統(tǒng)一管理。將面向用戶和服務調(diào)用機制獨立分層，屏蔽了復雜的數(shù)據(jù)類型和模型的處理機制。如圖3所示。
圖3 基于大數(shù)據(jù)架構的數(shù)據(jù)資源整合
在混合式數(shù)據(jù)管理架構下，平臺的業(yè)務管控、配置管理、進程處理、資源池訪問、數(shù)據(jù)來源管控認證通過邏輯化遞階管控模式實現(xiàn)。由HDFS、Zookeeper、Hbase、Kafka、Storm組合構成。業(yè)務應用系統(tǒng)的調(diào)取模式：通過基于JDBC API操作HBase的開源SQL引擎(Phoenix)訪問HBASE數(shù)據(jù)庫。Phoenix基于Hbase以標準SQL的方式對Hbase進行查詢操作，支持條件運算、分組、分頁等高級查詢。
將運營信息化系統(tǒng)業(yè)務中運營決策相關的功能設置為高級分析板塊，從而便捷地調(diào)用配置管控和進程處理層的建模分析工具和大數(shù)據(jù)結(jié)果集。數(shù)據(jù)分析包括實現(xiàn)數(shù)據(jù)的深入分析挖掘功能，除了對業(yè)務數(shù)據(jù)進行基本事務處理操作和統(tǒng)計匯總以外，還要使用在線、歷史數(shù)據(jù)進行各種復雜分析，如長期趨勢分析和數(shù)據(jù)挖掘等，包括實現(xiàn)OLAP多維分析、運營評估報表、預測分析等。
3.2 客流大數(shù)據(jù)應用于運營決策
城市軌道交通的客流數(shù)據(jù)是占用大數(shù)據(jù)平臺存儲和業(yè)務分析的重要內(nèi)容之一，客流量及其特征分析作為運營組織中制定列車開行方案、編制列車運行計劃的主要決策依據(jù)?；A數(shù)據(jù)通常從自動售檢票系統(tǒng)(AFC)、清分中心(ACC)的源系統(tǒng)中獲取，包括以5 min為周期采集的進/出站客流量，上/下行區(qū)間客流量，換乘客流量、乘客路徑的OD客流量，以及以日/月/年等維度統(tǒng)計的階段性匯總客流量等。首先利用大數(shù)據(jù)平臺對客流數(shù)據(jù)進行畫像，再運用到列車開行方案和行車調(diào)度，為運營組織提供決策支持。
3.2.1 基于客流大數(shù)據(jù)的特征類畫像
主要使用了Hadoop、Hive等框架，通過Hive將結(jié)構化的客流數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，實現(xiàn)對各類特征客流數(shù)據(jù)的查詢和提取功能，以SQL轉(zhuǎn)化為MapReduce任務運行。提取一定時間段的客流數(shù)據(jù)，生成客流特征分析的模型和業(yè)務數(shù)據(jù)集，將模型應用于該數(shù)據(jù)集得到最終的客流特征識別結(jié)果。定義客流特征畫像的標簽體系，包括基礎信息標簽、動態(tài)信息標簽。
1) 基礎信息標簽：線路、車站、車站所屬行政區(qū)、票卡類型、OD路徑、進站編碼、出站編碼、換乘路徑、換入線路、換出線路、上行區(qū)間、下行區(qū)間；
2) 動態(tài)信息標簽：高峰時段的起止時間戳、進/出站客流量超出閾值的車站、換乘客流量最大的車站及方向、區(qū)間客流量最大的方向及時段等。
通過深度數(shù)據(jù)融合及交叉分析，選取與運營決策過程中相關度較高的要素集合作為客流特征畫像的分析目標，并按照分析目標的層次關系聚類，進一步設計權重參數(shù)E={ε1,ε2,…,εi}，εi∈(0,1)，來控制不同應用場景下目標導向性。如表1所示，聚類功能縱向分為8個類別，每一類客流特征按照客流行為標簽統(tǒng)計，再根據(jù)當前場景下的權重值均衡化，形成綜合客流畫像。在數(shù)據(jù)挖掘過程中，將進出站客流、區(qū)間客流、換乘客流的數(shù)據(jù)設置聚類輸出數(shù)目或中心點，再選擇目標后，應用聚類算法和收斂參數(shù)，從而得到關注點的特征畫像，輸出結(jié)果集。
表1 客流特征聚類參數(shù)
客流特征分析在不同運營場景下策略調(diào)整或需求的動態(tài)變化時，支持多級標簽的疊加，如②和⑧疊加的客流分析結(jié)果，用于特殊運營場景下各行政區(qū)域的交通系統(tǒng)的樞紐接駁與線網(wǎng)運營組織調(diào)整計劃的配合方案；③、⑤、⑥疊加則作為針對日間通勤上班高峰期客流的疏解策略和編制列車開行計劃優(yōu)化的依據(jù)。
3.2.2 基于特殊運營場景大數(shù)據(jù)的運營計劃調(diào)整
特殊運營場景一般指車站限流、城市大型活動保障下對客流變化的影響，相應的常規(guī)列車運行計劃不再適用，包括上線列車數(shù)量、列車開行間隔、列車在站?？繒r間等均需調(diào)整。但這種客流的影響具有動態(tài)性、傳播性、演化性，只有借助大數(shù)據(jù)實時監(jiān)控客流在線網(wǎng)中的分布，通過運能和運量的匹配度計算，同步調(diào)整運營計劃方案，從而與實際客流的需求相匹配。首先將5 min為單位的客流數(shù)據(jù)持續(xù)導入大數(shù)據(jù)平臺中，與線網(wǎng)基礎數(shù)據(jù)、運營計劃關聯(lián)，具體算法如下：
Step1從AFC、ACC系統(tǒng)側(cè)獲取客流data文件到FTP服務器中。
Step2由數(shù)據(jù)采集層解析data文件并以JSON(UTF-8)的形式發(fā)布到Kafka中間件平臺。
Step3從Kafka取得數(shù)據(jù)并解析為對應數(shù)據(jù)對象，通過調(diào)用Java-API的方式實現(xiàn)寫入Hadoop大數(shù)據(jù)平臺中的HDFS文件系統(tǒng)中。
Step4使用hive-SQL建立Hive表，將HDFS的數(shù)據(jù)加載到Hive大數(shù)據(jù)平臺的客流庫中。
Step5將線路基礎數(shù)據(jù)文件，包括線路圖、車站線路部署信息、線路設備設施參數(shù)、乘務人員配備、線路供電區(qū)段能力參數(shù)、車輛屬性參數(shù)等載入。
Step6讀入列車運行計劃數(shù)據(jù)文件，選取某一運力配置計劃，編制列車運行計劃，加載計劃的基本條件和配置參數(shù)，包括適用的線路、首末車時間、交路方案、停站方案、列車編組方案、全日分時開行對數(shù)表，繪制特殊場景下的日列車運行圖。
Step7在實時客流大數(shù)據(jù)提取的基礎上，疊加列車運行圖，并實時動態(tài)更新客流量，計算與運力配置的匹配程度，用不同的色帶表示實際列車的運能利用情況。
根據(jù)上述算法，疊加大客流數(shù)據(jù)仿真的動態(tài)運能評估效果如圖4所示。中部區(qū)域淺色運行線顯示，7:30-8:50的高峰時段內(nèi)客流量遠超過運能，滿載率大于1，體現(xiàn)出部分列車運力明顯不足，急需增加列車數(shù)量減小開行間隔，緩解客流壓力。
圖4 運輸能力匹配仿真評估效果
此外，還可根據(jù)換乘樞紐多方向間的換乘關系，計算乘客下車后經(jīng)換乘走行至換乘方向列車是否能在一定換乘等待時間范圍內(nèi)完成換乘銜接過程，輔助調(diào)整列車運行圖的多列車接續(xù)、減少換乘樞紐乘客集聚量和運營組織效率評估。
4 應用案例
以某城市軌道交通運營公司建設的企業(yè)級信息化大數(shù)據(jù)中心為例，采用混合式架構的大數(shù)據(jù)平臺，根據(jù)運營業(yè)務系統(tǒng)、生產(chǎn)調(diào)度系統(tǒng)、經(jīng)營管理、網(wǎng)絡化運營決策系統(tǒng)等四類業(yè)務數(shù)據(jù)，應用數(shù)據(jù)管理體系和數(shù)據(jù)挖掘功能。業(yè)務板塊劃分如圖5所示。
圖5 大數(shù)據(jù)平臺的業(yè)務應用構成
此外，基礎數(shù)據(jù)處理系統(tǒng)包括以下模塊：
1) 數(shù)據(jù)源管理：包括對原始數(shù)據(jù)源系統(tǒng)的數(shù)據(jù)抽取，通過數(shù)據(jù)治理和清洗，保障輸入計算服務系統(tǒng)的數(shù)據(jù)質(zhì)量。
2) 數(shù)據(jù)提取、實時計算服務、結(jié)果輸出：面向各類業(yè)務的數(shù)據(jù)調(diào)取需求的輸入項設置為系統(tǒng)前端面向用戶，將數(shù)據(jù)計算服務等設置為后端模塊，實現(xiàn)數(shù)據(jù)交互，在滿足各類業(yè)務系統(tǒng)數(shù)據(jù)調(diào)取需求的基礎上，保證數(shù)據(jù)質(zhì)量和時效性。
3) 過程監(jiān)控、數(shù)據(jù)質(zhì)量管理：管理數(shù)據(jù)提取、計算過程、數(shù)據(jù)輸出過程中的通信、協(xié)議、連接、計算節(jié)點等是否正確、及時地響應，并發(fā)出報警和容錯處理。以及針對臟數(shù)據(jù)處理、數(shù)據(jù)質(zhì)量的統(tǒng)計，數(shù)據(jù)修復的補救措施，如數(shù)據(jù)發(fā)送出錯時的回滾和補錄等。
選取運營信息大數(shù)據(jù)平臺分析6個月的客流數(shù)據(jù)，根據(jù)乘客出行時間、票卡類型、集中路徑方向等生成城市的客運交通走廊和潮汐流向，在線網(wǎng)客流畫像的基礎上，針對客流與運輸能力的比較，通過高峰時段的線路最大斷面客流與該斷面相應時段的運能的適應性做出評估，超過閾值就發(fā)出絕對預警?？缧姓^(qū)域的高峰客流畫像示例如圖6所示。
圖6 大數(shù)據(jù)平臺的客流畫像應用
由結(jié)果可見，該城市中心跨行政區(qū)域塊(虛線劃分)間的地鐵線路客流在早高峰期間呈現(xiàn)潮汐式流動，原因是商業(yè)CBD、辦公區(qū)集中在該區(qū)域，城市南部工業(yè)區(qū)分散，客流基本均衡分布。
在客流特征畫像和大數(shù)據(jù)分析結(jié)果的基礎上，進一步合理配置運營計劃，如上線列車數(shù)量，區(qū)間運行時分、最大/小發(fā)車間隔、追蹤間隔、車站停站時間、首末班車時間等。經(jīng)過實時動態(tài)客流大數(shù)據(jù)的加載，實現(xiàn)線網(wǎng)客流的多維度、多粒度分析，實際運能運量的適應性分析，從而評估線網(wǎng)的承載能力，指導線網(wǎng)運營計劃調(diào)整。
5 結(jié) 語
隨著城市軌道交通運營企業(yè)內(nèi)大數(shù)據(jù)的廣泛應用，對平臺的搭建方式、選用的架構和采用的技術，逐步隨著業(yè)務需求和企業(yè)的戰(zhàn)略規(guī)劃定位向著更科學、更實用和因地制宜的方向發(fā)展。本文提出的混合式架構適用于目前已建有運營業(yè)務系統(tǒng)，對大數(shù)據(jù)應用業(yè)務需求已有初步探索的企業(yè)構建的綜合信息平臺，為運營決策和商務智能做進一步的挖掘。經(jīng)在國內(nèi)軌道交通企業(yè)的運營信息化大數(shù)據(jù)平臺運營效果良好，從投資成本降低、便捷擴展應用方面體現(xiàn)出卓越特性，為企業(yè)進一步將數(shù)據(jù)資源效益真正發(fā)揮提供決策支持。
猜你喜歡
工業(yè)設計(2022年8期)2022-09-09 07:43:20
軍民兩用技術與產(chǎn)品(2021年10期)2021-03-16 06:05:30
北京測繪(2020年12期)2020-12-29 01:33:58
裝備制造技術(2019年12期)2019-12-25 03:06:46
制造技術與機床(2019年10期)2019-10-26 02:47:06
中國洗滌用品工業(yè)(2019年4期)2019-05-11 09:27:34
鐵道通信信號(2018年5期)2018-06-28 03:06:24
家庭影院技術(2017年9期)2017-09-26 03:41:45
知識經(jīng)濟·中國直銷(2017年5期)2017-06-15 20:28:19
通信電源技術(2016年6期)2016-04-20 06:21:32
