一、我的项目背景
为了给用户提供更好的补能体验，蔚来能源在加电基础设施上进行了大量的投入，截止 2021 年底，曾经在全国各地布局了换电站 777 座，超充桩 3,404 根，目充桩 3,461 根，为用户装置家充桩 96,000+ 根。
为了对设施进行更高效的治理，须要将设施采集数据上报至云端进行存储，并提供实时数据查问、历史数据查问等业务服务，用来做设施监控和剖析。
现状
在业务诞生之初，咱们用作数据存储的选型是 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 左右。
- 定义超级表如下
SQL — 代码示例，非实在代码
CREATE STABLE device_data_point_0 (ts timestamp, d1 nchar(64), d2 nchar(64), …) TAGS (t1 binary(64));
- 最后采纳每条上报音讯进行一次数据写入，性能无奈满足，而将单条音讯写入改为批量写入，积攒一批数据（100 条）后，再批量写入一次，性能能够撑持
测试论断
采纳批量写入数据形式，调整适合的单批次数据量大小，应用单机部署（8 核 32 GB，500 GB 存储）默认配置的 TDengine 服务，RESTful API 写入形式，在 4k 并发流量下写入没有问题，同时生产积压数据时峰值达到 7 k/s，因为单条音讯蕴含信息量太大，理论解决中会拆分为 30 条写入 TDengine，所以理论写入 QPS 为 210 k/s，比满足同样数据流量的 HBase 集群规模要小不少，能够节省成本，再加上 TDengine 自身部署不依赖其余三方软件，也能够同时节俭运维老本。
迁徙计划
通过测试，咱们决定先对局部设施利用 TDengine 时序数据库代替 HBase，同时须要思考如何在不影响业务性能的状况下平滑过渡并实现迁徙。
数据双写
因为目前没有现成的工具能够间接把数据从 HBase 迁徙到 TDengine，如果本人开发一个工具做这件事件，开发成本太高，而且可能是一次性的。
思考到不想节约开发资源，同时咱们须要一个过渡期，期间如果 TDengine 呈现问题能够迅速切换回 HBase，不影响业务，所以不能马上把 HBase 废掉，所以咱们决定先实现 TDengine 写入，并且临时放弃 HBase 和 TDengine 两个数据库双写。
写入形式
依据后期测试后果，咱们抉择间接采纳批量形式写入数据：
- 并行处理不同设施类型数据
- 生产设施上报数据放入队列
- 当队列长度达到 n 或超过等待时间 t，从队列中取出数据批量写入
通过压测，在 n = 1,000，t = 500 ms 状况下，单次写入耗时根本在 10 ms 以内，意味着咱们能够反对单个设施类型每秒上万的并发写入，并且还有进一步的优化晋升空间。
查问切换
为了保障迁徙过程顺利，并且迁徙前后不会呈现数据不残缺的状况，咱们做了一个查问开关：
- 配置 TDengine 性能上线工夫
- 判断查问申请工夫范畴与配置工夫大小，决定查 HBase 还是 TDengine
- 过渡期完结后，进行 HBase 服务
迁徙后架构变为如下所示：
三、实际效果
目前咱们已将线上局部设施的数据切换到 TDengine 集群，上线后集群体现稳固。
比照之前应用 HBase：
- 查问速度晋升显著，从应用 HBase 查问单设施 24 小时数据的秒级返回，到应用 TDengine 查问查问雷同数据的毫秒级返回
- 每天增量数据占用的存储空间相当于原来应用 HBase 时的 50%
- 集群计算资源老本相比应用 HBase 节俭超过 60%
四、总结
- 总体上说，TDengine 读写性能体现很好，在满足咱们业务需要的同时，极大地节俭了计算资源和运维老本，目前尝试 TDengine 的业务场景还比较简单，只是单纯的数据写入和工夫范畴查问，后续能够联合 TDengine 更多进阶性能摸索其余能够落地的业务场景
- 应用上还有一些问题待解决，比方 schema 调整在利用发版过程中对数据写入的影响，产生预期外的写入异样，以及异样定义不明确，无奈疾速定位问题，尤其是跟 schema 相干数据写入问题
- 监控方面目前反对的监控指标较少，这个问题据说会在后续版本丰盛
- 数据迁徙方面，目前官网反对工具还比拟少，不能比拟不便的把数据从其余存储引擎迁徙到 TDengine，须要进行额定开发
对于作者
李鹏飞，蔚来汽车能源数字化产品开发部高级工程师，目前负责能源物联平台开发。
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。