关于tdengine:TDengine助力顺丰科技大数据监控改造

4次阅读

共计 3864 个字符，预计需要花费 10 分钟才能阅读完成。

作者：尹飞
小 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，咱们也有一些期待改良的性能点：