快手指标中台建设实践

背景介绍

1. 关于快手

2. 关于快手数据平台部

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

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

3. 指标相关介绍

4. 快手指标中台背景

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

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

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

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

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

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

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

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

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

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

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

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

指标管理

1. 指标管理相关背景

2. 指标管理解决方案

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 数据建模

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

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

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

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

指标服务

1. 指标服务相关背景

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

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

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

2. 指标服务解决方案

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

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

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

3. 统一分析语言 OAX

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

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

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

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

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

4. 统一查询引擎 OCTO

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

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

5. 指标加速

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

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

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

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

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

6. 指标中台落地情况

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

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

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

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

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

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

未来展望

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

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