金今优选物联网现全面招商,热烈欢迎!0510-88602202

标王 热搜:
 
 
当前位置: 首页 » 公告中心 » 行业新闻
兴盛优选:时序数据如何高效处理?
 [打印]添加时间:2022-08-12   有效期:不限 至 不限   浏览次数:548
   兴盛优选需要通过实时产生的数据来判断设备是否工作、检测通讯是否延时、观测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的支持团队相当负责,配合积极,让我们快速上手了这款轻便易用、性能超高的时序数据库。目前我们只接入了一部分服务器及设备,后续我们计划把公司全国范围内所有的服务器都接入进来,也会推荐公司更多部门使用。一切顺利的话,我们也会考虑包括仓库运货机器人,物流线设备等更多应用场景。