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

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

0 引言

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

本文根據(jù)城市軌道交通能耗特點，構(gòu)建了基于Hadoop的線網(wǎng)能耗大數(shù)據(jù)管理平臺。線網(wǎng)能耗平臺可以實現(xiàn)對線網(wǎng)所有線路用電參數(shù)以及能耗分析相關(guān)數(shù)據(jù)的采集、監(jiān)測和存儲，有利于實現(xiàn)對線網(wǎng)能耗的管理、評估以及線路之間能耗的對比、考核和管理。同時可以節(jié)約建設(shè)成本，避免線路能源管理系統(tǒng)的重復(fù)建設(shè)。

1 平臺架構(gòu)設(shè)計

線網(wǎng)能耗大數(shù)據(jù)平臺基于?Hadoop?技術(shù)實現(xiàn)，平臺架構(gòu)如圖?1?所示。整個平臺由數(shù)據(jù)源、數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)存儲、數(shù)據(jù)發(fā)布以及系統(tǒng)管理幾部分組成。下文中將對其中主要部分進行詳細(xì)描述。

1.1 數(shù)據(jù)接入

圖1 大數(shù)據(jù)平臺架構(gòu)

線網(wǎng)能耗大數(shù)據(jù)平臺通過通信網(wǎng)絡(luò)連接各線路專業(yè)系統(tǒng)，實現(xiàn)對能耗及能耗分析相關(guān)的實時及歷史數(shù)據(jù)的采集。采集數(shù)據(jù)主要包括以下幾類：①線路?100??kV、35??kV、1??500?V、0.4??kV?等高低壓柜的電能數(shù)據(jù)；②線路各車站?BAS?系統(tǒng)環(huán)境參數(shù)；③車站通風(fēng)空調(diào)系統(tǒng)中各類設(shè)備運營模式及運行參數(shù)；④線路各站客流數(shù)據(jù)；⑤其他數(shù)據(jù)。

為了緩解后臺服務(wù)器端的數(shù)據(jù)處理壓力，整個架構(gòu)引入數(shù)據(jù)接入隊列系統(tǒng)來緩沖客戶端發(fā)送過來的消息，以供后續(xù)程序處理，并提供消息的實時處理和持久化保存。

本文所述的架構(gòu)方案中，采用?KAFKA?作為數(shù)據(jù)采集接入的消息隊列系統(tǒng)。KAFKA?是一個分布式的消息發(fā)布訂閱系統(tǒng)，具有高吞吐、內(nèi)置分區(qū)、容錯功能，所以特別適合大規(guī)模消息處理應(yīng)用。KAFKA?邏輯結(jié)構(gòu)如圖?2?所示。

圖2 KAFKA 邏輯結(jié)構(gòu)

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

1.2 數(shù)據(jù)處理

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

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

經(jīng)過預(yù)處理環(huán)節(jié)的數(shù)據(jù)通過接口保存至?HBase?中，作為其底層基礎(chǔ)數(shù)據(jù)。同時一部分與實時業(yè)務(wù)相關(guān)的數(shù)據(jù)，發(fā)送至實時計算處理環(huán)節(jié)。實時計算處理部分的內(nèi)容可根據(jù)能耗平臺的實時業(yè)務(wù)需要進行定制，一般包括實時能耗統(tǒng)計、實時總功率計算、能耗異常報警等等，實時計算的結(jié)果直接提供給業(yè)務(wù)系統(tǒng)使用。

1.3 數(shù)據(jù)存儲

1.3.1 HBase+Phoenix 架構(gòu)設(shè)計

HBase[3]是以?HDFS?為底層存儲的分布式的列存儲數(shù)據(jù)庫，在非結(jié)構(gòu)化、大數(shù)據(jù)存儲、分析方面具有很好的性能。但是?HBase?不支持?SQL?操作，只能利用其?API?進行操作，使用不便，使得應(yīng)用業(yè)務(wù)通過性不好、開發(fā)成本較高。

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

圖3 HBase+Phoenix 架構(gòu)

如圖?3?所示，集群任務(wù)由?ZooKeeper?分布式應(yīng)用程序協(xié)調(diào)服務(wù)統(tǒng)一調(diào)度，ZooKeeper?通過?2181?端口將任務(wù)傳給分布在?HBase?上層的?Phoenix，Phoenix?解析并執(zhí)行任務(wù)內(nèi)容，然后使用?JDBC?連接將處理好的任務(wù)通過?HMaster?傳給?HBase，最終任務(wù)數(shù)據(jù)通過?HBase?持久化存入?HDFS?中。

1.3.2 數(shù)據(jù)分層存儲

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

基礎(chǔ)數(shù)據(jù)層保存經(jīng)過預(yù)處理的基本能源數(shù)據(jù)，不同線路、專業(yè)的數(shù)據(jù)保存在不同的數(shù)據(jù)表中，表?1?為線路基礎(chǔ)能耗數(shù)據(jù)表。

表1 基礎(chǔ)能耗數(shù)據(jù)表（basic:line1_p）

如表?1?所示，HBase?通過行鍵（Row?Key）、列簇?（Column?Family）和列（Column）組成表結(jié)構(gòu)。上表中根據(jù)HBase特性，將查詢的關(guān)鍵信息（車站?ID、設(shè)備ID、采樣時間、采樣類型等）拼接作為?KEY?鍵值以實現(xiàn)記錄的快速定位，滿足應(yīng)用層復(fù)雜查詢。

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

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

專用數(shù)據(jù)層面向統(tǒng)計分析功能、能耗指標(biāo)、報表等業(yè)務(wù)設(shè)計，通過定期對基礎(chǔ)數(shù)據(jù)和匯總數(shù)據(jù)運算統(tǒng)計并存儲，直接供各業(yè)務(wù)應(yīng)用使用。

2 測試系統(tǒng)搭建

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

表3 服務(wù)器配置

2.1 數(shù)據(jù)采集測試

每臺服務(wù)器運行?4?個生產(chǎn)者、4?個消費者線程。假設(shè)各線路能耗數(shù)據(jù)來源于單一的業(yè)務(wù)系統(tǒng)，在?KAFKA集群內(nèi)針對各線路分別劃分了主題，如?TOPIC_LIN1、TOPIC_LIN2?等，每個主題分為?3?個?Partition?分區(qū)，保留2?個副本進行存儲。

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

表4 KAFKA 測試結(jié)果

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

2.2 數(shù)據(jù)查詢測試

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

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

查詢測試語句：

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

100?次查詢測試結(jié)果如表?5?所示：

表5 數(shù)據(jù)查詢測試結(jié)果 s

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

表6 多用戶并發(fā)查詢測試結(jié)果 s

以上測試結(jié)果表明，?HBase?數(shù)據(jù)庫具有構(gòu)建大表的優(yōu)勢，并且使用?HBase+Phoenix?的組合架構(gòu)能夠滿足業(yè)務(wù)對數(shù)據(jù)查詢的需要。

3 結(jié)語

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