基于數據倉庫的北京軌道交通數據中心測試平臺

張義鑫 楊 軍 張 靜 程丹丹

(1.北京城建設計研究總院有限責任公司 北京 100037;2.北京軌道交通路網指揮中心 北京 100101)

1 數據倉庫的應用背景

隨著數據倉庫(data warehouse，DW)技術應用的不斷深入，越來越多的企業開始使用數據倉庫技術來搭建自己的數據庫系統。但每個行業都有自己的運行特點、專屬業務范圍及特定的歷史數據，因此企業在制訂數據倉庫的解決方案時，必須緊密結合本行業的特點及自身業務的發展需求，基于實際的測試案例，對不同設備進行認真比選后再做恰當的選擇。

伴隨著信息化項目建設的逐年增長，城市軌道交通也必將邁向“數字交通時代”。線網規模的擴大、網絡化的運營，使線路和車站之間實現了互聯、互通、資源共享，交通管理工作的壓力日益增加，傳統的單純以數據為中心構造的數據庫系統已經不能完全滿足現代交通管理工作發展的需求，迫切需要以新的理念和新的技術構建新的數據中心。

具體到北京地鐵，作為市內最重要的客運系統，過去幾年，軌道交通指揮部門已積累了大量的數據，數據總量呈現出指數級別的增長。但目前各個系統相對獨立，數據由各系統獨立管理和使用，產生了諸如數據孤立、不能形成多維網絡式數據對比、缺乏數據深入挖掘的狀況，造成了一定程度的數據浪費。如何提升信息化水準，借助現代化、智能化的信息管理技術，對提高交通管理水平具有十分重要的意義。

目前，已有同行對道路交通數據中心的建設進行了研究:程新謙等從北京市道路交通管理系統的應用現狀出發，分析了道路交通中數據中心的功能，并提出了具體的實現思路［1］;梁玉慶等針對北京市道路交通管理系統中信息資源孤立和浪費的問題，提出了基于數據倉庫的交通信息發布系統，闡述了系統構架方案，并進行了系統實現分析［2］。但這些對數據倉庫的應用研究大都還局限于道路交通領域，且只是對數據中心架構及功能實現進行了介紹，關于系統平臺設計以及前期如何搭建測試環境都沒有論述。可以說，數據倉庫應用于軌道交通領域，國內還沒有這方面的實踐。

筆者從城市軌道交通信息中心項目對數據倉庫技術的相關要求出發，結合業內在數據倉庫選擇前通常會進行的POC(proof of concept，概念原型驗證)測試，基于對業界主流MPP(massive parallel processing，大規模并行處理)數據倉庫的調研分析，搭建了軌道交通環境下完整的測試平臺，并借此完成了對數據倉庫主流廠家的實際測試，這對今后軌道交通信息中心項目的實施有一定的借鑒意義。

2 數據中心概況及存在的問題

隨著北京市軌道交通建設的快速發展，軌道交通已經逐漸成網。為提高全市軌道交通網絡的綜合協調能力，合理有效地利用資源，實現網絡化和多運營商的運營管理，北京市政府出臺了有關規定，并于2008年奧運前構建并成立了一個可以協調指揮北京軌道交通全網的指揮中心，即北京市軌道交通路網指揮中心。該中心由軌道交通調度指揮中心(traffic control center，TCC)、自動售檢票系統清算管理中心(AFC clearing center，ACC)兩大核心業務系統構成，承擔全線網信息的匯總及分析、運營監管、突發事件處置、票務清分清算等職責。

指揮中心建有輔助決策數據庫系統，基于存儲的軌道交通運營信息，可實現數據采集、綜合監視、信息交換、資料管理、統計分析等功能。但目前北京市軌道交通內部各系統數據大多只具有某一專門用途，如“客流信息類數據”、“列車運行信息類數據”及“清算信息類數據”等都處于分散、獨立的狀態，不能得到統一的分析和處理，大大降低了它們的用途。隨著交通管理人員對決策信息的需求日益廣泛，傳統的數據庫系統已無法滿足海量數據分析發展的需要。

1)數據庫系統無法滿足大量即席查詢、復雜查詢的需求。數據庫系統可實現數據庫內數據的增、刪、改及簡單查詢、報表生成等工作，所執行的查詢種類和報表內容/格式都需要信息系統管理人員預先設定。然而，業務人員的需求是不斷變化的，隨著對實時查詢、復雜查詢和新增報表需求的提出，信息系統管理人員不得不對原數據庫系統進行修改，重新編寫各種報表生成程序，浪費了大量的時間和精力。而且，開發更新的速度總滯后于用戶需求的變化速度，開發瓶頸已成為信息管理人員及時、準確、靈活使用數據庫系統的主要障礙。

2)現有數據庫系統無法滿足海量數據信息分析處理的需求。現有數據庫系統都是聯機事務處理系統(on-line transaction processing，OLTP)，而非聯機分析處理系統(on-line analytical processing，OLAP)。OLTP 數據庫系統的主要功能是對數據庫內數據的收集、簡單查詢和報表生成，對查詢得到的數據信息缺乏深入分析的能力。OLAP系統在擁有了完整的數據采集和存儲過程后，除了需快速地對數據進行增、刪、改、查之類的事務型處理，更關注的是長期運營信息的趨勢及變化分析，能夠在大量歷史數據的支持下，對某一主題的相關數據進行多角度比較，從中找出數據之間的內在聯系，得出科學的分析結果。目前，數據庫系統難以滿足對海量數據聯機分析處理的需求。

3)現有數據庫系統無法適應對研究對象進行多維靈活查詢。對于軌道交通信息分析人員，統計查詢分析需要靈活地指定時間維度、空間維度、票種維度等維度信息。如在粒度選擇中，可設定需要查詢指標的時間粒度、空間粒度、票種粒度，可以選擇的時間粒度最小到1 min，最大到年;可以選擇的空間“粒度”最小到設備，最大到線網;可選擇票種的“粒度”最小為單一票種的羅列，最大為全票種輸出。目前，數據庫系統難以適應用戶的“多粒度”要求。

4)現有數據庫系統無法滿足軌道交通運營信息膨脹、數據一體化整合的需求。隨著北京市軌道交通建設迎來新的發展，2010年新開通5條線之后，TCC、ACC系統的數據容量及分析處理能力接近飽和，需要更為強大的系統支持業務分析的發展。同時，由于目前TCC、ACC分屬于不同的業務領域，數據的分開存儲不利于數據進行一體化分析，難以形成客流、行車、設備管理等方面的合力，難以提高軌道交通網絡化運營管理水平，因此需要進行一體化整合。

當前，北京市軌道交通又掀起了新一輪建設高潮。軌道交通線路建設的規模、時序均超過了原來的預期，線網規模的擴大和發展，對網絡化的集中指揮、智能化管理、資源共享等提出了更高的要求。為了更好地科學管理網絡化的軌道交通系統，北京市交通委在《北京市交通科技創新規劃(2010—2015)》中，明確提出要開展軌道交通網絡化技術研究，以科技創新方式來確保軌道交通的規劃、建設、運營、維護的科學性、先進性和可靠性。可以說，以新的理念和技術構建基于數據倉庫的數據中心，使其具備足夠的靈活性和可擴展性，為交通管理的業務工作和領導的指揮決策提供支持，在整個交通管理信息化建設工作中具有重要的意義。

3 數據倉庫測試平臺的搭建

3.1 數據倉庫的關鍵技術

數據倉庫技術作為數據庫領域的分支，是后續的數據分析和數據挖掘的基礎，目的是把信息訪問從一種非結構化的或發展中的環境改變成一種結構化的或規劃良好的環境［3-4］。數據倉庫是面向主題的、集成的、不可更新的，它隨時間的變化而不斷變化，數據倉庫的構建方法［5］如圖1所示。

圖1 數據倉庫構建方法

可以說，數據倉庫是整個基于信息整合和數據挖掘的交通信息系統的核心，在數據源系統和后續的數據分析、挖掘中起著關鍵作用，合理的利用可以很好地解決OLTP和OLAP系統在計算資源和存儲信息方面的不同應用要求，更有效地實現數據挖掘和分析。

從數據倉庫的建模可引申出數據倉庫的運行架構，主要包括數據采集接口、ETL(extract transform and load)模塊、數據倉庫管理模塊、ODS(operational data store)系統、數據倉庫和數據集市以及為后續數據分析和挖掘提供的數據訪問接口。

本測試平臺的設計盡量經歷數據倉庫建模的全過程，旨在了解主流數據倉庫的新技術、新特點，加深對主流數據倉庫的認識;在熟悉主流數據倉庫的安裝、配置和使用的基礎上，研究不同數據倉庫產品的性能;最終為信息中心系統方案設計提供參考。

3.2 測試系統的拓撲設計

測試以信息中心項目需求為導向，從技術角度研究主流數據倉庫產品滿足需求的情況;按照公平公正的原則，到指定地點、按統一模式進行集中測試。

測試模擬了數據從源系統經加載至數據倉庫本地，進行建庫、建表，最終完成整套測試流程的全過程，測試拓撲見圖2。

圖2 測試平臺拓撲結構

測試硬件環境包括測試加載服務器、壓力測試服務器、磁盤陣列、千兆網絡交換機、各廠家的數據倉庫設備，以及準備的測試數據、測試用例及其他必要條件。

從測試系統拓撲設計可看出，信息中心數據倉庫體系大體可包括數據源、數據的獲取與集成、倉庫數據管理和數據應用服務4方面。

1)數據源(磁盤陣列)。主要以地鐵進/出站數據、計劃行車時刻表、行車時刻統計信息表為基礎，獲取各種動、靜態交通信息。這些數據存放于磁盤陣列的不同目錄下，需通過建表、建庫模型，對不同源數據進行抽取和聚集，形成多維視角［6］，為后續性能測試提供一個綜合的、面向分析的決策支持數據環境。

2)數據獲取與集成(數據加載服務器)。即ETL過程［7］，實際系統中不同數據源都是為各自應用而建立的，數據管理手段、硬件設備不盡相同，數據在編碼、命名、類型和語義等方面不可避免地存在沖突。本次測試在原始表結構基礎上進行相應改動，模擬了原始數據，通過ETL對數據進行轉換、清洗的預處理，再將數據加載到DW中。

3)倉庫數據管理(管理主機+節點服務器)。地鐵數據中心要求實現運營數據的實時監測，能做到分鐘級源數據加載和展示，要求操作界面良好，系統升級方便、高效。該處旨在查看系統本身是否具備對服務器、磁盤資源的監測管理功能，是否可動態管理系統各類資源，以保證系統性能的最優化。

4)數據應用服務(應用服務器)。主要包括:一是檢驗DW的整體性能，考察數據倉庫平臺是否支持線性擴展，且同時滿足OLTP/OLAP性能;二是模擬今后大量的前端應用、仿真建模對數據倉庫的數據高并發訪問;三是作為地鐵運營指揮中心，需提供7×24 h的不間斷服務，因此數據倉庫需具備高可用性。

3.3 測試內容及用例

3.3.1 測試內容

結合地鐵實際業務需求及本次測試重點，設計了以下內容，測試內容說明如圖3所示，各階段用例設計見表1。

圖3 測試內容說明

表1 測試步驟及內容設計

1)數據裝載/卸載測試。考察大數據量裝載/卸載效率，查看在加載一定數據量情況下的數據裝載(單獨裝載、并發裝載、實時裝載)效率和數據卸載效率。

2)SQL性能測試。對數據倉庫進行高并發、大數據量的操作，查看在此壓力情況下，數據倉庫的請求響應時間和資源消耗情況。

3)可擴展性測試。在計算、存儲、網絡資源一定的情況下，進行數據量線性擴展，其擴展過程能否做到快速高效、性能是否線性變化。

4)高可用性測試。在模擬服務器出現故障(系統盤、數據盤、網絡、存儲節點)的情況下，對服務的影響及快速恢復能力如何。

5)數據壓縮測試:測試數據倉庫對壓縮功能的支持程度(性能調優后的壓縮比為準)，以及壓縮后的能力及效率。

6)易管理性測試:考察系統安裝配置時間和可管理的程度。

3.3.2 測試用例

測試用例基于設計的數據表結構，以規范的SQL語句描述，一方面結合業務要求設計了地鐵實時業務、近線業務、離線業務的邏輯功能，另一方面也盡可能體現不同數據倉庫系統性能差異及自身特點。設計的測試ACC、TCC測試用例見表2～表3。

3.4 測試流程及結果記錄

數據倉庫是一個復雜的系統，要對系統功能進行全面測試，測試場景的構建將會十分復雜，并且可能存在測試案例重復與覆蓋不全面的問題。本次設計的測試流程如圖4所示。

表2 TCC測試用例設計

表3 ACC測試用例設計

本次測試基于3次大的數據量加載，分別進行性能特征的測試;數據加載與性能測試按序進行，每一次數據記載后都輪詢測試案例，提取每輪獨立的性能特征。這樣，在測試一定鋪底數據下個別業務性能的同時，又可縱向體現出大數據壓力下數據倉庫的擴展能力，保證了測試工作省時、省力、高效地運行。

整個測試嚴格按照流程圖所排的順序進行，性能測試對應的測試案例以規范的SQL形式給出。針對不同的測試內容，提取相關的測試用例，測試內容見表1，測試用例說明見表2～表3，測試結果記錄見表4。

4 結語

數據倉庫系統是一項綜合性的技術和解決方案，集成了數據存儲統計、聯機分析處理等多種數據處理技術。作為數字化城市軌道交通系統中的重要一環，北京軌道交通路網指揮中心在長期工作中積累了大量數據，利用數據倉庫技術實現了運營信息的高度集成共享，能為決策者提供完整、及時、準確、可信的決策信息，對提高業務決策水平及加速全市交通信息化發展具有重大的推動作用。

圖4 測試流程設計

表4 測試用例結果記錄

筆者結合當前北京軌道交通路網指揮中心建設信息中心的現狀，分析了數據倉庫建設的必要性，并提煉和總結了適于軌道交通行業數據倉庫測試的一般流程;從業務需求出發，完成了數據倉庫測試系統的拓撲設計、測試內容、測試案例及總體測試方案設計。測試平臺設計可以為企業數據倉庫的實際應用及現場測試方案的設計提供參考，為今后軌道交通信息中心類項目的實施提供一定的借鑒。

［1］程新謙.基于數據倉庫的北京智能交通管理數據中心系統分析［J］.道路交通與安全，2009，9(5):22-26.

［2］梁玉慶，沙濱.基于數據倉庫的交通信息發布系統［J］.道路交通與安全，2008(6):1-3.

［3］Inmon W H.Building the data warehouse［M］，4 ed.John Wiley＆Sons Inc，2005:21-23

［4］陳蘭芳.智能數據倉庫的設計方法［J］.中國計算機用戶，2006(5):48-48.

［5］彭曉剛.建設企業級數據倉庫［J］.金融電子化，2007:52-54.

［6］樊涓筑，張凡.數據倉庫技術在地鐵交通系統中的應用［J］.貴州工業大學學報:自然科學版，2006，35(2):83-87.

［7］繆嘉嘉，鄧蘇，劉青寶.ETL 綜述［J］.計算機工程，2004，30(3):14-22.