TDengine助力顺丰科技大数据监控改造

做者：尹飞

小T导读 ：顺丰科技大数据集群天天须要采集海量监控数据，以确保集群稳定运行。以前虽然采用了OpenTSDB+HBase做为大数据监控平台全量监控数据的存储方案，但有很多痛点，必须对全量监控数据存储方案进行改造。经过对IoTDB、Druid、ClickHouse、TDengine等时序数据存储方案的调研，最终咱们选择了TDengine。大数据监控平台采用 TDengine 后，在稳定性、写入性能、查询性能等方面都有较大的提高，而且存储成本下降为原有方案的1/10。

场景与痛点

顺丰科技致力于构建智慧大脑，建设智慧物流服务，持续深耕大数据及产品、人工智能及应用、综合物流解决方案等领域，在中国物流科技行业处于领先地位。为了保证各种大数据服务的平稳运行，咱们围绕OpenFalcon搭建了大数据监控平台。因为OpenFalcon自己采用的是rrdtool做为数据存储，不适合作全量监控数据的存储，因而咱们采用了OpenTSDB+HBase做为大数据监控平台全量监控数据的存储方案。

目前整个平台平均写入数十亿条/天。随着大数据监控平台接入的数据量愈来愈大，咱们有不少痛点须要解决，包括依赖多、使用成本高和性能不能知足等问题。

依赖多，稳定性较差 ：做为底层大数据监控平台，在数据存储方面依赖Kafka、Spark和HBase等大数据组件。过长的数据处理链路会致使平台可靠性下降，同时因为平台依赖大数据组件，而大数据组件的监控又依赖监控平台，在大数据组件出现不可用问题时，没法及时经过监控平台对问题进行定位。
使用成本高 ：因为监控数据写入数据量巨大，且须要保存全量监控数据半年以上，用以追溯问题。因此依据容量规划，咱们采用4节点OpenTSDB+21节点HBase做为全量监控数据存储集群。压缩后天天仍须要1.5T（3副本）左右空间存储，总体成本较高。
性能不能知足需求 ：OpenTSDB做为全量监控数据存储方案，在写入方面性能基本知足需求，可是在平常大跨度和高频次查询方面已没法知足要求。一方面，OpenTSDB查询返回结果慢，在时间跨度比较大的状况下，须要十几秒；另外一方面，OpenTSDB支持的QPS较低，随着用户愈来愈多，OpenTSDB容易崩溃，致使整个服务不可用。

技术选型

为解决上述问题，咱们有必要对全量监控数据存储方案进行升级。在数据库选型方面，咱们对以下数据库作了预研和分析：

IoTDB ：刚孵化的Apache顶级项目，由清华大学贡献，单机性能不错，可是咱们在调研时发现不支持集群模式，单机模式在容灾和扩展方面，不能知足需求。
Druid ：性能强大，可扩展的分布式系统，自修复、自平衡、易于操做，可是依赖ZooKeeper和Hadoop做为深度存储，总体复杂度较高。
ClickHouse ：性能最好，可是运维成本过高，扩展特别复杂，使用的资源较多。
TDengine ：性能、成本、运维难度都知足，支持横向扩展，且高可用。

经过综合对比，咱们初步选定TDengine做为监控数据存储方案。TDengine支持多种数据导入方式，包括JDBC和HTTP模式，使用都比较方便。因为监控数据写入对性能要求比较高，咱们最后采用了Go Connector，接入过程须要作以下操做：

数据清洗，剔除格式不对的数据；
数据格式化，将数据转化为实体对象；
SQL语句拼接，对数据进行判断，肯定写入的SQL语句；
批量写入数据，为提升写入效率，单条数据完成SQL拼接后，按批次进行数据写入。

数据建模

TDengine在接入数据前须要根据数据的特性设计schema，以达到最好的性能表现。大数据监控平台数据特性以下：

数据格式固定，自带时间戳；
上传数据内容不可预测，新增节点或服务都会上传新的标签内容，这致使数据模型没法前期统一建立，须要根据数据实时建立；
数据标签列很少，可是标签内容变化较多；数据数值列比较固定，包括时间戳，监控数值和采样频率；
单条数据数据量较小，100字节左右；
天天数据量大，超过50亿；
保存6个月以上。

根据上述特色，咱们构建了以下的数据模型。

按照TDengine建议的数据模型，每一种类型的数据采集点须要创建一个超级表，例如磁盘利用率，每一个主机上的磁盘均可以采集到磁盘利用率，那么就能够将其抽象成为超级表。结合咱们的数据特色和使用场景，建立数据模型以下：

以指标做为超级表，方便对同一类型的数据进行聚合分析计算；
监控数据自己包括标签信息，直接将标签信息做为超级表的标签列，相同的标签值组成一个子表。

库结构以下：

超级表结构以下：

落地实施

大数据监控平台是上层大数据平台稳定运行的底座，须要确保整个系统的高可用性；随着业务量增长，监控数据量持续增加，要保证存储系统能方便的进行横向扩展。基于以上两点，TDengine落地整体架构以下：

为保证整个系统的高可用和可扩展性，咱们前端采用nginx集群进行负载均衡，保证高可用性；单独分离出客户端层，方便根据流量需求进行扩容缩容。

实施难点以下。

数据写入 ：因为监控指标的上传接口是开放型的，只会对格式进行校验，对于写入的数据指标不肯定，不能预先建立好超级表和子表。这样对于每条数据都要检查判断是否须要建立新的超级表。若是每次判断都须要访问TDengine的话，会致使写入速度急剧降低，彻底没法达到要求。为了解决这个问题，在本地创建缓存，这样只须要查询一次TDengine，后续相关指标的写入数据直接走批量写入便可，大大提高了写入速度。另外，2.0.10.0以前的版本批量建立表的速度很是慢，为了保证写入速度，须要按照建立表和插入数据分批插入，须要缓存子表的数据信息，后面的版本优化了子表建立功能，速度有了大幅提高，也简化了数据插入流程。
查询问题 ：1. 查询bug。监控平台数据主要是经过Grafana进行数据展现，可是在使用过程当中，咱们发现官方提供的插件不支持参数设置，根据咱们的自身需求，对其进行了改造，并提供给社区使用。另外在使用过程当中，触发了一个比较严重的查询bug：在设置较多看板时，刷新页面会致使服务端崩溃。后经排查，发现是因为Grafana中一个dashboard刷新时会同时发起多个查询请求，处理并发查询致使的，后经官方修复。2. 查询单点问题。TDengine原生HTTP查询是直接查询特定服务端完成的。这个在生产环境是存在风险的。首先，全部的查询都集中在一台服务端，容易致使单台机器过载；另外，没法保证查询服务的高可用。基于以上两点，咱们在TDengine集群前端使用Nginx集群做反向代理，将查询请求均匀分布在各个节点，理论上能够无限扩展查询性能。
容量规划 ：数据类型，数据规模对TDengine性能影响比较大，每一个场景最好根据本身的特性进行容量规划，影响因素包括表数量，数据长度，副本数，表活跃度等。根据这些因素调整配置参数，确保最佳性能，例如blocks，caches，ratioOfQueryCores等。根据与涛思工程师沟通，肯定了TDengine的容量规划计算模型。TDengine容量规划的难点在于内存的规划，通常状况下，三节点256G内存集群最多支持2000w左右的子表数目，若是继续增长的话，会致使写入速度降低，且须要预留一部分的内存空间做为查询缓存使用，通常保留10G左右。若是子表数量超过2000w，则能够选择扩展新节点来分担压力。

改造效果

完成改造后，TDengine集群轻松扛住了全量监控数据写入，目前运行稳定。改造后架构图以下：

稳定性方面 ：完成改造后，大数据监控平台摆脱了对大数据组件的依赖，有效缩短了数据处理链路。自上线以来，一直运行稳定，后续咱们也将持续观察。
写入性能 ：TDengine的写入性能跟写入数据有较大关系，在根据容量规划完成相关参数调整后，在理想状况下，集群写入速度最高达到90w条/s的写入速度。在一般状况下（存在新建表，混合插入），写入速度在20w条/s。
查询性能 ：在查询性能方面，在使用预计算函数状况下，查询p99都在0.7秒之内，已经可以知足咱们平常绝大部分查询需求；在作大跨度（6个月）非预计算查询状况下，首次查询耗时在十秒左右，后续相似查询耗时会有大幅降低（2-3s），主要缘由是TDengine会缓存最近查询结果，相似查询先读取已有缓存数据，再结合新增数据作聚合。
成本方面 ：服务端物理机由21台降至3台，每日所需存储空间为93G（2副本），同等副本下仅为OpenTSDB+HBase的约1/10，在下降成本方面相对通用性大数据平台有很是大的优点。

总结

目前从大数据监控这个场景看，TDengine在成本，性能和使用便利性方面都有很是大的优点，尤为是在成本方面带来很大惊喜。在预研和项目落地过程当中，涛思的工程师提供了专业、及时的帮助，在此表示感谢。但愿TDengine可以不断提高性能和稳定性，开发新特性，咱们也会根据自身需求进行二次开发，向社区贡献代码。祝TDengine愈来愈好。对于TDengine，咱们也有一些期待改进的功能点：

对表名支持更友好；
对其余大数据平台的支持，联合查询需求；
支持更加丰富的SQL语句；
灰度平滑升级；
子表自动清理功能；
集群异常停机恢复速度。

后续咱们也将在顺丰科技的更多场景中尝试应用TDengine，包括：

物联网平台，做为底层物联网数据存储引擎构建顺丰科技大数据物联网平台；
Hive on TDengine，经过Hive on TDengine实现与现有其余数据源数据联合查询，使其能平滑的与现有系统使用，下降接入门槛。