基于大數據的城市軌道交通數據處理流程研究

蘭慧峰　左旭濤　王美霞　岳陽　周凡

摘? 要：該文對線網數據中心進行了簡要介紹，從邏輯架構、處理機制和數據存儲3個方面，對實時數據處理過程進行了分析。從邏輯架構、數據清洗、配置工作流、任務調度和數據存儲5個方面，對離線數據處理過程進行了分析。青島地鐵利用大數據技術，結合地鐵運營業務，對有關運營生產數據的實時及離線處理流程進行了研究，實現了線網實時生產數據及離線生產數據的數據處理服務，為運營決策提供數據支撐。

關鍵詞：數據中心;實時數據處理;離線數據處理;工作流

中圖分類號：TP311? ? ? ? ? 文獻標志碼：A

0 引言

隨著城市軌道交通線路的不斷增加，青島地鐵已步入網絡化運營階段。隨著新業務需求的產生，地鐵運營管理日益復雜，運營生產數據呈爆炸式增長。因此尋求有效地海量數據處理技術、數據治理方法和手段已經成為非常迫切的需求。青島地鐵是國內首個基于Hadoop大數據技術搭建線網中心的地鐵公司[1]，其結合實際業務應用，合理選擇技術路線，實現了線網實時生產數據及離線生產數據的數據處理服務，為運營指揮系統、應急指揮系統、線網統計分析、線網運營評估、信息服務等上層應用提供了數據支撐。

1 線網數據中心簡介

線網數據中心是青島地鐵線網中心的核心[2]，基于Hadoop大數據技術搭建[3]，是線網上層業務系統的數據來源。線網數據中心主要包括數據采集、數據處理、數據分析和數據輸出等功能模塊，其中數據處理是數據中心的核心。數據處理根據數據傳輸的時效性要求可分為實時數據處理和離線數據處理2個部分。實時數據是指對數據時效性要求較高的突發類事件信息、人員定位信息、突發事件處置意見等。同時，時效性在5 min、15 min等的客流類近線數據，在處理中也算作實時數據進行處理。離線數據主要是指時間范圍為昨日及昨日以前的結構化數據。每天通過采集層從接口服務器采集離線數據，并把采集數據存儲到HDFS臨時文件存儲區，經數據的清洗、加工和轉換后，存儲到數據中心。

2 實時數據處理

城市軌道交通實時數據主要包括線路、車站的客流情況，列車運行情況，設備的工作狀態、能耗等現場的信息，數據中心通過對這些數據進行采集和處理，將其反映到線網指揮中心，供指揮中心了解整個線網的運行情況，為列車調度、設備運維、突發事件處理等運營決策提供數據支撐和服務。

大數據的計算模式主要分為批量計算（batch computing）、流式計算（stream computing）、交互計算（interactive computing）、圖計算（graph computing）等。基于青島地鐵的線網數據中心建設主要應用了批量計算和流式計算2種。流式計算和批量計算是2種主要的大數據計算模式，分別適用于不同的大數據應用場景。對于處理實時性要求嚴格的線網實時數據，流式計算具有明顯的優勢。對于先存儲后計算、實時性要求不高并且數據比較全面的線網離線數據，批量計算更適合。

在流式計算中，數據往往是最近時間段的增量數據，如實時客流數據、行車數據及綜合監控數據等，數據的延時往往較短，實時性較強，但數據的信息量相對較少，只局限于該時間段內的數據信息，不具有全量信息的特征。

從數據來源方面來講，其與批量計算相比一個明顯的區別是其數據通常來源于“數據預處理服務”的實時供給（如Kafka），而不像批量計算那樣從數據存儲中獲取已存儲的數據。

線網數據中心從技術路線的統一性角度以及功能要求等角度出發，選用了Spark作為分布式計算的框架，選擇Spark Streaming技術作為流式計算的基礎框架。

2.1 邏輯架構

實時數據處理架構圖如圖1所示。

系統的邏輯架構主要描述實時數據處理模塊建設的關鍵主體。根據實時數據處理業務的相關主體類別，將系統的邏輯架構分為數據源層、數據采集層和分析層3個層次。

數據源層定義了實時數據的數據來源、數據格式等。

采集層定義了數據采集的清洗規則、轉換規則、采集頻率、消息格式等。

分析層定義了數據加工算法、實時指標的存儲規則等。

2.2 處理機制

數據中心的數據采集層將采集到的實時數據通過Kafka消息的方式傳輸到Kafka消息隊列中，數據消費者需要掃描Kafka MQ消息隊列，當消息隊列中存在數據時，接收這些數據并對其進行解析，根據業務要求輸出到Redis等內存數據庫，供上層使用。

Kafka消費者程序的數據處理流程有4步。1）對約定的消息隊列（Topic）進行定時掃描。2）當掃描到消息數據時，根據數據標準協議完成數據解析。3）將解析后的數據根據應用場景進行加工處理，并將處理結果輸出到Redis內存數據庫中。4）繼續步驟（1），進行下一個消息隊列數據的掃描。

2.3 數據存儲

因傳統關系庫不能滿足實時系統快速響應的要求，該系統選擇Redis作為實時數據加工、分析結果數據存儲的數據庫。根據青島地鐵線網中心的業務需求，合理設計實時指標的數據存儲方式、數據過期策略等，向上層應用提供高速讀寫、穩定運行的數據服務。

3 離線數據處理

3.1 邏輯架構

離線數據處理架構如圖2所示。

3.2 數據清洗

配置工作流之前，首先要進行數據清洗[4]，數據清洗的流程分解為以下3步。

3.2.1 數據清洗、去重、轉換

數據處理的數據源頭被稱為貼源層，貼源層數據是各數據源業務系統的未加處理的數據合集。在未經處理之前，數據質量無法保證，需根據業務規則進行清洗，并去除重復的數據。各數據源業務系統通常由不同的供應商提供，各業務主體之間，甚至同一業務主體之間，都可能存在不同的業務編碼，這樣就給線網生產數據的融合造成了巨大的麻煩。數據轉換的目的是為青島地鐵的各上層應用提供一致的、規范的數據，對不同業務主體的業務數據進行統一的業務編碼，經清洗、去重和轉換后，寫入基礎明細層。

3.2.2 加工、分析

加工、分析是數據處理的核心，只有經過加工、分析，原始數據才能轉化為有效數據，成為有用的信息。

3.2.3 數據同步

把加工、分析結果同步到應用服務器，給上層應用提供數據服務。

3.3 配置工作流

工作流是對工作流程及其各操作步驟之間的業務規則的抽象、概括描述，是將工作流程中的工作，如何前后組織在一起的邏輯和規則[5]。由工作流的定義可以看出，工作流編制的重點是弄清楚工作的前后邏輯，為了弄清楚組織邏輯，可以按以下4個步驟進行。

3.3.1 業務梳理

如果把數據加工、分析的結果稱做指標，那么就可以區分出哪些指標是由基礎明細數據生成的，該類指標可稱為基礎指標。而對于由基礎指標生成的新指標，可稱為衍生指標。

3.3.2 依賴梳理

在梳理好業務，把加工指標區分為基礎指標、衍生指標后，畫出指標的依賴關系圖，如圖3所示。

根據依賴關系圖，我們可以定義工作流的Step1、Step2、Step3...StepN。

3.3.3 工作流粒度劃分

工作流粒度劃分可以分為縱向粒度劃分和橫向粒度劃分2種。縱向粒度劃分參照數據的依賴關系即可，如果所有工作流都按縱向劃分去設置，則存在數量大、配置麻煩、集群資源利用率不高等問題，而Oozie任務調度平臺既支持縱向依賴配置，也支持橫向并行配置。橫向粒度劃分在滿足縱向依賴的前提下，要考慮工作流的整體執行時長，不能因為其中一個任務的執行時間過長，導致所有工作流執行時間變長，因此選擇依賴相同、執行時長相似的任務是工作流橫向劃分的依據。

3.3.4 依賴條件檢查

在工作流的編制中，除了需要重點關注數據加工、分析的依賴關系外，還需要注意數據是否具備數據加工、分析的依賴條件，歷史數據的采集是按T+1（昨天）方式，按天增量采集，指標的加工、分析同樣是按照按天增量的方式加工、分析，在采集數據的過程中，存在很多不可控因素，導致數據不能按時采集到位，為了保證數據的正確性、完整性，在每個工作流開始執行之前，必須進行數據是否滿足依賴條件的檢查。

3.4 任務調度

在編制好數據加工、分析的工作流后，為了滿足數據中心7×24 h穩定運行的要求，需要按時對編制好的工作流任務進行調度。

3.5 數據存儲

Hive是基于Hadoop的數據倉庫工具，青島地鐵數據中心采用Hive作為數據倉庫，DB2作為集市層數據存儲媒介，為上層應用提供數據服務。按照業內廣泛采用的分層設計方式，核心區域劃分為基礎明細層、匯總層和集市層[6]。其在整個青島地鐵數據中心數據架構中處于數據服務層。分層設計的示意圖如圖4所示。

3.5.1 數據源層

數據源層定義了離線數據的數據來源和數據格式。

3.5.2 貼源層

貼源層實現了從采集到的文件數據到Hive表的關系映射，為基礎明細層數據的加工做好準備。

數據中心通過源系統的數據傳輸接口獲取源數據，根據不同的傳輸周期完成數據加載，加載方式包括實時加載、準實時加載和定時加載3種。為了保證數據能夠在短時間內完成數據入庫，同時降低對前端應用訪問數據倉庫數據的影響，在數據倉庫內設置了臨時數據區，即貼源層。在此基礎上，完成數據從貼源層到基礎明細層的數據轉換工作。

貼源層主要用于保存ACC、ATS和綜合監控等源系統的接口數據，尚未對數據進行加工和轉換，是基礎明細層的數據來源。與源系統不同的是，貼源層中包含了從不同線路、多個源系統中加載進來的接口數據，是源系統的未加處理的數據合集，實現了源系統數據的融合和可跨系統的查詢分析功能。

3.5.3 基礎明細層

基礎明細層是數據服務層中最重要的一個區域，其是按照地鐵數據標準的要求，對緩沖層數據進行統一加工和整合，是存儲明細粒度的歷史數據區域，可以為青島地鐵各個業務部門的不同業務需求提供一致的、規范的數據。同時，基礎明細層數據可作為匯總層和集市層的數據源，并可以直接向高級數據分析人員開放，進行深度地指標查詢、統計分析和數據挖掘。

基礎明細層需要結合各線路ATS、綜合監控和ACC等源系統的數據特征，切實考慮線網級城市軌道交通數據融合以及業務應用場景和發展需要，根據城市軌道交通行業的經驗，開發具有先進性、高可靠性、高可擴展性和高效性的數據模型，有效融合和存儲城市軌道交通的業務信息資源，支撐數據中心目前和未來各種運營管理和數據分析等應用場景。

從設計上來看，基礎明細層是數據中心的核心，需要支撐數據中心所有業務主題的數據存儲，同時支持主題域、實體和數據模型的擴展。城市軌道交通行業的數據模型是構建數據基礎明細層的核心，其需要能夠全面覆蓋交通行業的數據內容，有效支撐城市軌道交通行業的分析業務場景，滿足數據中心長期的業務發展需求，因此，基礎明細層數據模型要具有良好的開放性、可擴展性、易操作性。

從實現上來看，基礎明細層的建設要集合城市軌道交通業務及行業經驗，物理表結構設計參照交通行業的數據模型，考慮行業業務規則及擴展性要求，嚴格遵循第三范式（3NF）[7]，減少數據冗余，提高訪問效率。

3.5.4 匯總層

匯總層是從城市軌道交通業務需求的視角出發，提煉出對數據處理具有共性的數據訪問和統計分析的需求，從而構建出的一個面向上層應用、提供共性數據訪問服務的公共數據。其數據流向是從基礎明細層抽取數據，經過有針對性的匯總加工后，滿足上層業務的數據需求。

3.5.5 集市層

集市層是利用匯總層的公共數據，根據上層應用的需求，組合形成面向不同主題域的集市層。向上層應用提供有針對性的數據服務。集市層是從數據倉庫中抽取出來的為某類特定業務系統服務的數據集合，是數據倉庫與應用層之間的接口。

數據中心的集市層中主要包括面向生產管理的指標統計分析、運營評估、運營信息報送及發布、地理信息展示與應急指揮系統的集市層。從數據聚合的粒度考慮，數據中心的集市層是根據業務需要，而匯總的重度匯總數據，并根據具體需要實現在多個維度和多粒度層次上的匯總。集市層中的數據模型根據上層應用的需求特點，適當考慮增加數據冗余設計，以提高數據分析查詢的效率。

4 結語

隨著大數據技術的普及，未來線網中心的建設越來越有取代傳統數據倉庫的趨勢，青島地鐵作為國內首個基于大數據技術搭建線網中心的地鐵公司，在大數據技術應用的基礎上，實現了實時數據處理及離線數據處理流程，為未來城市軌道交通行業的相關應用提供技術路線和指導幫助。

參考文獻

[1]羅情平，左旭濤，舒軍.青島地鐵線網管理與指揮中心系統的需求分析[J].城市軌道交通研究，2017，20（12）：5-9.

[2]石述紅.信息時代的數據中心[J].數字通信世界，2018（11）：136.

[3]郭建偉，杜麗萍，李瑛，等.Hadoop平臺的分布式數據平臺系統研究[J].中國科技信息，2013（10）：97-98.

[4]Megan Squire.干凈的數據：數據清洗入門與實踐[M].北京：人民郵電出版社，2016.

[5]趙文，胡文蕙，張世琨，等.工作流元模型的研究與應用[J].軟件學報，2003，14（6）：1052-1059.

[6]馮曉云，陸建峰.基于Hive的分布式K_means算法設計與研究[J].計算機光盤軟件與應用，2013（21）：62-64.

[7]蘇選良.管理信息系統[M].北京：電子工業出版社，2003.