为什么腾讯QQ的大数据平台选择了InfluxDB数据库?( 三 )
讲到InfluxDB , 就不能不提InfluxData的开源高性能时序中台TICK(Telegraf + InfluxDB + Chronograf + Kapacitor) , InfluxDB是作为TICK的存储系统进行设计和开发的 。
TICK专注于DevOps监控、IoT监控、实时分析等应用场景 , 是一个集成了采集、存储、分析、可视化等能力的开源时序中台 , 由Telegraf、 InfluxDB、Chronograf、Kapacitor 4个组件以一种灵活松散但紧密配合、互为补充的方式构成 , 各个模块相互配合、互为补充 , 整体系统架构如图1-2所示 。
本文插图
▲图1-2 TICK系统架构
Telegraf是用于采集和上报指标的数据采集程序 , 采用灵活的、可配置的插件实现 。
Telegraf可以通过配置文件的配置 , 采集当前运行主机的指定指标 , 如CPU负载、内存使用等 , 也可以从第三方消费者服务(如StatsD、Kafka等)拉取数据 , 上报到已支持的多种存储系统、服务或消息队列 , 如InfluxDB、Graphite、OpenTSDB、Datadog、Librato、Kafka、MQTT、NSQ等 。
InfluxDB是专注于时序数据场景(如DevOps监控、IoT监控、实时分析等)的高性能时序型数据库 , 支持灵活的自定义保留策略和类SQL的操作接口 。
Chronograf是可视化的、BS架构的管理系统 , 可用于配置和管理接收到的监控数据、告警 , 并支持通过灵活强大的模块和库 , 快速配置数据可视化仪表盘、告警规则、可视化规则 。
Kapacitor是从零构建的原生数据处理引擎 , 支持流式处理和批量处理 , 支持灵活强大的自定义功能 , 如定义新的告警阈值、告警指标特征、告警统计异常特征等 , 以及后续的告警处理行为 。
除了灵活 , Kapacitor也很开放 , 能灵活地集成对接第三系统 , 如HipChat、OpsGenie、Alerta、Sensu、PagerDuty、Slack等 。
本文插图
02 InfluxDB的优势
存储和分析时序数据的时序型系统并不鲜见 , 自计算机问世以来 , 我们一直在数据库中存储时序数据 。
最初 , 使用通用存储系统存储时序数据 , 如MySQL 。 第一代时序平台 , 如KDB +、RRDtool、Graphite等 , 在20年前就推出了 , 主要用于存储和分析数据中心的时序数据 , 以及高频金融数据、股票波动率等 。
根据DB-Engines等数据库趋势跟踪和行业分析网站发布的信息 , 时序型数据库是数据库市场中份额增长最快的部分 。 原因很明显 , 计算机虚拟世界 , 如数据库、网络、容器、系统、应用程序等 , 和物理世界 , 如家用设备、城市基础设施、工厂机器、电力设施等 , 正在创建海量的时序数据 。
现在更多的企业会通过时序存储和数据分析来获得预测能力和实时决策能力 , 从而为客户提供更好的使用体验 。 这意味着底层数据平台需要发展以应对新的工作负载的挑战 , 以及更多的数据点、数据源、监控维度、控制策略和精度更高的实时响应 , 对下一代时序中台提出了更高的要求 , 具体如下所示 。
- 专为时序存储和高性能读写而设计:计算机虚拟世界的各种系统和应用 , 以及物理世界的IoT设备等都在创建海量的时序数据 , 每秒千万级的数据吞吐量是很常见的 , 而且这些数据还需要可以以非阻塞方式接收并且可压缩以节省有限的存储资源 。
- 专为实时操作而设计:预测能力和实时决策能力 , 需要收到数据后 , 就能实时输出最新的数据分析结果 , 执行预定义的操作 。
- 专为高可用性而设计:现代软件系统需要全天候可用 , 除了基本的集群能力 , 还需要根据需求自动扩容和缩容 , 支持柔性可用等 。
- 热量|为什么有的人喝凉水都长肉,有的人却光吃不胖?营养科医生:原因其实很简单
- 驱动中国腾讯内部人士爆料:与“老干妈”合作多个环节有漏洞 却无人察觉
- 疫情|美国疫情速报:确诊数已逼近284万;特朗普发话:99%新冠病例完全无害;美专家:实际感染数或是现有数据10~24倍
- 央视记者火线追踪,腾讯告老干妈成热点,检察机关可以提前介入
- 蜜蜂蜇熊刺针拔不出而被肢解致死
- 三星手机|为什么三星手机,在我国越来越没市场了?原来这是必然结果
- 主从|Redis系列(五):主从复制
- 腾讯|原创 腾讯如果想冻结阿里的资金,阿里除了束手就擒还有办法反制么?
- 不执著财经|为什么越来越多的外企都搬迁到东南亚?
- 腾讯财讯|刚刚!中信证券、中信建投又澄清了,第二个“南北车”难诞生?