摘要
 

實(shí)現(xiàn)建筑精細(xì)化管理需要面向建筑能耗、環(huán)境、設(shè)備運(yùn)行和使用需求等海量數(shù)據(jù)。提出一種面向大數(shù)據(jù)的建筑能耗與環(huán)境實(shí)時(shí)管理云平臺(tái)架構(gòu)設(shè)計(jì)，通過(guò)應(yīng)用分布式消息中間件、分布式NewSQL數(shù)據(jù)庫(kù)、分布式計(jì)算框架等大數(shù)據(jù)技術(shù)，以及深度神經(jīng)網(wǎng)絡(luò)與機(jī)器學(xué)習(xí)框架等人工智能技術(shù)，滿足海量數(shù)據(jù)集成、存儲(chǔ)、處理和分析需求。這些成果可以為建筑高效運(yùn)行管理提供技術(shù)支撐。

 

關(guān)鍵詞

建筑能耗與環(huán)境；實(shí)時(shí)管理；系統(tǒng)架構(gòu)；大數(shù)據(jù)；分布式

 

 

 

1

背 景

我國(guó)國(guó)家機(jī)關(guān)和大型公共建筑能耗監(jiān)測(cè)系統(tǒng)建設(shè)示范覆蓋了30多個(gè)省、自治區(qū)、直轄市，以及計(jì)劃單列市，全國(guó)累計(jì)監(jiān)測(cè)11000余棟建筑[1]，已經(jīng)積累了大量的建筑能耗數(shù)據(jù)。但是，目前這些數(shù)據(jù)有效利用率不高，平臺(tái)價(jià)值未充分發(fā)揮。其中一個(gè)很重要的原因是建筑能耗監(jiān)測(cè)平臺(tái)數(shù)據(jù)全面性不夠，只有能耗數(shù)據(jù)，甚至只有分項(xiàng)電耗數(shù)據(jù)。要為建筑運(yùn)行管理提供更有效的數(shù)據(jù)支撐，應(yīng)充分采集建筑各種能耗數(shù)據(jù)、室內(nèi)外環(huán)境數(shù)據(jù)、機(jī)電設(shè)備運(yùn)行數(shù)據(jù)，以及人流等使用需求數(shù)據(jù)，但會(huì)造成數(shù)據(jù)量的急劇增長(zhǎng)，因而對(duì)平臺(tái)的數(shù)據(jù)集成能力、存儲(chǔ)能力、處理能力、分析能力和展現(xiàn)能力都提出了很大的挑戰(zhàn)。

 

2

建筑能耗與環(huán)境管理平臺(tái)新需求

建筑能耗與環(huán)境管理平臺(tái)要為建筑運(yùn)行管理提供更有效的技術(shù)支撐，面向的海量數(shù)據(jù)對(duì)此提出了新的要求。

 

（1）強(qiáng)大的數(shù)據(jù)集成能力：需要集成大量的建筑能源、室內(nèi)外環(huán)境、機(jī)電系統(tǒng)設(shè)備運(yùn)行數(shù)據(jù)以及使用需求。

 

（2）海量數(shù)據(jù)存儲(chǔ)和處理能力：平臺(tái)的存儲(chǔ)和處理能力應(yīng)該能夠進(jìn)行水平擴(kuò)展，以滿足海量數(shù)據(jù)存儲(chǔ)和處理的需求。

 

（3）智能的數(shù)據(jù)分析能力：集成機(jī)器學(xué)習(xí)、深度學(xué)習(xí)等人工智能技術(shù)，能夠基于大數(shù)據(jù)進(jìn)行建筑能耗預(yù)測(cè)、診斷和優(yōu)化等應(yīng)用。

 

（4）豐富的數(shù)據(jù)展現(xiàn)能力和友好易用的用戶界面：在Web端和移動(dòng)APP端為用戶提供多端應(yīng)用。

 

3

面向大數(shù)據(jù)的云平臺(tái)架構(gòu)設(shè)計(jì)

3.1 平臺(tái)總體架構(gòu)

為滿足海量數(shù)據(jù)傳輸、集成、存儲(chǔ)和分析需求，平臺(tái)采用大數(shù)據(jù)技術(shù)和人工智能技術(shù)構(gòu)建，總體架構(gòu)可分為數(shù)據(jù)集成、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)處理、數(shù)據(jù)分析、數(shù)據(jù)展現(xiàn)等，如圖1所示。

 

圖 1    面向大數(shù)據(jù)的云平臺(tái)總體架構(gòu)

 

（1）建筑的能源、環(huán)境和設(shè)備運(yùn)行實(shí)時(shí)數(shù)據(jù)傳輸?shù)椒植际较⒅虚g件，可同時(shí)支持MQTT協(xié)議、TCP協(xié)議和WebService協(xié)議接口。

 

（2）消息處理子系統(tǒng)從消息中間件中獲取數(shù)據(jù)，將數(shù)據(jù)緩存到Redis。

 

（3）數(shù)據(jù)存儲(chǔ)子系統(tǒng)將Redis中的數(shù)據(jù)定時(shí)持久化到數(shù)據(jù)庫(kù)。

 

（4）采用分布式數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)，支持分布式事務(wù)和水平彈性擴(kuò)展，可按需擴(kuò)展，有效應(yīng)對(duì)高并發(fā)、海量數(shù)據(jù)場(chǎng)景。

 

（5）采用分布式數(shù)據(jù)處理框架進(jìn)行匯總計(jì)算和指標(biāo)計(jì)算。

 

（6）基于機(jī)器學(xué)習(xí)庫(kù)、深度學(xué)習(xí)庫(kù)開發(fā)數(shù)據(jù)分析模塊，實(shí)現(xiàn)能耗預(yù)測(cè)、診斷和優(yōu)化運(yùn)行等數(shù)據(jù)分析應(yīng)用。

 

（7）Web服務(wù)為上層Web和APP提供數(shù)據(jù)服務(wù)，分布式緩存為數(shù)據(jù)訪問(wèn)加速。

 

3.2 數(shù)據(jù)集成

3.2.1 數(shù)據(jù)通信協(xié)議

目前公共建筑能耗監(jiān)測(cè)系統(tǒng)采用的是基于TCP的傳輸協(xié)議。TCP協(xié)議是底層傳輸協(xié)議，沒(méi)有定義QoS（QualityofService，服務(wù)質(zhì)量）。上海市住房和城鄉(xiāng)建設(shè)管理委員會(huì)DGJ08-2068─2017《公共建筑用能監(jiān)測(cè)系統(tǒng)工程技術(shù)標(biāo)準(zhǔn)》在國(guó)家住房和城鄉(xiāng)建設(shè)部《國(guó)家機(jī)關(guān)辦公建筑和大型公共建筑能耗監(jiān)測(cè)系統(tǒng)分項(xiàng)能耗數(shù)據(jù)傳輸技術(shù)導(dǎo)則》基礎(chǔ)上增加了WebService協(xié)議，便于建筑上傳能耗數(shù)據(jù)。WebService協(xié)議是一種基于TCP的通用協(xié)議，但WebService的處理開銷較大，不適合高頻率傳輸大量數(shù)據(jù)。

 

本平臺(tái)數(shù)據(jù)傳輸采用MQTT協(xié)議。MQTT協(xié)議已經(jīng)成為OASIS（結(jié)構(gòu)信息標(biāo)準(zhǔn)化促進(jìn)組織）標(biāo)準(zhǔn)（參見(jiàn)MQTT官方網(wǎng)站），是物聯(lián)網(wǎng)的重要組成部分。MQTT基于“發(fā)布/訂閱”模式的消息傳輸協(xié)議，是輕量級(jí)的M2M（Machine-to-Machine）通信協(xié)議，適合于低帶寬、不可靠連接、嵌入式設(shè)備、CPU/內(nèi)存資源緊張的場(chǎng)景。MQTT定義了0、1、2三種QoS服務(wù)質(zhì)量等級(jí)，可根據(jù)消息的重要程度確定QoS等級(jí)，同時(shí)MQTT的“發(fā)布/訂閱”模式可支持下行數(shù)據(jù)的傳輸，平臺(tái)可向數(shù)據(jù)采集器發(fā)送控制指令。

 

3.2.2 數(shù)據(jù)傳輸格式

現(xiàn)有能耗監(jiān)測(cè)系統(tǒng)采用XML數(shù)據(jù)傳輸格式，平臺(tái)和數(shù)據(jù)采集器之間采用JSON格式，同時(shí)兼容原有XML格式和通信協(xié)議。XML格式通用性強(qiáng)，但是處理開銷較大，不適合海量數(shù)據(jù)實(shí)時(shí)傳輸。JSON是一種輕量級(jí)的數(shù)據(jù)交換格式，比XML簡(jiǎn)潔，格式簡(jiǎn)單，占用帶寬較少，處理性能要求低，更適用于大量網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)膱?chǎng)景。

 

3.2.3 消息中間件

在分布式系統(tǒng)中廣泛運(yùn)用消息中間件進(jìn)行系統(tǒng)間的數(shù)據(jù)交換，主要解決應(yīng)用耦合、異步消息、流量削峰等問(wèn)題，以實(shí)現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)。消息中間件是大型分布式系統(tǒng)不可缺少的組件。建筑中的數(shù)據(jù)采集器發(fā)送的數(shù)據(jù)先進(jìn)入平臺(tái)的消息中間件，由消息處理程序進(jìn)行后續(xù)處理。

 

課題平臺(tái)采用Artemis消息中間件。Artemis是Apache基金會(huì)支持的開源項(xiàng)目，是高性能、支持集群的異步消息中間件，支持包括MQTT在內(nèi)的多種協(xié)議。Artemis既作為MQTT的服務(wù)端，同時(shí)也作為消息中間件，后期隨著數(shù)據(jù)量的擴(kuò)展，可以采用Kafka作為海量數(shù)據(jù)中間件。

 

3.3 數(shù)據(jù)緩存

為提高數(shù)據(jù)訪問(wèn)效率，對(duì)于平臺(tái)的實(shí)時(shí)數(shù)據(jù)使用數(shù)據(jù)緩存存放最新的能源和環(huán)境數(shù)據(jù)。目前流行的分布式緩存有Memcached、Redis。Redis支持的數(shù)據(jù)類型豐富，包括String（字符串）、List(鏈表)、Set(集合)、Zset（SortedSet，有序集合）和Hash（哈希類型）多種數(shù)據(jù)格式，支持?jǐn)?shù)據(jù)持久化，平臺(tái)采用Redis作為分布式緩存。

 

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

平臺(tái)的數(shù)據(jù)存儲(chǔ)需要數(shù)據(jù)庫(kù)支撐。數(shù)據(jù)庫(kù)可分為傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)、NoSQL數(shù)據(jù)庫(kù)、NewSQL數(shù)據(jù)庫(kù)等。分布式領(lǐng)域的CAP定理指出，在一個(gè)分布式系統(tǒng)中，Consistency（一致性）、Availability（可用性）、PartitionTolerance（分區(qū)容錯(cuò)性）三者不可兼得[2]。在大數(shù)據(jù)時(shí)代，傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)如Oracle、MSSQLServer、MySQL等，滿足一致性和可用性，但都面臨高并發(fā)讀寫和高可擴(kuò)展性、高可用性的挑戰(zhàn)——關(guān)系型數(shù)據(jù)庫(kù)難以處理海量數(shù)據(jù)。關(guān)系型數(shù)據(jù)庫(kù)的橫向擴(kuò)展通常采用主從復(fù)制、集群、分片（Sharding）等方法，但都有不足，面臨各種問(wèn)題。近年出現(xiàn)的NoSQL數(shù)據(jù)庫(kù)可以很好地支持海量數(shù)據(jù)擴(kuò)展，以滿足海量數(shù)據(jù)存儲(chǔ)需求。NoSQL有高擴(kuò)展性、高可用性、無(wú)預(yù)定義模式的特點(diǎn)，但是不支持SQL語(yǔ)句、不支持事務(wù)、不支持ACID(原子性、一致性、隔離性和持久性)，且每種NoSQL有自己的API，很難規(guī)范應(yīng)用程序接口，同時(shí)原有開發(fā)模式需要做較大的改變。

 

針對(duì)NoSQL的不足，近年來(lái)出現(xiàn)了NewSQL數(shù)據(jù)庫(kù)，如谷歌的GoogleSpanner/F1、阿里巴巴OceanBase、TiDB、CockroachDB等。它們不僅具有NoSQL對(duì)海量數(shù)據(jù)的存儲(chǔ)管理能力，還保持了傳統(tǒng)數(shù)據(jù)庫(kù)支持ACID和SQL等特性。

 

3.5 數(shù)據(jù)庫(kù)

平臺(tái)采用TiDB數(shù)據(jù)庫(kù)。TiDB是新一代開源分布式NewSQL數(shù)據(jù)庫(kù)，實(shí)現(xiàn)了自動(dòng)的水平伸縮、強(qiáng)一致性的分布式事務(wù)、基于Raft算法的多副本復(fù)制等重要的NewSQL特性。TiDB結(jié)合了關(guān)系型數(shù)據(jù)庫(kù)和NoSQL的優(yōu)點(diǎn)，部署簡(jiǎn)單，在線彈性擴(kuò)容和異步表結(jié)構(gòu)變更不影響業(yè)務(wù)，通過(guò)異地多活及自動(dòng)故障恢復(fù)保障數(shù)據(jù)安全，同時(shí)兼容MySQL協(xié)議，使遷移使用成本降到極低。平臺(tái)通過(guò)TiDB同時(shí)滿足海量數(shù)據(jù)實(shí)時(shí)寫入、實(shí)時(shí)查詢以及數(shù)據(jù)在線分析需求。

 

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

常規(guī)數(shù)據(jù)處理技術(shù)已無(wú)法滿足平臺(tái)海量數(shù)據(jù)處理要求，平臺(tái)采用分布式數(shù)據(jù)處理技術(shù)提高計(jì)算性能。分布式計(jì)算將一個(gè)龐大的計(jì)算任務(wù)劃分為若干個(gè)子任務(wù)，然后為計(jì)算機(jī)網(wǎng)絡(luò)中的計(jì)算節(jié)點(diǎn)分別分配一部分子任務(wù)，通過(guò)并行處理提高處理效率，最后綜合整理計(jì)算數(shù)據(jù)，得到最后的計(jì)算結(jié)果。

 

3.6.1 分布式計(jì)算優(yōu)點(diǎn)

與集中式計(jì)算相比，分布式計(jì)算有以下優(yōu)點(diǎn)：①分布式網(wǎng)絡(luò)中的每臺(tái)機(jī)器都能存儲(chǔ)和處理數(shù)據(jù)，降低了對(duì)機(jī)器性能的要求，所以不必購(gòu)買昂貴的高性能機(jī)器，可以大大降低硬件投資成本；②擴(kuò)展性好，在當(dāng)前系統(tǒng)存儲(chǔ)或計(jì)算能力不足時(shí)，可以簡(jiǎn)單地通過(guò)增加廉價(jià)PC機(jī)的方式來(lái)增加系統(tǒng)的處理和存儲(chǔ)能力；③處理能力極強(qiáng)，龐大的計(jì)算任務(wù)可以在合理分割后由分布式網(wǎng)絡(luò)中的機(jī)器并行地處理。

 

3.6.2 平臺(tái)數(shù)據(jù)處理的兩種類型

平臺(tái)數(shù)據(jù)處理分為批量處理和實(shí)時(shí)計(jì)算兩種類型。

 

（1）批量計(jì)算。對(duì)于小時(shí)、日、月、年等定時(shí)計(jì)算任務(wù)采用批量計(jì)算。平臺(tái)采用Spark作為分布式數(shù)據(jù)處理引擎。Spark是一個(gè)新興大數(shù)據(jù)處理引擎，與Hadoop比較，Spark采用的有向無(wú)環(huán)圖（DAG）計(jì)算模型比Hadoop的Mapreduce計(jì)算模型有更廣泛的適用性，同時(shí)Spark通過(guò)在內(nèi)存中緩存數(shù)據(jù)，提高迭代式計(jì)算的性能，比Hadoop的運(yùn)行速度有極大提高。Spark同時(shí)為批處理(SparkCore)、交互式（SparkSQL）、流式（SparkStreaming）、機(jī)器學(xué)習(xí)（Mllib）、圖計(jì)算（Graphx）提供了統(tǒng)一的數(shù)據(jù)處理平臺(tái)。Tispark是將SparkSQL直接運(yùn)行在分布式存儲(chǔ)引擎Tikv上的OLAP解決方案。借助Spark平臺(tái)，同時(shí)融合Tikv分布式集群的優(yōu)勢(shì)，與Tidb一起為用戶一站式滿足HTAP(HybridTransactional/AnalyticalProcessing)需求。

 

（2）實(shí)時(shí)計(jì)算。批量計(jì)算面向的是海量離線數(shù)據(jù)的處理與分析，主要針對(duì)一段時(shí)期內(nèi)采集與存儲(chǔ)的靜態(tài)數(shù)據(jù)，數(shù)據(jù)總吞吐量較好，但不適用于持續(xù)到達(dá)的數(shù)據(jù)流。對(duì)于需要進(jìn)行實(shí)時(shí)處理的數(shù)據(jù)采用SparkStreaming、Storm、Flink等流式計(jì)算框架進(jìn)行實(shí)時(shí)計(jì)算。實(shí)時(shí)計(jì)算系統(tǒng)不斷地接收數(shù)據(jù)采集系統(tǒng)持續(xù)發(fā)來(lái)的數(shù)據(jù)流、實(shí)時(shí)地進(jìn)行處理與分析，并及時(shí)反饋結(jié)果，以滿足對(duì)數(shù)據(jù)處理有較高實(shí)時(shí)性要求的場(chǎng)景。實(shí)時(shí)計(jì)算系統(tǒng)輸出的數(shù)據(jù)，可視情況進(jìn)行存儲(chǔ)，以便之后進(jìn)一步分析與應(yīng)用。

 

3.7  數(shù)據(jù)分析

數(shù)據(jù)分析功能是平臺(tái)支撐建筑運(yùn)行管理的關(guān)鍵，平臺(tái)通過(guò)機(jī)器學(xué)習(xí)和深度學(xué)習(xí)框架支持其數(shù)據(jù)分析功能。目前常用的機(jī)器學(xué)習(xí)庫(kù)有SparkMLlib、Scikit-Learn等機(jī)器學(xué)習(xí)庫(kù)，可支持線性回歸、邏輯回歸、樸素貝葉斯、K-means、kNN（k-最近鄰）、決策樹、支持向量機(jī)（SVM）、Boosting等常用機(jī)器學(xué)習(xí)算法。深度學(xué)習(xí)框架有GoogleTensorFlow、微軟CNTK、MXNet、FacebookCaffe2、Caffe、Torch、PyTorch、百度PaddlePaddle、Keras等多種開源框架。其中TensorFlow應(yīng)用最為廣泛，平臺(tái)應(yīng)用TensorFlow開發(fā)數(shù)據(jù)分析應(yīng)用子系統(tǒng)，實(shí)現(xiàn)能耗預(yù)測(cè)和分析診斷功能。

 

3.8 數(shù)據(jù)展現(xiàn)

數(shù)據(jù)展現(xiàn)層為用戶提供基于Web和APP的用戶界面，對(duì)該層的設(shè)計(jì)具有以下特點(diǎn)。

 

（1）前后端分離的RESTful風(fēng)格架構(gòu)。前端頁(yè)面和后臺(tái)程序接口采用前后端分離的RESTful風(fēng)格架構(gòu)，數(shù)據(jù)通過(guò)JSON格式進(jìn)行數(shù)據(jù)交換。RESTful架構(gòu)設(shè)計(jì)具有以下特性：①無(wú)狀態(tài)，每個(gè)請(qǐng)求都必須包含所有必需的信息；②資源，應(yīng)用程序數(shù)據(jù)和功能可以劃分為各種資源，每種資源對(duì)應(yīng)一個(gè)特定的URI；③狀態(tài)轉(zhuǎn)化（操作），采用HTTP協(xié)議的GET、POST、PUT、DELETE動(dòng)作表示操作。

 

（2）前端組件化。前端采用成熟的Vue框架，基于HTML5技術(shù)開發(fā)。Vue是一套用于構(gòu)建用戶界面的漸進(jìn)式框架，具有雙向數(shù)據(jù)綁定和組件化開發(fā)功能。與現(xiàn)代化的工具鏈以及各種支持類庫(kù)結(jié)合使用，Vue能夠?yàn)閺?fù)雜的單頁(yè)應(yīng)用提供驅(qū)動(dòng)。

 

（3）后端微服務(wù)化。微服務(wù)架構(gòu)模式將大型的、復(fù)雜的應(yīng)用程序構(gòu)建為一組相互配合的服務(wù)，微服務(wù)之間通過(guò)RESTAPI形式的接口或者消息隊(duì)列進(jìn)行整合。整個(gè)系統(tǒng)由很多微服務(wù)構(gòu)成，因此具備更高的敏捷性、可伸縮性和可用性；系統(tǒng)可以水平擴(kuò)展，從而降低了對(duì)各服務(wù)進(jìn)行局部改良和快速迭代的難度。

 

4

結(jié)    語(yǔ)

本文提出一種面向大數(shù)據(jù)的建筑能耗和環(huán)境實(shí)時(shí)管理云平臺(tái)架構(gòu)設(shè)計(jì)。通過(guò)應(yīng)用物聯(lián)網(wǎng)協(xié)議、分布式消息中間件、分布式數(shù)據(jù)庫(kù)、分布式計(jì)算等大數(shù)據(jù)技術(shù)以及人工智能技術(shù)，提供較強(qiáng)的海量數(shù)據(jù)采集、存儲(chǔ)、處理和分析能力。在后續(xù)工作中，將在平臺(tái)基礎(chǔ)上結(jié)合機(jī)電系統(tǒng)、空調(diào)系統(tǒng)等專業(yè)知識(shí)和數(shù)據(jù)以及人工智能技術(shù)，開發(fā)節(jié)能診斷、能源管理、環(huán)境管理、設(shè)備運(yùn)行優(yōu)化等專業(yè)應(yīng)用，為建筑智慧運(yùn)行奠定基礎(chǔ)。

 

參考文獻(xiàn)

[1]丁洪濤,劉海柱,殷帥.我國(guó)公共建筑節(jié)能監(jiān)管平臺(tái)建設(shè)現(xiàn)狀及趨勢(shì)研究[J].建設(shè)科技,2017(23):10-11.

[2]GILBERTS,LYNCHN.Brewer'sconjectureandthefeasibilityofconsistent,available,partition-tolerantwebservices[J].ACMSIGACTNews,2002,33(2):51-59.

 

基金項(xiàng)目

國(guó)家重點(diǎn)研發(fā)計(jì)劃項(xiàng)目“基于全過(guò)程的大數(shù)據(jù)綠色建筑管理技術(shù)研究與示范”（2017YFC0704200），上海市建筑科學(xué)研究院（集團(tuán)）有限公司科研創(chuàng)新項(xiàng)目“面向智慧園區(qū)的通用實(shí)時(shí)計(jì)算與數(shù)據(jù)平臺(tái)關(guān)鍵技術(shù)研究”（M5.10）資助

 

作者簡(jiǎn)介

陳勤平，教授級(jí)高工，現(xiàn)供職于上海市建筑科學(xué)研究院，主要研究方向?yàn)榻ㄖ畔⒒敖ㄖ?jié)能。