首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

服务器数量从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 。

引入 TDengine 之后的架构

在进行了充分的测试和验证之后,我们将 TDengine 引入到了我们的系统之中。新的系统架构如下图所示:

从架构图中可以看到,车载数据依然通过 GPS-AGENT 网关进行报文解析后发送到 Apache Kafka 中,再通过应用多开启一个 Kafka group 同时消费消息,以此达到两端数据的一致。

业务系统最新车辆位置信息不再通过 Redis 读取,这样就简化了架构。查询只读取 TDengine,HBase 在一定的时间后会下线。

优化效果

引入 TDengine 之后,从各项指标来看,数据非常亮眼。

压缩率

如图我们看到一个 5 万行的表,每行在 600 字节以上,压缩后的磁盘 size 是 1665KB,压缩率高达 1%。接下来我们看个百万行的子表。

它实际占用磁盘大小为 7839KB。我们的压缩效果比 TDengine 官方的各种测试还要好很多,这应该与我们业务数据重复度相对较高有一定关系。

日增量

我们现在的业务日写入量超过 5000 万,对 TDengine 来说日增的磁盘大小基本维持在单台 1.4G 左右。

各项指标的整体对比

下图是我们实际落地前后各项指标的对比。

下图是数据增量的对比。

从对比可以看出,TDengine 确实极大降低了我们的各项成本。

问题和建议

一个相对较新的系统,在使用过程中难免会遇到一些问题,我们也和 TDengine 的研发团队一起去定位、解决。

比如下面这个就是我们在使用 JDBC 过程中遇到的问题。我们也给官方提 PR 修复了。这就是开源的魅力吧,大家都可以参与进来。

有两个地方,我们也希望 TDengine 能进一步优化:

  1. 2.3.0.x 以下的监控功能还比较简单,我们期待后期的版本能提供更强更细致的监控。我们注意到新发布的版本引入了一个叫 TDinsight 的监控工具,我们也会尽快尝试一下。
  2. 目前的 interval 函数还不支持按业务列 group by 普通列,后续希望也能够得到支持。
  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/4SlRIbxhe7QvVCSQF8LV
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

相关快讯

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券