智能建筑|面向大數(shù)據(jù)的建筑能耗與環(huán)境實時管理云平臺架構(gòu)設(shè)計

文章來源:綠色建筑陳勤平,秦 俊2019-04-30 14:36

摘要
 
實現(xiàn)建筑精細化管理需要面向建筑能耗、環(huán)境、設(shè)備運行和使用需求等海量數(shù)據(jù)。提出一種面向大數(shù)據(jù)的建筑能耗與環(huán)境實時管理云平臺架構(gòu)設(shè)計,通過應(yīng)用分布式消息中間件、分布式NewSQL數(shù)據(jù)庫、分布式計算框架等大數(shù)據(jù)技術(shù),以及深度神經(jīng)網(wǎng)絡(luò)與機器學(xué)習框架等人工智能技術(shù),滿足海量數(shù)據(jù)集成、存儲、處理和分析需求。這些成果可以為建筑高效運行管理提供技術(shù)支撐。
 
關(guān)鍵詞
建筑能耗與環(huán)境;實時管理;系統(tǒng)架構(gòu);大數(shù)據(jù);分布式
 
 
 
1
背 景
我國國家機關(guān)和大型公共建筑能耗監(jiān)測系統(tǒng)建設(shè)示范覆蓋了30多個省、自治區(qū)、直轄市,以及計劃單列市,全國累計監(jiān)測11000余棟建筑[1],已經(jīng)積累了大量的建筑能耗數(shù)據(jù)。但是,目前這些數(shù)據(jù)有效利用率不高,平臺價值未充分發(fā)揮。其中一個很重要的原因是建筑能耗監(jiān)測平臺數(shù)據(jù)全面性不夠,只有能耗數(shù)據(jù),甚至只有分項電耗數(shù)據(jù)。要為建筑運行管理提供更有效的數(shù)據(jù)支撐,應(yīng)充分采集建筑各種能耗數(shù)據(jù)、室內(nèi)外環(huán)境數(shù)據(jù)、機電設(shè)備運行數(shù)據(jù),以及人流等使用需求數(shù)據(jù),但會造成數(shù)據(jù)量的急劇增長,因而對平臺的數(shù)據(jù)集成能力、存儲能力、處理能力、分析能力和展現(xiàn)能力都提出了很大的挑戰(zhàn)。
 
2
建筑能耗與環(huán)境管理平臺新需求
建筑能耗與環(huán)境管理平臺要為建筑運行管理提供更有效的技術(shù)支撐,面向的海量數(shù)據(jù)對此提出了新的要求。
 
(1)強大的數(shù)據(jù)集成能力:需要集成大量的建筑能源、室內(nèi)外環(huán)境、機電系統(tǒng)設(shè)備運行數(shù)據(jù)以及使用需求。
 
(2)海量數(shù)據(jù)存儲和處理能力:平臺的存儲和處理能力應(yīng)該能夠進行水平擴展,以滿足海量數(shù)據(jù)存儲和處理的需求。
 
(3)智能的數(shù)據(jù)分析能力:集成機器學(xué)習、深度學(xué)習等人工智能技術(shù),能夠基于大數(shù)據(jù)進行建筑能耗預(yù)測、診斷和優(yōu)化等應(yīng)用。
 
(4)豐富的數(shù)據(jù)展現(xiàn)能力和友好易用的用戶界面:在Web端和移動APP端為用戶提供多端應(yīng)用。
 
3
面向大數(shù)據(jù)的云平臺架構(gòu)設(shè)計
3.1 平臺總體架構(gòu)
為滿足海量數(shù)據(jù)傳輸、集成、存儲和分析需求,平臺采用大數(shù)據(jù)技術(shù)和人工智能技術(shù)構(gòu)建,總體架構(gòu)可分為數(shù)據(jù)集成、數(shù)據(jù)存儲、數(shù)據(jù)處理、數(shù)據(jù)分析、數(shù)據(jù)展現(xiàn)等,如圖1所示。
 
圖 1    面向大數(shù)據(jù)的云平臺總體架構(gòu)
 
(1)建筑的能源、環(huán)境和設(shè)備運行實時數(shù)據(jù)傳輸?shù)椒植际较⒅虚g件,可同時支持MQTT協(xié)議、TCP協(xié)議和WebService協(xié)議接口。
 
(2)消息處理子系統(tǒng)從消息中間件中獲取數(shù)據(jù),將數(shù)據(jù)緩存到Redis。
 
(3)數(shù)據(jù)存儲子系統(tǒng)將Redis中的數(shù)據(jù)定時持久化到數(shù)據(jù)庫。
 
(4)采用分布式數(shù)據(jù)庫存儲數(shù)據(jù),支持分布式事務(wù)和水平彈性擴展,可按需擴展,有效應(yīng)對高并發(fā)、海量數(shù)據(jù)場景。
 
(5)采用分布式數(shù)據(jù)處理框架進行匯總計算和指標計算。
 
(6)基于機器學(xué)習庫、深度學(xué)習庫開發(fā)數(shù)據(jù)分析模塊,實現(xiàn)能耗預(yù)測、診斷和優(yōu)化運行等數(shù)據(jù)分析應(yīng)用。
 
(7)Web服務(wù)為上層Web和APP提供數(shù)據(jù)服務(wù),分布式緩存為數(shù)據(jù)訪問加速。
 
3.2 數(shù)據(jù)集成
3.2.1 數(shù)據(jù)通信協(xié)議
目前公共建筑能耗監(jiān)測系統(tǒng)采用的是基于TCP的傳輸協(xié)議。TCP協(xié)議是底層傳輸協(xié)議,沒有定義QoS(QualityofService,服務(wù)質(zhì)量)。上海市住房和城鄉(xiāng)建設(shè)管理委員會DGJ08-2068─2017《公共建筑用能監(jiān)測系統(tǒng)工程技術(shù)標準》在國家住房和城鄉(xiāng)建設(shè)部《國家機關(guān)辦公建筑和大型公共建筑能耗監(jiān)測系統(tǒng)分項能耗數(shù)據(jù)傳輸技術(shù)導(dǎo)則》基礎(chǔ)上增加了WebService協(xié)議,便于建筑上傳能耗數(shù)據(jù)。WebService協(xié)議是一種基于TCP的通用協(xié)議,但WebService的處理開銷較大,不適合高頻率傳輸大量數(shù)據(jù)。
 
本平臺數(shù)據(jù)傳輸采用MQTT協(xié)議。MQTT協(xié)議已經(jīng)成為OASIS(結(jié)構(gòu)信息標準化促進組織)標準(參見MQTT官方網(wǎng)站),是物聯(lián)網(wǎng)的重要組成部分。MQTT基于“發(fā)布/訂閱”模式的消息傳輸協(xié)議,是輕量級的M2M(Machine-to-Machine)通信協(xié)議,適合于低帶寬、不可靠連接、嵌入式設(shè)備、CPU/內(nèi)存資源緊張的場景。MQTT定義了0、1、2三種QoS服務(wù)質(zhì)量等級,可根據(jù)消息的重要程度確定QoS等級,同時MQTT的“發(fā)布/訂閱”模式可支持下行數(shù)據(jù)的傳輸,平臺可向數(shù)據(jù)采集器發(fā)送控制指令。
 
3.2.2 數(shù)據(jù)傳輸格式
現(xiàn)有能耗監(jiān)測系統(tǒng)采用XML數(shù)據(jù)傳輸格式,平臺和數(shù)據(jù)采集器之間采用JSON格式,同時兼容原有XML格式和通信協(xié)議。XML格式通用性強,但是處理開銷較大,不適合海量數(shù)據(jù)實時傳輸。JSON是一種輕量級的數(shù)據(jù)交換格式,比XML簡潔,格式簡單,占用帶寬較少,處理性能要求低,更適用于大量網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)膱鼍啊?/div>
 
3.2.3 消息中間件
在分布式系統(tǒng)中廣泛運用消息中間件進行系統(tǒng)間的數(shù)據(jù)交換,主要解決應(yīng)用耦合、異步消息、流量削峰等問題,以實現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)。消息中間件是大型分布式系統(tǒng)不可缺少的組件。建筑中的數(shù)據(jù)采集器發(fā)送的數(shù)據(jù)先進入平臺的消息中間件,由消息處理程序進行后續(xù)處理。
 
課題平臺采用Artemis消息中間件。Artemis是Apache基金會支持的開源項目,是高性能、支持集群的異步消息中間件,支持包括MQTT在內(nèi)的多種協(xié)議。Artemis既作為MQTT的服務(wù)端,同時也作為消息中間件,后期隨著數(shù)據(jù)量的擴展,可以采用Kafka作為海量數(shù)據(jù)中間件。
 
3.3 數(shù)據(jù)緩存
為提高數(shù)據(jù)訪問效率,對于平臺的實時數(shù)據(jù)使用數(shù)據(jù)緩存存放最新的能源和環(huán)境數(shù)據(jù)。目前流行的分布式緩存有Memcached、Redis。Redis支持的數(shù)據(jù)類型豐富,包括String(字符串)、List(鏈表)、Set(集合)、Zset(SortedSet,有序集合)和Hash(哈希類型)多種數(shù)據(jù)格式,支持數(shù)據(jù)持久化,平臺采用Redis作為分布式緩存。
 
3.4 數(shù)據(jù)存儲
平臺的數(shù)據(jù)存儲需要數(shù)據(jù)庫支撐。數(shù)據(jù)庫可分為傳統(tǒng)關(guān)系型數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫、NewSQL數(shù)據(jù)庫等。分布式領(lǐng)域的CAP定理指出,在一個分布式系統(tǒng)中,Consistency(一致性)、Availability(可用性)、PartitionTolerance(分區(qū)容錯性)三者不可兼得[2]。在大數(shù)據(jù)時代,傳統(tǒng)關(guān)系型數(shù)據(jù)庫如Oracle、MSSQLServer、MySQL等,滿足一致性和可用性,但都面臨高并發(fā)讀寫和高可擴展性、高可用性的挑戰(zhàn)——關(guān)系型數(shù)據(jù)庫難以處理海量數(shù)據(jù)。關(guān)系型數(shù)據(jù)庫的橫向擴展通常采用主從復(fù)制、集群、分片(Sharding)等方法,但都有不足,面臨各種問題。近年出現(xiàn)的NoSQL數(shù)據(jù)庫可以很好地支持海量數(shù)據(jù)擴展,以滿足海量數(shù)據(jù)存儲需求。NoSQL有高擴展性、高可用性、無預(yù)定義模式的特點,但是不支持SQL語句、不支持事務(wù)、不支持ACID(原子性、一致性、隔離性和持久性),且每種NoSQL有自己的API,很難規(guī)范應(yīng)用程序接口,同時原有開發(fā)模式需要做較大的改變。
 
針對NoSQL的不足,近年來出現(xiàn)了NewSQL數(shù)據(jù)庫,如谷歌的GoogleSpanner/F1、阿里巴巴OceanBase、TiDB、CockroachDB等。它們不僅具有NoSQL對海量數(shù)據(jù)的存儲管理能力,還保持了傳統(tǒng)數(shù)據(jù)庫支持ACID和SQL等特性。
 
3.5 數(shù)據(jù)庫
平臺采用TiDB數(shù)據(jù)庫。TiDB是新一代開源分布式NewSQL數(shù)據(jù)庫,實現(xiàn)了自動的水平伸縮、強一致性的分布式事務(wù)、基于Raft算法的多副本復(fù)制等重要的NewSQL特性。TiDB結(jié)合了關(guān)系型數(shù)據(jù)庫和NoSQL的優(yōu)點,部署簡單,在線彈性擴容和異步表結(jié)構(gòu)變更不影響業(yè)務(wù),通過異地多活及自動故障恢復(fù)保障數(shù)據(jù)安全,同時兼容MySQL協(xié)議,使遷移使用成本降到極低。平臺通過TiDB同時滿足海量數(shù)據(jù)實時寫入、實時查詢以及數(shù)據(jù)在線分析需求。
 
3.6 數(shù)據(jù)處理
常規(guī)數(shù)據(jù)處理技術(shù)已無法滿足平臺海量數(shù)據(jù)處理要求,平臺采用分布式數(shù)據(jù)處理技術(shù)提高計算性能。分布式計算將一個龐大的計算任務(wù)劃分為若干個子任務(wù),然后為計算機網(wǎng)絡(luò)中的計算節(jié)點分別分配一部分子任務(wù),通過并行處理提高處理效率,最后綜合整理計算數(shù)據(jù),得到最后的計算結(jié)果。
 
3.6.1 分布式計算優(yōu)點
與集中式計算相比,分布式計算有以下優(yōu)點:①分布式網(wǎng)絡(luò)中的每臺機器都能存儲和處理數(shù)據(jù),降低了對機器性能的要求,所以不必購買昂貴的高性能機器,可以大大降低硬件投資成本;②擴展性好,在當前系統(tǒng)存儲或計算能力不足時,可以簡單地通過增加廉價PC機的方式來增加系統(tǒng)的處理和存儲能力;③處理能力極強,龐大的計算任務(wù)可以在合理分割后由分布式網(wǎng)絡(luò)中的機器并行地處理。
 
3.6.2 平臺數(shù)據(jù)處理的兩種類型
平臺數(shù)據(jù)處理分為批量處理和實時計算兩種類型。
 
(1)批量計算。對于小時、日、月、年等定時計算任務(wù)采用批量計算。平臺采用Spark作為分布式數(shù)據(jù)處理引擎。Spark是一個新興大數(shù)據(jù)處理引擎,與Hadoop比較,Spark采用的有向無環(huán)圖(DAG)計算模型比Hadoop的Mapreduce計算模型有更廣泛的適用性,同時Spark通過在內(nèi)存中緩存數(shù)據(jù),提高迭代式計算的性能,比Hadoop的運行速度有極大提高。Spark同時為批處理(SparkCore)、交互式(SparkSQL)、流式(SparkStreaming)、機器學(xué)習(Mllib)、圖計算(Graphx)提供了統(tǒng)一的數(shù)據(jù)處理平臺。Tispark是將SparkSQL直接運行在分布式存儲引擎Tikv上的OLAP解決方案。借助Spark平臺,同時融合Tikv分布式集群的優(yōu)勢,與Tidb一起為用戶一站式滿足HTAP(HybridTransactional/AnalyticalProcessing)需求。
 
(2)實時計算。批量計算面向的是海量離線數(shù)據(jù)的處理與分析,主要針對一段時期內(nèi)采集與存儲的靜態(tài)數(shù)據(jù),數(shù)據(jù)總吞吐量較好,但不適用于持續(xù)到達的數(shù)據(jù)流。對于需要進行實時處理的數(shù)據(jù)采用SparkStreaming、Storm、Flink等流式計算框架進行實時計算。實時計算系統(tǒng)不斷地接收數(shù)據(jù)采集系統(tǒng)持續(xù)發(fā)來的數(shù)據(jù)流、實時地進行處理與分析,并及時反饋結(jié)果,以滿足對數(shù)據(jù)處理有較高實時性要求的場景。實時計算系統(tǒng)輸出的數(shù)據(jù),可視情況進行存儲,以便之后進一步分析與應(yīng)用。
 
3.7  數(shù)據(jù)分析
數(shù)據(jù)分析功能是平臺支撐建筑運行管理的關(guān)鍵,平臺通過機器學(xué)習和深度學(xué)習框架支持其數(shù)據(jù)分析功能。目前常用的機器學(xué)習庫有SparkMLlib、Scikit-Learn等機器學(xué)習庫,可支持線性回歸、邏輯回歸、樸素貝葉斯、K-means、kNN(k-最近鄰)、決策樹、支持向量機(SVM)、Boosting等常用機器學(xué)習算法。深度學(xué)習框架有GoogleTensorFlow、微軟CNTK、MXNet、FacebookCaffe2、Caffe、Torch、PyTorch、百度PaddlePaddle、Keras等多種開源框架。其中TensorFlow應(yīng)用最為廣泛,平臺應(yīng)用TensorFlow開發(fā)數(shù)據(jù)分析應(yīng)用子系統(tǒng),實現(xiàn)能耗預(yù)測和分析診斷功能。
 
3.8 數(shù)據(jù)展現(xiàn)
數(shù)據(jù)展現(xiàn)層為用戶提供基于Web和APP的用戶界面,對該層的設(shè)計具有以下特點。
 
(1)前后端分離的RESTful風格架構(gòu)。前端頁面和后臺程序接口采用前后端分離的RESTful風格架構(gòu),數(shù)據(jù)通過JSON格式進行數(shù)據(jù)交換。RESTful架構(gòu)設(shè)計具有以下特性:①無狀態(tài),每個請求都必須包含所有必需的信息;②資源,應(yīng)用程序數(shù)據(jù)和功能可以劃分為各種資源,每種資源對應(yīng)一個特定的URI;③狀態(tài)轉(zhuǎn)化(操作),采用HTTP協(xié)議的GET、POST、PUT、DELETE動作表示操作。
 
(2)前端組件化。前端采用成熟的Vue框架,基于HTML5技術(shù)開發(fā)。Vue是一套用于構(gòu)建用戶界面的漸進式框架,具有雙向數(shù)據(jù)綁定和組件化開發(fā)功能。與現(xiàn)代化的工具鏈以及各種支持類庫結(jié)合使用,Vue能夠為復(fù)雜的單頁應(yīng)用提供驅(qū)動。
 
(3)后端微服務(wù)化。微服務(wù)架構(gòu)模式將大型的、復(fù)雜的應(yīng)用程序構(gòu)建為一組相互配合的服務(wù),微服務(wù)之間通過RESTAPI形式的接口或者消息隊列進行整合。整個系統(tǒng)由很多微服務(wù)構(gòu)成,因此具備更高的敏捷性、可伸縮性和可用性;系統(tǒng)可以水平擴展,從而降低了對各服務(wù)進行局部改良和快速迭代的難度。
 
4
結(jié)    語
本文提出一種面向大數(shù)據(jù)的建筑能耗和環(huán)境實時管理云平臺架構(gòu)設(shè)計。通過應(yīng)用物聯(lián)網(wǎng)協(xié)議、分布式消息中間件、分布式數(shù)據(jù)庫、分布式計算等大數(shù)據(jù)技術(shù)以及人工智能技術(shù),提供較強的海量數(shù)據(jù)采集、存儲、處理和分析能力。在后續(xù)工作中,將在平臺基礎(chǔ)上結(jié)合機電系統(tǒng)、空調(diào)系統(tǒng)等專業(yè)知識和數(shù)據(jù)以及人工智能技術(shù),開發(fā)節(jié)能診斷、能源管理、環(huán)境管理、設(shè)備運行優(yōu)化等專業(yè)應(yīng)用,為建筑智慧運行奠定基礎(chǔ)。
 
參考文獻
[1]丁洪濤,劉海柱,殷帥.我國公共建筑節(jié)能監(jiān)管平臺建設(shè)現(xiàn)狀及趨勢研究[J].建設(shè)科技,2017(23):10-11.
[2]GILBERTS,LYNCHN.Brewer'sconjectureandthefeasibilityofconsistent,available,partition-tolerantwebservices[J].ACMSIGACTNews,2002,33(2):51-59.
 
基金項目
國家重點研發(fā)計劃項目“基于全過程的大數(shù)據(jù)綠色建筑管理技術(shù)研究與示范”(2017YFC0704200),上海市建筑科學(xué)研究院(集團)有限公司科研創(chuàng)新項目“面向智慧園區(qū)的通用實時計算與數(shù)據(jù)平臺關(guān)鍵技術(shù)研究”(M5.10)資助
 
作者簡介
陳勤平,教授級高工,現(xiàn)供職于上海市建筑科學(xué)研究院,主要研究方向為建筑信息化及建筑節(jié)能。
【版權(quán)聲明】本網(wǎng)為公益類網(wǎng)站,本網(wǎng)站刊載的所有內(nèi)容,均已署名來源和作者,僅供訪問者個人學(xué)習、研究或欣賞之用,如有侵權(quán)請權(quán)利人予以告知,本站將立即做刪除處理(QQ:51999076)。

省區(qū)市分站:(各省/自治區(qū)/直轄市各省會城市碳交易所,碳市場,碳平臺)

華北【北京、天津、河北石家莊保定、山西太原、內(nèi)蒙】東北【黑龍江哈爾濱、吉林長春、遼寧沈陽】 華中【湖北武漢、湖南長沙、河南鄭州】
華東【上海、山東濟南、江蘇南京、安徽合肥、江西南昌、浙江溫州、福建廈門】 華南【廣東廣州深圳、廣西南寧、海南??凇?/span>【香港,澳門,臺灣】
西北【陜西西安、甘肅蘭州、寧夏銀川、新疆烏魯木齊、青海西寧】西南【重慶、四川成都、貴州貴陽、云南昆明、西藏拉薩】
關(guān)于我們|商務(wù)洽談|廣告服務(wù)|免責聲明 |隱私權(quán)政策 |版權(quán)聲明 |聯(lián)系我們|網(wǎng)站地圖
批準單位:中華人民共和國工業(yè)信息部 國家工商管理總局? 指導(dǎo)單位:發(fā)改委 生態(tài)環(huán)境部 國家能源局 各地環(huán)境能源交易所
電話:13001194286
Copyright@2014 tanpaifang.com 碳排放交易網(wǎng) All Rights Reserved
國家工信部備案/許可證編號京ICP備16041442號-7
中國碳交易QQ群:?6群碳交易—中國碳市場??5群中國碳排放交易網(wǎng)