当前位置：网站首页>边缘盒子+时序数据库，美的数字化平台 iBuilding 背后的技术选型

边缘盒子+时序数据库，美的数字化平台 iBuilding 背后的技术选型

2022-08-03 19:36:00 【涛思数据TDengine】

小 T 导读：在 2021 楼宇科技 TRUE 大会上，美的暖通与楼宇事业部首次发布了数字化平台 iBuilding，以“软驱硬核”方式赋能建筑行业。作为一个全新的项目，iBuilding 在数据库选型上比较谨慎，分别对比了多款 Database 产品之后，才做出了自己的选择。本文分享了他们的数据库选型思考和落地经验。

政策背景

根据 2021 年 12 月由美控智慧建筑联合亿欧智库共同发布的《中国楼宇自控白皮书》，2021 年中国楼宇智能化市场产值约达 7238.2 亿元，结合近几年行业的发展趋势，经过初步估算，2016-2021 年中国楼宇智能化市场规模逐年上升，存量规模接近 5000 亿元，新增规模超过 2200 亿元。

因楼宇智能化在低碳、节能方面优势突出，同时能为人们的生活带来更多舒适体验，加之政府对楼宇智能化建设规范化、科学化的引导，未来楼宇智能化将有非常好的发展前景。从目标来看，楼宇智能化符合建筑行业对数字化和智能化的发展需求，未来将继续助力中国建筑行业转型升级，以顺应国家对节能减排和数字经济的要求。

业务介绍

随着 5G 时代的到来，美的一方面在继续打造工业互联网产品，另一方面也在不断进行科技赋能，研发更加绿色环保的集成方案，为工业及制造业提供全新的思路。

作为美的集团旗下的五大业务板块之一，美的暖通与楼宇事业部确立了“暖通及楼宇智慧生态集成解决方案引领者”的发展愿景，旨在用智慧集成的行业解决方案满足复杂的建筑需求，目前主要涉足中央空调、电梯、楼宇控制等领域。在 2021 楼宇科技 TRUE 大会上，美的暖通与楼宇事业部首次发布了数字化平台 iBuilding，以“软驱硬核”方式赋能建筑行业。

作为一个全新的项目，我们分别对比了关系型数据库（Relational Database）以及主流的时序数据库（Time Series Database），包括 InfluxDB、TDengine、MySQL 等。对比关系型数据库 MySQL 来说，在这个场景下，我们不需要复杂的查询，却需要高效的存储和大范围时间的数据拉取。和同为时序数据库的 InfluxDB 对比，TDengine 的单机版性能远好于 InfluxDB。因此，在综合评估了适配、查询、写入和存储等综合能力后，我们最终选择了 TDengine 这款产品。

iBuilding 项目属于“智慧楼宇”的一部分，项目本身用于边缘侧对大型制冷设备（中央空调）的智能监控与交互。具体应用场景是：项目所涉及的几十个楼区，各自都有一些大型离心式冷水机组（10 台左右），我们在每个楼区都部署了一个 TDengine 到 ARM64 系统上。通过 Python 程序，系统会先进行数据采集，然后把数据写入 TDengine ，最后再把数据上传到云端的 TDengine 进行处理。

具体实践

以其中一个 Database 环境为例：

我们根据 TDengine “一个设备一张表，一类设备一个超级表”的建模原则，创建了如下表，两类设备的指标数分别为 97 和 199 ，数据列以 float 和 int 为主，设备每 5s 上报一批数据：

对于边缘侧的数据采集，由于资源有限，所以资源数据的使用就成为了十分重要的指标。这方面 TDengine 表现非常好，进一步帮我们降本增效了。

我们承载数据库服务的边缘盒子配置为 2GB 内存，4C CPU，ARM64 位的系统。由于子表数量不大，以及 TDengine 写入内存比较固定的特点，当前内存占用还不到 200MB。数据库日常 CPU 消耗比较低，大概在 3%-5% 左右，保守估计即便写入量扩大 50-100 倍，也没有问题。

应用效果

求某个设备 70 天前到 40 天前之间，每隔一段时间的设备用电量，无数据则用 prev 值填充。结果如下：

查询一个月之前的某设备某几项指标之和，按照时间戳降序排序。查询大约 19 万行数据，耗时 0.4s。结果如下：

‍

经验汇总

在使用 TDengine 的过程中，我们也遇到过一些小问题，比如：我们环境众多，但是客户端和服务端又要保持版本精确一致，升级起来会比较复杂。再比如：监控库中 log 中的 dn 表的 disk_used 语义并不是实际的 TDengine 对磁盘的占用，而是数据文件所在文件系统的总占用，有些情况下会让用户误以为是 TDengine 的空间占用，导致与预期不符，就像下图一样：