服务器数量从21台降至3台，TDengine在跨越速运集团的落地实践_大数据_周美华



 写点什么

跨越速运集团有限公司创建于 2007 年。拥有“国家 AAAAA 级物流企业”、“国家级高新技术企业”、“中国物流行业 30 强优秀品牌”、“中国电商物流行业知名品牌”、“广东省诚信物流企业”等荣誉称号。在胡润研究院发布的《2018 Q3 胡润大中华区独角兽指数》《2019 一季度胡润大中华区独角兽指数》榜单中，跨越速运两次上榜，估值约 200 亿元，与菜鸟网络、京东物流、达达-京东到家等企业入选中国物流服务行业独角兽企业。作为一家物流企业，如何高效地记录和处理车辆的轨迹信息，对于整体的交付效率至关重要。

项目背景

数年前车辆轨迹定位存储引擎项目成立，跨越速运集团购置的数万台车辆经过车载定位设备上报信息到 GPS-AGENT 网关，服务解析报文下发到 Apache Kafka 消息中间件，再通过应用将历史位置定位信息写入 Apache HBase，最新车辆位置信息写入 Redis，以此提供给业务服务进行对车辆的实时监控与分析。

原来的业务架构如下图所示：

在原有系统的实际运行过程中，我们也遇到了很多痛点。比如说，因为数据保存在 HBase 中，当我们需要查询较大跨度的时间内的数据时，系统的性能会显著下降。

具体可以总结如下：

于是我们开始思考，该如何改进系统来解决这些痛点呢？

项目演化

在开始新的技术选型之前，我们重新对业务场景进行了梳理，可以用下面这张图来概括。

我们依次来看一下：

（1）数据不更新不删除：轨迹信息是按照车辆实际信息的时间戳上报，不存在更新和删除的需求。只需要按照某个时限来保存。

（2）无需传统数据库的事务处理：因为数据不需要更新，也就不需要像传统数据库那样用事务来保证更新安全。

（3）流量平稳，一段时间内车辆的数量和上报的频率都可以确定。

（4）数据的查询分析基于时间段和空间区域，这跟业务需求有关。

（5）除存储、查询操作外，还需要根据业务的实际需求进行各种统计和实时计算等操作。

（6）数据量巨大，一天采集的数据超过 5000 万条，并且会随业务规模的不断增长而增长。

技术选型

通过以上分析可以看到，车辆轨迹是典型的时间序列数据，所以用专门的时序数据库来处理会比较高效。在调研阶段，我们对比了几款比较有代表性的时序数据库产品。

综合对比后的结果如下：

InfluxDB 集群版本收费，硬件成本也相对较高；
CTSDB 腾讯云时序数据库，内存用量高，费用成本相对较高；
OpenTSDB 底层基座还是 HBase ，引入并不能使架构变得简单；
TDengine 集群功能开源，具有典型的分布式数据库特征，压缩比例也非常高。

通过对比，我们认为 TDengine 的很多优秀特性能够满足我们的业务场景。

于是我们基于 TDengine 进行了前期调研和演练。具体包括如下几个方面：

我们从多个方面对 TDengine 的功能和性能进行了全方位的测试，功能完全能够满足我们的需求，性能、压缩率给我们带来了很大的惊喜。

在完成基本的功能和性能测试之后，我们又结合业务进行了场景测试和演练，主要包含如下几方面的工作：

数据在写入时候对集群扩缩容
cacheLast 的应用是否有效
统计聚合分析 interval，interp 的一些业务场景应用
update 参数的覆盖场景
常用业务的查询语句，同等查询范围的数据对比

深入理解 TDengine

在实际落地 TDengine 之前，我们也深入研究了这个系统的架构、设计等各方面特性。这里也简单分享一下 TDengine 的核心概念。

TDengine 架构

如果是第一次接触 TDengine，可以看一下如下这张图，其中的 dnode 就是实际存储数据的物理节点，dnode 框中的 V2、V7 等小框叫 vnode，也就是虚拟节点，m0、m1 就是元数据管理节点，存储一些集群信息与表信息，熟悉分布式中间件的朋友肯定能直观地感受到 TDengine 具有非常典型的分布式数据库特征。

超级表

TDengine 有个超级表的概念，例如在跨越速运集团业务场景下，所有的车辆变成一张张子表，所有的子表会继承一张叫超级表的父表，超级表定义子表的结构规范，不存储实际物理数据，我们可以通过只查超级表做数据的统计分析查询，而不用一个个子表去汇总。

高压缩特点

TDengine 采用了二阶段压缩策略，一阶段压缩会使用 delta-delta 编码、simple 8B 方法、zig-zag 编码、LZ4 等算法，二阶段压缩会采用 LZ4 算法。一阶段压缩会针对每个数据类型做特定的算法压缩，二阶段再做一次通用压缩，前提是在建库的时候将参数 comp 设置为 2 。