基于“湖倉一體”技術的城軌大數據平臺設計與升級改造實踐

吳雁軍，光志瑞，李明華，陳建華

（北京市地鐵運營有限公司技術創新研究院分公司；地鐵運營安全保障技術北京市重點實驗室，北京 100082）

中國城市軌道交通行業經歷了近20 年的快速發展。截至2023 年6 月30 日，我國已有57 座城市開通了城市軌道交通線路，運營總里程已達10 566 km[1]，特別是北京、上海、廣州、深圳等超大型城市的軌道交通已全面進入規模化和網絡化運營階段。城市軌道交通業務復雜，空間上跨越車站、線路、線網三種維度，專業上覆蓋客流、行車、設備、供電、車輛、軌道等多種門類，關聯信息化系統有綜合監控系統(integrated supervision and control system，ISCS)、火災報警系統(fire alarm system，FAS)、環境與設備監控系統(building automatic system，BAS)、監控和數據采集系統(supervisory control and data acquisition，SCADA)、自動列車監控系統(automatic train supervision，ATS)、自動售檢票系統的清分中心(AFC clearing center，ACC)、多線路管理中心(multiple line center，MLC)、自動售檢票系統(automatic fare collection，AFC)等數十個，每天會產生海量多源異構數據[2]。如何將這些數據有機地結合起來，來滿足城市軌道交通快速發展產生的新需求，對城軌大數據平臺建設提出了巨大的挑戰。

一方面，城市軌道交通網絡化快速發展，使網絡化運營的調度指揮工作復雜程度大大增加，這對作為調度指揮系統“大腦”的數據中心平臺提出了極高的要求。另一方面，軌道交通運營時間超過10 年的城市已有15 座，其配套的數據平臺已經不能滿足軌道交通安全提升、品質提升、效率提升、效益提升的需求，大多面臨更新改造的問題。因此，如何升級改造既有數據中心平臺或建設新的大數據平臺，成為非常值得研究的課題。鑒于在城市軌道交通領域利用第三代大數據技術解決上述問題的研究成果并不多見，在參考軌道交通領域既有重要文獻[3]的基礎上，本文以城市軌道交通行業大數據平臺的建設與升級改造為場景，研究并提出基于最新“湖倉一體”大數據技術的城軌大數據平臺設計，助力城市軌道交通大數據體系的建設與完善。

1 城軌大數據平臺技術發展階段和現狀

1.1 城軌大數據平臺技術發展階段

城軌大數據平臺技術的發展與大數據技術自身的發展密不可分，到目前為止大致可分為3 個階段[4]，如圖1 所示。

圖1 大數據技術發展歷程Figure 1 Big data technology development history

第1 階段，數據倉庫(data warehouse)階段。數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策和信息的全局共享，面向聯機分析處理(on-line analytical processing，OLAP)，支持海量結構化數據的復雜分析。2011 年以前，城軌數據中心的核心任務是解決傳統關系型數據庫無法承載海量結構化數據復雜分析的難題，因此主流的城軌數據中心平臺搭建主要采用數據倉庫軟硬件一體機技術。例如，北京市軌道交通指揮中心線網指揮中心(traffic control center，TCC)二期數據中心平臺、廣州市軌道交通工程線網指揮平臺(comprehensive operation coordination center，COCC)一期數據中心平臺、深圳市軌道交通網絡運營控制中心(network operation control center，NOCC)一期數據中心平臺均采用Teradata Aster數據倉庫軟硬件一體機，西安地鐵線網(應急)指揮中心(network contingency and operating contrd center，NCC)一期采用Oracle ExaData 數據倉庫軟硬件一體機。數據倉庫擁有海量結構化數據的離線分析能力，但不支持非結構化數據分析，也不支持實時數據分析，導致數據中心平臺功能單一，主要用于指標計算與報表輸出，不能滿足調度指揮系統實時監控需求。

第2 階段，數據湖(data lake)[5]階段。隨著城軌業務的發展，在指標分析的基礎上實時監控和機器學習等新需求日增，這與數據倉庫只支持結構化歷史數據分析、不支持非結構數據、不支持實時分析的特性之間的矛盾日益突出。2011 年12 月，Hadoop 1.0.0 的發布開啟了基于數據湖技術搭建大數據平臺的新篇章。以Hadoop 為代表的數據湖技術構建的大數據平臺可以存儲任何形式(包括結構化、非結構化和半結構化)和任何格式(包括文本、音頻、視頻和圖像等)的原始數據。這使得數據湖能搭建真正的大規模數據平臺，數據存儲成本也更為廉價。憑借該優點，Hadoop 在數年間逐步取代數據倉庫軟硬件一體機建設方案，成為城軌數據中心建設的主流技術。例如，青島地鐵線網運營管理與指揮中心(metro management & command center，MMCC)一期數據中心平臺就采用Hadoop 技術搭建，很好地解決了數據倉庫不能處理非結構化數據、不支持流處理的問題。大數據平臺成為統一的基礎平臺，既能支持離線指標計算，也能支持調度指揮系統所需的實時監控。但Hadoop 本身并不支持結構化數據分析，使用Hadoop 生態HBase、Hive 等組件雖然可以實現類SQL 語句查詢，但不支持刪除、修改操作，且執行效率不高、開發煩瑣，不具備數據倉庫操作管理的便利性。

第3 階段，湖倉一體(data lakehouse)階段。隨著云計算技術的興起，依托云平臺的新一代數據倉庫——大規模并行處理數據庫(massively parallel processing，MPP)逐漸發展成熟。MPP 能彌補Hadoop 在結構化數據分析處理效率上的短板，因此，“Hadoop+MPP”混合架構理念被提出。例如，蘇州市軌道交通線網指揮中心(network control center，NCC)一期數據中心平臺利用Hadoop 技術實現非結構化數據的分布式存儲與實時計算，運用MPP 實現結構化數據的快速分析，在一定程度上解決了數據湖技術存在的問題。但“Hadoop+MPP”的模式只是數據湖與數據倉庫的簡單組合，兩套系統相對獨立，同時開發與維護兩套系統成本較高，且會造成數據冗余與邏輯不完全一致等問題，因此城軌數據中心亟需一套完美解決上述問題的方案。針對這一需求，2020 年“湖倉一體”概念被提出[4]。湖倉一體是一種通過一套數據湖倉組件實現數據湖和數據倉庫兩者優勢的新范式，借助數據湖的低成本存儲，實現與數據倉庫中類似的數據結構和數據管理功能，這使得真正打通數據倉庫和數據湖兩套體系、構建一套有機的大數據技術生態體系成為可能。

1.2 湖倉一體大數據平臺的技術特點

湖倉一體大數據平臺實現原理如圖2 所示。數據湖倉由兩部分組成：底層的數據湖作為存儲層，用來存儲包含結構化、半結構化和非結構化數據的任意種類數據；上層是由元數據、緩存、索引組成的數據管理層。數據管理層讀取底層的數據，通過對數據的抽取、轉化、加載(extract-transform-load，ETL)后，以接口的形式提供給上層應用訪問。這些接口分為3 大類：元數據接口、高性能SQL 接口以及申明性數據幀API 接口。其中，元數據接口實現數據湖倉對多源異構數據的統一管理，高性能SQL 接口提供高性能SQL引擎實現對數據分析、報表報告的支持，申明性數據幀接口實現對數據科學與機器學習的支持。

圖2 湖倉一體技術實現原理Figure 2 Implementation principle of the Data Lakehouse technology

數據倉庫、數據湖和湖倉一體3 種技術，在數據格式、數據類型、數據訪問、可靠性、應用場景支持等方面有明顯區別[6]，具體如表1 所示。

表1 大數據平臺構建技術對比Table 1 Comparison of Big Data platform construction technologies

從技術形態上來說，數據倉庫一般是獨立的標準化系統，如Teradata Aster 數倉軟硬件一體機、華為GaussDB for DWS。數據湖更像是一種架構指導，需要配合周邊工具來實現業務需要。Hadoop 是最常用的數據湖技術，Hadoop 生態豐富的組件為其提供了高效的工具。湖倉一體也是一種架構，以數據湖為中心，把數據湖作為中央存儲庫，再圍繞數據湖建立專用“數據服務環”，環上的服務包括了數據倉庫、大數據處理、機器學習、交互式查詢等一系列服務。目前，業界主流湖倉一體開源技術有Apache Iceberg、Apache Hudi 和Delta Lake。國內廠商也紛紛推出了自己的湖倉一體解決方案，如華為云FusionInsight、阿里云MaxCompute 等。

綜上所述，湖倉一體技術很好地避免了數據湖與數據倉庫的局限性。基于湖倉一體技術搭建的城軌大數據平臺有以下4 大優勢：

1) 存算分離。同時實現低成本與高性能。數據湖倉存儲層通過分布式存儲實現類似數據湖的大容量與低成本，計算層利用Hudi 等數據湖倉組件實現類似數據倉庫高性能分析能力，支持軌道交通海量數據低成本存儲、高效率分析。

2) 流批一體。同時支持實時處理與離線處理。平臺既能滿足海量離線數據的批處理計算需求(如夜間運行批處理計算前一天所有運營指標)，也能滿足實時數據的流處理計算需求(例如，持續處理當前進出站客流量，實時推算線網斷面客流等實時指標)，更好地支持運營狀態監控與分析。

3) OLAP+OLTP。同時支持聯機分析處理(online analytical processing，OLAP)與聯機事務處理(online transaction processing，OLTP)。平臺既能支持從數據湖倉獲取原始數據并在數據倉庫通過OLAP 進行復雜的分析挖掘，也能支持通過OLTP 將處理結果反饋回數據湖倉，及時更新數據源，更好地支持復雜運營場景科學決策。

4) 多重負載。同時支持數據分析與機器學習。通過統一的數據管理，平臺既能支持敏捷分析，也能支持人工智能，打通了數據分析與機器學習，使二者無縫集成，為AI 大模型新技術在軌交領域的應用創造了條件，為智慧地鐵建設提供堅實支撐。

2 架構設計

為了充分發揮“湖倉一體”技術的優勢，指導城軌大數據平臺的建設和升級改造，現結合城市軌道交通行業特點，從系統架構、部署架構與數據架構3 個方面開展分析。

2.1 系統架構

依據湖倉一體架構“存算分離、流批一體”的機制，城軌大數據平臺的總體架構可分為6 層(如圖3 所示)，自下而上分別是數據源、采集層、存儲層、計算層、服務層和應用層。

圖3 系統架構Figure 3 System architecture

2.1.1 數據源

數據源，即大數據平臺的數據來源系統，為大數據平臺提供了海量要存儲和應用的數據。數據源既包括ACC、ISCS 等生產系統，也包括OA 系統等管理系統，還包括氣象信息系統、航班與公交等其他交通方式信息系統[7]。

2.1.2 采集層

采集層，負責從數據源采集各類數據，然后傳遞給存儲層進行存儲。數據采集時，根據存儲結構類型不同分別采用不同的采集方式。對于結構化數據(如OA 系統的員工表)，可通過數據遷移采集；對于非結構化數據(如Excel 文件)，可通過FTP 服務采集，CCTV視頻流可通過流媒體服務器采集；對于半結構化數據(如Json 格式數據)，支持物聯網的系統可以通過物聯網網關系統采集，支持數據服務的系統可以通過訪問其API 接口采集，支持數據主動推送的系統可以通過消息隊列接收數據。

2.1.3 存儲層

存儲層，也就是數據湖倉的存儲部分，負責將采集層傳遞過來的數據進行存儲，數據湖倉應是企業中全量數據的單一存儲系統。數據按照時效性不同可分為實時數據、離線數據和近線數據。為了響應不同類似數據的存儲和應用特征，湖倉一體數據平臺中的存儲層設計了兩種存儲模式，即實時存儲和分布式存儲。對于實時數據，為了保障其時效性和讀取效率，通常將其保存在消息隊列或內存數據庫，如Kafka 或Redis；對于離線數據，為保證其安全性與并行性應采用分布式存儲[8]，也可以通過Hadoop 分布式文件系統(hadoop distributed system，HDFS)[9]或對象存儲服務來存儲；對于近線數據，可選內存數據庫也可以選分布式存儲，具體根據業務需求確定。

2.1.4 計算層

計算層，負責數據的處理、計算與管理。本層以Apache Iceberg、Apache Hudi 和Delta Lake 等數據湖倉組件為核心，以存儲層的分布式存儲作為支撐，利用流處理引擎與批處理引擎實現“流批一體”的數據處理機制，實現對在線分析(OLAP)與事務處理(on-line transaction processing，OLTP)的同時支持。流處理引擎用于以流處理的方式處理實時數據，常用的有Hadoop 生態的Flink 引擎和Spark Streaming 引擎；批處理引擎用于以批處理的方式處理離線數據，常用的有Hadoop 內置的MapReduce 引擎和Hadoop 生態的Spark 引擎。數據倉庫作為湖倉一體架構的重要組成部分也建在本層，目前最常用的數據倉庫是MPP，它同時支持行存儲與列存儲，支持事務處理機制，提供PB 級結構化數據的高效在線分析能力，在結構化數據的處理方面具有明顯優勢，是湖倉一體架構的重要補充。此外，為了豐富數據庫類型，本層還應部署NoSQL數據庫，如文檔型數據庫MongoDB、圖數據庫Neo4J；為了支持AI 計算，本層還應部署機器學習與深度學習平臺；為了滿足用戶的多樣化需求，還應部署內存計算引擎與交互式查詢引擎等。

2.1.5 服務層

服務層，集成湖倉一體大數據平臺對外提供服務。具體包括數據集成與開發、實時計算、離線計算、數據資產目錄、數據服務、數據科學、數據運維監管等一系列服務。

2.1.6 應用層

應用層，即使用大數據平臺的應用系統。大數據平臺為應用系統提供數據支持與算法、算力支持，但嚴格意義上，應用層不劃入大數據平臺。在城市軌道交通領域，核心的應用軟件有綜合決策平臺、智能運行平臺、智能客服平臺、智能運維平臺和主動安防平臺等智慧地鐵中心級平臺，以及智慧車站平臺、智慧車輛段平臺、智慧列車平臺等智慧地鐵現場級平臺。

在這6 層之外，還需要一些管理模塊提供數據治理與數據安全等公共服務，確保大數據平臺平穩、安全地運行。如圖3 系統架構所示，統一數據治理與統一資源管理模塊跨越大數據平臺采集層、存儲層和計算層，提供大數據平臺的數據管理服務；統一數據安全管理與統一授權管理模塊跨越采集層和服務層，提供對數據安全與用戶授權服務。

2.2 部署架構

城軌大數據平臺應部署在云平臺上[10]。云平臺為大數據平臺統一提供計算資源、存儲資源和安全資源[11]。大數據平臺按照所在云平臺的網絡空間可分為3 個域：安全生產域、內部管理域和外部服務域。具體部署架構如圖4 所示。

圖4 部署架構Figure 4 Deployment architecture

安全生產域連接AFC/MLC/ACC、ATS、ISCS、PSCADA、CCTV 等生產系統，獲取實時數據用于支撐實時監控與生產大數據分析，需要部署Hadoop 集群、MPP 集群、Redis 集群、kafka 集群和應用服務器。其中，Hadoop 集群需要部署Hudi 數據湖倉、Spark引擎、Flink 引擎等關鍵組件，以實現對“流批一體”數據處理能力和“多重負載”機器學習能力的支持。外部服務域主要用于發布面向互聯網用戶的服務和收發互聯網數據的接口服務程序，考慮現有業務對計算資源的需求并不大，僅考慮部署應用服務器和關系數據庫。內部管理域連接OA 系統、EAM 系統等管理系統，并接收從安全生產域輸入的生產數據，以及從外部服務域輸入的互聯網數據，進而實現三域數據的融合分析，因此需要部署安全生產域類似集群與組件。

2.3 數據架構

依據湖倉一體技術“存算分離、流批一體”的機制，按照城市軌道交通數據從采集、存儲、處理到展示的過程，城軌大數據平臺的數據架構可分為4 層(如圖5 所示)，自下而上分別是數據源、存儲層、計算層、展示層。

圖5 數據架構Figure 5 Data architecture

2.3.1 數據源

數據源，即大數據平臺的數據來源系統，與系統架構中的數據源一致。數據源包括各種生產系統、管理系統以及外部系統。這些系統為大數據平臺提供數據，但嚴格意義上不屬于大數據平臺。

2.3.2 存儲層

從數據源傳遞過來的數據在存儲層進行存儲，根據數據時效性不同分別采用不同的存儲方式。實時數據以消息的形式按專業分別保存在Kafka 消息隊列的對應主題下；離線數據以CSV 文件、日志文件、Parquet 列式存儲文件等形式保存在分布式文件系統(HDFS)或者對象存儲系統中，作為數據湖倉的底層；而近線數據可以根據業務需要任意選擇上述兩種方式。實時數據也可以根據業務需求通過累積的方式轉變為歷史數據，然后作為離線數據進行存儲。

2.3.3 計算層

數據在計算層進行處理、分析，形成分析結果，然后推送給展示層進行展示。對于離線數據，依托批處理引擎或流批一體引擎進行處理，在數據湖倉上層Hudi 等組件或MPP 中進行保存、分析。在數據湖倉中，從存儲層讀取的原始數據保存在原始層，分析過程的臨時數據保存在臨時層，分析結果保存在最終層。MPP 中的保存、分析與數據湖倉類似，只是3個內部層通常被稱為貼源層、明細層、匯總層。對于實時數據，從消息隊列kafka 讀取數據后，經流處理引擎或流批一體引擎處理，直接推給展示層進行展示。對于近線數據，同樣既可以當作離線數據也可以作為實時數據來處理、分析。

2.3.4 展示層

展示層將計算層的分析結果提供給上層應用進行展示。對于分析結果中的離線數據，按照專業分別保存到數據集市的對應域中，數據集市通常選擇關系型數據庫。對于分析結果中的實時數據，按照專業分別保存到內存數據庫的對應域中，內存數據庫通常選擇Redis 鍵值庫。對于分析結果中的近線數據，同樣既可以當作離線數據也可以作為實時數據來保存、展示。

3 應用案例

2022 年1 月，北京市地鐵運營有限公司在既有全量數據倉庫基礎上，在打造的下一代企業級大數據平臺中突破性地采用了湖倉一體架構設計，為智慧地鐵建設更好地提供數據與算法支撐。如圖6 所示，Hadoop 平臺的分布式文件系統(HDFS)具有提供海量多源異構數據的存儲能力作為數據湖倉的存儲層，Spark、Flink 等批處理和流處理引擎實現了對流處理與批處理的同時支持，Hudi 數據湖倉組件實現了在線分析(OLAP)與事務處理(OLTP)的同步支持，MPP 具有提供快速數據分析能力，既有全量數倉系統的接入確保了歷史數據的延續性。此外，統一的數據管理系統實現了湖倉共享存儲資源池，支持通過標準SQL 訪問跨域多源數據，支持數據科學與AI 訓練推理，減少了數據搬遷，實現了海量數據的快速價值挖掘。

圖6 大數據平臺總體架構Figure 6 Big data platform overall architecture diagram

在系統部署方面，大數據平臺基于云平臺部署，依照業務需求與網絡安全要求，在安全生產網和內部管理網均部署了數據湖倉集群(包含Hadoop 節點、Kafka節點、Redis 節點)、數據倉庫集群(即MPP 節點)和大數據業務集群(包含數據管理系統、各類大數據分析系統)，還在運維管理網部署了數據安全系統。在數據管理系統的協調下，打通了數據湖與數據倉庫，構建了一套擁有完整的、有機的湖倉一體大數據技術生態體系。

北京地鐵大數據平臺(見圖7)作為新一代數據平臺，與既有采用數據倉庫技術的全量數據倉庫系統相比，在4 方面取得了突破性改善(見表2)。

表2 兩代數據平臺對比Table 2 Comparison of the two generations of data platforms

圖7 北京地鐵大數據平臺部署架構Figure 7 Big data platform deployment architecture diagram

北京地鐵智慧地鐵大數據平臺作為企業級大數據平臺，接入了地鐵運營所涉及的全專業數據，依托“湖倉一體”技術，不但具有了強大的運營指標融合計算能力，還具有了高效的運營數據實時分析能力，同時通過對AI 平臺的數據支持，保障了人工智能模型優化能力，在提升地鐵運營水平的同時支撐了智慧地鐵建設諸多關鍵技術的科研攻關，為國家重點研發計劃“超大城市軌道交通系統高效運輸與安全服務關鍵技術”等項目的順利實施奠定了堅實的基礎，為北京地鐵的數字化轉型貢獻了力量，也為湖倉一體大數據平臺架構做了成功的驗證，為城軌大數據平臺建設與升級改造提供了新的解決方案。

4 結束語

本文研究了基于“湖倉一體”技術的大數據平臺升級改造設計要點，并在北京地鐵數據中心的大數據平臺升級改造中進行了應用驗證，取得了良好效果。需要強調的是，首先，湖倉一體并不等同于數據湖+數據倉庫。擁有數據湖和數據倉庫的大數據平臺必須具有統一的數據治理、統一的數據安全管理以及統一的資源管理等機制，將數據湖和數據倉庫有機地融合起來才是真正的湖倉一體架構。其次，湖倉一體大數據平臺架構在城市軌道交通領域的應用才剛剛起步，如何充分發揮數據湖倉組件的作用，使大數據平臺擺脫對大規模并行處理數據庫(MPP)的依賴還需進一步研究。總之，從發展趨勢來看，“湖倉一體”技術必將在城市軌道交通企業數字化轉型過程中發揮重要作用，值得繼續研究和不斷探索。