当前位置:网站首页>兴盛优选:时序数据如何高效处理?

兴盛优选:时序数据如何高效处理?

2022-08-11 11:14:00 InfoQ

小 T 导读:
兴盛优选需要通过实时产生的数据来判断设备是否工作、检测通讯是否延时、观测 SNMP OID 流量是否正常等,从而保障运维与网络人员及时发现问题并修复。为高效处理各类
时序数据
,保障服务的稳定运行,在对比了 Elasticsearch、InfluxDB 和 
TDengine
 三款产品之后,他们选择并落地了 TDengine。

企业介绍

湖南兴盛优选电子商务有限公司(简称兴盛优选),总部位于湖南长沙,是一家关注民生的互联网“新零售”平台,主要定位是解决家庭消费者的日常需求,提供包括蔬菜水果、肉禽水产、米面粮油、日用百货等全品类精选商品。兴盛优选依托社区实体便利店,通过“预售+自提”的模式为用户提供服务,是社区电商中唯一一家估值超过 150 亿美金的“独角兽”。

业务背景

为了保证互联网服务的高效和稳定,我们需要监控公司所有的节点服务器(包括云服务器)、交换机及路由器。我们需要通过实时产生的数据来判断设备是否工作、检测通讯是否延时、观测 SNMP OID 流量是否正常等,从而保障运维与网络人员及时发现问题并修复。
这类数据是非常典型的时序数据,应该如何高效地处理呢?现在市面上有几款非常流行的
时序数据库
Time Series Database
)产品。应该如何评估并选择适合我们业务场景的技术平台呢?

产品调研

针对该业务场景,我们调研了如下几个产品:Elasticsearch、InfluxDB 和 TDengine。具体对比如下。
Elasticsearch
  • 优点:可以分布式部署,可以无障碍插入,支持任意的字段类型,查询速度快。
  • 缺点:只适合记录日志且并发数据量不大的情况,对于海量设备的时序数据写入有性能问题。
InfluxDB
  • 优点:支持无模式(Schemaless 写入),限制较少。
  • 缺点:当面对大批量的数据同时插入或读取时,内存容易被占满,导致死机。尤其是其中的轮询机制,在检验过期数据时,内存占用特别大。此外,在读取数据时,读出来的是列表,可读性差,解析比较麻烦。
TDengine
  • 优点:列式存储以及“一个设备一张表”的模型与我们业务场景十分契合。此外,还可以兼容我们以前使用 InfluxDB 时所习惯的插入方式,代码可读性强,支持强绑定参数。在执行海量数据的查询时,响应速度比 InfluxDB 更快。
  • 缺点:Schemeless 的支持还在持续完善之中。
由于该项目未来需要监控我们公司的所有服务器,平均每台对应的 OID 会有几百个,如果每 1-5 秒采集存储一次,并发数据量会非常大。因此,我们从候选中淘汰了 Elasticsearch。
接下来我们又继续对比了 InfluxDB 和 TDengine。InfluxDB 单节点性能不足,集群闭源且性能未知。反观 TDengine,其集群功能是开源的,且保留了企业版的部分核心功能。这让我们可以直接非常深入地了解 TDengine 的优劣。从这方面考虑,我们选择了 TDengine。而且在实际使用中,我们又发现了 TDengine 的一大优势,其“一个设备一张表”的模型十分契合我们的实际场景。

系统架构

在引入 TDengine 之后,我们的系统架构如下图所示。
在该架构下,前端制定好规则下发(例如:流量阈值,延时阈值),后端看是否需要存储规则,或检查规则是否发生变化,然后把规则下发给 ETCD 来做定时任务调度。我们共有三个程序任务,通过 ETCD 管理,定时和各类设备通信,根据不同规则分别抓取各自需要的数据:
  • SNMP 引擎通过 OID 监控网络设备各项指标
  • TCPing 引擎用于监控服务器 TCP 端口状态
  • ICMP 引擎重点采集接收或返回数据的时间
这三大类数据采集之后,会经过统一处理,再写入 TDengine。
我们使用 5 个节点搭建了一套 TDengine 集群:
我们选择了无模式写入,在写入时自动建表,具体写入方式可参考官网。这样一来,每一台服务器对应的类型都是一张超级表,我们选择尽量地分表 ,提升查询速度。
对于 SNMP 类型的超级表来说,每一个子表就是一个 OID。
对于 TCPing 类型,我们按照 TCP 端口来区分子表。
对于 ICMP 类型的超级表,我们以 task_id 和 task_type 作为区分子表的依据:
目前我们已经存储了 500 万张子表,平均算下来设备上报频率大概为 3 秒 1 行,总数据量达到了百亿级别,而占用的存储空间只有 70GB 左右。这应该得益于 TDengine 针对性地使用了列式压缩,存储资源占用很小,压缩率大概为 8% 左右。TDengine 可以很好地顶住写入和存储压力。而查询方面,我们会批量查询部分表的特定时间的值,大部分数据用于实时的监控报警。

经验总结

在使用过程中,花时间相对较多的大概是无模式插入的摸索吧。
对于从 InfluxDB 切换过来的用户,初期可能会有一些不适应。因为 TDengine 最初并不是按照 Schemaless 来设计的,这个功能是后期加入的,系统最终还是会把无模式转化成 SQL 再进行写入,只是简化了用户的操作。不过 TDengine 一直在完善相关的生态适配,比如对于大小写的特殊字符的存储,完善元数据管理,收纳各种形式的数据类型,也在逐步向 InfluxDB 的自由式写入靠近。
除此之外,我们也遇到过一个问题,目前 Go 连接器的查询 API 暂时不支持将多条 SQL 拼接在一起统一执行。因此我们采取了并发读取,但性能可能会受到一点影响,期待后续的版本能够解决。
最后,TDengine 的支持团队相当负责,配合积极,让我们快速上手了这款轻便易用、性能超高的时序数据库。目前我们只接入了一部分服务器及设备,后续我们计划把公司全国范围内所有的服务器都接入进来,也会推荐公司更多部门使用。一切顺利的话,我们也会考虑包括仓库运货机器人,物流线设备等更多应用场景。


想了解更多
TDengine Database
的具体细节,欢迎大家在
GitHub
上查看相关源代码。
原网站

版权声明
本文为[InfoQ]所创,转载请带上原文链接,感谢
https://xie.infoq.cn/article/3e81fc85c9af003782b617e22