小T导读：广联达立足建筑产业，围绕工程项目的全生命周期，是提供以建设工程领域专业应用为核心基础支撑，以产业大数据、产业新金融等为增值服务的平台服务商。广联达科技股份有限公司数字城市BU在TDengine Database推出1.0版本时就开始试用TDengine系统。
TDengine应用场景
1.1 业务场景
广联达科技股份有限公司数字城市BU在TDengine Database推出1.0版本时就开始试用TDengine系统，主要用于建设工程项目的工地物联网数据和城市运营管理过程中的设备监测物联网数据的存储和管理，应用于智慧城市、智慧工地的系统中，具体包含城市交通、照明、环境监测、给排水、燃气监测、停车场以及工地环境质量监测，在智慧城市的交通、城管、能源监测管理、生命线安全监控、施工环境等领域提供智能化管理依据。
系统整体的架构如下图所示，通过广联达自研的IoT平台接入物联网设备采集的时序数据，数据上报后放入TDengine物联网大数据平台，在此平台上再进一步做各种业务相关的应用层开发。
1.2 时序数据类型及规模
在某新区智慧城市大数据管理系统中，使用TDengine Database来存储各类终端设备的采集数据，比如智能灯杆上照明情况、用电情况，供水压力流量数据、燃气压力、可燃气体泄露、污水排污成分数据、环境监测设备上的PM2.5、 PM10等信息，停车场通行数据等结构化时序数据等。
目前系统上存在3000+的监测设备，每日新增的监测数据量约在2620MB。如果按照此类设备的增量，后面会达到十万个监测设备，每日数据增量应该在80GB左右。
1.3 数据模型的设计
在流数据的时序数据模型中，主要包括两部分模型：运行状态监测值与运行状态错误/报警值，两者都是设备运行时按照时间顺序产生的数据。在设计过程中，考虑到运行状态中的监测值本身的数据和类型都取决于设备模型本身能够提供的监测数据类型和数量；而报警信息是通过规则引擎计算触发之后，生成的具有一定业务标识信息的数据。基于两种数据的来源和产生原理，对两种时序数据的存储进行了分别处理。具体处理方式如下。
1）运行状态监测值–时序数据
环境监测的状态监测数据样例如下：
{"uuid":"012126","pm25":14.3,"pm10":18.9,"pa":100740.0,"temp":28.0,"rshi":86.4,"wind_speed":1.7,"wind_direction":157.5,"noise":77.2,"time":20190702180330}
{"uuid":"018181","pm25":20.2,"pm10":21.3,"pa":100740.0,"temp":28.1,"rshi":86.2,"wind_speed":1.62,"wind_direction":157.5,"noise":75.9,"time":20190702180330}监测点的运行状态数据取决于监测点模型的设置，因此我们在建立模型的过程中，解析模型信息，在TDengine Database中建立了与设备模型监测数据匹配的超级表(STable)，并且根据相关业务需求，建立了常用查询维度的Tag信息，为该类型下设备监测信息传入存储做好准备。
2）运行状态错误/报警值–时序数据
环境监测的状态报警数据样例如下：
{"uuid":"018181","item":"noise","value":75.9,"alarm":"true","level":"2","time":20190702180330}
{"uuid":"012126","item":"noise","value":77.2,"alarm":"true","level":"2","time":20190702180330}监测设备的报警信息，按照相关业务需求，统一处理为一类报警信息数据，因此在系统中设计了一套针对报警信息存储的超级表，所有设备的报警信息都依照该超级表的模型结构，进行保存。同样建立了常用查询维度的Tag信息。
选择TDengine的理由
2.1 TDengine对业务性能需求的满足和提升
物联网应用系统中对数据的查询需求多样且复杂，此前的实现方案都是借助于如HBase生态中的各种组件进行数据的存储和查询。在流处理过程中，更多采用Spark Streaming，或者Storm来进行实时处理查询等，由于TDengine相对于前者使用的各种重型组件来说，在部署维护、入门、数据迁移、学习使用上都有先天性的优势，因此在部署物联网数据存储平台过程中，结合实际业务中的数据查询需要，我们首选了TDngine实现。
1）窗口查询
物联网时序数据的一个典型查询应用就是窗口查询，而在传统解决方案中，不是实现窗口查询的方式难以落地，就是数据查询效率不能接受。在HBase中是通过各种汇聚来实现查询，效率难以保证；Spark Streaming的查询处理虽然可以通过SQL来实现，但是对于窗口函数的定义和读取晦涩冗长。在TDengine中，可以通过一个SQL语句直接实现，也可以通过API直接获取。在Spark Streaming中四五十行的逻辑，在TDengine的API中，调用五行即可达到目的。
2）连续查询
连续查询，通过interval()函数在TDengine中周期性进行聚合计算，并可直接获取最新数据，对实际业务中的定时查询实现很有帮助，避免了进行起止时间查询的方式，对功能实现来说，降低不少编码工作。
3）支持标准SQL
TDengine支持标准的SQL操作，同时也提供了完备的JDBC驱动包，对传统的DBMS工具组件提供了标准支持，因此，原有基于Java的业务系统在开发效率上完全可以无缝迁移到TDengine中。对于大屏查询、报表工作等业务操作，无需进行特定的开发工作。
4）标签维度查询
按照业务常用的查询维度，在超级表上做不同的Tag，比如基于设备ID、位置描述、型号等信息，契合常用查询维度，结合Tag查询，直接可以对一类设备进行数据筛选查询，避免了之前系统，先查业务关系再去join实际数据的过程，逻辑上清晰，实现上简单，业务上便捷。
2.2 大幅提升时序数据读写及流处理性能
对于省市级规模的智慧城市管理系统，涉及的智能监测设备数量非常大，对监测点产生的时序数据的读写性能要求比较高，并且针对一些城市生命线或危险源相关的设备监测数据的实时流数据处理性能要求也很高，比如设备报警需要基于不同设备的阀值规则通过流处理生成报警信息，其实时性要求比较高。采用普通关系型数据库存储的解决方案很难满足业务上的性能要求，而采用TDengine的技术方案，不仅在时序数据读写的性能上有大幅提升，而且利用其针对时序数据高性能的插入、查询、聚合统计以及大规模的实时流式计算等功能，可大大提升基于业务规则的流数据处理性能。
2.3 节约计算资源和存储成本
由于TDengine采用独特的列式存储以及领先的压缩算法，其存储空间比一般数据库大大减少，从而节约了大量的计算资源和存储成本，并且从系统安装到数据备份、数据恢复几乎都能自动完成；扩容、升级等运维操作也能轻松完成 ，系统的运维成本也能降低不少。
TDengine应用技巧和经验
3.1 善用超级表
超级表（STable）作为TDengine的特色，具备了模板和索引的双重特性功能，结合Tag查询以及自动生成子表功能，对数据操作存储完全自动化、智能化，以及在简单业务上更加灵活。
3.2 善用JDBC工具
由于对SQL的支持，TDengine很容易支持JDBC规范的接口。我们在实际开发过程中，基于Java调用JDBC驱动来操作TDengine，得益于TDengine的SQL支持能力和完备JDBC驱动，我们用来开发的JDBC框架和DBClient工具直接可以进行工作，Mybatis和DataGrip工具继续在数据实现转型中发挥来巨大的辅助作用。
3.3 强大的订阅机制
在部分实时性要求比较高的场景下，我们尝试使用到了TDengine的订阅机制，对流处理中回调功能进行补全加强，订阅了一个SQL的查询结果集。目前，对于流处理业务来说，对符合固定逻辑的数据获取，非常好用，因此最适合采用订阅的方式来进行逻辑驱动。目前TDengine中的订阅功能只有C和Java语言端的实现（在用1.5.2版本）。
TDengine应用中遇到的问题
4.1 JDBC驱动并非完美
虽然目前JDBC驱动已经非常完备，但是偶尔几个标准实现上会有不同的结果，当然这些功能都是非数据接口上的，不影响正常数据操作。目前发现的有：在DataGrip上的确认数据库是否存在的返回值，有不同结果；有些特定的SQL并不是标准类型，被IDE回报说不支持的类型，实际上能够执行成功。
4.2 文档有待完善，大家多多实践
目前的文档一些地方其实不够明确，大家需要多动手实践摸索，很多隐藏的内容，在文档中并未体现，多操作多尝试会有更多收获和体会。
作者简介：王碧波，广联达科技股份有限公司数字城市数据平台部架构师，从事IT技术十余年，参与过H2Database、Mybatis、TDengine等开源项目；先后在百度、易到用车、树根互联工作，参与过应用云、PaaS、SaaS平台的设计和研发工作，对分布式和高性能计算有深入研究，近年来专注于微服务、DevOps、物联网领域的技术架构设计和具体实践。
本文首发于公众号：广联达研究院
