城市軌道交通線網(wǎng)能耗大數(shù)據(jù)平臺(tái)設(shè)計(jì)

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

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

0 引言

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

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

1 平臺(tái)架構(gòu)設(shè)計(jì)

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

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

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

線網(wǎng)能耗大數(shù)據(jù)平臺(tái)通過通信網(wǎng)絡(luò)連接各線路專業(yè)系統(tǒng)，實(shí)現(xiàn)對(duì)能耗及能耗分析相關(guān)的實(shí)時(shí)及歷史數(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è)備運(yùn)營(yíng)模式及運(yùn)行參數(shù)；④線路各站客流數(shù)據(jù)；⑤其他數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

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

線網(wǎng)能耗大數(shù)據(jù)平臺(tái)需要存儲(chǔ)全線?3～5?年的歷史能耗數(shù)據(jù)，用于支撐數(shù)據(jù)查詢和統(tǒng)計(jì)分析功能。大量的數(shù)據(jù)簡(jiǎn)單保存在歷史數(shù)據(jù)庫(kù)中，必然造成查詢搜索緩慢，且不利于數(shù)據(jù)庫(kù)的維護(hù)管理。本方案根據(jù)數(shù)據(jù)倉(cāng)庫(kù)的分層管理思想，將數(shù)據(jù)分為基礎(chǔ)數(shù)據(jù)層、匯總數(shù)據(jù)層和專用數(shù)據(jù)層?3?層結(jié)構(gòu)，并針對(duì)每一數(shù)據(jù)分層分別在HBase?中創(chuàng)建對(duì)應(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、采樣時(shí)間、采樣類型等）拼接作為?KEY?鍵值以實(shí)現(xiàn)記錄的快速定位，滿足應(yīng)用層復(fù)雜查詢。

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

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

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

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

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

表3 服務(wù)器配置

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

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

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

表4 KAFKA 測(cè)試結(jié)果

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

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

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

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

查詢測(cè)試語句：

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

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

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

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

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

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

3 結(jié)語

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