Kuaishou Metric Middle Platform: Design, Architecture, and Practices

导读 指标中台是快手数据平台部的核心平台之一，本文将分享快手指标中台从设计到落地的实践经验。

主要内容包括以下几大部分：

1.

背景介绍

2.

指

标管理

3.

指标服务

4.

未来展望

分享嘉宾｜夏桂林 快手 指标中台技术负责人

编辑整理｜赵云

内容校对｜李瑶

出品社区｜DataFun

01

背景介绍

1. 关于快手

快手是一个普惠的数字社区，在这里每个人都可以记录生活、分享生活。快手通过短视频和直播的形式成功构建了电商、商业化等多元化的业务生态系统。

截止到今年第一季度，根据公开财报数据，快手的平均日活跃用户数（DAU）达到了 3.93 亿，平均月活跃用户数（MAU）达到了 6.97 亿。在如此大的用户规模背后，是快手强大的技术在支持，这其中也包括数据平台部的技术。

2. 关于快手数据平台部

快手数据平台部的使命是打造高效且智能的自助式数据平台工具，用于业务的分析决策提效。职责是提供从数据集成、加工，到分析全链路的智能数据开发、管理和分析的泛大数据平台化能力，加速数据分析决策效率。

数据平台部主要围绕着基础建设和数据能力这两方面展开：

基础建设：技术架构的底层是大数据的引擎层，在引擎层之上有一站式的数据采集以及数据开发的工具。通过这些工具，可以将数据汇总到大数据平台上，再经过数据加工和融合打通，就形成了数据中台一体化的数仓。在数仓之上，我们会去沉淀各种资产。这就是我们在基础建设方面的工作。

数据能力：在基础建设之上，我们构建了各种数据能力，以满足各种场景下的数据分析需求，比如面向通用分析场景的数据分析能力等。

目前快手有着万级别的集群规模，以及 EB 级别的数据规模。如此海量的数据，给我们大数据技术带来了巨大的挑战。

今天我们分享的指标中台就是数据平台部的核心平台之一。

3. 指标相关介绍

在介绍我们的指标中台之前，先来回顾一下指标相关的概念。在数据分析中，指标是衡量业务表现的重要工具。

以活跃用户数为例，它是一个原子指标，代表用户活跃度的基础度量。这个指标可以进一步拆分为业务过程（用户行为事件），对象实体（用户），以及度量（用户数）。

通过添加修饰词，如“新增”，我们可以将指标限定在特定范畴，例如新增用户。

此外，通过指定时间范围（如“近 7 日”）和维度（如按城市），我们还可以构建派生指标，从而更细致地观察数据的分布。

基于这些原子指标和派生指标就可以构建指标体系，它可以帮助业务进行更有效的管理和决策。然而，指标体系也是一把双刃剑，如果使用得当，可以显著提升业务效率；如果使用不当，则可能带来额外的负担。因此，正确理解和应用指标对于业务成功至关重要。

4. 快手指标中台背景

在快手指标中台建立之前，公司的数据仓库拥有 10 万量级的数据表，当时采用的是数仓直接对接应用系统的方式，这种烟囱式建设模式导致了数据管理和应用效率的问题。这种模式下，指标分散在 BI 系统、AB 系统和运营系统等不同应用平台，缺乏统一管理，造成了资源浪费。主要带来以下问题：

数据质量：由于指标管理不统一、指标口径不统一，导致业务分析时难以对账，需要大量时间排查原因。

研发效率：每个应用平台的指标能力重复建设，严重浪费了研发资源，降低了研发效率。

为了解决以上问题，快手经过慎重考虑，决定建设一套企业级的指标中台系统，通过将数据层和应用层进行解耦，来解决指标质量和研发效率的问题。

5. 如何构建企业级指标中台

那么如何去构建企业级指标中台呢？

我们首先对行业趋势和业界常用方案进行了调研。

（1）行业趋势

Headless BI：Headless BI 采用“一处定义，多处使用”的理念，实现指标一经定义，即可在 BI 平台、运营平台等多处使用；其优势在于将数据层与应用层解耦，通过统一的服务接口保证指标的服务质量；当然，其整体实现的技术成本和挑战也比较高。

智能建模：基于表元信息抽取，利用算法和规则等技术手段自动构建表与表之间的关系，以减少人工建模的复杂性和成本。

（2）业界方案

指标驱动生产：基于已经定义好的指标元数据信息（派生指标、复合指标、加工口径等），来设计指标的生产链路，也就是业界 NoETL 的思路；主要优点是通过控制生产过程来保证指标质量，落地比较彻底，适用于一般场景的指标数据加工和聚合，其缺点是应用场景比较单一，无法应对复杂业务场景；

指标驱动分析：主要面向数据消费场景，提供更灵活多样的数据分析能力；而在数仓建设不做过多的限制，所以可能存在指标质量风险（当然该问题可以通过其他方法来解决），整体的实现复杂程度比较高。

指标驱动生产和指标驱动分析并非互斥，业界已有公司同时做生产方向和分析方向，并且取得不错的效果。基于快手已有较为成熟的数仓体系，我们认为现阶段基于指标来驱动分析的方案能更好地发挥数据价值。

6. 快手指标中台解决方案

基于以上的考虑，我们采用了 Headless BI 的理念建设了快手指标中台，通过实现指标的统一指标管理和统一指标服务，来解决指标质量和研发效率问题。

指标中台在整个数据链路中起到了承上启下的作用。

向下，通过对各种数据源进行统一接入，来保障指标口径和数据质量，并且屏蔽了底层物理技术的实现细节，让用户只需感知指标维度层面的使用；

向上，通过统一的指标查询服务，为上层应用提供稳定可靠的指标服务，从而保障指标质量。

在与应用方的合作过程中，主要采用两种模式：

合作共建：一种是指标中台与 BI 工具的深度合作，通过这种方式构建快手的 BI 体系，实现数据的深入分析和可视化；

开放生态：另一种是指标中台结合开放 API，构建一个开放的生态，允许更广泛的数据访问和应用集成，从而促进数据的共享和创新。

通过这种综合性的解决方案，能够为企业提供强大的数据支持和灵活的分析能力，推动企业数据驱动的决策和业务增长。

整个指标中台是围绕着指标管理和指标服务两部分来建设的，接下来将分别进行详细介绍。

02

指标管理

1. 指标管理相关背景

首先来介绍指标管理。

在指标管理方面，主要问题是指标管理不统一和指标口径不一致；指标管理不统一导致了指标多处管理、严重浪费成本等问题，指标口径不一致导致了指标同义不同名、同名不同义等问题，比如同样是支付订单金额指标，有的业务方叫 GMV，有的业务方叫支付金额，这种同义不同名的现象给我们日常指标沟通和使用都带来问题和困难。我们希望通过标准化流程对指标进行有效管理，协助业务提高指标管理效率，降低业务成本，从而提高业务决策效率。

2. 指标管理解决方案

那么如何才能有效管理指标呢？

我们的具体做法是采用流程+规范+管理工具的方式来构建指标管理模块，主要分为以下部分：

指标标准化流程与规范：采用标准化的流程和规范来统一指标和维度信息的接入；

元数据管理：对接入的指标维度元数据进行统一管理；

模型管理：对指标维度等元数据进行数据建模，形成数据模型，将数据模型进行有效管理；

数据集管理：在元数据管理和模型管理的基础上形成数据集管理，对外提供统一的服务。

下面来分别介绍以上步骤。

3. 指标标准化规范和流程

指标标准化规范和流程主要解决两个问题：统一指标口径、提高指标质量。在整个流程中的各个环节都需要制定并落实相关规范，具体如下：

业务口径制定：在明确需求后，将制定业务口径，确保指标的定义与业务目标一致，要落实数据规范和指标命名规范。

数据开发：根据业务口径进入指标开发阶段，要落实数据开发规范和数据模型规范，并且在平台保证一致性规范。

指标服务提供：落实指标服务规范。

审批授权：为保证指标口径的统一，我们会对各业务线进行梳理，每个业务线会有对应的数据域，数据域有数据管家对指标口径进行审批和授权。

整体来讲，我们是在关键流程中落实相关规范来保障数据开发质量，进而保障指标的质量。在整个流程中，需要多个团队通力合作，才能确保指标的统一性和高质量。

4. 元数据/模型/数据集管理

在元数据管理方面，整体采取分层管理的方法来确保数据的有效组织和使用：

概念层（元数据管理）：主要负责指标、维度、数据表以及绑定等元数据的统一管理。

逻辑层（模型管理）：在元数据管理之上，我们面临的第一个问题是原始录入指标的元数据通常不能直接用于业务。例如，一个维度可能绑定多张维表，在指标服务时基于原始元数据计算维度应该从哪张维表取数是非常浪费资源的，所以需要进行数据建模，基于元数据重新梳理和构建数据关系，形成数据模型，进而提高指标使用时的查询性能。

应用层（数据集管理）：第二个问题是业务线可能有成千上万的指标，用户的一些使用场景只关注少量指标，但在使用时却需要从大量指标中检索特定指标，这无疑增加了用户的理解成本和使用成本。为了解决这个问题，我们设计了数据集，即特定指标、维度和数据表的一个集合，从而缩小指标数据的范围。用户可以将关注的指标和维度圈选到一个数据集中，这样在使用看板或报表时，可以直接使用数据集提供服务，而不需要从大量指标中逐一检索。数据集也是我们对外提供服务的载体。

5. 数据建模

在元数据管理中，有一步非常关键，就是数据建模，这里单独介绍一下数据建模。

数据建模是数据管理过程中非常关键的一步，它直接影响到后续数据的使用和分析。数据建模，即基于指标维度和数据表的关联关系，实现从指标维度元数据到数据模型的转换。具体做法是采用三步建模的方式：

（1）概念建模：在指标定义阶段，定义指标、维度、数据表之间的关系。

（2）逻辑建模：逻辑建模是一个自动化的建模服务，包括模型发现、关联字段、最佳路径计算和模型索引的构建。

（3）物理建模：生成最终的数据模型，包括星型模型和雪花模型。

其中关键的建模步骤是逻辑建模过程。为了让大家更好的理解逻辑建模过程，这里以一个例子来介绍：

模型发现：如上图中的例子，在平台上定义了一个指标（活跃设备数）和一个维度（省份 ID），指标绑定在事实表上，维度绑定在事实表和两张维表上；首先会通过模型发现检测到指标口径以及指标和表的绑定关系的变化，一旦发现变化，就会自动触发建模流程。

关联字段：模型发现后，首先通过关联字段（省份 ID 绑定的维表字段）进行模型的初步构建，在该例子中事实表和维表通过province_id 相关联，而 province_id 会关联两个维表，即城市维表和省份维表。

最佳路径计算：初步建模后，接下来对模型进行优化，即最佳路径优化，主要遵循选粗表不选细表、选快表不选慢表的原则；在上述例子中，虽然省份维表和城市维表均满足绑定要求，但省份维表比城市维度粒度更粗，在后续指标服务过程有更好的查询性能，所以这一步会将城市维表裁剪掉，只留下省份维表。

数据模型：最终得到数据模型，记录表与表之间的关系，以及一些附加信息（可累加性等信息）。

有了数据模型之后，就可以对外提供指标服务了。接下来将介绍指标服务部分。

03

指标服务

1. 指标服务相关背景

指标服务是数据架构中的重要组成部分，其核心功能是提供指标取数的能力。随着业务的不断发展，对指标服务的要求也在不断提高，主要问题与挑战如下：

需求多样性：除普通计算能力外，业务需要高级计算和分析能力，如窗口函数计算、同比/环比分析等；

联邦查询：数据可能分布在不同的存储系统中，如 ClickHouse、Hive 或 MySQL 等，传统的解决方案是将数据同步到单一引擎，但这会给业务增加开发和存储成本。所以业务对联邦查询的需求也愈发强烈；

查询效率：不同存储系统中的查询效率存在差异，比如像 Hive 离线引擎查询慢、ClickHouse Join 查询性能慢，从而会影响业务的分析效率。

2. 指标服务解决方案

为了解决上述问题，我们将指标服务设计成以下三层：

统一分析语言层：提供丰富的语义表达能力，使用户能够定义复杂的计算和分析需求；

统一查询引擎层：提供联邦查询能力，允许用户跨引擎进行查询，而无需关心底层物理存储的复杂性；

指标加速层：提供指标查询加速能力，优化查询性能，解决查询效率低下的问题。

3. 统一分析语言 OAX

统一分析语言（OAX）是一种以数据集为载体，面向分析场景的分析语言，包括五个要素：数据范围、指标、维度、时间范围和过滤条件。

为了大家更好地理解 OAX 语言，我们以一个例子来说明：比如要获取 2022-2023 年广东省各市的 GDP 总值及其在全省 GDP 中的占比。

不使用 OAX 语言：首先我们需要分别求出广东省各市的 GDP 总值，然后计算广东省的 GDP 总值，再把两者计算求出占比，整个过程一般需要三个 SQL 来完成；

使用 OAX 语言：我们可以这样操作，数据范围是国民经济数据集，指标为各市的 GDP 总值及其占比，维度是年份、省份和城市，时间条件是 2022 年至 2023 年，过滤条件是省份为广东。如图中 SQL 的第 5 行，通过 EXCLUDE[城市]去掉了城市维度，也就是省 GDP，再用各市的 GDP 除以省 GDP，就是我们需要的占比这一指标。可以看到，使用 OAX 语言可以极大地简化计算的定义，提高业务分析效率。

以上例子是 OAX 语言的动态粒度计算的能力，OAX 语言的能力主要包括三部分：

基本计算：OAX 提供了一系列基本的计算函数，如 SUM、COUNT DISTINCT、CONCAT 等等。

动态粒度计算：允许用户在计算过程中根据需要调整数据的粒度，进行更灵活的分析。如 EXCLUDE、INCLUDE、FIXCLUDE 等。

表计算：表计算是 OAX 的一个高级特性，它允许用户在数据表中进行跨行的计算。例如 RUNNING SUM（累计求和），用于计算从表的开始到当前行的连续值的总和。这种方法不仅简化了计算过程，而且提高了计算的准确性和效率。

OAX 属于语言层面，要真正落地还需要一个载体去实现，即统一查询引擎 OCTO。

4. 统一查询引擎 OCTO

统一查询引擎 OCTO 是一个支持联邦查询的通用查询平台，它能够将统一分析语言（OAX）转化为实际的查询操作。

OCTO 的架构主要包括：

（1）接口层：主要联邦查询语言，基于 Substrait 协议扩展而来。

（2）查询层：首先是解析接口层的联邦查询语言，构建逻辑查询计划；然后对查询计划进行编排，这里是实现二次计算的关键，像同环比、动态粒度计算等能力均为二次计算能力；最后将编排后的计划交由引擎执行。

（3）适配层：适配异构引擎的查询能力。

我们还是以一个例子来看一下整体处理流程：

（1）定义 OAX 查询语言：以前面求各市 GDP 占比的样例为例，首先定义好 OAX 语言的五要素；这时还是指标维度范围；

（2）翻译成联邦查询语言：然后将 OAX 语言翻译成联邦查询语言；这一步主要结合指标维度元数据和数据模型信息，将 OAX 语言的五要素转换成物理引擎的表和字段信息，组织成联邦查询语言；这时就是物理底表范围；

（3）查询计划：将联邦查询语言翻译成查询计划，在该例中，广东省各市 GDP 总值和广东省 GDP 总值分别是两个计算算子，然后将这两算子 Join 计算得出 GDP 占比；

（4）得出结果：最后将计算结果返回。

总结一下，OCTO 具有三大特点：

（1）联邦查询能力：OCTO 是支持异构数据源的通用联邦查询平台，可以通过查询计划编排实现各种高级数据分析能力；

（2）开放能力：作为通用平台，可支持运营平台、质检平台等多种应用系统的指标需求。

（3）查询性能优化：

RBO：基于规则的优化，如谓词下推、列裁剪、join 消除等。

CBO：基于成本的优化，遵循选择快表、小表的原则，提高查询性能。

5. 指标加速

OCTO 的查询优化主要是在查询计划层面，而有些场景下查询计划层面的优化无法满足要求，比如无法优化 Hive 引擎查询慢的问题。为了解决此类查询性能问题，我们设计了指标加速层，其主要采用的是用空间换时间的思想。

指标加速层的配置方式有两种：

用户手动配置：用户可以基于特定的指标和维度手动配置加速规则，系统根据这些规则生成 ETL 任务，自动提交给任务调度平台，定期执行以加载数据到高速引擎。

自动化分析配置：平台根据用户在指标和维度上的查询历史记录，自动分析提效场景，然后创建自动化的 ETL 任务进行数据加速。

指标加速层的应用场景包括：

冷引擎到热引擎：将存储在性能较低的存储引擎（如 Hive 表）中的指标数据加速到性能更高的存储引擎（如 ClickHouse）；

关联查询到单表查询：将涉及多表关联查询的场景优化为单表查询场景，通过加速任务，提前将数据聚合到单张表再加速到热引擎中，以提高查询性能；

大表到小表：在某些大宽表场景下，每次查询少量常用指标维度都需要进行全表扫描，导致查询性能不佳；指标加速可以将频繁查询的指标和维度单独形成小表，减少查询时的数据扫描量，提升查询效率。

指标加速层上线以来，加速任务已达到百级，加速指标占比约为 10%，整体查询性能提高了 10 倍。

6. 指标中台落地情况

指标中台自上线以来，全面覆盖了公司的分析领域，主要表现如下:

质量：没有重大质量故障；

效率：10 倍以上的效率提升；

成本：极大地提高了数据复用度；

指标管理：快手核心业务线指标全部接入指标中台，上万指标数量；

指标服务：接入几十个应用方，单日查询次数达到上百万次；

运营情况：日活跃用户达到千级别，月活跃用户达到万级别，为数据分析师、运营人员、DE 和业务人员的提效提供支撑。

04

未来展望

指标中台在未来发展中将重点聚焦于两个关键领域，即智能化和高性能。

智能化方面：平台计划利用大型模型的能力来探索智能取数功能，以实现更高级的业务分析自动化。通过标准化的指标信息构建交互式的自助 BI 产品，从而提升用户体验，提供高质量的对话式智能分析服务。这种智能化的趋势将极大地提高数据分析的效率，使用户能够更快速地获取所需信息，同时降低技术门槛，实现数据的普惠。

高性能：平台将继续优化和提高查询性能，不断提升用户的查询体验。此外，随着技术的发展，也会探索如向量化、native sql 等新技术，以进一步提升数据处理能力，满足日益复杂的业务需求。

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