小 T 导读：在 TDengine 平稳运行的数周时间里，中天钢铁的新系统平均每周收录 3000 多辆车辆表与 100 多条船只表，每张表中数据或多或少，累计数量已达百万，业务的实际效果也达到了预期。本文分享了他们对于新项目的数据库选型、应用的思考，同时也进行了业务效果分析。
为了满足业务发展需求，我们需要新开发一套功能，对厂内每辆运输车辆的实时 GPS 位置进行追踪，通过大数据平台对 GPS 坐标进行处理、分析、可视化展示。同时也需要对公司货运船只进行实时监控，运用 GPS 平台的分析处理能力对船只的航运轨迹进行预判，计算其是否偏离航线。这些 GPS 数据来自于中天云商 App，只要运输车辆司机打开云商 App，系统每隔 10 秒会自动发送该车辆 GPS 信号到大数据平台，再由大数据平台分析处理。
数据处理路径主要为，大数据平台将 ERP 中关联过合同的 MMSI 信息同步到 GPS 平台，由 GPS 平台挑选出 300 条船舶的 MMSI 同步至船达通平台，同时将接收数据接口地址发送到船达通平台，船达通平台会根据 MMSI 编号以及推送地址，每隔 10 分钟将该船只的最新位置以及动静态信息推送至 GPS 平台。基于此，调研到一个合适的数据库，对于实现项目的数据处理需求至关重要。
关于数据库选型调研的思考
本质上来讲，行车记录、行船记录都是时序数据，天然带有时间戳，这些时序数据到达服务器时都是有序递增的，且时序数据的特点是流量平稳却非常巨大，这点和电商数据不太一样，比如双十一时电商数据会出现陡增，平常却没有那么高流量。作为典型的时序数据，车联网数据每隔 10 秒或 10 分钟发送一条，相对固定，在调研时我们发现，TDengine “一辆车一张表”的模型很契合这一场景。
同时，时序数据在查询时要匹配特定的时间线或数据标签，且实时状态查询、数据降精度、整体趋势分析较多，普通数据库无法提供这种函数。基于“一辆车一张表”这样的设计，TDengine 能够实现任何一台设备采集的数据，在存储介质里都是一块一块连续存放的，且按照时间排序，保证了在查询单个设备一个时间段的数据时，查询性能能够有数量级的提升。
另外一方面，虽然不同设备由于网络的原因，到达服务器的时间无法控制，是完全乱序的，但对于同一个设备而言，数据点的时序却是可以保证的。“一个设备一张表”就保证了一张表插入的数据是有时序保证的，这样一来数据插入操作就变成了一个简单地追加操作，插入性能也有了大幅度提升。
在压缩性能上，通过下表几家 Database 的对比，也可看出 TDengine 的优秀：
同时 TDengine 针对同类型设备间的聚合问题，创新性地提出超级表的概念，让多设备间的聚合变得灵活方便，也让实时数据大屏显示、监测设备分类管理变得极其简单。总结而言，TDengine 针对时序数据的写入、存储、索引、查询等方面都进行了特定的优化，从而实现了更优的数据加载、压缩、查询、写入性能，非常匹配工业传感器数据的应用分析场景。
虽然接入设备繁多，但 TDengine 兼容性很强，写入、读取和统计效率也大大高于其他同类型数据库。对比 InfluxDB 来看，其测试数据显示如下：
为了评估不同长度的时间窗口对查询性能的影响，我们选取了第四个查询场景，设定并行执行的 work 数量 16， 时间区间是随机选取的 1h / 2h / 4h / 8h / 12h 等连续时间段，单个聚合时间窗口维持在 1min 不变。获得的查询响应时间如下所示：
平台架构的实现
下图是我们的数据处理路径图，数据通过中天云商、船达通平台将数据抽到 GPS 平台，通过 GPS 平台分析处理后将数据存入数据仓库（TDengine）。
基于 TDengine，GPS 平台会对实时获取的 GPS 数据以及 AIS 数据进行分析处理和存储，再通过每辆车、每条船对应的表，实现车辆船只轨迹可视化。
根据业务不同，我们创建了两张超级表，分别为车超级表与船超级表。超级表是具有沟通的 Schema 共同元数据表的集合，可以认为创建一个超级表，它下面能够再次创建很多子表，对超级表的查询相当于作用到它下面所有的子表。
比如当你要查一个超级表的平均值，假设它下面有 100 万张表，我就相当于对这 100 万张表做了查询，这样用一个超级表就解决了这个问题。每新增一条信息则依照对应载具信息新建子表或者在已有子表中插入最新数据。
测试与查询
目前 TDengine 在我们的生产环境中运行平稳，通过对生产环境的机器进行检测，CPU 使用率平常不到 1%，内存使用率稳定在 25%。下图为集群中一台机器的监控图表：
在 TDengine 平稳运行的数周时间里，中天钢铁的新系统平均每周收录 3000 多辆车辆表与 100 多条船只表，每张表中数据或多或少，累计数量已达百万，业务的实际效果也达到了预期。
现在可以根据车辆车牌号、需要查询的时间区间来可视化车辆轨迹。在数据库中存储上车辆信息时间、经纬度、车牌信息，在展示页面中就会实时显示当前厂内所有提货车辆的最新位置（前提是必须保持中天云商处于打开状态），当车辆提货出厂后，则不再发送 GPS 信息，系统会将该车辆判断为离线状态，不再显示。或者当司机异常关闭中天云商超过 8 个小时，系统也将视该车辆为离线，从屏幕显示中去除，直到重新接收到 GPS 信号。
根据船舶名称、需要查询的时间区间，就可以查询该艘船只的历史 AIS 轨迹图，如果有的船只中途异常关闭 AIS 信息发送装置，则系统无法接收到该船只的 AIS，展示的历史轨迹中则会出现间断。船只 AIS 信息永久保存在 TDengine 库中，在其中可以查询任意时间段内的 AIS 轨迹。
未来规划
本次在中天钢铁 GPS 平台车辆调度中使用了 TDengine，我们发现它不仅性能高效，在设计上也很人性化，其支持的 SQL 查询语句，让人无需学习就能立刻上手。再就是关于 TDengine 在监控领域的应用，监控无非是做一个数据的存储，数据库的存储性能相当重要，TDengine 表现很突出。
总而言之，TDengine 的应用真正让车联网、工业互联网、运维监测大数据平台的搭建变得简单，不仅降低硬件成本、运维成本，还能大幅降低对研发和运维人员的需求。后续我们也会继续分享 TDengine 的更多应用场景和实践经验等，给到大家参考。
当然，对于 TDengine 我们也有一些建议，希望它能够发展地越来越好：
- 支持更加丰富的 SQL 语句：能够针对特有的场景，提供更加灵活的 SQL 语句，便于做更加复杂的计算分析，这也是 AIOps 的进阶部分。
- 子表自动清理功能：由于域名会存在下线问题，目前的 TTL 策略只是针对数据而不是 Table 本身，淘汰子表还需要人工运维介入。
- 现在 TDengine 对于数据的更新只有相同时间戳覆盖这种办法，希望能提供数据删除功能（小T提示：TDengine 2.6 企业版已经提供删除功能 ⬅️点击链接文章看详情）。
- 提供简洁易操作的可视化界面，如 Navicat 之于 MySQL。
