按照TDengine官方的建议，“一个数据采集点一张表，同一类型数据采集点一张超级表”，我针对不同分厂的水表、电表、蒸汽表和燃气表分别建立的超级表，每个仪表单独建表，保证每张表的时间戳严格递增。在实践TDengine的过程中，重点体会如下：
1）集群搭建门槛低
TDengine集群安装部署非常便捷，尤其相比于其他集群，仅需要简单的配置就可以实现生产环境级的搭建，官方文档也比较丰富，社区活跃，也大为降低了后续运维成本。
2）插入与查询效率极高
TDengine的插入与查询性能极高，这点在实际运行时也深有感触，用last_row函数查询仪表最新数据，基本上可以达到毫秒级，在几十亿级的数据上进行聚合查询操作，也可达到百毫秒级，极大提供了系统的响应速度。
3）全栈式时序处理引擎
在未使用TDengine之前，我们主要采用InfluxDB/Redis和Kafka/Redis/HBase/Flink两种技术栈，对于我们中小型研发团队来讲，无论是系统搭建，还是实施运维都非常棘手。但是使用TDengine后，一切都简化了，TDengine将数据库、消息队列、缓存、流式计算等功能融合一起，以一种全栈的方式，为我们的大数据系统带来了便捷。技术方案的对比如表4所示。
注：方案一为InfluxDB/Redis，方案二为Kafka/Redis/HBase/Flink，方案三为TDengine
从表4的对比方案中可以看出，TDengine（方案三）是有着很大的优势，尤其在开源EMQX Broker的支持上也非常好（主要依赖于Restful接口），其他的例如Kafka和InfluxDB只能和企业版EMQX集成；在数据插入和查询效率方面，上述三种方案关键在于TDengine、HBase和InfluxDB的对比，官网有非常详细的测试报告，TDengine也是有绝对优势，这里就不过多叙述。所以选择TDengine是势在必行的。
3.5 技术期望
在时序数据库性能方面，TDengine有着很大的优势，并且也集成了消息订阅和流计算功能，可以说在中小型物联场景下，是无需部署Kafka和Flink的。当然个人理解TDengine不是为了完全取代Kafka和Flink而生的，尤其是在大型云服务项目中，更多是共存。
但是在边缘端，TDengine凭借着极低的资源占用率和优秀的时序处理性能，将会产生更大的能量，期望能彻底集成边缘流计算和MQTT broker等功能，扩充Modbus、OPC-UA等常见工业协议支持，向下连接工业设备或者物联设施，向上和边缘Kubernetes生态（如KubeEdge、K3S等）协同，或者直接和云中心协同。
3.6 系统运行界面
项目重点是能耗统计，而在线采集到TDengine里的数据都是累计量，所以在计算能耗时，需要在不同的超级表执行按表分组、按时间周期采样的查询，类似下面语法：
selectlast(累计列)as max_val,first(累计列)as min_val from[超级表名]where[标签栏相关过滤]and ts>=now-10h INTERVAL(1h)groupby[仪表编号];
得益于TDengine的极佳性能，基本能保证不超过百毫秒的访问延时，下面是一些相关的PC端、移动端界面（我们移动端是用H5做的，为了直接能跑在Android和iOS上）。
其实从2019年开始就一直在关注TDengine，也看了很多陶总的演讲，受益匪浅，尤其在今年8月份，TDengine进行了集群版开源，也正好准备启动能源数据采集项目，所以果断采用TDengine作为核心时序引擎，目前也是收获了非常的效果。本次项目实施过程中，尤其感谢涛思数据的苏晓慰工程师，多次协助解决TDengine相关的实施问题。计划在后续其他项目也也会继续推广TDengine，同时也愿意为一些商业版功能付费，支持国产，支持涛思。
作者介绍
于淼，学历硕士，副研究员，主要从事MES系统研发以及智能制造相关理论和标准研究，主要研究方向：数字工厂使能技术、制造执行系统关键技术和智能制造标准体系等，参与国家级项目及企业项目十余项，包括国家重点研发计划以及国家智能制造专项等。