微信海量数据查询如何从1000ms降到100ms？( 二 ) _数据查询

2.2 数据层架构
分析完用户习惯，再看下目前的数据层架构。多维监控底层的数据存储/查询引擎选择了 Apache-Druid 作为数据聚合、存储的引擎， Druid 是一个非常优秀的分布式 OLAP 数据存储引擎，它的特点主要在于出色的预聚合能力和高效的并发查询能力，它的大致架构如图：

文章插图

节点
解析
Mater节点
Overlord：实时数据摄入消费控制器

Coordinator：协调集群上数据分片的发布和负载均衡
实时节点
MiddleManager：实时数据写入中间管理者，创建 Peon 节点进行数据消费任务并管理其生命周期

Peon：消费实时数据，打包并发布实时数据分片
存储节点
Historical：存储数据分片
DeepStorage：分片中转存储，不对外查询
MetaDataStorage：元信息，如表结构
Zookeeper：存储实时任务和状态信息

2.3 为什么查询会慢
查询慢的核心原因，经微信团队分析如下：

协议数据分片存储的数据片段为 2-4h 的数据，每个 Peon 节点消费回来的数据会存储在一个独立分片。
假设异常检测获取 7 * 24h 的数据，协议一共有 3 个 Peon 节点负责消费，数据分片量级为 12*3*7 = 252 ，意味着将会产生 252次数据分片 I/O 。
在时间跨度较大时、MiddleManager、Historical 处理查询容易超时， Broker 内存消耗较高。
部分协议维度字段非常复杂，维度排列组合极大 (>100w) ，在处理此类协议的查询时，性能就会很差。

03

优化方案设计

根据上面的分析，团队确定了初步的优化方向：

减少单 Broker 的大跨度时间查询。
减少 Druid 的 Segments I/O 次数。
减少 Segments 的大小。

3.1 拆分子查询请求
在这个方案中，每个查询都会被拆解为更细粒度的“子查询”请求。例如连续查询 7 天的时间序列，会被自动拆解为 7 个 1天的时间序列查询，分发到多个 Broker ，此时可以利用多个 Broker 来进行并发查询，减少单个 Broker 的查询负载，提升整体性能。

文章插图

但是这个方案并没有解决 Segments I/O 过多的问题，所以需要在这里引入一层缓存。

3.2 拆分子查询请求+Redis Cache
这个方案相较于 v1 ，增加了为每个子查询请求维护了一个结果缓存，存储在 Redis 中：

文章插图

假设获取 7*24h 的数据， Peon 节点个数为 3 ，如果命中缓存，只会产生 3 次 Druid 的 Segments I/O （最近的 30min）数据，相较几百次 Segments I/O 会大幅减少。
接下来看下具体方法：

3.2.1 时间序列子查询设计
针对时间序列的子查询，子查询按照「天」来分解，整个子查询的缓存也是按照天来聚合的。以一个查询为例：

{"biz_id": 1, // 查询协议表ID：1"formula": "avg_cost_time", // 查询公式：求平均"keys": [// 查询条件：维度xxx_id=3{"field": "xxx_id", "relation": "eq", "value": "3"}],"start_time": "2020-04-15 13:23", // 查询起始时间"end_time": "2020-04-17 12:00" // 查询结束时间}

其中 biz_id、 formula,、keys 了每个查询的基本条件。但每个查询各不相同，不是这次讨论的重点。

本次优化的重点是基于查询时间范围的子查询分解，而对于时间序列子查询分解的方案则是按照「天」来分解，每个查询都会得到当天的全部数据，由业务逻辑层来进行合并。

举个例子， 04-15 13:23 ～ 04-17 08:20 的查询，会被分解为 04-15、04-16、04-17 三个子查询，每个查询都会得到当天的全部数据，在业务逻辑层找到基于用户查询时间的偏移量，处理结果并返回给用户。