CN103353873A - 基于时间度量数据实时查询服务的优化实现方法及系统 - Google Patents

Abstract

本发明提供了一种基于时间度量数据实时查询服务的优化实现方法及系统，通过基于TSD的时间度量数据基于查询的分布式设计，以及基于此设计之上的分片和降采样等相关优化，有效地将时间度量元数据的一致性降级成最终一致性，可以支持度量数据的任意水平扩展，同时查询服务能够承受高并发、高吞吐下的实时查询压力，实现时间度量查询服务的高可用性和高可扩展性。

Description

基于时间度量数据实时查询服务的优化实现方法及系统

技术领域

本发明涉及基于时间的度量数据查询服务的优化设计，特别适用于大中型网站的实时运营监控、故障预警、快速排障、容量规划、以及性能调优等诸多领域。涉及一种基于时间度量数据实时查询服务的优化实现方法及系统。

背景技术

随着一些大中型互联网企业内部的应用增多，对于实时监控整个网站的服务质量提出了越来越高的要求。为了做到实时掌握整个网站的运行情况，以不断优化系统性能，就需要收集各个应用的不同层面的实时度量数据，并对其进行有效地分析和利用。

为了随时支持高效地排障、调优，就需要保存大量的历史度量数据。随着这些度量数据不断累积，使得系统存储的压力会随之也不断加大。与此同时，对这些度量数据大量的并发查询需求，进一步提高了实现度量数据查询服务的难度。

一般的基于传统数据库的解决方案，既无法支撑基于时间的海量度量数据的存储，也无法支持高并发的查询。这基本需要涉及专门的TSD（time seriesdatabase，参见http://en.wikipedia.org/wiki/Time_series_database）实现。然而基于大数据的分布式TSD实现，同样也受到Brewer的CAP分布式理论(参见http://www.cs.berkeley.edu/～brewer/cs262b-2004/PODC-keynote.pdf)的制约。著名的TSD开源实现，如opentsdb(参见http://opentsdb.net/)不支持大数据、高吞吐的度量数据查询。

发明内容

本发明的目的在于提供一种基于时间度量数据实时查询服务的优化实现方法及系统，能够支持度量数据的任意水平扩展，同时查询服务能够承受高并发、高吞吐下的实时查询压力。

为解决上述问题，本发明提供一种基于时间度量数据实时查询服务的优化实现方法，包括对查询数据库作如下操作：

存储不同的度量，每个度量包括多个度量数据点，每个度量数据点包括度量值和标签集合，所述标签集合中的每个标签由一个key/value对组成，不同的度量中的度量数据点有不同的key的集合，但同一度量中的度量数据点的key的集合是相同的，将属于同一度量，且将含有相同key/value对的组合的数据点归为一个基础时间度量序列并记录在元数据表中。

进一步的，在上述方法中，还包括对查询数据库如下操作：

利用不同的命名空间对不同的度量进行分片，即将同一类的度量归为同一个命名空间，一个度量只能属于一个命名空间，每个命名空间包含多个度量，将同一个命名空间的所有度量保存在同一张Hbase表中，同一个命名空间中的所有度量数据的生命周期相同。

进一步的，在上述方法中，还包括对查询数据库作如下操作：

当发现某类查询的查询时间跨度长、查询开销超过阈值，且查询的频率达到一预设定频率，则定期启动的map/reduce批处理任务对该类查询的相关度量进行周期性的计算获取降采样数据，并预先将降采样数据插入到HBase表中。

进一步的，在上述方法中，还包括对查询服务器作如下操作：

采用多台查询服务器同时对外提供度量的查询服务，每台查询服务器定期以一定时间间隔同步元数据表，并将其缓存在各自内存中，当任何一台查询服务器的度量元数据发生变化时，首先会和其缓存中的元数据表进行比对和更新，若如果比对成功，则更新成功；否则，更新也就失败，则该查询服务器进行冲突解决，并决定是否需要再次提交更新；

每台查询服务器对度量元数据的更新提交成功后，就更新其内存缓存。

进一步的，在上述方法中，还包括对查询服务器作如下操作：

采用基于时间分段的缓存策略，通过后台的批处理线程定期将零散的数据缓存段进行合并。

根据本发明的另一面，提供一种基于时间度量数据实时查询服务的优化实现方法系统，包括查询数据库，用于存储不同的度量，每个度量包括多个度量数据点，每个度量数据点包括度量值和标签集合，所述标签集合中的每个标签由一个key/value对组成，不同的度量中的度量数据点有不同的key的集合，但同一度量中的度量数据点的key的集合是相同的，将属于同一度量，且将含有相同key/value对的组合的数据点归为一个基础时间度量序列并记录在元数据表中。

进一步的，在上述系统中，所述查询数据库，利用不同的命名空间对不同的度量进行分片，即将同一类的度量归为同一个命名空间，一个度量只能属于一个命名空间，每个命名空间包含多个度量，将同一个命名空间的所有度量保存在同一张Hbase表中，同一个命名空间中的所有度量数据的生命周期相同。

进一步的，在上述系统中，所述查询数据库，还用于当发现某类查询的查询时间跨度长、查询开销超过阈值，且查询的频率达到一预设定频率，则定期启动的map/reduce批处理任务对该类查询的相关度量进行周期性的计算获取降采样数据，并预先将降采样数据插入到HBase表中。

进一步的，在上述系统中，还包括多台查询服务器，用于同时对外提供度量的查询服务，其中，

每台查询服务器定期以一定时间间隔同步元数据表，并将其缓存在各自内存中，当任何一台查询服务器的度量元数据发生变化时，首先会和其缓存中的元数据表进行比对和更新，若如果比对成功，则更新成功；否则，更新也就失败，则该查询服务器进行冲突解决，并决定是否需要再次提交更新；

每台查询服务器对度量元数据的更新提交成功后，就更新其内存缓存。

进一步的，在上述系统中，所述查询服务器采用基于时间分段的缓存策略，通过后台的批处理线程定期将零散的数据缓存段进行合并。

与现有技术相比，本发明通过基于TSD的时间度量数据基于查询的分布式设计，以及基于此设计之上的分片（sharding）和降采样等相关优化，有效地将时间度量元数据的一致性降级成最终一致性，可以支持度量数据的任意水平扩展，同时查询服务能够承受高并发、高吞吐下的实时查询压力，实现时间度量查询服务的高可用性和高可扩展性。

附图说明

图1是本发明一实施例的基于命名空间的度量数据切分。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

实施例一

本发明提供一种基于时间度量数据实时查询服务的优化实现方法，包括对查询数据库作如下操作：

存储不同的度量，每个度量包括多个度量数据点，每个度量数据点包括度量值和标签集合，所述标签集合中的每个标签由一个key/value对组成，不同的度量中的度量数据点有不同的key的集合，但同一度量中的度量数据点的key的集合是相同的，将属于同一度量，且将含有相同key/value对的组合的数据点归为一个基础时间度量序列并记录在元数据表中。具体的，基于时间度量数据定义如下，每种不同的度量i都有自己的名称，即metric(i)。度量数据点metric_data_point(i,t)，它属于度量i，且该度量数据点发生在时间t上。每个数据度量点，都会有以下属性：

（1）度量值metric_data_value(i,t)，可以是整型或者浮点型数值数据；

（2）标签集合tags(i,t)，是一组标签的集合，而标签tag(i,t,k)代表了这个集合中第k个标签。每个标签都是有一个key/value对组成。标签集合可以为空，或者集合不为空，但某个度量数据点的某个tag_value是空。

例如，“CPU利用率”可以是这个系统的一个度量的名称。假定一台服务器server1在某个时刻t1吐出了它的CPU利用率的度量数据点metric_data_point(“CPU利用率”,t1)，该度量数据点包含度量值，即t1时刻的该服务器的CPU利用率，假定是30%，即0.3。但是光有这些数据还是不够的，还需要配上属于该度量数据点的所有标签信息：

该服务器的IP信息，譬如tag_key=“ip”，tag_value=“192.168.100.81”；

运行在该服务器上的应用编号，譬如tag_key=“appid”，tag_value=“900401”；

该服务器是否是虚拟机信息，譬如tag_key=“is_vm”,tag_value=“1”。

不同的度量中的度量数据点可能会有不同的标签tag_key集合，但同一度量中的度量数据点的标签tag_key集合是相同的。进一步可定义基础时间度量序列，即属于某一度量metric(i)，且符合如下规则的所有度量数据点的集合：所有的数据点都含有相同的tag_key，并且相应的tag_value也相同。因此一个度量metric(i)可能会包含多个基础时间序列。每个基础时间度量序列都有自己的唯一表示，并记录在元数据表中。每个度量都有其自己的度量名称，度量名称可以由用户在创建度量时指定。为每个度量都分配了唯一的metric_id。一个度量可以包含多个基础时间度量序列。一个基础时间度量序列有唯一的tag_name/tag_value组合。一个查询从本质上来说，其实是针对一个度量在指定时间范围内对满足其基础时间度量序列数据的查询。为每一个基础时间度量序列都分配了唯一的basic_metric_series_id。此外，把基础时间度量序列名称定义为：“metric_id”+“tag1”+“value1”+“tag2”+“value2”…，其中不同的tag/value对是经过一定的规则排过序的。

优选的，对查询数据库还可进行如下操作：

利用不同的命名空间对不同的度量进行分片（sharding），即将同一类的度量归为同一个命名空间（namespace），一个度量只能属于一个命名空间，每个命名空间包含多个度量，将同一个命名空间的所有度量保存在同一张Hbase表中，同一个命名空间中的所有度量数据的生命周期相同。具体的，一个度量只能属于某一个namespace，而一个namespace可以包含多个度量。譬如namespace“hotel_business”，会包含所有和酒店业务相关的度量。在一个namespace下的所有度量数据在系统中的生命周期相同。一个namespace的所有度量数据会保存在一张Hbase表中。为每个namespace都分配了唯一的namespace_id。在度量数据的分片优化方面，HBase是当前流行的基于大数据的数据库实现。因此存储海量的基于时间的度量数据很合适。然而，将所有的度量数据放到一个HBase表实例中，却并非是好主意。一方面，单一的HBase表实例受到region split，compression等因素影响，会对查询性能产生集中式的影响。其次，不同namespace下的度量数据，对于TTL的要求不同，不适合放在相同的度量数表中。再者从架构设计角度而言，支持分片式的设计，将更有利于今后的扩展。因此，如图1所示，本实施例中利用不同的namespace对不同的度量数据进行分片（sharding）处理。相同类型的度量数据会公用一个HBase表实例。不同的表实例，可以共享同一个HBase数据库中，也可以分散到不同的HBase数据库去。这样，当一个HBase数据库处于维护状态或发生故障时，分散在其他的HBase数据库的度量数据将不会受到影响。

优选的，对查询数据库还可进行如下操作：

当发现某类查询的查询时间跨度长、查询开销超过阈值，且查询的频率达到一预设定频率，则定期启动的map/reduce批处理任务对该类查询的相关度量进行周期性的计算获取降采样数据，并预先将降采样数据插入到HBase表中。具体的，查询服务器会为每个查询建立自己的时间度量数据点，并将这些度量数据记录到HBase中。基于这些度量数据，周期性启动一个分析任务，以定期分析来自客户的查询、相关的查询热点，对所有查询进行基于查询开销的分类。当发现某类查询的查询时间跨度长，查询开销超过阈值，并且查询的频率达到我们预设定频率，则系统自动判定这些查询相关的度量数据需要做预降采样，即作基于Map/reduce的度量数据预先降采样，定期自动启动的map/reduce批处理任务会对这些度量进行周期性的计算，预先将降采样数据插入到HBase中。那么新的查询就会利用降采样的数据结果，从而大大降低查询的开销。

优选的，本实施例的方法还包括对查询服务器作如下操作：

采用多台查询服务器同时对外提供度量的查询服务，每台查询服务器定期以一定时间间隔同步元数据表，并将其缓存在各自内存中，当任何一台查询服务器的度量元数据发生变化时，首先会和其缓存中的元数据表进行比对和更新，若如果比对成功，则更新成功；否则，更新也就失败，则该查询服务器进行冲突解决，并决定是否需要再次提交更新；

每台查询服务器对度量元数据的更新提交成功后，就更新其内存缓存。具体的，在基于最终一致性的分布式查询方面，为了实现查询的高可扩展性和高可用性，单台的查询服务器是不能满足要求的，因此必须实现成分布式查询架构。此外，为了满足大量实时并发查询需求，系统的高可用性也是我们设计的目标。考虑到性能，实现元数据的原子一致性的代价太大。就实际而言，也没有原子一致性需求。根据著名的CAP理论，可以通过把一致性进行降级，来获得更好的可用性和分区容忍型。本实施例中采用服务集群方式，用多台服务器同时对外提供度量数据的查询服务。服务器会定期以一定时间间隔(T)同步元数据表信息，并将其缓存在内存。当任何一台服务器发生度量元数据发生变化时，首先会和元数据表进行比对和更新。这是个原子操作，如果比对成功则更新成功；反之的话更新也就失败。如果更新失败，那么该服务器需要进行冲突解决，并决定是否需要再次提交更新。服务器对元数据的更新提交成功后，就会更新其内存缓存。虽然其他服务器不能立即得知该元数据变化，但在下次和元数据表进行同步时，会所有新的变化都同步到各自的内存缓存。这就是度量元数据最终一致性的实现。

优选的，还包括对查询服务器作如下操作：

采用基于时间分段的缓存策略，通过后台的批处理线程定期将零散的数据缓存段进行合并。具体的，在数据缓存优化方面，由于查询服务器需要支持大量的并发查询，如果没有缓存设计，HBase将不得不承受很大的压力。这是我们不愿见到的。但是一般的基于web的缓存方式，对于我们而言却没有多大的帮助，因为每次查询都带着自己的查询时间范围，因此带着相同查询时间范围相同的查询会非常的少，因此直接缓存查询结果没有太大意义。因此本实施例采用了基于时间分段的缓存策略，在数据缓存文件中的相邻的缓存段，它们的时间范围可能是不相邻的。如果在数据缓存文件中存在大量零散的数据缓存段，那会引发大量的磁盘随机读，会影响效率。因此后台有个批处理线程，会定期将零散的数据缓存段进行合并，以提升IO读效率。

综上，为了支持大数据、高吞吐的度量数据查询，availability和partitiontolerant都是必选项，关键是如何从设计上对度量元数据consistency进行适当降级，以得到更高的分布式系统并发性能。其次，不同类型的度量数据，其生命周期可能是不同的。为了有效地支持海量的不同类型的度量数据，最好的方法就是引入分片（sharding）技术。再次，通过度量查询服务自身，可以轻松地找到有热点的昂贵的度量查询。基于上述几点，本实施例进行了基于TSD的时间度量数据的分布式设计，并在此基础上采用了合理的预降采样策略，从而优化哪些昂贵的查询。另外，通过有效地将时间度量元数据的一致性降级成最终一致性，从而在设计上实现了时间度量查询服务的高可用性和高可扩展性。本实施例提供了一种基于分布式高可扩展，支持高并发、高吞吐的基于时间度量的查询服务的架构，基于此高弹性架构，可以支持度量数据的任意水平扩展，同时查询服务能够承受高并发、高吞吐下的实时查询压力。这是一般TSD所难以实现的

实施例二

本发明还提供另一种基于时间度量数据实时查询服务的优化实现系统，包括查询数据库，用于存储不同的度量，每个度量包括多个度量数据点，每个度量数据点包括度量值和标签集合，所述标签集合中的每个标签由一个key/value对组成，不同的度量中的度量数据点有不同的key的集合，但同一度量中的度量数据点的key的集合是相同的，将属于同一度量，且将含有相同key/value对的组合的数据点归为一个基础时间度量序列并记录在元数据表中。

优选的，所述查询数据库，利用不同的命名空间对不同的度量进行分片，即将同一类的度量归为同一个命名空间，一个度量只能属于一个命名空间，每个命名空间包含多个度量，将同一个命名空间的所有度量保存在同一张Hbase表中，同一个命名空间中的所有度量数据的生命周期相同。

优选的，所述查询数据库，还用于当发现某类查询的查询时间跨度长、查询开销超过阈值，且查询的频率达到一预设定频率，则定期启动的map/reduce批处理任务对该类查询的相关度量进行周期性的计算获取降采样数据，并预先将降采样数据插入到HBase表中。

优选的，本实施例的系统还包括多台查询服务器，用于同时对外提供度量的查询服务，其中，

每台查询服务器定期以一定时间间隔同步元数据表，并将其缓存在各自内存中，当任何一台查询服务器的度量元数据发生变化时，首先会和其缓存中的元数据表进行比对和更新，若如果比对成功，则更新成功；否则，更新也就失败，则该查询服务器进行冲突解决，并决定是否需要再次提交更新；

每台查询服务器对度量元数据的更新提交成功后，就更新其内存缓存。

优选的，所述查询服务器采用基于时间分段的缓存策略，通过后台的批处理线程定期将零散的数据缓存段进行合并。

实施例二的其它详细内容具体可参见实施例一，在此不再赘述。

综上所述，本发明通过基于TSD的时间度量数据基于查询的分布式设计，以及基于此设计之上的分片（sharding）和降采样等相关优化，有效地将时间度量元数据的一致性降级成最终一致性，可以支持度量数据的任意水平扩展，同时查询服务能够承受高并发、高吞吐下的实时查询压力，实现时间度量查询服务的高可用性和高可扩展性。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

显然，本领域的技术人员可以对发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包括这些改动和变型在内。

Claims (10)

1.一种基于时间度量数据实时查询服务的优化实现方法，其特征在于，包括对查询数据库作如下操作：

存储不同的度量，每个度量包括多个度量数据点，每个度量数据点包括度量值和标签集合，所述标签集合中的每个标签由一个key/value对组成，不同的度量中的度量数据点有不同的key的集合，但同一度量中的度量数据点的key的集合是相同的，将属于同一度量，且将含有相同key/value对的组合的数据点归为一个基础时间度量序列并记录在元数据表中。

2.如权利要求1所述的基于时间度量数据实时查询服务的优化实现方法，其特征在于，还包括对查询数据库如下操作：

利用不同的命名空间对不同的度量进行分片，即将同一类的度量归为同一个命名空间，一个度量只能属于一个命名空间，每个命名空间包含多个度量，将同一个命名空间的所有度量保存在同一张Hbase表中，同一个命名空间中的所有度量数据的生命周期相同。

3.如权利要求2所述的基于时间度量数据实时查询服务的优化实现方法，其特征在于，还包括对查询数据库作如下操作：

当发现某类查询的查询时间跨度长、查询开销超过阈值，且查询的频率达到一预设定频率，则定期启动的map/reduce批处理任务对该类查询的相关度量进行周期性的计算获取降采样数据，并预先将降采样数据插入到HBase表中。

4.如权利要求1所述的基于时间度量数据实时查询服务的优化实现方法，其特征在于，还包括对查询服务器作如下操作：

采用多台查询服务器同时对外提供度量的查询服务，每台查询服务器定期以一定时间间隔同步元数据表，并将其缓存在各自内存中，当任何一台查询服务器的度量元数据发生变化时，首先会和其缓存中的元数据表进行比对和更新，若如果比对成功，则更新成功；否则，更新也就失败，则该查询服务器进行冲突解决，并决定是否需要再次提交更新；

每台查询服务器对度量元数据的更新提交成功后，就更新其内存缓存。

5.如权利要求1至4任一项所述的基于时间度量数据实时查询服务的优化实现方法，其特征在于，还包括对查询服务器作如下操作：

采用基于时间分段的缓存策略，通过后台的批处理线程定期将零散的数据缓存段进行合并。

6.如权利要求1项所述的基于时间度量数据实时查询服务的优化实现系统，其特征在于，包括查询数据库，用于存储不同的度量，每个度量包括多个度量数据点，每个度量数据点包括度量值和标签集合，所述标签集合中的每个标签由一个key/value对组成，不同的度量中的度量数据点有不同的key的集合，但同一度量中的度量数据点的key的集合是相同的，将属于同一度量，且将含有相同key/value对的组合的数据点归为一个基础时间度量序列并记录在元数据表中。

7.如权利要求1所述的基于时间度量数据实时查询服务的优化实现系统，其特征在于，所述查询数据库，利用不同的命名空间对不同的度量进行分片，即将同一类的度量归为同一个命名空间，一个度量只能属于一个命名空间，每个命名空间包含多个度量，将同一个命名空间的所有度量保存在同一张Hbase表中，同一个命名空间中的所有度量数据的生命周期相同。

8.如权利要求7所述的基于时间度量数据实时查询服务的优化实现系统，其特征在于，所述查询数据库，还用于当发现某类查询的查询时间跨度长、查询开销超过阈值，且查询的频率达到一预设定频率，则定期启动的map/reduce批处理任务对该类查询的相关度量进行周期性的计算获取降采样数据，并预先将降采样数据插入到HBase表中。

9.如权利要求6所述的基于时间度量数据实时查询服务的优化实现系统，其特征在于，还包括多台查询服务器，用于同时对外提供度量的查询服务，其中，

每台查询服务器定期以一定时间间隔同步元数据表，并将其缓存在各自内存中，当任何一台查询服务器的度量元数据发生变化时，首先会和其缓存中的元数据表进行比对和更新，若如果比对成功，则更新成功；否则，更新也就失败，则该查询服务器进行冲突解决，并决定是否需要再次提交更新；

每台查询服务器对度量元数据的更新提交成功后，就更新其内存缓存。

10.如权利要求6至9任一项所述的基于时间度量数据实时查询服务的优化实现系统，其特征在于，所述查询服务器采用基于时间分段的缓存策略，通过后台的批处理线程定期将零散的数据缓存段进行合并。

Images