过实例学习HBase：OpenTSDB

OpenTSDB概述

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

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

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

 

图 7-1 OpenTSDB 图形输出。[1] OpenTSDB 是一种数据可视化工具。基本上它以这样的图形深入展示所存储的数据。

 

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

 

1 挑战：基础架构监控

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

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

       生成如图7-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的目标和那些目标提出的技术挑战。让我们深入细节学习如何设计一个应用系统来满足这些挑战。