不管你使用哪种OLAP引擎,都可以这样搞定查询优化

王愉翔 王雨舟 2019-02-14 09:55:41
编者有言:友情提示,本文提到的缓存思想不仅仅可以用在Druid上,同样可以用在ClickHouse,Impala等其他的OLAP引擎的查询优化上。接下来,我们就一起来看看知乎数据分析平台在查询优化方面的成果~

 

知乎作为中文知识内容平台,业务增长和产品迭代速度很快,如何满足业务快速扩张中的灵活分析需求,是知乎数据平台组要面临的一大挑战。

 

知乎数据平台团队基于开源的Druid打造的业务自助式的数据分析平台,经过研发迭代,目前支撑了全业务的数据分析需求,是业务数据分析的重要工具。

 

目前,平台主要的能力如下:

 

  • 统一的数据源管理,支持摄入离线数仓的Hive表和实时数仓的Kafka流。

  • 自助式报表配置,支持多维分析报表、留存分析报表。

  • 灵活的多维度多指标的组合分析,秒级响应速度,支持嵌套式「与」和「或」条件筛选。

  • 自助式仪表盘配置。

  • 开发平台接口,为其他系统提供数据服务。

  • 统一的数据权限管理。

 

目前,业务使用平台的数据如下:

 

  • 自助式配置仪表盘数:495个,仪表盘内报表共计:2399张。

  • 日请求量3w+。

  • 为A/B Testing、渠道管理、APM、数据邮件等系统提供数据API。

 

一、数据分析平台架构

 

知乎实时多维分析平台架构

 

二、技术选型-Druid

 

Druid是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid支持低延时的数据摄取,灵活的数据探索分析,高性能的数据聚合,简便的水平扩展。适用于数据量大,可扩展能力要求高的分析型查询系统。

 

Druid整体架构

 

三、Druid数据结构和架构简介

 

1、Druid数据结构
 

 

  • Data Source:Druid的基本数据结构,在逻辑上可以理解为关系型数据库中的表。它包含时间、维度和指标三列。

  • Segment:Druid用来存储索引的数据格式,不同的索引按照时间跨度来分区,分区可通过segmentGranularity(划分索引的时间粒度)进行配置。

 

2、查询服务的相关组件
 

 

内部组件

 

  • Historical:用于加载和提供Segment文件供数据查询。

  • Broker:提供数据查询服务,通过路由查询请求到对应的Historical节点并获得数据,合并数据后返回给调用方。

  • Router:当Druid集群到达TB级别的规模时才需要启用的节点,主要负责将查询请求路由到不同的Broker节点上。

 

外部组件

 

  • Deep Storage:用于存储Segment文件供Historical节点下载。Deep Storage不属于Druid内部组件,用户可根据系统规模来自定义配置。单节点可用本地磁盘,分布式可用HDFS。

  • Metastore Storage:用于存储Druid的各种元数据信息,属于Druid的外部依赖组件,生产环境中可用MySQL。

 

四、平台的演进

 

1、Druid查询量大
 

 

在Druid成为主力查询引擎之后,我们发现大查询量的场景下直接查Druid会有一些弊端,其中最大的痛点就是查询响应慢。

 

2、缓存查询结果
 

 

为了提高整体查询速度,我们引入了Redis作为缓存。

 

使用Redis来缓存查询结果

 

最简单的缓存设计,是将Druid的查询体(Request<body>)作为key,Druid的返回体(Response<body>)作为value。

 

上述的缓存机制的缺点是显而易见的,只能应对查询条件完全一致的重复查询。在实际应用中,查询条件往往是多变的,尤其是查询时间的跨度。

 

举个例子,在相同指标维度组合下用户发起两次查询,第一次查询10月1日到10月7日的数据,Druid查出结果并缓存到Redis。用户调整时间跨度到10月2日到10月8日,发起第二次查询,这条请求的不会命中Redis,又需要Druid来查询数据。

 

从例子中,我们发现两次查询的时间跨度交集是10月2日到10月7日,但是这部分的缓存结果并没有被复用。这种查询机制下,查询延时主要来自于Druid处理重复的请求,缓存结果没有被充分利用。

 

3、提高缓存的复用
 

 

为了提高缓存复用率,我们需要增加一套新的缓存机制:当查询在Redis没有直接命中时,先扫描Redis中是否已缓存查询中部分时间跨度的结果提取命中的结果,未命中再查询Druid。在扫描的过程中,被扫描的对象是单位时间跨度的缓存。

 

为了能获得到任意一个单位时间跨度内的缓存,除了在Redis中缓存单条查询的结果之外,需要进一步按时间粒度将总跨度等分,缓存所有单位时间跨度对应的结果(如下图所示):

 

Druid结果按时间粒度缓存

 

4、减少Redis IO
 

 

从上图中我们发现,对每个单位时间跨度的结果判断是否已被缓存都需要对Redis进行一次读操作,当用户查询量增大时,这种操作会对Redis集群造成比较大的负担,偶尔会出现Redis连接超时的情况。

 

为了减少对Redis的IO,我们对时间跨度单独设计了一套缓存机制。

 

基于减少读操作的想法,我们设计了通过一次读操作就可得到已经被缓存的所有时间跨度,然后再一次性地将所有缓存的结果读出。

 

  • 要实现一次性获得缓存的所有时间跨度,我们需要在每次缓存Druid查询结果后,再缓存查询请求和它覆盖的时间跨度,在RedisKey-Value规则上,我们先把查询体(Request<body>)剔除时间跨度,生成一个时间无关的查询体(Interval Excluded Request<body>)作为缓存的key;提取查询粒度(Granularity),把剔除出来的时间跨度按粒度分隔开(Set<Timestamp>)作为value。

  • 要实现一次性读出所有缓存结果,通过Redis的MGET获得Interval Excluded Request对应的各个时间戳。

  • 判断当前请求的所有单位时间跨度是否命中缓存,命中的结果会被直接返回。

 

优化后缓存机制如下图所示:

 

Redis读操作优化

 

5、Druid查询时间跨度长
 

 

在未命中缓存的情况下,设置较长的查询时间跨度(长时间跨度:2周以上),Druid经常会出现返回速度变慢,甚至阻塞其他查询请求的现象。

 

我们测试了长时间跨度的查询请求对集群整体的影响,通过对Druid集群的监控数据的分析,我们发现被长时间跨度查询命中的Broker节点会出现内存消耗过大的问题,并且随着时间跨度的增大,内存消耗跟着提高,甚至出现内存不足导致Broker节点无响应的问题。

 

6、一个Broker处理一个请求
 

 

在调研了Druid执行原理以后,我们发现一个查询请求只会被Router路由到一个Broker节点,经由Broker节点去Historical节点上查找目标数据在Deep Storage的存储位置,最后返回的数据也是经过Broker节点来合并返回结果。查询的时间跨度越长,对Broker的压力也越大,内存消耗越多。

 

单个Broker处理长时间跨度查询

 

7、多个Broker处理一个请求
 

 

单个Broker的性能无法满足长时间跨度的查询,为了让提高查询性能,我们尝试把一个查询N天数据的请求,拆分成N个查询,每个只查询一天,然后异步地将这些请求发出,结果这N个请求都被很快的返回了。和拆分前的查询耗时相比,拆分后的耗时大大减小。

 

多个Broker处理长时间跨度查询

 

从Broker节点的监控来看,当一个长时间的查询请求被多个Broker一起处理,可以减少单个Broker内存消耗,并且加快了整体的查询速度。提速程度请参考下图的测试比对,测试用例采用平台一天的所有查询,测试方式是在不命中Redis的情况下异步地「回放」这些查询到Druid。

 

benchmark

 

根据上述Broker在查询过程中的工作原理,想达到长时间跨度查询的提速,我们需要在用户发起查询之后把请求拆分。

 

拆分的机制是根据每个查询请求的查询时间粒度而定,例如上述中的一个N天跨度的天粒度请求,在查询到达Druid集群之前,我们尝试把它拆分成N个1天跨度的天级别粒度请求。

 

整个查询从拆分到命中Druid的过程如下图所示(在Druid内部的工作细节请参考上文)。

 

按时间粒度拆分用户查询请求

 

8、缓存结果过期
 

 

前两步的演进完成了从高负载下查询性能低、查询时间跨度长而速度慢、Redis复用率低,到查询性能高、Redis IO稳定。

 

分析平台的数据源来自于离线数仓的Hive和实时数仓的Kafka。重新摄入上游数据到Druid后,对应时间列的Segment文件会进行重建索引。

 

在Segment文件索引重建之后,对应的Druid查询结果也会发生改变。当这个情况发生时,用户从Redis获取到的结果并没有及时得到更新,这时就会出现数据不一致的情况。因此一套平台用户无感的缓存自动失效机制就显得尤为重要。

 

9、缓存自动失效
 

 

在Druid查询链路下,数据源的最近成功摄入的时间可以被抽象为它的最新版本号,利用这一思想,我们可以给每个数据源都打上数据版本的标签,在数据更新后,给更新的数据源替换新的标签。这样一来,每次校验Druid查询结果是否过期时就有了参照对象。

 

Druid支持MySQL存储元数据信息(Metastore Storage),元数据中的时间戳就恰好可以作为数据版本。在用户查询请求发起后,先后取出Redis缓存结果中携带的时间戳和MySQL元数据版本,然后比较两个时间。

 

  • Redis缓存的时间较新的话说明缓存未过期,可以直接返回缓存结果。

  • 反之,说明Redis缓存数据已经过期,这一对Key-Value会被直接删除,然后去查询Druid。

 

在添加了数据版本校验后,一个请求的整个生命周期如下图所示:

 

缓存自动失效机制

 

五、总结

 

本文重点介绍了知乎数据分析平台对Druid的查询优化。

 

通过自研的一整套缓存机制和查询改造,该平台目前在较长的时间内,满足了业务固化的指标需求和灵活的分析需求,减少了数据开发者的开发成本。

 

数据分析平台在上线后,提供了非常灵活的能力。在实践中,我们发现过度的自由未必是用户想要的。适当的流程约束,有助于降低用户的学习成本,以及大幅度改善业务在该平台上的查询体验。早期我们对数据的摄入并没有做过多的约束,在整个数据稳定性提升过程中,通过和数仓团队的大力配合,我们对摄入的数据源做了优化,包括限制高基数维度等治理的工作。

 

本文的缓存思想不仅仅可以用在Druid上,同样可以用在ClickHouse,Impala等其他的OLAP引擎的查询优化上。

 

参考
 

 

http://druid.io/docs/latest/design/

最新评论
访客 2019年03月19日

牛批,醍醐灌顶

访客 2019年03月18日

似乎很屌 ~

访客 2019年03月08日

两台ECS,windows server 2016 + sql server 20…

访客 2019年03月07日

介绍的devops工具链不完整呀 开源的应该以jenkins为核…

访客 2019年03月05日

0611

活动预告