TDengine在吉科软车辆监管中的应用实践

吉科软信息技术有限公司是国家高新技术企业，公司以“让天下没有不放心的食品”为使命，以“做数字化捍卫食品安全的领军企业”为愿景，以打造食用农产品全流程追溯、全流程监管、全流程服务、全产业链升级为核心的产业互联网生态链为主营业务，运用卫星遥感、5G通信、大数据、云计算、物联网、区块链和人工智能等技术，推出一系列国内首创、行业领先和可落地的研发成果，为智慧农业、智慧食安、智慧城市提供解决方案。

项目背景介绍：

车辆轨迹定位监控项目旨在通过车辆的轨迹监管、异常预警、历史轨迹回放，达成对车辆的统一监管、轨迹追踪、大数据分析及可视化应用等目的。该项目现已对数万台车辆经过车载定位设备上报定位数据至GIS网关服务，服务解析报文下发至消息队列，应用再将定位数据写入InfluxDB，最新车辆位置信息写入Redis，为客户提供车辆实时位置跟踪和历史轨迹回放等查询分析服务。

选型时的思考：

首先我们梳理了当前车辆监管架构的主要特性和新需求：

• 持续高并发写入，带有tag，时间戳有时会乱序写入(存在离线数据上传的情况，离线数据的时间戳小于当前时间戳)；
• 业务数量级增长快，预估未来每天写入约8亿条数据；
• 对基于时间戳范围的聚合查询，属于低频查询，通常是由用户触发，查询最近几天的轨迹，按执行任务的时间进行轨迹回放。
• 实时查询需求，对每个车辆有最后一个定位点数据的查询需求，获取实时位置监控；
• 因为数据量非常大，所以需要支持数据压缩，降本增效；
• 期望每个车辆单独建表；
• 需支持批量数据写入，且业务期望写入延时较低；
• 车辆监管项目有产品国产化的需求，在中间件的选择上需采用国产化产品。

此前，我们的项目一期采用了InfluxDB时序数据库作为存储车辆轨迹数据，二期项目需要重新升级改版后进行全新架构设计，同时也要考虑业务规模的快速增长、国产化要求及InfluxDB的单节点问题。

因此我司需要需对时序数据库进行重新选型。我们对业界主流的时序数据库做了分析和测试：

• InfluxDB：由InfluxData开发的开源时序型数据。它由Go写成，着力于高性能地查询与存储时序型数据。被广泛应用于存储系统的监控数据，IoT行业的实时数据等场景。缺点是开源版本只支持一个节点，开源版本没有集群功能,存在前后版本兼容性问题，非国产化产品。
• OpenTSDB：基于HBase的分布式、可伸缩的时间序列数据库。作为基于通用存储开发的时序数据库典型代表，起步比较早，在时序数据库领域的认可度相对较高，但HBase成本高的问题无法免除。
• TDengine：国产开源时序数据库，使用类SQL查询语言来插入或查询数据；通过连续查询，支持基于滑动窗口的流式计算；引入超级表，让设备之间的数据聚合通过标签变得简单灵活；内嵌缓存机制，每台设备的最新状态或记录都可快速获得；分布式架构，支持线性扩展，以保证任何规模的数据量都可以处理；支持多副本，无单点故障，保证系统的高可用与高可靠。这些功能和特性都非常符合我们的需求。

通过实际对比后、再加上迁移改动最小化以及国产化需求等因素，我们最终选定TDengine作为车辆轨迹数据的存储方案。

落地：

初期我们选用了三台服务器，搭建了3节点3副本的集群。目前已投入一批车辆运营监控，后续我们将逐步迁移全部车辆的轨迹数据至TDengine。

历史数据从InfluxDB迁移至TDengine，采用的方案是基于Datax数据同步，我们扩展开发了InfluxDB的读插件和TDengine的写插件，单进程数据同步可达到6万/秒的同步速度。（该速度受限于influxdb的读取，在该过程中 influxdb的内存上涨过快撑不住， 所以最终测试的同步速度 是6万/秒。目前官方已发布“基于DataX的TDengine数据迁移工具和taosAdaptor工具”）

 

 

      以迁移的部分数据进行分析：总数据量为6.5亿，分布在14742个子表中，占用磁盘空间4.7G，压缩率达到4%。开启了cachelast选项为1缓存子表最近一行数据，利用该缓存特性，查询指定车辆的最新GIS定位数据进行实时监控时，可直接从缓存中读取，加快读取速度。 

       在使用TDengine之前，对于所有车辆的最新位置实时监控，我们采用的方案是在接收gis数据存储至InfluxDB时，同时将车辆的最新位置数据存储至Redis和Mysql，使用TDengine后方案中对实时位置的存储直接使用TDengine的缓存子表最近一行数据的特性就可以实现，完全可以去掉Redis和Mysql的存储。

性能表现：

项目对车辆轨迹数据的应用场景主要集中在车辆实时位置监控、车辆时间范围内的轨迹回放。

1.车辆实时位置监控场景：

查询单个或多个车辆的最新GIS位置数据。单个车辆最新位置查询：select last_row(*) from d_track where car_id in ('dc8a9a0d7b634c9ba4446445c6c');

利用查询超表的单个车辆最新位置数据时间在11毫秒。如果直接锁定子表进行查询的话， select last_row(*) from _018d16c826cb405ea4a94a14cd4f95a9 ;

 返回最后一条位置数据的响应时间在1毫秒。

 多个车辆的最新位置数据查询，依旧使用超表结合标签进行查询， 查询响应时间在12毫秒左右。

 继续扩大查询范围，查询500~1000个车辆的最新位置的查询响应时间也能在1秒之内返回结果，完全达到业务响应的时间需求。

2.时间范围内车辆的轨迹数据查询

 指定车辆在指定时间范围内的轨迹数据查询，直接定位到具体的子表进行查询，select * from _0128a4d193424dcfb217242f054716d4 where time >'2021-09-08 10:34:44.000' and time <'2021-09-23 21:38:18.000' ;

 测试数据的查询响应时间为0.07秒左右。

        在以上两种数据查询场景中，TDengine的性能不仅完全可满足需求，更是比原InfluxDB+Redis+Mysql方案大幅度的提升，解决了原方案中车辆查询较大时间跨度的轨迹数据响应超级慢的问题。

写在最后：

       非常感谢涛思的TDengine，切实解决了我们在国产化、性能、降本、平滑迁移的刚性需求。也非常感谢涛思的罗格老师在我们尝试和应用TDengine过程中给予的悉心指导，加快了我们对TDengine的掌握，更快的应用落地。

        当前TDengine的大规模应用车辆监管项目中，支撑现有数万辆车的行驶轨迹监控，未来将继续扩大规模支撑更多的车辆轨迹监控。

作者：

孙运盛，吉科软技术研究院架构师，致力于微服务、大数据、人工智能方向的研究与应用。