OpenTSDB原理系列-读取流程

1.OpenTSDB I/O Thread收到HTTP Query请求后，会根据OpenTSDB是否使用了SALT进行不同的处理。

相关配置项：

参数1：tsd.storage.salt.width

默认值：0

说明：SALT的字节长度。当设置为0时，表示不使用SAL。

参数2：tsd.storage.salt.buckets

默认值：20

说明： SALT的数量。当“tsd.storage.salt.width”为非0时，才发挥作用。该配置项的值，不能超过SALT的字节长度所能表示的最大数字。例如SALT的字节长度为1时，该配置项的不能配置成大于256。这两个配置在OpenTSDB初始化就必须确定，运行过程中不能随意修改，否则会导致历史数据读取错误。

是否使用了SALT，只会对生成的HBase Scanner数量产生影响，每个HBase Scanner的处理流程都是相同的。

当使用了SALT，就会生成相应SALT数量的HBase Scanner。

需要注意的是，Scanner的StatKey和StopKey中，只包含了{SALT+Metric ID+Timestamp}。如果需要查询的Metric中包含大量不同的TagName或者TagValue的话，这个Scanner可能需要扫描大量的数据，影响OpenTSDB查询的性能。

2.为每个Scanner设置Filter，设置Filter可以更精确的过滤HBase的行，减少无效数据行的传输和处理，以提高查询的性能。

如果HTTP Query中设置了Tag的查询条件，Scanner中就会设置KeyRegexpFilter；如果同时设置了explicitTags 为true，Scanner中还会再设置FuzzyRowFilter。

参数3：tsd.query.enable_fuzzy_filter

默认值：true

说明：当查询请求中包含explicitTags字段的时候，是否在HBase的Scan请求中使用FuzzyRowFilter

注意：

• 虽然设置了Filter，但是在HBase服务端需要扫描的数据量并不会减少，只是减少了返回的数据量。

• Scan caching默认值为128，可以通过如下配置项进行配置：

参数4：tsd.storage.hbase.scanner.maxNumRows

默认值：128

说明：每次scan时从HBase一次返回的数据行数。

3.最后调用Scanner的scan方法，scan方法采用了异步调用。

这样，一个HTTP Query的请求调用已经被处理完了。

1. 一个HTTP Query所生成的多个Scanner，可能发送到了多个RegionServer上，所以OpenTSDB可能收到多个RegionServer发送过来的scanner结果。

2. 每个RegionServer的scanner结果，都由其绑定的一个线程进行处理。这个线程既负责从socket中接收Scanner结果，也要负责处理这些scanner结果。因此，它只能逐个处理这些Scanner结果。

3. 当处理完一个scanner结果后，如果这个scanner的所有结果还没有传输完，就继续异步调用scan方法，以获得后续的scanner结果。调用完后，就继续处理下一个scanner结果。

4. 当一个scanner的所有结果都已经处理完了，而且这个scanner不是所关联HTTP Query请求的最后一个被处理的Scanner，那么就把处理后的数据暂时缓存起来。然后继续处理下一个scanner结果；如果是最后一个scanner，就把这个HTTP Query请求的所有scanner结果进行合并，生成一个HTTP Query的Response，并发送回到OpenTSDB应用。

至此，在OpenTSDB的应用端，就已经完成了一次完整的HTTP Query查询。

OpenTSDB系列文章推荐：

OpenTSDB原理系列-元数据模型

OpenTSDB原理系列-TSDB数据表设计

OpenTSDB原理系列-线程模型

本文转载自微信公众号【Nosql漫谈】。

原文链接：https://mp.weixin.qq.com/s/bOibxMEuqxAa9OGCQI-Lrg