• 美的数字化平台 iBUILDING 背后的技术选型


    小 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 进行处理。

    TDengine Database

    具体实践

    以其中一个 Database 环境为例:

    TDengine Database

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

    TDengine Database
     
    TDengine Database

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

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

    TDengine Database

    应用效果

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

    TDengine Database
     
    TDengine Database

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

    TDengine Database
     
    TDengine Database

    经验汇总

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

    TDengine Database

    后面我们和 TDengine 社区工作人员一起讨论了这个情况,大家认为可以新增一列,专门用来统计 TDengine 的数据文件的大小,然后把它与 disk_used、disk_total 一起规范化统一命名,就可以防止用户误解了。

    目前 TDengine 官方已经在积极地处理优化。这也是开源社区的一大价值,大家都可以参与进去,让产品不断迭代,发展地更好。

    写在最后

    当前,TDengine 主要被应用于中央空调制冷设备的监控业务中,作为先行试点,这一场景已经取得了不错的效果。但由于机组价格昂贵、成本较高,因此通过平台动态生成操作指令的这类智能化操作仍需谨慎,所以目前该功能还没有正式开放。

    在楼宇智能化方面,我们也有很多工作要做,从边缘侧的监控、到指令控制、再到边云协同的一体化服务,我们会在这些场景中继续探索和挖掘 TDengine 的潜力。


    想了解更多 TDengine Database的具体细节,欢迎大家在GitHub上查看相关源代码。

  • 相关阅读:
    用SecureCRT来上传和下载文件
    Linux指令--tar,gzip
    Linux指令--文件和目录属性
    Linux指令--which,whereis,locate,find
    Linux指令--head,tail
    Linux指令--more,less
    Linux指令--nl
    Linux指令--cat,tac
    Linux指令--touch
    Linux指令--cp
  • 原文地址:https://www.cnblogs.com/taosdata/p/16565287.html
Copyright © 2020-2023  润新知