快手数据中台建设 - 指标规范化以及OneService平台化实战

hadoop123 2021-01-08

1210

导读：

在大数据领域，指标是对业务的数据度量，所以业务获取的数据通常都以指标形式进行交付，例如：业务方提出的数据需求内容、向业务方展示的数字看板等，指标可谓是无处不在。但是，对指标的管理以及对外指标服务过程中，常会面临“规范不统一”、“口径不一致”、“出口不统一”等一系列问题。针对这些问题，快手数据平台构建了符合快手现状的指标中台体系（代号：盖亚/Gaia）并在全集团数据中台体系落地。本文为大家详细介绍快手的指标规范化建设以及OneService平台化的实战经验，主要内容包括：

1.指标管理/服务面临的问题以及解决方案

2.指标规范化建设

3.指标服务OneService平台化建设

4.落地成果与未来规划

1.指标管理/服务面临的问题以及解决方案

指标管理/服务面临的问题

如下图所示的数据服务架构图，在快手我们基于离线数据仓库构建了丰富的应用产品，包含ABtest平台、报表平台以及分析平台等，通过这些产品满足不同的业务数据分析场景需求。可以看出，每个平台都沉淀了万级别的指标。

如果从指标管理/服务的视角，发现这样的数据服务架构存在如下问题：

指标管理不统一

多处管理：成本较高
重复管理：指标泛滥

指标口径不统一

同名不同义：口径不一致
同义不同名：命名不规范

指标流程不统一

系统独立：管理不统一、流程不统一

针对这些问题，业界常用的解决方案是建立统一的指标管理系统，从而收口指标相关元信息的管理。但是大家在构建指标管理系统时，通常做得并不是很完善，主要表现以下几个方面：

数据字典，约等于wiki；
无体系化的流程保障机制，数据准确性无法保障；
指标血缘关系缺失，与数据生产、数据消费没有建立血缘关系；
管理与数据应用分离，无法一处变更，全局生效。

最终引起指标管理动力不足。即数据开发没有足够强的动力去管好指标，因为指标的管与不管，数据依然正常服务业务方，并没有起到关键性的作用。

解决方案

我们可以看到，在快手我们面临的是复杂的业务场景以及大量的指标（万级别指标），如果不建设完善的指标体系生态来支撑业务，则“数据赋能业务”变成为“数据拖累业务”。快手推行统一的数据中台战略，所以在指标领域建设上，我们的目标是建设成统一的指标体系中台，以提升我们数据对外的服务质量以及服务效率。

在数据内容层面，我们建设了OneData体系，做到“一处生产，全局复用”。在OneData体系之上，我们期望构建出统一的指标生态体系-盖亚（Gaia）体系：

OneMetric体系：统一管理指标口径信息，基于指标口径的元信息构建数据模型，做到“一处管理，全局引用”。

OneService体系：统一指标服务出口，上层业务、数据门户等都统一从OneService获取指标数据，做到“一处服务，全局调用”。

在统一的数据中台体系下，我们制定了标准的快手数据资产标准化管理规范，包括统一的规范、流程，从需求对接、指标口径定义、数据开发构建分析产品到发布。在整体流程中，多个团队方协作形成OneTeam共建，主要包含内容团队、工具团队以及产品团队，其中工具团队主要负责沉淀规范流程、提升数据开发、数据服务以及数据管理的效率。

以下分别介绍指标规范化建设以及指标服务OneService平台化建设，重点会介绍我们工具团队打造的OneMetric以及OneService体系的系统设计以及关键技术。

2.指标规范化建设

规范流程建设

我们定义了各种指标规范，工具团队需要进行规范沉淀到系统，提升指标建设的规范性，同时也需要建立规范对应的分级保障机制。以指标/维度等级、安全等级为例，系统需要针对不同等级指标建设对应的质量、资源以及安全等保障机制。

在指标规范建设过程中，我们按照领域抽象、数据模型抽象，抽象出标准的指标、维度以及事实表、维表。基于此标准的建设框架，我们就可以建设出规范的指标、维度，并接入到指标中台体系，打造基于标准指标维度服务业务的新模式。

OneMetric系统

OneMetric目标是统一指标口径管理，进而统一上层应用的指标口径。其设计思路是通过管理指标元信息，构建出标准的数据模型信息（包含表与表之间的连接关系），再基于表与表之间关系推导出指标与维度的关系。有了这个重要的模型元信息，我们可以提供基于指标维度的模型检索能力。整体架构如下图所示，整体分为两层：元数据层和模型层，模块包含元数据管理模块、模型构建模块、模型搜索模块以及指标一致性模块。

下面分别介绍每个模块设计及其关键技术。

元数据管理模块

元数据管理模块首先管理指标/维度的定义信息，包括逻辑定义信息以及物理定义信息。其次，如果要对外提供指标服务，进行数据集的管理。从使用场景角度，数据集可以是面向分析场景构建，例如：效果广告数据集、展示广告数据集等；从数据管理角度，数据集是管理指标/维度的集合，并且基于此限定数据模型的边界以及指标/维度的范围。

指标一致性模块

指标一致性模块在整个OneMetric体系承担“指标口径一致性”重要职责。数据仓库通常是按照分层、分主题建设，在DWS层沉淀指标计算口径逻辑，在TOPIC层构建分析主题，APP层构建面向特定场景构建数据应用层表。基于此数据仓库设计原则，会存在如下两种情况：

第一种情况：同一指标在不同层次会出现；
第二种情况：同一指标也会在同一层不同数据表存在。

则从指标一致性的视角，我们需要确保指标口径的一致性，所以我们构建了指标一致性检测模块，从两方面进行口径检测：

实时一致性检测：在指标绑定新的物理表时，若指标在现有数据仓库已经存在绑定的计算口径，需要确保两个计算口径的结果一致性，这时会进行两个计算口径实时的一致性检测；
例行一致性检测：在经过实时一致性检测之后，能确保指标在不同路径下的口径一致性，但在实际应用中，还会存在数据刷新、逻辑变更等情况，这时我们可以通过例行的检测，发现不同计算路径的数据不一致问题。

模型构建模块

模型构建模块会依据指标/维度的物理定义信息，即指标/维度与表的绑定关系，基于维度建模的思想，通过事实表关联维表，同时维表可以再关联维表，进而构建出表与表之间的连接关系，最终得到数据仓库领域的维度模型。基于此构建的数据模型关系，主要包含几个重要信息：

表与表之间的连接关系：表与表如何关联，通过什么字段关联；
指标/维度与模型之间的关系：指标/维度在哪些数据模型中存在；
指标与引擎之间的关系：指标可以在哪些物理引擎中支持。

模型搜索模块

基于模型构建模块构建的模型索引信息，我们构建了模型搜索模块，其目标是提供基于指标/维度的模型搜索能力。对于给定的指标/维度，找出符合条件且效率最优的数据模型。主要经过两个阶段：

筛选阶段：在OneMetric体系下，通常满足一个指标/维度组合会存在多个模型，筛选阶段就是找出符合条件的模型。

指标筛选：筛选出包含指标的模型
维度筛选：筛选出包含维度的模型
范围筛选：筛选出维度范围满足要求的模型
日期筛选：筛选出时间范围满足要求的模型

排序阶段：基于筛选出的模型，进行各维度的排序，选择出最优模型。

生产排序：按照模型中表的生产完成时间，取完成时间比较早的表
效率排序：按照模型中表的引擎、表的宽度进行排序，优先取高速引擎（例如OLAP引擎优先），宽表减少数据Join操作
维度排序：按照模型中表的粒度，粒度越粗则聚合成本越低
手动排序：按照模型中表的优先级进行排序

3.指标服务OneService平台化建设

系统架构

在OneService体系下，我们期望提供面向指标/维度为交互语言的指标查询服务，对应用层屏蔽底层技术细节。所以，OneService需要将指标/维度查询任务翻译为面向大数据引擎的执行计划，并进行相应的任务调度以及数据计算。其中重点包括两个核心能力：

语言翻译能力：将面向指标/维度的查询语言转换为面向引擎的查询语言。
二次计算能力：基于表的取数结果再进行二次的运算能力。在实际应用场景下，通常会有二次计算的需求，例如同环比、分位查询等。

OneService系统架构如下图所示，可以看出OneService会强依赖OneMetric的模型元数据信息以及检索能力，在OneService中主要分为引擎层和服务层：

引擎层：负责任务的执行计划生成、任务调度以及数据计算，包含查询引擎模块以及OneSQL模块；

服务层：对外提供指标/维度元数据服务以及数据查询服务。

下面分别介绍系统中涉及到一些关键技术。

关键技术-语言抽象

在查询语言层面，OneService提供统一的指标/维度语言，则需要将自然语言分析需求转换为结构化的查询语言。我们通过如下案例来说明语言抽象的思路，例如一个常见的分析需求：

电商本周各地域母婴产品支付订单金额

如果我们将该需求进行结构化抽取，可以做如下解释：

电商：数据范围
本周：时间范围 = [20201019 – 20201025]
各地域：维度 = [地域]
母婴产品：过滤条件 =  [商品二级类目 = 母婴产品]
支付订单金额 ：指标 = [支付订单金额 ]

通过这样的结构化理解，则统一的指标查询语言可以由五要素组成：数据集、时间范围、指标、维度、筛选条件。基于此五要素，设计出OneService统一指标维度查询DSL。如下图所示，当前语法规则设计比较简单，类似Json语法风格。

关键技术-执行计划

在实际应用情况中，除了简单的五要素，实际还存在一些同环比类似的分析场景，则一次取数任务并不是提交一次引擎查询就可以满足需求。所以按照实际场景，查询引擎在处理一次取数任务时，会生成一个执行计划DAG，主要包含两层拆分原则：

语义拆分：按照查询引擎提供的DSL语义进行第一层拆分，一个Job（对应用户一次取数任务）会拆分为多个Task，每个Task表示一次逻辑的指标/维度查询。

引擎拆分：按照指标维度所存在的表引擎进行第二层拆分，一个Task会拆分多个Query，每个Query表示一次面向引擎的查询。

基于以上执行计划拆解，一次取数任务的执行流程如下图所示。查询引擎根据统一的语法规则以及数据模型中的引擎分布情况生成物理执行计划，提交给数据引擎执行，如果存在跨引擎或者二次计算场景，需要通过二次计算模块中进行二次计算。其中，执行计划中的Query通过OneSQL模块进行面向引擎语言的语言翻译。

关键技术-OneSQL

OneSQL目标是将指标数据模型转换为物理数据引擎的查询语言，在大数据领域数据引擎是丰富多样的，从分类上看包含SQL类的引擎，KV类的引擎以及其他自定义DSL的引擎。为了适配不同引擎的语法规则，我们进行了统一中间层抽象。首先将一个数据模型转为一棵统一的AST树，在AST树基础上我们还可以应用一些RBO优化规则，在引擎之上再做一些生成SQL层面的优化，就像我们数据开发实际在写SQL时，期望得到最优的SQL写法。基于规则优化之后，再利用引擎的语法规则，将AST树转换为面向引擎的查询语言。

4.落地成果与未来规划

落地成果

我们在一年不到的时间，从0到1完成了OneMetric以及OneService指标中台体系建设。在该体系下，我们的数据服务模式从原来的SQL模式转换为基于指标维度的服务新模式，数据仓库中的数据统一接入盖亚体系之中，再服务于业务。与此同时，应用产品也从原有的SQL取数切换为指标维度取数，包括常见的分析看板、指标取数、OLAP以及邮件报表等全部从OneService调用指标维度数据，进而统一了指标口径的管理以及指标服务出口。整体上，在指标中台体系下，我们提供了高质量的指标数据（指标口径统一管控）以及高效率的数据服务（数据无需数据开发手写SQL，由OneService系统自动生成SQL）。

在业务对接方面，接入主站、电商、游戏等核心业务。

在配置能力方面，数据从管理到发布，只需分钟级别完成。

在查询能力方面，支持Hive/Druid/Hbase引擎，且支持不同引擎之间的联合查询，并提供基于指标/维度的函数算子。

在查询性能方面，离线查询实现分钟级别查询，同步查询毫秒查询。

未来规划

未来重点从以下几个方向演进：

接入更多业务，全面推广到公司更多数据业务
构建数据服务领域的OneService，让数据配置即服务
构建面向数据服务的OneDSL
构建OneCache，提升性能
自动化/智能化探索

作者介绍

刘一凡，快手数据服务工具链（智能指标模型平台、统一数据服务OneService平台）团队负责人，专注于大数据开源技术以及大数据中台化的生态体系建设。

快手数据工厂团队介绍

快手核心大数据中台团队，为全公司构建业界领先的智能大数据生产和服务平台，赋能全业务线提升公司数据创新效率。目前涉及方向包括数据开发工具链（数据开发平台、大规模工作流调度、全链路质检平台）、数据流工具链（异构数据交换和同步、实时开发平台）、数据服务工具链（智能指标模型平台、百万级并发数据服务化平台）、数据管治工具链（全链路元数据平台、数据治理平台、数据地图、数据安全平台）。目前在寻找各类技术方向的Java和数据平台研发工程师，欢迎有识之士加入我们！

数据库

文章转载自hadoop123，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。