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

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

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

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

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

1 城軌大數(shù)據(jù)平臺技術(shù)發(fā)展階段和現(xiàn)狀

1.1 城軌大數(shù)據(jù)平臺技術(shù)發(fā)展階段

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

圖1 大數(shù)據(jù)技術(shù)發(fā)展歷程Figure 1 Big data technology development history

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

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

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

1.2 湖倉一體大數(shù)據(jù)平臺的技術(shù)特點

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

圖2 湖倉一體技術(shù)實現(xiàn)原理Figure 2 Implementation principle of the Data Lakehouse technology

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

表1 大數(shù)據(jù)平臺構(gòu)建技術(shù)對比Table 1 Comparison of Big Data platform construction technologies

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

綜上所述，湖倉一體技術(shù)很好地避免了數(shù)據(jù)湖與數(shù)據(jù)倉庫的局限性?；诤}一體技術(shù)搭建的城軌大數(shù)據(jù)平臺有以下4 大優(yōu)勢：

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

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

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

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

2 架構(gòu)設(shè)計

為了充分發(fā)揮“湖倉一體”技術(shù)的優(yōu)勢，指導(dǎo)城軌大數(shù)據(jù)平臺的建設(shè)和升級改造，現(xiàn)結(jié)合城市軌道交通行業(yè)特點，從系統(tǒng)架構(gòu)、部署架構(gòu)與數(shù)據(jù)架構(gòu)3 個方面開展分析。

2.1 系統(tǒng)架構(gòu)

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

圖3 系統(tǒng)架構(gòu)Figure 3 System architecture

2.1.1 數(shù)據(jù)源

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

2.1.2 采集層

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

2.1.3 存儲層

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

2.1.4 計算層

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

2.1.5 服務(wù)層

服務(wù)層，集成湖倉一體大數(shù)據(jù)平臺對外提供服務(wù)。具體包括數(shù)據(jù)集成與開發(fā)、實時計算、離線計算、數(shù)據(jù)資產(chǎn)目錄、數(shù)據(jù)服務(wù)、數(shù)據(jù)科學(xué)、數(shù)據(jù)運維監(jiān)管等一系列服務(wù)。

2.1.6 應(yīng)用層

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

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

2.2 部署架構(gòu)

城軌大數(shù)據(jù)平臺應(yīng)部署在云平臺上[10]。云平臺為大數(shù)據(jù)平臺統(tǒng)一提供計算資源、存儲資源和安全資源[11]。大數(shù)據(jù)平臺按照所在云平臺的網(wǎng)絡(luò)空間可分為3 個域：安全生產(chǎn)域、內(nèi)部管理域和外部服務(wù)域。具體部署架構(gòu)如圖4 所示。

圖4 部署架構(gòu)Figure 4 Deployment architecture

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

2.3 數(shù)據(jù)架構(gòu)

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

圖5 數(shù)據(jù)架構(gòu)Figure 5 Data architecture

2.3.1 數(shù)據(jù)源

數(shù)據(jù)源，即大數(shù)據(jù)平臺的數(shù)據(jù)來源系統(tǒng)，與系統(tǒng)架構(gòu)中的數(shù)據(jù)源一致。數(shù)據(jù)源包括各種生產(chǎn)系統(tǒng)、管理系統(tǒng)以及外部系統(tǒng)。這些系統(tǒng)為大數(shù)據(jù)平臺提供數(shù)據(jù)，但嚴格意義上不屬于大數(shù)據(jù)平臺。

2.3.2 存儲層

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

2.3.3 計算層

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

2.3.4 展示層

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

3 應(yīng)用案例

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

圖6 大數(shù)據(jù)平臺總體架構(gòu)Figure 6 Big data platform overall architecture diagram

在系統(tǒng)部署方面，大數(shù)據(jù)平臺基于云平臺部署，依照業(yè)務(wù)需求與網(wǎng)絡(luò)安全要求，在安全生產(chǎn)網(wǎng)和內(nèi)部管理網(wǎng)均部署了數(shù)據(jù)湖倉集群(包含Hadoop 節(jié)點、Kafka節(jié)點、Redis 節(jié)點)、數(shù)據(jù)倉庫集群(即MPP 節(jié)點)和大數(shù)據(jù)業(yè)務(wù)集群(包含數(shù)據(jù)管理系統(tǒng)、各類大數(shù)據(jù)分析系統(tǒng))，還在運維管理網(wǎng)部署了數(shù)據(jù)安全系統(tǒng)。在數(shù)據(jù)管理系統(tǒng)的協(xié)調(diào)下，打通了數(shù)據(jù)湖與數(shù)據(jù)倉庫，構(gòu)建了一套擁有完整的、有機的湖倉一體大數(shù)據(jù)技術(shù)生態(tài)體系。

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

表2 兩代數(shù)據(jù)平臺對比Table 2 Comparison of the two generations of data platforms

圖7 北京地鐵大數(shù)據(jù)平臺部署架構(gòu)Figure 7 Big data platform deployment architecture diagram

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

4 結(jié)束語

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