城軌線網指揮中心的大數據組織

徐 煒，張 寧，王 健，章瀾嵐，婁永梅

（1.東南大學自動化學院，南京 210018；2.東南大學智能運輸系統研究中心軌道交通研究所，南京 210018；3.南京地鐵建設有限責任公司，南京 210024；4.南京熊貓信息產業有限公司，南京 210008，5.北京全路通信信號研究設計院集團有限公司，北京 100070）

1 概述

隨著城市進程不斷推進，線網規模的不斷擴大，機器學習、人工智能數據驅動型新興技術蓬勃發展，各地城市軌道交通逐步進入網絡化、智能化運營時代。當前城市軌道交通擁有多個相互孤立的且極為復雜的業務系統，雖然通過數據治理，形成了行業范圍統一的數據標準和數據質量管理體系，初步解決了“信息孤島”問題[1]，但是未經合理規劃組織的數據難以保證數據分析和挖掘的效率，也很難保證以后運營應用需求的拓展。

線網指揮中心(Network Control Center,NCC)作為城市軌道交通運營調度體系的最高指揮機構，主要面向常態監管和應急調度，負責對下屬各區域控制中心(Operating Control Center,OCC)及相關單位進行集中監控和調度管理，為各級各專業運營維護人員和乘客提供更為優質的運營決策支撐和信息服務。線網指揮中心集中了來自于內部業務系統、協同部門、外部系統的海量多源異構數據[2-4]，需要通過分布式環境下合理的大數據組織，保證決策支持的可靠性和時效性，提高查詢效率，建成擴展性強、抗源變化的大數據平臺。

近年來，國內外城市軌道交通線網指揮中心建設研究主要針對自動售檢票系統、綜合監控系統、智能維護系統等特定系統或應用的業務功能需求和相關數據組織管理[5-9]，缺少全行業的、綜合的大數據組織方面的研究。目前，北京、上海、廣州、南京等城市線網指揮中心已建成并應用，為大數據組織相關標準的形成積累了設計和實施的經驗。

本文以南京地鐵線網指揮中心建設為例，從需求分析、主題域確定、數據維度設計、數據粒度設計等方面詳細分析和討論了城市軌道交通線網指揮中心的大數據組織要求。旨在從數據倉庫底層打破“煙囪式”平臺系統架構，統籌數據協調組織。

2 軌道交通業務梳理

為避免系統重復建設、提高平臺建設效率、符合運營管理人員使用習慣，在進行數據組織之前，需要對城市軌道交通業務流程和需求、技術條件、企業文化等充分調研，并從功能需求和數據需求兩個方面進行梳理。

2.1 軌道交通業務需求

在網絡化運營時期，城市軌道交通精細化管理正面臨著規劃建設，線網運能匹配、客流引導、資源配置、維護維修、緊急事件協調處理等運營組織，地鐵運營服務信息個性化等一系列亟待解決的問題。在正常情況下，線網指揮中心負責對各線路系統設備和運營狀態以及監控位置，對跨線資源進行集中調度和管理；在故障、事故等緊急狀態下，負責線網的運力調配和應急指揮工作。實現提高線網運營管理精細化水平和乘客服務水平的目標。

線網指揮中心業務功能包含了：1)監督職能：監督線網各種運維狀態；2)應急職能：突發事件協調指揮調度跟蹤；3)協調職能：統籌協調內外部部門合作；4)信息管理：信息的收集、核實、傳遞、上報和發布等；5)指標管理：運營生產指標數據的計算、統計、分析和評估等；6)資源調配：跨線資源的協調調配等，涵蓋數據信息服務、決策支撐、統計分析3個方面功能。

2.2 軌道交通數據需求

通過對軌道交通業務需求的梳理，線網指揮平臺不僅需要采集線網基礎信息、客流、行車、供電、視頻圖像、設備設施、突發事件等內部數據，還需要接入氣象、地質、社會安全事件、大型活動、公共交通等外部數據。源數據的完備程度、可獲得性、規范性、完整性、時效性、顆粒度是數據需求分析的重點，判斷數據的支撐程度和業務需求實現的可能性。這些海量多源異構數據只有經過數據轉換、數據拆分、數據整合等數據治理環節形成規范化的標準數據之后才能進行有效的大數據組織。

3 大數據主題設計

在業務探索和數據探索的基礎上，即可劃分主題域，構建數據的邏輯架構和物理架構。除了底層面向整個企業的數據倉庫采用第三范式建模以外，面向特定部門的數據集市通常采用維度建模。根據業務梳理的結果，將南京城市軌道交通線網指揮中心的系統劃分為十一個主題域。其中具體內容如表1 所示。

表1 主題域具體內容Tab.1 Specific contents of subject domain

主題域和主題域之間存在的關系描述如圖1所示。主題域中的事實表的內容主要是城市軌道交通運營生產相關的指標。

4 大數據維度設計

數據的維度設計面向特定主題，主要包括確定維度的存儲編號和描述信息兩方面內容。由于數據倉庫維度建模的靈活性較差，當業務發生變化時，需要重新進行維度的定義，因而數據維度的層級結構設計和物理存儲設計需要格外細致。

4.1 數據維度的層次結構設計

多維數據模型在數據倉庫中廣為應用，典型數據模型包括星型模式、雪花模式和星座模式。其中，星型模式以事實表為中心，所有維度表直接連接在事實表上。該模式因經過數據預處理，組織直觀，執行效率高；雪花模式是對星型模式的擴展，每個維度表可以向外連接到多個詳細類別表，對有關維度進行詳細描述，達到縮小事實表，提高查詢效率的目的，該模型更為規范，但維護成本較高，性能會有所降低；星座模式基于多張事實表，且共享一致性維度信息，避免了冗余和數據復用。南京地鐵線網指揮中心選擇在一致性和性能之間取得平衡的星座模式設計數據維度，圍繞當前主題下的指標數據，共享時間、空間、票卡類型等通用維度表，實現規范、高效的數據分析和管理。

圖1 主題域關系示意圖Fig.1 Schematic diagram for the relationship of subject domain

4.2 數據維度的存儲設計

依據存儲數據維度信息的大小和變化頻率，需要采用相匹配的數據物理存儲結構，具體包含以下幾種類型。

緩慢變化維(Slow Changing Dimension)：維度中大部分屬性不變化或者很少變化，僅需要定時更新或者按需更新。線網基礎信息中線路維度、車站維度、斷面維度，時間維度、票卡類型維度等均屬于緩慢變化維度。為了應對城市軌道交通未來錯綜復雜、易變且精細化決策需求，可通過在記錄中添加有效時間起止日期、有效標志位等冗余字段應對維度中的數據變化。既能簡單過濾出維度的當前值，提高查詢效率，又方便關聯歷史任一時刻下的事實數據進行對比分析和挖掘。

快速變化維(Rapidly Changing Dimension)：維度中的屬性數據頻繁變化。設備設施維度是城市軌道交通中比較常見的快速變化維，需要將這些快速變化的屬性分裂成一個或多個單獨的屬性，并在事實表中使用多個關鍵字關聯。

大維(Huge Dimension)和迷你維(Mini Dimension)：這兩類維度依據數據量的多少進行區分。在采用分布式架構的數據倉庫中，大維表數據通過選擇合理的分區鍵，保證數據跨所有分區平均分布和連接匹配的數據位于同一分區，避免發生跨分區的數據遷移和重定向，優化連接處理和并行查詢的效率。迷你維表數據較少，連接時將表中數據發送到所有需要的數據分區中。

退化維(Degenerate Dimension)：維度的內容一般是編號數據，僅需要保持在事實表中，而不需要建立對應的維度表。軌道交通的票卡編號維度、交易編號維度、日期維度等均屬于退化維。

5 數據粒度設計

數據粒度是對數據維度的進一步細化，反映了事實表的明細程度[10-11]。在數據倉庫粒度設計的過程中應優先遵循保留不可細分的原子粒度的業務數據的原則，滿足未來不確定的業務需求。小粒度數據不利于存儲、查詢和分析，可以進一步將實時粒度數據整合、匯總成為概要性數據并進行存儲。而大粒度數據不利于決策，不能成為底層細節數據的替代品。同時，單一粒度數據難以滿足多種業務場景的應用需要，因而，有必要基于業務分析模型，確定數據粒度表，對城市軌道交通線網指揮中心數據倉庫中的海量數據進行多重粒度設計，分別應用于企業級數據倉庫和部門級數據集市中。

5.1 多重粒度

數據粒度決定了數據倉庫中的數據容量和線網指揮平臺運營決策支撐的能力。但具體決策應用對數據粒度級別的要求并不一致。如：短時客流預測、線網客流仿真和列車運行圖評估等功能采用低粒度級別的明細客流數據進行分析和運算，而線網規劃決策等功能則采用高粒度級別的匯總客流數據進行評估和分析。這就需要在數據倉庫中采用多重粒度針對不同級別的決策需求提供相應粒度級別的數據，一方面滿足數據存儲空間的要求，另一方面滿足數據查詢、分析、挖掘性能和效果的要求。一般而言，在企業級的數據倉庫中存儲較低粒度級別的數據，在部門級的數據集市中存儲高粒度級別的數據。具體對照如表2所示。

表2 數據倉庫中的多重粒度Tab.2 Multiple granularity in data warehouse

5.2 粒度表設計

采用多重粒度的數據倉庫需要通過數據表的形式管理數據粒度，可以改善數據倉庫的存儲結構，減少數據存儲、更新過程的工作量，提高存儲、查詢和分析的效率。確定數據粒度表，首先需要依據現有系統現狀和未來可預見的需求確定可接受的最小粒度級別、可存儲的數據量和數據粒度劃分策略，進而定義數據粒度表的維度、索引、粒度級別、映射關系等粒度表的關鍵元素。

以南京地鐵線網指揮中心數據倉庫中的時間粒度為例，時間維度的粒度表包含了索引、粒度級別、統計開始時間、統計結束時間、描述、各粒度級別之間索引的相互映射關系等字段。具體內容如表3所示。

6 結語

大數據組織是應對快速增長的數據規模和未來運營業務功能拓展、銜接數據倉庫數據治理和數據挖掘應用之間的必要環節，可以有效降低系統維護的復雜性，改善數據倉庫的存儲結構，提高查詢、分析、運算的效率，支持未來可變的決策需求。本文從需求分析、主題域設計、數據維度設計、數據粒度設計四個方面，以南京地鐵線網指揮中心為例，對數據倉庫的大數據組織進行了詳細分析和討論，研究成果成功應用的同時，由于業務需求和應用技術的發展會對數據組織不斷產生新的要求，也為未來可預見的應用系統留有充分的裕量。

表3 城市軌道交通時間維度粒度表Tab.3 Table for time dimension granularity of urban rail transit