AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

知乎如何基于开源 Druid 打造下一代数据分析平台?

  • 2018-11-19
  • 本文字数:4155 字

    阅读完需:约 14 分钟

知乎如何基于开源Druid打造下一代数据分析平台?

AI 前线导读: 本文重点介绍了知乎数据分析平台对 Druid 的查询优化。通过自研的一整套缓存机制和查询改造,该平台目前在较长的时间内,满足了业务固化的指标需求和灵活的分析需求,减少了数据开发者的开发成本。


更多干货内容请关注微信公众号“AI 前线”(ID:ai-front)


背 景

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


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


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


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

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

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

  4. 自助式仪表盘配置

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

  6. 统一的数据权限管理


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


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

  2. 日请求量 3w+

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

数据分析平台架构


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

技术选型 - Druid

Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。


Druid 支持低延时的数据摄取,灵活的数据探索分析,高性能的数据聚合,简便的水平扩展。适用于数据量大,可扩展能力要求高的分析型查询系统。



Druid 整体架构

Druid 数据结构和架构简介

Druid 数据结构


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

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


查询服务的相关组件


内部组件


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

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

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


外部组件


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

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

平台的演进

Druid 查询量大

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

缓存查询结果

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



使用 Redis 来缓存查询结果


最简单的缓存设计,是将 Druid 的查询体(Request)作为 key,Druid 的返回体(Response)作为 value。上述的缓存机制的缺点是显而易见的,只能应对查询条件完全一致的重复查询。在实际应用中,查询条件往往是多变的,尤其是查询时间的跨度。


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


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

提高缓存的复用

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


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



Druid 结果按时间粒度缓存

减少 Redis IO

从上图中我们发现,对每个单位时间跨度的结果判断是否已被缓存都需要对 Redis 进行一次读操作,当用户查询量增大时,这种操作会对 Redis 集群造成比较大的负担,偶尔会出现 Redis 连接超时的情况。为了减少对 Redis 的 IO,我们对时间跨度单独设计了一套缓存机制。基于减少读操作的想法,我们设计了通过一次读操作就可得到已经被缓存的所有时间跨度,然后再一次性地将所有缓存的结果读出。


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

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

  3. 判断当前请求的所有单位时间跨度是否命中缓存,命中的结果会被直接返回。优化后缓存机制如下图所示:



Redis 读操作优化

Druid 查询时间跨度长

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


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

一个 Broker 处理一个请求

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



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

多个 Broker 处理一个请求

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



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


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



benchmark


根据上述 Broker 在查询过程中的工作原理,想达到长时间跨度查询的提速,我们需要在用户发起查询之后把请求拆分。拆分的机制是根据每个查询请求的查询时间粒度而定,例如上述中的一个 N 天跨度的天粒度请求,在查询到达 Druid 集群之前,我们尝试把它拆分成 N 个 1 天跨度的天级别粒度请求。整个查询从拆分到命中 Druid 的过程如下图所示(在 Druid 内部的工作细节请参考上文)。



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

缓存结果过期

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


分析平台的数据源来自于离线数仓的 Hive 和实时数仓的 Kafka。重新摄入上游数据到 Druid 后, 对应时间列的 Segment 文件会进行重建索引。在 Segment 文件索引重建之后,对应的 Druid 查询结果也会发生改变。当这个情况发生时,用户从 Redis 获取到的结果并没有及时得到更新,这时就会出现数据不一致的情况。因此一套平台用户无感的缓存自动失效机制就显得尤为重要。

缓存自动失效

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


Druid 支持 MySQL 存储元数据信息(Metastore Storage),元数据中的时间戳就恰好可以作为数据版本。在用户查询请求发起后,先后取出 Redis 缓存结果中携带的时间戳和 MySQL 元数据版本,然后比较两个时间。Redis 缓存的时间较新的话说明缓存未过期,可以直接返回缓存结果;反之,说明 Redis 缓存数据已经过期,这一对 Key-Value 会被直接删除,然后去查询 Druid。


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



缓存自动失效机制

总 结

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


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

团队介绍

知乎的大数据平台团队,属于知乎的技术中台。面对业务的多元化发展和精细化运营,数据的需求变得越来越多,大数据平台团队主要负责:


  • 搭建公司级可视化分析系统和数据服务

  • 维护全端数据的采集、集成和数据仓库,对接业务系统

  • 管理数据生命周期,提供一站式的数据开发、数据权限、元信息管理和任务调度平台

  • 提供 AB Testing 实验平台,系统化集成实验分析框架,推动业务增长


随着知乎业务规模的快速增长,以及业务复杂度的持续增加,我们团队面临的技术挑战也越来越大,欢迎对技术感兴趣、渴望技术挑战的小伙伴加入我们,一起建设知乎的数据平台。


参考引用[1] http://druid.io/docs/latest/design/

会议推荐

12 月 20-21,AICon将于北京开幕,在这里可以学习来自 Google、微软、BAT、360、京东、美团等 40+AI 落地案例,与国内外一线技术大咖面对面交流。


2018-11-19 17:546074

评论

发布
暂无评论
发现更多内容

强化学习从基础到进阶-常见问题和面试必知必答[8]:近端策略优化(proximal policy optimization,PPO)算法

汀丶人工智能

人工智能 深度学习 强化学习 6 月 优质更文活动 ppo算法

跑得更快!华为云GaussDB以出色的性能守护“ERP的心脏”

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 6 月 PK 榜

用友BIP全球司库十问之资金结算如何统一管理?

用友BIP

全球司库 资金管理

精选|Dubbo异步化实践

得物技术

如何在 NGINX 中安全地分发 SSL 私钥

NGINX开源社区

nginx ssl

当金融风控遇上人工智能,众安金融的实时特征平台实践

NebulaGraph

人工智能 风险控制 金融风控

云原生应用交付平台 Orbit 主要功能与核心能力

CODING DevOps

Orbit gitops 应用管理

Zilliz Cloud 明星级功能详解|解锁多组织与角色管理功能,让你的权限管理更简单!

Zilliz

SaaS 非结构化数据 Zilliz AIGC zillizcloud

阿里云顺利通过云原生中间件成熟度评估

阿里巴巴云原生

阿里云 云原生 中间件 成熟度

人脸识别技术的挑战和未来发展

数据堂

人脸识别技术的优缺点及实际应用

数据堂

【AI 充电】KServe + Fluid 加速大模型推理

阿里巴巴云原生

阿里云 Kubernetes 云原生

人脸识别技术的历史发展及未来趋势

数据堂

数据湖系列之三 | 打造高性能云原生数据湖,层级 namespace 对象存储加速大数据计算

Baidu AICLOUD

数据湖 对象存储 层级namespace

企业需要什么样的全面预算管理?

用友BIP

全面预算

深度分析:企业大数据分析的选型需要关注哪些能力

对不起该用户已成仙‖

AI 2.0来袭,AIGC如何重新定义招聘?

用友BIP

AI 招聘

有奖问卷 | 2023 中国软件研发效能调查问卷即将截止

CODING DevOps

软件测试/测试开发丨Python内置库学习笔记

测试人

Python 程序员 软件测试 内置库

升哲科技受邀出席第十四届夏季达沃斯论坛

SENSORO

Flutter卡片分享功能实现:将你的内容分享给世界

编程的平行世界

flutter android

故障分析 | 从慢日志问题看 MySQL 半一致性读的应用场景

爱可生开源社区

MySQL innodb 事务

11个开源项目,5位技术大咖…华为云亮相2023开放原子全球开源峰会

华为云开发者联盟

开源 后端 华为云 华为云开发者联盟 企业号 6 月 PK 榜

国产替代,本质是价值替代

用友BIP

浅显易懂传统开发与低代码开发的区别

互联网工科生

低代码 JNPF 传统开发

人脸识别技术的原理及其应用

数据堂

知乎如何基于开源Druid打造下一代数据分析平台?_大数据_王愉翔_InfoQ精选文章