城市軌道交通線網能耗大數據平臺設計

王志心，李佑文，褚紅健，顏儒彬

（南京國電南自軌道交通工程有限公司，江蘇南京 210032）

0 引言

城市軌道交通是一種快捷高效、安全舒適的城市公共客運交通方式，其在解決城市交通擁擠和促進城市社會、經濟發展等方面具有極其重要的作用。同時，城市軌道交通也是耗能大戶，僅電費一項就占運營直接成本的?20%?左右。為了掌握用電情況，運營單位通常建設線路能源管理系統用于對全線用電參數進行采集、監控和存儲[1-2]。但隨著城市軌道交通網絡化運營的發展，目前的能源管理系統存在重復建設、相對封閉（只能實現單線路的采集和監測）、數據格式不一、統計分析方法較少等缺陷。

本文根據城市軌道交通能耗特點，構建了基于Hadoop的線網能耗大數據管理平臺。線網能耗平臺可以實現對線網所有線路用電參數以及能耗分析相關數據的采集、監測和存儲，有利于實現對線網能耗的管理、評估以及線路之間能耗的對比、考核和管理。同時可以節約建設成本，避免線路能源管理系統的重復建設。

1 平臺架構設計

線網能耗大數據平臺基于?Hadoop?技術實現，平臺架構如圖?1?所示。整個平臺由數據源、數據采集、數據處理、數據存儲、數據發布以及系統管理幾部分組成。下文中將對其中主要部分進行詳細描述。

1.1 數據接入

圖1 大數據平臺架構

線網能耗大數據平臺通過通信網絡連接各線路專業系統，實現對能耗及能耗分析相關的實時及歷史數據的采集。采集數據主要包括以下幾類：①線路?100??kV、35??kV、1??500?V、0.4??kV?等高低壓柜的電能數據；②線路各車站?BAS?系統環境參數；③車站通風空調系統中各類設備運營模式及運行參數；④線路各站客流數據；⑤其他數據。

為了緩解后臺服務器端的數據處理壓力，整個架構引入數據接入隊列系統來緩沖客戶端發送過來的消息，以供后續程序處理，并提供消息的實時處理和持久化保存。

本文所述的架構方案中，采用?KAFKA?作為數據采集接入的消息隊列系統。KAFKA?是一個分布式的消息發布訂閱系統，具有高吞吐、內置分區、容錯功能，所以特別適合大規模消息處理應用。KAFKA?邏輯結構如圖?2?所示。

圖2 KAFKA 邏輯結構

圖2中，消息的生產者創建消息數據，消息的消費者消費消息數據。生產者使用?push?模式將消息發布到?Broker，消費者使用?pull?模式從?Broker?訂閱并消費消息。數據按主題（Topic）進行劃分，本方案中各線路上傳數據按照線路、數據類型、實時或歷史數據等創建不同的分區，如?ISCS_TOPIC、PSCADA_TOPIC、EMS_TOPIC?等等。

1.2 數據處理

架構方案中，數據處理分為數據預處理和實時計算處理?2?個部分。基于?Hadoop?生態圈?Spark/Storm?流式計算框架，通過其多線程處理和高效的并行化任務使得數據處理過程的效率得到顯著提高。

消費者端從?KAFKA?Broker?中?pull?數據后，首先通過數據的預處理環節對數據的完整性及合理性進行檢驗，并對異常數據進行修正，處理內容包括：①數據數量應等于預期記錄的數據數量；②數據的時間順序符合預期的開始、結束時間，并且中間應連續；③數據進行越限檢驗，刪除越限數據，并以前一時刻數據代替；④所有經過修正的數據應以特殊標示記錄。

經過預處理環節的數據通過接口保存至?HBase?中，作為其底層基礎數據。同時一部分與實時業務相關的數據，發送至實時計算處理環節。實時計算處理部分的內容可根據能耗平臺的實時業務需要進行定制，一般包括實時能耗統計、實時總功率計算、能耗異常報警等等，實時計算的結果直接提供給業務系統使用。

1.3 數據存儲

1.3.1 HBase+Phoenix 架構設計

HBase[3]是以?HDFS?為底層存儲的分布式的列存儲數據庫，在非結構化、大數據存儲、分析方面具有很好的性能。但是?HBase?不支持?SQL?操作，只能利用其?API?進行操作，使用不便，使得應用業務通過性不好、開發成本較高。

Phoenix[4]是在?HBase?上構建?JAVA?中間件。通過Phoenix?可以使得業務應用像使用?SQL?訪問關系型數據庫一樣訪問?HBase，從而降低業務開發成本。Phoenix引擎將?SQL?查詢轉換為?1?個或多個?HBase?Scan，并編排執行以生成標準的?JDBC?結果集，規避了?Map-Reduce?框架的繁瑣計算過程，減少了查詢時間延遲，對?HBase?入侵性極小，也不影響?HBase?單獨使用的其他操作。相對于Hive?和?Impala?而言，Phoenix?的性能很高，對于簡單的低延遲查詢，其性能量級為?ms，對于百萬級別的行數來說，其性能量級為?s。

圖3 HBase+Phoenix 架構

如圖?3?所示，集群任務由?ZooKeeper?分布式應用程序協調服務統一調度，ZooKeeper?通過?2181?端口將任務傳給分布在?HBase?上層的?Phoenix，Phoenix?解析并執行任務內容，然后使用?JDBC?連接將處理好的任務通過?HMaster?傳給?HBase，最終任務數據通過?HBase?持久化存入?HDFS?中。

1.3.2 數據分層存儲

線網能耗大數據平臺需要存儲全線?3～5?年的歷史能耗數據，用于支撐數據查詢和統計分析功能。大量的數據簡單保存在歷史數據庫中，必然造成查詢搜索緩慢，且不利于數據庫的維護管理。本方案根據數據倉庫的分層管理思想，將數據分為基礎數據層、匯總數據層和專用數據層?3?層結構，并針對每一數據分層分別在HBase?中創建對應的命令空間。

基礎數據層保存經過預處理的基本能源數據，不同線路、專業的數據保存在不同的數據表中，表?1?為線路基礎能耗數據表。

表1 基礎能耗數據表（basic:line1_p）

如表?1?所示，HBase?通過行鍵（Row?Key）、列簇?（Column?Family）和列（Column）組成表結構。上表中根據HBase特性，將查詢的關鍵信息（車站?ID、設備ID、采樣時間、采樣類型等）拼接作為?KEY?鍵值以實現記錄的快速定位，滿足應用層復雜查詢。

匯總數據層將基礎數據按照能耗分類/分項/分戶（如線路、車站用電量，牽引、照明用電量等）以及不同時間粒度（小時、日、月、年用電量等）進行不同粒度的匯總統計，表?2?為線路分項用電統計表。

表2 線路分項用電統計表(mid:line_category_total)

專用數據層面向統計分析功能、能耗指標、報表等業務設計，通過定期對基礎數據和匯總數據運算統計并存儲，直接供各業務應用使用。

2 測試系統搭建

整個?Hadoop?生態圈由?4?臺惠普?DL580?Gen8?服務器搭建，分別在各個服務器內部署了?Hadoop?生態圈內的組件。服務器配置如表?3?所示。在實際工程應用中，線網能耗大數據平臺主要用于實現對線網各線路數據的實時采集以及對各類應用業務提供數據支撐。所以，本文模擬實際線網（16?條線路）能耗大數據平臺的數據容量分別進行數據采集及數據查詢兩方面的測試。

表3 服務器配置

2.1 數據采集測試

每臺服務器運行?4?個生產者、4?個消費者線程。假設各線路能耗數據來源于單一的業務系統，在?KAFKA集群內針對各線路分別劃分了主題，如?TOPIC_LIN1、TOPIC_LIN2?等，每個主題分為?3?個?Partition?分區，保留2?個副本進行存儲。

一般情況下，地鐵單線路中能耗數據點數（包括相電壓、線電壓、電流、功率、功率因素、電能等）在2?萬～5?萬點之間。本次測試按照不同的數據采集個數進行了多次模擬測試，多次測試平均值如表?4?所示。

表4 KAFKA 測試結果

根據上述測試結果，KAFKA?性能已經非常優異，其性能也遠遠高于一般的?JMS?產品。?同時?HBase?寫入性能很好、并行度高，在測試過程中，集群?CPU?資源使用率不超過?50%，磁盤繁忙程度大致在?70%～80%。測試結果表明，設計方案能夠滿足線網能耗數據平臺的業務需要。

2.2 數據查詢測試

本次查詢性能測試采用能耗點數據查詢作為測試用例。能耗點數據查詢即根據指定的能耗數據點?ID?從數據庫中查詢一段時間內的歷史能耗數據，通過記錄數據檢索所花費的時間評估數據查詢性能。

在?HBase?中，基礎能耗數據按照線路劃分，以月份為單位進行存儲，每條線路包含?5??000?電度量測點，采集周期?5??min，線路單月歷史能耗數據記錄為?5??000×288×30?=?4??320?萬條。

查詢測試語句：

SELECT?TIMESTAMP,VALUE?FROM?WHERE?DEVICEID=XXX?AND?TIMESTAMP>=XXX?AND?TIMESTAMP<=XXX

100?次查詢測試結果如表?5?所示：

表5 數據查詢測試結果 s

為更好地評估架構?HBase+Phoenix?的性能特點，本文采用上述基礎能耗數據表進行了并發測試，測試過程中模擬?100?用戶同時發起查詢操作，測試結果如表?6?所示：

表6 多用戶并發查詢測試結果 s

以上測試結果表明，?HBase?數據庫具有構建大表的優勢，并且使用?HBase+Phoenix?的組合架構能夠滿足業務對數據查詢的需要。

3 結語

本文根據城市軌道交通能耗特點，構建基于?Hadoop的線網能耗大數據平臺，實現對線網所有線路的用電參數以及能耗分析相關數據的采集、監測與存儲。文章中針對大數據平臺整理架構以及架構中數據接入、數據處理、數據存儲幾個部分進行了詳細說明，并通過搭建測試平臺對方案可行性進行了評估。測試結果表明，本方案能夠滿足對線網各線路數據的實時性要求以及對各類應用業務提供數據支撐。