智能建筑｜面向大数据的建筑能耗与环境实时管理云平台架构设计

摘要
 

实现建筑精细化管理需要面向建筑能耗、环境、设备运行和使用需求等海量数据。提出一种面向大数据的建筑能耗与环境实时管理云平台架构设计，通过应用分布式消息中间件、分布式NewSQL数据库、分布式计算框架等大数据技术，以及深度神经网络与机器学习框架等人工智能技术，满足海量数据集成、存储、处理和分析需求。这些成果可以为建筑高效运行管理提供技术支撑。

 

关键词

建筑能耗与环境；实时管理；系统架构；大数据；分布式

 

 

 

1

背 景

我国国家机关和大型公共建筑能耗监测系统建设示范覆盖了30多个省、自治区、直辖市，以及计划单列市，全国累计监测11000余栋建筑[1]，已经积累了大量的建筑能耗数据。但是，目前这些数据有效利用率不高，平台价值未充分发挥。其中一个很重要的原因是建筑能耗监测平台数据全面性不够，只有能耗数据，甚至只有分项电耗数据。要为建筑运行管理提供更有效的数据支撑，应充分采集建筑各种能耗数据、室内外环境数据、机电设备运行数据，以及人流等使用需求数据，但会造成数据量的急剧增长，因而对平台的数据集成能力、存储能力、处理能力、分析能力和展现能力都提出了很大的挑战。

 

2

建筑能耗与环境管理平台新需求

建筑能耗与环境管理平台要为建筑运行管理提供更有效的技术支撑，面向的海量数据对此提出了新的要求。

 

（1）强大的数据集成能力：需要集成大量的建筑能源、室内外环境、机电系统设备运行数据以及使用需求。

 

（2）海量数据存储和处理能力：平台的存储和处理能力应该能够进行水平扩展，以满足海量数据存储和处理的需求。

 

（3）智能的数据分析能力：集成机器学习、深度学习等人工智能技术，能够基于大数据进行建筑能耗预测、诊断和优化等应用。

 

（4）丰富的数据展现能力和友好易用的用户界面：在Web端和移动APP端为用户提供多端应用。

 

3

面向大数据的云平台架构设计

3.1 平台总体架构

为满足海量数据传输、集成、存储和分析需求，平台采用大数据技术和人工智能技术构建，总体架构可分为数据集成、数据存储、数据处理、数据分析、数据展现等，如图1所示。

 

图 1    面向大数据的云平台总体架构

 

（1）建筑的能源、环境和设备运行实时数据传输到分布式消息中间件，可同时支持MQTT协议、TCP协议和WebService协议接口。

 

（2）消息处理子系统从消息中间件中获取数据，将数据缓存到Redis。

 

（3）数据存储子系统将Redis中的数据定时持久化到数据库。

 

（4）采用分布式数据库存储数据，支持分布式事务和水平弹性扩展，可按需扩展，有效应对高并发、海量数据场景。

 

（5）采用分布式数据处理框架进行汇总计算和指标计算。

 

（6）基于机器学习库、深度学习库开发数据分析模块，实现能耗预测、诊断和优化运行等数据分析应用。

 

（7）Web服务为上层Web和APP提供数据服务，分布式缓存为数据访问加速。

 

3.2 数据集成

3.2.1 数据通信协议

目前公共建筑能耗监测系统采用的是基于TCP的传输协议。TCP协议是底层传输协议，没有定义QoS（QualityofService，服务质量）。上海市住房和城乡建设管理委员会DGJ08-2068─2017《公共建筑用能监测系统工程技术标准》在国家住房和城乡建设部《国家机关办公建筑和大型公共建筑能耗监测系统分项能耗数据传输技术导则》基础上增加了WebService协议，便于建筑上传能耗数据。WebService协议是一种基于TCP的通用协议，但WebService的处理开销较大，不适合高频率传输大量数据。

 

本平台数据传输采用MQTT协议。MQTT协议已经成为OASIS（结构信息标准化促进组织）标准（参见MQTT官方网站），是物联网的重要组成部分。MQTT基于“发布/订阅”模式的消息传输协议，是轻量级的M2M（Machine-to-Machine）通信协议，适合于低带宽、不可靠连接、嵌入式设备、CPU/内存资源紧张的场景。MQTT定义了0、1、2三种QoS服务质量等级，可根据消息的重要程度确定QoS等级，同时MQTT的“发布/订阅”模式可支持下行数据的传输，平台可向数据采集器发送控制指令。

 

3.2.2 数据传输格式

现有能耗监测系统采用XML数据传输格式，平台和数据采集器之间采用JSON格式，同时兼容原有XML格式和通信协议。XML格式通用性强，但是处理开销较大，不适合海量数据实时传输。JSON是一种轻量级的数据交换格式，比XML简洁，格式简单，占用带宽较少，处理性能要求低，更适用于大量网络数据传输的场景。

 

3.2.3 消息中间件

在分布式系统中广泛运用消息中间件进行系统间的数据交换，主要解决应用耦合、异步消息、流量削峰等问题，以实现高性能、高可用、可伸缩和最终一致性架构。消息中间件是大型分布式系统不可缺少的组件。建筑中的数据采集器发送的数据先进入平台的消息中间件，由消息处理程序进行后续处理。

 

课题平台采用Artemis消息中间件。Artemis是Apache基金会支持的开源项目，是高性能、支持集群的异步消息中间件，支持包括MQTT在内的多种协议。Artemis既作为MQTT的服务端，同时也作为消息中间件，后期随着数据量的扩展，可以采用Kafka作为海量数据中间件。

 

3.3 数据缓存

为提高数据访问效率，对于平台的实时数据使用数据缓存存放最新的能源和环境数据。目前流行的分布式缓存有Memcached、Redis。Redis支持的数据类型丰富，包括String（字符串）、List(链表)、Set(集合)、Zset（SortedSet，有序集合）和Hash（哈希类型）多种数据格式，支持数据持久化，平台采用Redis作为分布式缓存。

 

3.4 数据存储

平台的数据存储需要数据库支撑。数据库可分为传统关系型数据库、NoSQL数据库、NewSQL数据库等。分布式领域的CAP定理指出，在一个分布式系统中，Consistency（一致性）、Availability（可用性）、PartitionTolerance（分区容错性）三者不可兼得[2]。在大数据时代，传统关系型数据库如Oracle、MSSQLServer、MySQL等，满足一致性和可用性，但都面临高并发读写和高可扩展性、高可用性的挑战——关系型数据库难以处理海量数据。关系型数据库的横向扩展通常采用主从复制、集群、分片（Sharding）等方法，但都有不足，面临各种问题。近年出现的NoSQL数据库可以很好地支持海量数据扩展，以满足海量数据存储需求。NoSQL有高扩展性、高可用性、无预定义模式的特点，但是不支持SQL语句、不支持事务、不支持ACID(原子性、一致性、隔离性和持久性)，且每种NoSQL有自己的API，很难规范应用程序接口，同时原有开发模式需要做较大的改变。

 

针对NoSQL的不足，近年来出现了NewSQL数据库，如谷歌的GoogleSpanner/F1、阿里巴巴OceanBase、TiDB、CockroachDB等。它们不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。

 

3.5 数据库

平台采用TiDB数据库。TiDB是新一代开源分布式NewSQL数据库，实现了自动的水平伸缩、强一致性的分布式事务、基于Raft算法的多副本复制等重要的NewSQL特性。TiDB结合了关系型数据库和NoSQL的优点，部署简单，在线弹性扩容和异步表结构变更不影响业务，通过异地多活及自动故障恢复保障数据安全，同时兼容MySQL协议，使迁移使用成本降到极低。平台通过TiDB同时满足海量数据实时写入、实时查询以及数据在线分析需求。

 

3.6 数据处理

常规数据处理技术已无法满足平台海量数据处理要求，平台采用分布式数据处理技术提高计算性能。分布式计算将一个庞大的计算任务划分为若干个子任务，然后为计算机网络中的计算节点分别分配一部分子任务，通过并行处理提高处理效率，最后综合整理计算数据，得到最后的计算结果。

 

3.6.1 分布式计算优点

与集中式计算相比，分布式计算有以下优点：①分布式网络中的每台机器都能存储和处理数据，降低了对机器性能的要求，所以不必购买昂贵的高性能机器，可以大大降低硬件投资成本；②扩展性好，在当前系统存储或计算能力不足时，可以简单地通过增加廉价PC机的方式来增加系统的处理和存储能力；③处理能力极强，庞大的计算任务可以在合理分割后由分布式网络中的机器并行地处理。

 

3.6.2 平台数据处理的两种类型

平台数据处理分为批量处理和实时计算两种类型。

 

（1）批量计算。对于小时、日、月、年等定时计算任务采用批量计算。平台采用Spark作为分布式数据处理引擎。Spark是一个新兴大数据处理引擎，与Hadoop比较，Spark采用的有向无环图（DAG）计算模型比Hadoop的Mapreduce计算模型有更广泛的适用性，同时Spark通过在内存中缓存数据，提高迭代式计算的性能，比Hadoop的运行速度有极大提高。Spark同时为批处理(SparkCore)、交互式（SparkSQL）、流式（SparkStreaming）、机器学习（Mllib）、图计算（Graphx）提供了统一的数据处理平台。Tispark是将SparkSQL直接运行在分布式存储引擎Tikv上的OLAP解决方案。借助Spark平台，同时融合Tikv分布式集群的优势，与Tidb一起为用户一站式满足HTAP(HybridTransactional/AnalyticalProcessing)需求。

 

（2）实时计算。批量计算面向的是海量离线数据的处理与分析，主要针对一段时期内采集与存储的静态数据，数据总吞吐量较好，但不适用于持续到达的数据流。对于需要进行实时处理的数据采用SparkStreaming、Storm、Flink等流式计算框架进行实时计算。实时计算系统不断地接收数据采集系统持续发来的数据流、实时地进行处理与分析，并及时反馈结果，以满足对数据处理有较高实时性要求的场景。实时计算系统输出的数据，可视情况进行存储，以便之后进一步分析与应用。

 

3.7  数据分析

数据分析功能是平台支撑建筑运行管理的关键，平台通过机器学习和深度学习框架支持其数据分析功能。目前常用的机器学习库有SparkMLlib、Scikit-Learn等机器学习库，可支持线性回归、逻辑回归、朴素贝叶斯、K-means、kNN（k-最近邻）、决策树、支持向量机（SVM）、Boosting等常用机器学习算法。深度学习框架有GoogleTensorFlow、微软CNTK、MXNet、FacebookCaffe2、Caffe、Torch、PyTorch、百度PaddlePaddle、Keras等多种开源框架。其中TensorFlow应用最为广泛，平台应用TensorFlow开发数据分析应用子系统，实现能耗预测和分析诊断功能。

 

3.8 数据展现

数据展现层为用户提供基于Web和APP的用户界面，对该层的设计具有以下特点。

 

（1）前后端分离的RESTful风格架构。前端页面和后台程序接口采用前后端分离的RESTful风格架构，数据通过JSON格式进行数据交换。RESTful架构设计具有以下特性：①无状态，每个请求都必须包含所有必需的信息；②资源，应用程序数据和功能可以划分为各种资源，每种资源对应一个特定的URI；③状态转化（操作），采用HTTP协议的GET、POST、PUT、DELETE动作表示操作。

 

（2）前端组件化。前端采用成熟的Vue框架，基于HTML5技术开发。Vue是一套用于构建用户界面的渐进式框架，具有双向数据绑定和组件化开发功能。与现代化的工具链以及各种支持类库结合使用，Vue能够为复杂的单页应用提供驱动。

 

（3）后端微服务化。微服务架构模式将大型的、复杂的应用程序构建为一组相互配合的服务，微服务之间通过RESTAPI形式的接口或者消息队列进行整合。整个系统由很多微服务构成，因此具备更高的敏捷性、可伸缩性和可用性；系统可以水平扩展，从而降低了对各服务进行局部改良和快速迭代的难度。

 

4

结    语

本文提出一种面向大数据的建筑能耗和环境实时管理云平台架构设计。通过应用物联网协议、分布式消息中间件、分布式数据库、分布式计算等大数据技术以及人工智能技术，提供较强的海量数据采集、存储、处理和分析能力。在后续工作中，将在平台基础上结合机电系统、空调系统等专业知识和数据以及人工智能技术，开发节能诊断、能源管理、环境管理、设备运行优化等专业应用，为建筑智慧运行奠定基础。

 

参考文献

[1]丁洪涛,刘海柱,殷帅.我国公共建筑节能监管平台建设现状及趋势研究[J].建设科技,2017(23):10-11.

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

 

基金项目

国家重点研发计划项目“基于全过程的大数据绿色建筑管理技术研究与示范”（2017YFC0704200），上海市建筑科学研究院（集团）有限公司科研创新项目“面向智慧园区的通用实时计算与数据平台关键技术研究”（M5.10）资助

 

作者简介

陈勤平，教授级高工，现供职于上海市建筑科学研究院，主要研究方向为建筑信息化及建筑节能。