Druid.io大查询分析思路

Druid.io 是CPU和IO双密集型的大数据组件，因为Druid架构中无论是处理实时数据摄入的peon进程还是存储历史数据的历史节点，在负责数据存储的同时还需要处理其节点上数据的查询。因为这样的架构，导致Druid的服务节点对磁盘，内存和CPU都有着比较高的要求。而Druid架构本身是无法对查询进行隔离的，所以单个节点上可能并行处理着多条查询。而处理查询的线程资源和内存资源是有限的，所以查询之间可能存在互相影响。在这样的背景下，当查询耗时比较久需要定位原因时，面对纷繁的指标，如果没有正确的思路，那么问题定位可能会浪费开发或运维人员较多的时间。为此，将自己日常工作中学习到的查询问题定位流程总结，方便日后不断优化问题分析流程。此次总结主要以历史数据查询为主。

1. 预备备

1.1 查询链路

Druid查询链路

拿出一张精简的查询流程图，我们先简单的看一下Druid查询的大概流程，不考虑太多的外部依赖。
①首先客户端发送http请求，请求Broker节点（假设集群中没有设置Router节点）；
②接着Broker就会根据zookeeper上信息，把客户端查询拆分成不同的subquery，分发给不同的查询节点；
③实时数据查询路由给middleManager上的peon进程，历史数据查询路由给相应的historical节点；
④各个查询节点处理完查询之后把查询节点返回给Broker；
⑤Broker节点把各个节点返回的结果进行合并，返回给客户端。至此，一个完整的查询链路结束。

1.2 Druid监控指标

在之前的文章中也有提过，Druid组件会将自身的指标信息通过emitter发送出来。这一部分信息我们是可以采集到的，Druid原生也支持httpEmitter。通过这个emitter我们可以将指标信息发送给本地或者其他的http服务，通过http服务我们可以将指标信息发送到kafka的topic中，这样我们就可以像摄入一般实时数据那样保存实时的Druid指标信息了。
目前我们生产上是这样采集指标信息的，流程架构如下：

image.png

社区还有一些其他的emitter，没有尝试过，感兴趣的可以去官网了解一下。
Druid的指标还是相当丰富的，这里不做一一介绍，主要说几个跟查询分析有关的指标。

Broker端

metric	Description	关联维度
query/time	查询耗时，这个耗时是相对于整个查询而言	Common: dataSource, type, interval, hasFilters, duration, context, remoteAddress, id. Aggregation Queries: numMetrics, numComplexMetrics. GroupBy: numDimensions. TopN: threshold, dimension.
query/node/bytes	各个节点返回的数据	id, status, server.
query/node/ttfb	子查询从节点上返回第一个结果的耗时	id, status, server

Historical端

metric	Description	关联维度
query/time	查询耗时,这个耗时是指某条查询在这个单个节点上的耗时	Common: dataSource, type, interval, hasFilters, duration, context, remoteAddress, id. Aggregation Queries: numMetrics, numComplexMetrics. GroupBy: numDimensions. TopN: threshold, dimension
query/segment/time	单个segment的查询耗时	id, status, segment.
query/wait/time	某条查询或者某个segment等待给执行的时间	id, segment

Jetty

metric	Description
jetty/numOpenConnections	jetty的连接数量

以上，分析大查询的主要指标就是这些了。

2. 淡定分析

一般情况，当大查询出现之后，我们能获取到的信息一般有两个:

1. queryID
2. 查询时间

那我们的分析也就从这两个已知信息入手。首先我们要知道的是，一个查询耗时很长，可能并不是它本身涉及到的数据量过大或查询语句过于复杂，也可能是因为其他的大查询占用了太多的资源，导致它的耗时增加。所以，分析这类查询问题的时候我们不能只关注于这个点的问题，更要在纵向上分析其他的的查询是否有问题。
以下为了方便描述，我就使用plyql来查询Druid的指标信息。这个是一款可以将SQL语句转换成Druid查询的工具。没有的话，也可以人工把下面的SQL语句转换成json查询。

2.1 首先确认查询在哪些节点上耗时比较长

./plyql -h druid-broker-host:8082 -q "select __time, host, value_max   from druid_metrics where metric in ('query/time') and __time>='2019-12-09T13:50:00+08:00' and __time<='2019-12-09T14:05:00+08:00' and id = ''test-query-id" '

返回结果如下

image.png

注意:返回的结果中有个8082端口，这个是broker节点的端口号，后面我们可以通过这个确认查询路由到的broker，然后从这个broker日志中捞出queryID对应的查询语句。
我们可以看到这个查询被分发到了不同的历史节点上，而且每个节点的查询耗时都比较长。这里我们可以先从一个历史节点分析，例如：historical01。我们要分析这个查询在这个节点上是否是因为其他的查询才导致的耗时较长。这里我们就要用到两个指标，一个 query/wait/time, quer/sgment/time。如果前者过大，则可能是因为节点要处理的查询过多。如果后者过大，则大概率是因为查询本身过于复杂导致，但是这种情况下，一般通过判断查询语句就能看出了，这里就不考虑这种情况了。其实，还有第三种情况就是 query/wait/time, quer/sgment/time这两个指标值都不大，但是查询的耗时很长。目前我们生产环境中，第三种情况是比较常见的。这个和第一种情况一样，一般都是因为其他查询的影响导致的。所以我们要查看，这个query所在节点对应时间点的前一段时间是否出现了大查询，即耗时比较长的查询。我们先查看 query/wait/time和 quer/sgment/time这两个指标。

./plyql -h druid-broker-host:8082 -q "select segment,metric, value_max from druid_metrics where metric in ('query/segment/time','query/wait/time') and __time>='2019-12-09T13:50:00+08:00' and __time<='2019-12-09T14:05:00+08:00' and id = 'test-query-id' and host='historical01:8083' "

image.png

从返回的结果来看，query和wait的time都不算很长，但是我们知道这个查询在这个节点上耗时很长。所以肯定有很多的时间是耗费在等待资源上了。那么我们现在要做的就是找出这个占资源的查询，分析它为什么占了资源。

2.2 确认资源使用较多的查询

还是在这个历史节点上，我们查看这个查询之前的一段时间，看看是否有耗时比较大的查询。这里需要使用子查询，因为我们要选出查询耗时较长的查询，而且需要根据时间排序。因为一般都是最早的那个耗时较多的查询导致后面的查询耗时增加。

 ./plyql -h druid-broker-host:8082 -q "select * from (select __time,id, value_max   from druid_metrics where metric in ('query/time') and __time>='2019-12-09T13:50:00+08:00' and __time<='2019-12-09T14:05:00+08:00' and host='historical01:8083' order by value_max desc limit 30) order by __time""

image.png

从结果来看每个查询的耗时都比较大，这样我们是没法确认，我们需要找的是一个分界的值。这里的查询时间还没有到达我们过滤的边界，所以我们增加返回的数据量。

 ./plyql -h druid-broker-host:8082 -q "select * from (select __time,id, value_max   from druid_metrics where metric in ('query/time') and __time>='2019-12-09T13:50:00+08:00' and __time<='2019-12-09T14:05:00+08:00' and host='historical01:8083' order by value_max desc limit 100) order by __time""

image.png

到这里我们就找到了最开始耗时比较长的查询。那么接下来就是分析一波这几个查询。可以用之前类似的 query/wait/time和 query/segment/time来分析。如果 query/segment/time比较大，那么基本上就是这个查询的问题了。接着就可以把这个查询的查询语句从日志里捞出来看了。查询语句记录在broker的日志里，怎么确定broker我们在之前的查询中已经提到过了。
但是，有一种情况也有可能发生，就是这个最开始的几个查询的 query/wait/time和 query/segment/time这两个指标也不大，但是查询耗时长。这时候就要进行第三步分析了。

3. 确认处理查询的并发量

这个我们可以从两个方面考虑，一个是这段时间的查询访问量，一个是jetty的连接数。当节点处理的查询并发比较大时，也可能会对资源造成较大的压力，导致查询耗时增加。这个可以通过zabbix查看到是节点的性能情况，这里只从Druid层面分析。

3.1 查询访问量

每个查询都会对应一个queryID，我们只需要对这段时间的queryID做个简单的count就可以算出这个节点的查询访问量了。

./plyql -h druid-broker-host:8082 -q "select count(id)   from druid_metrics where metric in ('query/time') and __time>='2019-12-09T13:50:00+08:00' and __time<='2019-12-09T14:05:00+08:00' and host='historical01:8083'"

image.png

如果需要查看dataSource访问量的话，只需要再做个group by:

./plyql -h druid-broker-host:8082 -q "select count(id)   from druid_metrics where metric in ('query/time') and __time>='2019-12-09T13:50:00+08:00' and __time<='2019-12-09T14:05:00+08:00' and host='historical01:8083' group by dataSource"

image.png

3.1 jetty连接数

./plyql -h druid-broker-host:8082 -q "select __time, value_max from druid_metrics where metric in ('jetty/numOpenConnections') and __time>='2019-12-09T13:50:00+08:00' and __time<='2019-12-09T14:05:00+08:00' and host='historical01:8083'"

image.png

这两个指标，可以跟历史数据比较，就可以知道访问量是否有波动了。

4. 小结

其实Druid查询涉及到的内容比较多，这里只讨论如何分析耗时比较长的情况。但是为什么会导致这种情况，如何去避免这种情况的产生？这又会涉及到Druid本身的数据分配和查询路由策略。这一部分若有机会，再做总结。