OpenTSDB简介

摘自opentsdb.net官方介绍:

       OpenTSDB is a distributed, scalable TimeSeries Database (TSDB) written on top ofHBase. OpenTSDB was written to address a commonneed: store, index and serve metrics collected from computer systems (networkgear, operating systems, applications) at a large scale, and make this dataeasily accessible and graphable.

       Thanks to HBase'sscalability, OpenTSDB allows you to collect manythousands of metrics from thousands of hosts and applications,at a high rate (every few seconds). OpenTSDB will never delete or downsample dataand can easily store billions of data points. As a matter of fact, StumbleUpon uses it to keep track ofhundred of thousands of time series and collects over 1 billion data points perday in their main production datacenter. Other sites such asBox orTumblrare pushing tens of billions of data points per day.

       Imagine havingthe ability to quickly plot a graph showing the number ofDELETE statements going to your MySQLdatabase along with the number of slow queries and temporary files created, andcorrelate this with the 99th percentile of your service's latency. OpenTSDBmakes generating such graphs on the fly a trivial operation, while manipulatingmillions of data point for veryfinegrained, real-time monitoring.

      

摘自HBase实战7.1节:

       OpenTSDB是一种基于HBase编写的分布式、可扩展的时间序列数据库。OpenTSDB可以用来处理一种通用需求:存储、索引和服务从大规模计算机系统(网络设备、操作系统、应用系统)采集来的参数数据,并且使这些数据易于访问和可视化。

OpenTSDB解决了基础架构监控的普遍性问题,它是一个了不起的项目。如果你开发过生产系统,你会知道基础架构监控的重要性。如果你没有这种经验,也不要担心,我们会告诉你的。OpenTSDB存储的数据是时间序列数据(time series),这也是一个有趣的地方。传统关系型模型不大适合高效处理时间序列数据的存储和查询。关系型数据库厂商为解决这种问题经常会依靠一些非标准的解决方案,例如,把时间序列数据存储成不透明的团儿(blob),然后用专用查询扩展模块进行解析。

OpenTSDB是StumbleUpon公司开发出来的,这个公司使用HBase的经验非常丰富。OpenTSDB是一个使用HBase作为后台存储搭建应用系统的了不起的例子。OpenTSDB是开源的,所以你可以访问到全部代码。整个项目使用了不到15,000行Java,因此可以从整体上对它进行消化吸收。OpenTSDB根本上是一种在线数据可视化工具。在学习它的模式时,请记住这一点。HBase中存储的每个数据点在用户需要时必须能够被访问,如图7-1所示的图表那样展示出来。

 

简单地说,这就是OpenTSDB。下面我们将更仔细地看看OpenTSDB被设计用来解决什么挑战(需求)以及需要存储的数据种类。此后,我们将思考对于像OpenTSDB这样的应用系统为什么使用HBase是个好的选择。现在先让我们了解一下基础架构监控,以便你可以理解这个领域的问题如何诱发了这种数据模式。

 1挑战:基础架构监控

       基础架构监控是为了监视所部署的系统而使用的术语。人们部署了大量的软件项目,用来提供在网络上访问的在线系统和服务。问题是,你部署了这些系统,这意味着你有责任维护好这些系统。怎么知道系统是活着还是死了?每小时系统服务了多少个请求?系统每天什么时间流量最大?如果你曾经因为服务终止在半夜收到过短信告警,这说明你已经在使用基础架构监控工具了。

基础架构监控不仅仅是通知和告警。触发半夜告警的事件系列只是这类工具收集的全部数据中的一小部分。相关数据还包括每秒服务请求数、并发活跃用户数、数据库读写、平均响应延迟时间、进程占用内存等等。每一个数据都是一个特定参数的时间序列测量结果,只是提供了整体系统运行视图的一部分小快照。在一段时间窗口里把这些测量结果收集起来,你就拥有了一个系统运行的视图。

       生成时间序列图片需要按照参数和时间间隔采集的数据,OpenTSDB必须能够从大量系统里收集各种参数,还要支持对任何参数的在线查询。下一节你将看到这个需求如何成为OpenTSDB模式设计的重要考虑因素。

       时间序列数据在OpenTSDB模式设计中扮演了关键角色,所以我们已经多次提到它。让我们熟悉一下这种数据类型。

2 数据:时间序列

可以把时间序列数据看做数据点或者二元数组的一个集合。每个数据点有一个时间戳和一个测量结果。按时间排序的数据点集合是有时间顺序的。测量结果通常以有规律的时间间隔来采集。例如,你可能使用OpenTSDB每15秒采集一次MySQL进程发送的字节数。本例中,你会得到一个如图7-2所示的数据点序列。通常这些数据点也会携带测量结果的元数据,比如生成序列的完整主机名。


Time   时间

Measurements        测量结果

7-2 时间序列数据是一个按照时间排序的数据点序列。在这里,相同比例的两个时间序列显示在同一个图里。它们的时间间隔不同。当可视化表示一个时间序列时, X轴的值一般表示时间戳。

时间序列数据通常在经济学、金融、自然科学和信号处理中可以看到。通过给测量结果附加一个时间戳,我们可以了解测量结果值随时间发展的变化,也可以了解基于时间的模式形态。例如,某个地方的当前温度每小时测量一次,很自然可以根据前面的点预测将来的点。你可以基于前5小时的测量结果来猜测下一小时的温度。

时间序列数据从数据管理角度看颇具挑战性。系统里所有数据点可能共享相同字段,例如:日期/时间,位置和测量结果。但是这些字段不同值的两个数据点可能完全无关。如果一个点是纽约的温度而另一个是旧金山的,即使时间戳相同它们可能也是无关的。如何用一种相关的高效的方式存储和排序数据呢?纽约的所有测量结果不应该存储在一起吗?

另一个值得注意的问题在于如何记录这种数据。在计算机科学里,树(Tree)是一种用于随机访问的高效的数据结构,但是当以有序方式构造树时必须特别小心。时间序列天生按照时间排序,经常按照这个顺序被存储下来。这可能导致存储结构以最糟糕的方式构建,如图7-3所示。


 (a) Balanced Tree 平衡树 (b)Unbalanced Tree 不平衡树

7-3 平衡树和不平衡树。把数据存进基于数据值自我分类的数据结构时,可能导致最糟糕的数据分布状态。

       像树一样,这种顺序也会给分布式系统带来严重破坏。HBase归根结底是一种分布式B-树。当数据按照时间戳跨节点分区时,新数据拥塞在单个节点上,导致热点问题(hot spot)。随着写入数据的客户端增加,那个单个节点很容易被压垮。

简而言之,这就是时间序列数据。现在让我们看看HBase可以给OpenTSDB系统的表带来什么。

3 存储:HBase

因为HBase提供可扩展的数据存储能力,同时支持低延迟查询,它给OpenTSDB这样的应用系统提供了极佳的选择。HBase是一种通用的、具有灵活数据模型的数据存储,这支持OpenTSDB设计一种高效的、相对可定制的模式来存储数据。本例中,模式可以针对时间序列测量结果和它们的附属标签而定制。HBase提供强一致性,所以OpenTSDB生成的报表可以作为实时报表使用。HBase提供的采集数据视图一直保持最新状态。由于OpenTSDB需要支持巨大的数据量,HBase的水平扩展能力是非常关键的决定因素。

当然也可以考虑使用其他数据库。你可能使用MySQL支持OpenTSDB这样的系统,但是如果每天采集数百万数据点,一个月以后那种部署会怎么样呢?六个月以后呢?你的应用架构生产运行十八个月以后呢?你如何扩展最初的MySQL机器来处理整个数据中心生成的监控数据量呢?假设你已经随着生成数据的增长提高了部署的配置,你能够维护集群部署。那么你可以为运维团队提供诊断一次系统中断而需要的特殊查询服务吗?

如果使用传统关系型数据库来部署,所有这一切是有可能解决的。你会得到一张令人印象深刻的用户案例清单,它们描述了基于这些技术的大量的成功部署。这里存在的问题可以归结为成本和复杂性。扩展一个关系型系统来处理这种数据量需要采用分区策略(partition)。 这种方式通常把分区的工作放进应用代码里。应用系统无法从这种分区数据库中查询数据。相反,应用系统必须根据所有主机和所有数据范围的当前信息来辨别哪一个数据库持有查询的数据。另外,数据分区情况下,你失去了关系型系统的一个主要优点:强大的查询语言。分区了的数据散布在彼此不知道的多个机器上,这意味着查询功能被弱化成按值查找。任何复杂一点儿的查询又要回到客户端代码里解决。

HBase对客户端应用隐藏了分区的细节。由集群分配和管理分区,所以应用代码很幸福地什么都不需要知道。这意味着在代码里你需要管理的复杂性大大降低。虽然HBase不支持像SQL那样丰富的查询语言,但你可以通过设计HBase模式从而把在线查询的大部分复杂性留在集群上。HBase协处理器(coprocessor)也支持把任意在线查询代码留在托管数据的节点上运行。此外,你拥有强大的MapReduce来处理离线查询,这赋予你更多更丰富的工具来构造报表。

 

 

附:OpenTSDB监控系统的研究和介绍

http://www.searchtb.com/2012/07/opentsdb-monitoring-system.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值