快手统一分析服务建设实践

导读 本次分享内容为快手在分析领域的技术建设实践。

文章将围绕下面四点展开：

1. 分析领域介绍

2. 分析服务发展历程

3. 分析服务 3.0 建设实践

4. 总结和展望

分享嘉宾｜钱佳 快手 大数据平台技术专家

编辑整理｜鲍亭文

内容校对｜李瑶

出品社区｜DataFun

---

01 分析领域介绍

首先来介绍一下分析领域的业务背景。

比如一个分析需求是统计 2020 年到 2021 年某省各市的 GDP 以及对应的占比。标准化的处理流程分为三个阶段，首先是进行数据的加工和生产，把原始数据建设成标准的数据仓库；第二步是通过分析平台，把需要的两个表，一个是 GDP 的明细事实表，还有一个是城市的维表，接入到分析平台进行表和表之间的关系建模，生成所需的数据集；第三步就是基于这个数据集进行指标计算，通过分析工具得到我们想要的具体的 GDP 及对应的占比。

快手分析领域整体建设如上图所示。建设的愿景是致力于提供丰富的分析产品和服务，助力业务提升数据获取与分析的效率。

整体结构分为两层，下层是分析 PASS，这是整个分析服务的基建；上层是分析SAAS，包括各种数据应用，比如通用的 BI 和实验分析、专题分析、定制化的 BI 产品以及基于低代码的数据应用工厂。同时业务也可以通过页面嵌入，以及 SDK 来满足他们的接入需求。下面将重点介绍分析服务。

02分析服务发展历程

分析服务化的发展历程主要分为四个阶段，分别是 2019 年的工具化阶段，2020-2021 年的分析服务 1.0 平台化搭建，2021-2022 年分析服务 2.0 接入 Gaia 标准指标数据集，以及当前的分析服务 3.0 阶段，主要是统一非标准和标准分析服务。下面简要介绍一下各个阶段的建设背景，以及我们对应的方案。

1. 平台化阶段（分析服务 1.0 阶段）

首先是平台化阶段，也就是分析服务 1.0 阶段。

建设之前面临两个问题，第一个是用户分析效率低，分析入口多，分析门槛高，需要用户掌握 SQL，而一些业务同学不具备 SQL 能力。第二个问题是研发效率低，我们有八套分析工具，同时运维和迭代这八套工具成本比较高，并且也会存在一些研发质量问题。

针对上述问题，我们整体的解决思路是两个统一：首先是产品统一，即提供一站式分析平台，通过提供 SQL 取数、多维分析可视化工具，来降低用户的分析门槛；第二是服务统一。之前的分析工具，对接的是物理的数据，基于物理数据查询。要做到服务产品上的统一，就需要将物理数据抽象成用户或者业务可以理解的指标和维度的集合，即数据集。

解决方案如上图右侧所示，整体分为四层。引擎层主要是针对各种数据源的引擎适配。元数据层主要是维护数据集的元信息。需要说明的是，分析 1.0 主要面向非标准数据集，这种数据集主要都是用户自己定义的，使用范围也只局限于用户。上层是非标准模型构建以及服务层，分别对元数据和查询服务进行了抽象和统一。

2. 标准化阶段（分析服务 2.0 阶段）

分析服务 2.0 标准化建设，面临的主要问题是随着用户自定义非标数据的广泛使用，对于一些关键指标，由于没有统一管理，导致数据质量差，加工消费效率低。解决思路为接入指标中台标准数据集。针对关键指标，做到统一定义、统一加工和统一消费。

整体架构如图所示，也是分为四层。左边是一个非标准的分析服务。右边是 Gaia 指标中台的标准数据集服务。UGC 这种非标准模式是用户自己定义自己使用的。标准的部分则由专业同学统一定义，供其他用户使用。同时，伴随着分析需求的增多，应用层除了支持通用BI，也出现了定制化 BI 以及各种分析产品的需求。这两套服务的服务分层也比较类似，为后续 3.0 的统一埋下了伏笔。

3. 分析服务 3.0 阶段

3.0 阶段面临的问题就是统一化的问题。分析服务有两套，一套是标准的，另外一套是非标准的，两套服务能力没有对齐，比如高级分析能力的支持，进而会导致整个研发效率比较低。对外，用户或者业务需要对接两套 SDK；对内，查询性能无法对齐，新数据源接入需要多处适配，并且对联邦查询的支持较弱。

因此我们对一些关键的服务分层进一步进行抽象。抽象出两个引擎，一个是分析引擎，另一个是查询引擎。接下来将详细介绍 3.0 方案的建设实践。

03分析服务 3.0 建设实践

1. 分析服务 3.0 整体方案

3.0 的目标是打造一个高可用高性能的数据分析服务，助力业务提升分析效率。3.0 主要分为三层，最底层是数据层，中间是分析服务层，上层是应用层。其中分析服务层包括一个指标中台和两个引擎，即统一分析引擎和统一查询引擎。

3.0 的特性包括：

• 标准指标中台+BI，形成快手特色 BI。
• 统一分析+低代码，构造了数据应用工厂，可以短而快地构建数据应用产品。
• 两套引擎分别提供了开放能力。统一分析引擎提供了统一分析语言 OAX，即快手的分析表达式；统一查询引擎，抽象出了统一查询语言 FQL，即联邦查询语言。

下面重点介绍这两个引擎。

2. 统一分析引擎

（1）架构

统一分析引擎，实现了两套服务的统一。它包括三层，分别为数据准备、数据加速和数据服务。数据服务层，统一了非标和标准两套元数据和查询服务，对外提供统一的分析接入语言 OAX。数据加速层，为了提升数据分析和查询的性能，统一进行了加速。主要包含三个方面，一个是智能缓存，一个是物化，还有整个查询的链路优化。数据准备层，对物理数据进行了抽象，数据接入抽象为逻辑表。物理数据抽象成业务可以理解的指标。

（2）数据准备

在统一服务的过程中，对物理数据进行了三层抽象，抽象成业务视角关心的指标维度组合，并通过这个语义层构成了数据集，通过服务化提供给上层应用。这样做的好处主要有三点：

• 首先是数据解耦，业务无需关心底层数据，降低物理数据和上层应用的耦合。
• 第二是效率提升，包括消费效率的提升，一处定义的数据集可以在多处使用；分析效率的提升，对于一些符合的指标计算，以及高级分析，无需对物理数据再进行重复加工；还有生产效率的提升，由一处定义数据集，避免重复加工。
• 第三是质量提升，统一指标的定义加工和消费，从源头保证指标数据准确。

（3）数据加速

数据加速方案包含三部分，即智能缓存、模型物化和查询优化，下面逐一介绍。

• 智能缓存
• 智能缓存是通过智能预热来实现的。一般查询缓存是在查询过后，缓存这个结果，便于提升下次同一查询的速度。但是这存在一个问题，就是无法解决首次查询慢的问题。之前的版本中通过人工配置和周期性的预热来触发查询，以解决首次查询慢的问题。但是覆盖场景较少，主要针对大屏或者可视化的大屏看板，其他场景不支持。另外，这种对于天级别的数据，分钟级别的预热可能会造成一些不必要的资源浪费。数据准确性也难以保证，可能出现数据更新不及时，会预热缓存一些不准确的结果。并且预热没有处理限流的管控能力。
• 智能预热通过三个执行器，即触发器、计算器和执行器，来解决上述问题。其中，触发器支持触发式预热。比如通过消费元数据，变更事件能及时预热，避免天级数据、分钟级数据的频繁更新问题。第二是覆盖了更多场景，根据比较 Top 的查询来支持更多的场景。第三是执行性方面，增加了相关的执行限流和管控，以及降级等操作。一个是持续分片处理，还有一个是指标维度。分片处理过后，会把相应的结果缓存起来。缓存数据主要包括三个粒度，一个是整体查询缓存，一个是时序缓存，还有一个指标维度的分片缓存。
• 模型物化
• 第二块是通过模型物化来进行数据加速。主要解决大表或多表交换场景下查询慢或查询失败的问题。模型物化分为三个阶段，一个是分析阶段，主要是找出可以加速的查询模型。第二是加速阶段，根据查询模型，得到要生产加速的元数据提供给自动化生产底座，生产完得到一些小表，并反注射到模型里进行模型更新。第三是应用阶段，主要是参与模型构建和筛选，以便小表可以在下次查询中被命中，进而解决查询慢以及查询失败的问题。
• 查询优化
• 第三，通过查询优化实现数据加速。分析引擎侧主要是面对查询。如上图所示，输入OAX 分析源，通过解析得到一个 AST 抽象语法树。同时抽象语法树内部会进行两阶段处理，一是分析编排，针对高级分析能力，比如 LOD 粒度计算以及同环比，进行编排处理。二是模型构建，之前处理的都是一层数据集，需要进行模型的二次计算得到逻辑层，即 AST。接下来将 AST 转换成逻辑计划。这个逻辑计划根据物理编排得到物理计划，最终输出 FQL。整个语言的解析是基于 Calcite 来实现的。
• 下面详细介绍三个阶段的优化。首先是分析编排的优化。这个优化主要解决的是比如前面提到的高级分析能力，LOD 粒度计算等问题。我们之前的实现会拆成多个物理子查询下载到引擎，查询完会对这些子查询的结果在内存里面进行二次加工计算。在数据量较大的情况下，会面临两个问题，首先数据计算不准确，由于物理查询限制了返回结果，因此无法做到全局排序；其次是大数据量导致整个处理性能会比较慢。因此我们针对分析编排进行了下推优化。从之前下推到多个物理子查询，进行视图抽象。经过后续模型构建处理，下推到引擎得到一个大的产品，避免了多次物理子查询。
• 第二块是构建优化模型。模型构建主要分为两个步骤，一个是模型筛选，一个是模型展开。针对模型筛选我们做了一系列优化，如果模型涉及到多张表，会选择一些就续时间比较早的。有些表可能是热引擎，有些表可能是冷引擎，我们会优先选择热引擎的表。同样，针对不同的粒度，有一些维度粒度比较粗，有些粒度比较细，我们会优先选择粒度比较粗的小表。针对模型展开构建优化，一方面是事实维度，组合条件整体下推。另一方面是针对事实维度表通过关联键进行相应的一些过滤条件下推，还有子查询消除。
• 第三块是基于 Calcite 实现优化。Calcite 自身支持的优化规则也比较多，有几十种。常见的比如位次下推，会把过滤条件下推到数据源，减少读取函数。还有列剪枝，过滤掉不需要的列。除了基于自身的一些规则之外，我们还扩展了一些优化规则。比如 groupby bitmap 来替换精确系统的查询实现。另外，还通过 local query 这种模式来进行优化。

（4）数据服务

接下来，是数据服务方面，重点介绍我们的数据服务分析语言 OAX。OAX 全称为快手开放分析表达式，致力于以数据集为载体，提供面向分析场景的查询语言。OAX 的语法主要有两种表现形式，一种是基于 PB 的定义，另外一种是基于类SQL，提供三类计算能力，包括基础计算，如四值运算、聚合计算等；粒度计算，主要是 LOD，如明确粒度的 INCLUDE、指定粒度的 FIXED 以及高维的 EXCLUDE；还有一种是表计算，比如累积计算、日均计算。四大数据类型，包括数值、字符串、日期、布尔等类型。五个分析要素，主要是指标、维度、数据集、过滤条件和时间范围。

3. 统一查询引擎

接下来介绍查询引擎。查询引擎面临的挑战主要有两个，一个是多个业务的烟囱式建设；另一个是联邦查询能力缺失或者不足，在 BI 领域常规处理会把多数据源引擎，抽取到单一数据引擎。抽取处理同时会带来以下问题：数据冗余存储成本高；抽取加工耗时长，时效性比较低，另外抽取过后的数据形成孤岛，无法被业务使用。

对此我们的整体解决方案就是对服务进行分层梳理，并进行服务抽象和统一。如上图所示，最底层是数据层，中间是查询引擎，查询引擎又分为三层，分别是适配层、查询层和接入层。适配层接入各种数据源引擎。查询层，支持联邦查询。接入层统一了查询语言 FQL，即 Federation Query Language 联邦查询语言。上层应用除了面向统一分析以外，还提供了一些在线的 API 服务。

适配层，由于要对接多个数据源，每个数据源协议可能不一致，接入方式也会不一样。为了降低接入成本，并保证对后续数据源扩展的支持，我们对数据源接入进行了抽象。抽象为统一机构数据源接入。具体实现借鉴了 Presto 的插件化思想。每个数据源只需要实现自身的一个 connector。以 ClickHouse 的接入为例，只需要实现一个 ClickHouse 的 connector，然后通过插件化的方式，注入到查询引擎中。每个数据源需要实现两个接口，一个是 MetaData Provider，主要提供数据源的相关接口；另一个是 QueryData Provider，提供查询数据的相关接口。

查询层实现了统一联邦查询。查询流程如上图所示，输入一个 FQL，经过生成执行计划，紧接着执行这个计划。执行计划包括两部分，一个是直接进行查询。另一个是联邦查询。以 MySQL 和 ClickHouse 为例，它们对 substrait 这种方式还不够支持。所以需要直连引擎，把已经返回的数据封装成 Arrow，即一种开源的内存格式。分别针对MySQL 和 ClickHouse 查询出结果，然后转成 Arrow 交给 Dataframe。Dataframe 是我们基于 DataFusion 开源的一个产品。Dataframe 的输入主要是 Arrow，输出也是 Arrow。这个能力主要是基于 Dataframe 相关的查询能力。

接入层统一了查询引擎 FQL。FQL 是基于开源的 substrait 进行了扩展的一个查询语言。扩展点包含两方面，首先定义了一个分析领域的自定义函数，包括时间处理函数、方差协方差等函数。另外一方面，扩展了一些计算节点，支持 NativeQuery，利用底层的引擎进行查询。

数据抽象 DataFrame，一方面基于 Arrow 进行数据抽象。另一方面集成了datafactory 这个分布式产品的能力。这里简要介绍一下 Arrow 相关的知识。Arrow 也是一个开源的列式内存格式。它可以将表格内每一列单独存储提高查询效率。另外，利用现代化计算，充分利用 CPU 的并行运算能力，提升运算速度。第三块是零拷贝，无需复制就可以实现计算机的数据共享，减少内存占用。第四方面，它是跨语言运行。

以上就是统一查询引擎的相关建设。

04总结和展望

分析服务 3.0 在稳定性方面，实现了四个 9，并且没有 D0 和 D1 故障。性能方面，统一查询引擎的性能提升了 20% 以上，查询整体耗时 P90 在 15 秒左右。生态方面，目前已接入 50+ 应用，每天的查询次数在 500 万以上。

最后来分享一下对未来的规划。

当前已经历平台标准化，接下来将向智能化方向发展。智能化主要包括三个方面：

一个是智能分析。之前主要是解决发生了什么以及为什么发生这种定位分析或者诊断分析，接下来会增强分析功能，支持预测分析以及角色分析，解决未来会发生什么，以及该做什么的问题。另外还会考虑通过接入大模型来完善和补充智能分析。

第二方面是智能诊断，主要是针对分析和查询进行诊断，包括归因、查询性能以及通过诊断给出一些相应的优化建议。

第三方面是智能加速。根据诊断结果分场景进行智能加速。比如对于频繁查询的冷引擎诉求，可以进行物化加速。

以上就是本次分享的内容，谢谢大家。