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

 

3.2.3 消息中間件

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

 

課題平臺采用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ù)訪問效率，對于平臺的實(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ù)持久化，平臺采用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定理指出，在一個(gè)分布式系統(tǒng)中，Consistency（一致性）、Availability（可用性）、PartitionTolerance（分區(qū)容錯(cuò)性）三者不可兼得[2]。在大數(shù)據(jù)時(shí)代，傳統(tǒng)關(guān)系型數(shù)據(jù)庫如Oracle、MSSQLServer、MySQL等，滿足一致性和可用性，但都面臨高并發(fā)讀寫和高可擴(kuò)展性、高可用性的挑戰(zhàn)——關(guān)系型數(shù)據(jù)庫難以處理海量數(shù)據(jù)。關(guān)系型數(shù)據(jù)庫的橫向擴(kuò)展通常采用主從復(fù)制、集群、分片（Sharding）等方法，但都有不足，面臨各種問題。近年出現(xiàn)的NoSQL數(shù)據(jù)庫可以很好地支持海量數(shù)據(jù)擴(kuò)展，以滿足海量數(shù)據(jù)存儲需求。NoSQL有高擴(kuò)展性、高可用性、無預(yù)定義模式的特點(diǎn)，但是不支持SQL語句、不支持事務(wù)、不支持ACID(原子性、一致性、隔離性和持久性)，且每種NoSQL有自己的API，很難規(guī)范應(yīng)用程序接口，同時(shí)原有開發(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ù)庫，實(shí)現(xiàn)了自動(dòng)的水平伸縮、強(qiáng)一致性的分布式事務(wù)、基于Raft算法的多副本復(fù)制等重要的NewSQL特性。TiDB結(jié)合了關(guān)系型數(shù)據(jù)庫和NoSQL的優(yōu)點(diǎn)，部署簡單，在線彈性擴(kuò)容和異步表結(jié)構(gòu)變更不影響業(yè)務(wù)，通過異地多活及自動(dòng)故障恢復(fù)保障數(shù)據(jù)安全，同時(shí)兼容MySQL協(xié)議，使遷移使用成本降到極低。平臺通過TiDB同時(shí)滿足海量數(shù)據(jù)實(shí)時(shí)寫入、實(shí)時(shí)查詢以及數(shù)據(jù)在線分析需求。

 

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

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

 

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

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

 

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

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

 

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

 

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

 

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

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

 

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

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

 

（1）前后端分離的RESTful風(fēng)格架構(gòu)。前端頁面和后臺程序接口采用前后端分離的RESTful風(fēng)格架構(gòu)，數(shù)據(jù)通過JSON格式進(jìn)行數(shù)據(jù)交換。RESTful架構(gòu)設(shè)計(jì)具有以下特性：①無狀態(tài)，每個(gè)請求都必須包含所有必需的信息；②資源，應(yīng)用程序數(shù)據(jù)和功能可以劃分為各種資源，每種資源對應(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)代化的工具鏈以及各種支持類庫結(jié)合使用，Vue能夠?yàn)閺?fù)雜的單頁應(yīng)用提供驅(qū)動(dòng)。

 

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

 

4

結(jié)    語

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

 

參考文獻(xiàn)

[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.

 

基金項(xiàng)目

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

 

作者簡介

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