TDengine 在蔚来能源系统的落地实践

2022-03-21 00:00:00 查询 数据 业务 设备 写入

一、项目背景


现状

在业务诞生之初，我们用作数据存储的选型是 MySQL + HBase，MySQL 存储设备新实时数据，HBase存储设备原始数据，大体架构如下：



之所以选择 HBase，有以下几个理由：

  • HBase 在大数据领域应用较为广泛，适合存储海量数据，写入性能好
  • 支持动态添加列，非常方便兼容数据模型变化
  • 底层是键值对存储，数据可以比较稀疏，空数据不占存储空间
  • 团队 HBase 技术使用相对较为成熟


痛点

初期因为设备不多，数据量不大，加上查询场景单一，HBase 表现不错，可以满足业务需求。

随着换电站和超充站等设备在的快速布局，设备数量持续增长，积累的数据量越来越多，长时间跨度数据查询效率出现瓶颈，再加上查询场景不断丰富，HBase 已经无法满足当前业务需要。问题主要体现在以下几点：

  • HBase 只支持 Rowkey 索引，有很大的局限性，一些查询场景依赖 Rowkey 设计合理，如果业务调整，无法兼容
  • 可以引入二级索引解决，单独维护查询条件与 Rowkey 关系，查询时先查到 Rowkey 再查数据，不管是引入中间件还是自己实现，都会增加整体架构和实现复杂度
  • HBase 单表随着数据量增大，会触发自动分区，导致写入性能下降，需要通过建表时指定预分区来解决，调整起来很麻烦，需要重新建表生效
  • HBase 不适用于大范围扫描查询，性能比较差
  • HBase 不支持聚合查询，大跨度时间范围查询数据量太大，图表无法渲染
  • HBase 部署需要依赖 ZooKeeper，运维成本高


二、落地方案


技术选型

为了解决这些痛点，我们将目光投向时下流行并且更适合物联网领域的时序数据库。经过调研，对比多个技术选型，终决定使用 TDengine 代替 HBase 作为设备原始数据存储。

在选型时我们考虑过 OpenTSDB，也是一款的时序数据库产品，在部门其他业务中已经有过比较成熟的使用，能解决一部分遇到的痛点：

  • OpenTSDB 在 HBase 基础上做了优化，包括存储元数据映射和压缩机制，使数据存储占用空间大大降低
  • OpenTSDB 提供数据聚合查询功能，可以支持更大时间跨度查询的业务需求


但是 OpenTSDB 底层还是基于 HBase 的，HBase 存在的一些问题，OpenTSDB 依然会有，并且架构并没有变简单，没有摆脱 HBase 的依赖。

经过对比，我们决定尝试一下 TDengine，其官方给出的性能指标，单节点部署情况下可以达到 14810 k/s 读取，和 880k/s 写入，同时 TDengine 具备的一些特点能很好地解决我们遇到的痛点：

  • 引入超级表概念对应设备类型，对每个设备创建子表继承超级表，通常相同设备类型的设备数据模型一定相同，通过超级表管理 schema 直接对子表生效很方便，同时对每个设备建表可以很好地做数据隔离，同时避免互相影响
  • 采用多级存储，不同时间的数据使用不同存储介质，新数据经常访问存 SSD 保证效率，老数据存 HDD，节约成本
  • 不依赖任何第三方软件，集群安装部署方便，支持灵活扩容
  • 提供多种聚合函数，支持对数据的聚合查询


前期测试

我们使用 TDengine 做了一些简单的性能测试，评估使用 TDengine 是否能满足我们的业务需求。

测试准备

  • 采用单节点部署
  • 8 核 32GB，500GB 存储
  • 采用默认配置
  • 采用 RESTful API 方式写入数据

测试场景

模拟 10,000 个设备上报数据，消息并发约 4k 左右。

  • 定义超级表如下
-- 代码示例，非真实代码
CREATE STABLE device_data_point_0 (ts timestamp, d1 nchar(64), d2 nchar(64), ...) TAGS (t1 binary(64));

相关文章