干货 | 用数据描述和驱动业务，携程指标标准化管理实践

一、背景

携程金融自 2017 年成立以来，继承了互联网企业“小步快跑，快速迭代”的基因，一直保持高速发展。不过业务的频繁迭代以及分散性的数据组织架构，给数据治理工作带来了很大的挑战。特别是在指标应用层面，这些挑战更为明显：

• 业务频繁迭代，数据知识相对于业务模型变更存在一定滞后性，导致不同数据使用人员对业务理解存在较大偏差。
• 数据团队比较分散，指标建设存在严重冗余，不仅导致资源浪费，并且在口径描述上缺乏一致性管理，导致在指标使用过程中有很多分歧。
• 标准化规范浮于表面，无法在数据开发的全生命周期实现系统性约束和校验，存在数据质量风险。

针对以上这些问题，我们参考了业界比较成熟的 OneData 方法论。OneData 提出了数据建设的三个统一：统一指标定义、统一数仓建模，统一开发流程。基于此，我们结合金融独有的组织架构及业务特点，从指标定义标准化、流程管理系统化两个层面进行了设计和实践，以保障数据能有效支撑和驱动业务的高速发展。

二、指标定义标准化：关于指标定义的思考

数仓建设者对业务的把控程度直接决定了数仓质量的高低，因此在数据建设过程中如何实现数据模型与业务模型的统一，一直是我们思考的重点。之前我们都是通过文档或 wiki 的形式来梳理并记录业务知识。比如在指标文档中，我们会通过详细的文字描述信息来确认指标口径。但是受限于文档维护者对业务和需求的理解程度以及口语化描述本身的局限性，这种方式很容易带来理解歧义问题。

通过日常工作总结，我们发现要解决理解歧义问题，必须从两个方面入手：统一收口指标口径描述和标准化定义流程。

口径定义收口，即做到指标的统一录入和查询功能，保证指标定义逻辑对所有用户是可见的。口径定义收口很容易通过系统实现，但是如何保证指标定义流程的标准化呢？最重要的是要保证指标定义工作可流程化。

我们总结了数据分析人员日常指标定义的工作流程，发现了其中可以流程化的四个节点，如下图所示：

我们以“每日 IOS 端金融 APP 注册用户数”指标为例对指标的定义过程进行描述：

• 指标定义的首要流程，需要明确其要量化的业务线和场景。该例指标需量化的是“金融”板块的“拉新”场景。
• 其次对该业务线场景下所涉及的业务流程（或事件）进行梳理，明确关键业务步骤，并找到该指标所量化的业务节点，即“注册”。
• 然后是考虑如何对该业务事件进行量化，即明确定义“注册”事件的量化口径是“用户数”。
• 最后就是对指标进行维度拆解，该例所涉及的维度有两个“每日”和“IOS 端”。“每日”按照日期维度对指标进行聚合汇总；“IOS 端”是限定注册来源，进行下钻过滤。

三、流程管理系统化：系统设计实践

基于以上描述，我们可以看到指标定义流程已经完成了标准化拆解。但在数据标准管理中，通常标准规范相对好制定，而标准落地就比较困难，这大多都是因为数据标准缺乏有效约束造成的。因此我们开始了“指标标准化管理系统”的开发，借助工具化手段将预定义规范约束到指标定义、开发、应用等各个链路。

在该系统中，我们将指标定义拆解出的四个流程抽象为了"业务板块和数据域"、"业务过程"、“维度管理”、"指标设计"四个模块。下面就依次介绍一下这几个模块的具体实现。

3.1 业务板块和数据域

指标体系构建的第一步就是对当前需要分析的业务场景进行抽象，明确其所属场景。业务板块代表有独特业务场景和流程的业务体系。业务板块是一种大的划分，各业务板块之间的业务重叠度极低。数据使用方可根据自身业务的理解和抽象，在所属业务板块下创建的独有的指标体系，数据独立建设。数据域则是某个业务板块下，对一类业务活动的抽象集合，是一个较高层次的数据归类标准，是对企业业务过程进行抽象、提炼、组合的集合，一般与数仓主题层对应，面向业务分析。业务板块和数据域是有效归纳组织业务过程的方式，方便了对指标的快速定位。

3.2 业务过程

业务过程可以说是该系统中最核心的模块。通过将一次业务行为事件抽象为业务过程，并在每个业务过程中维护了具体的表和数仓关联了起来，实现了业务模型与数据模型的统一。

3.2.1 概念

业务过程代表某个数据域下的不可拆分的事件行为。业务过程代表的是一次业务事件，而且该事件在该数据域下是具体、明确且没有歧义的。业务过程一般用来标识一次业务活动中的关键节点事件。

业务过程可分为两类：事务型和快照型。事务型业务过程代表一个时点动作，因此都会具有时间属性。比如一次“交易”业务中可能会有：下单，付款，取消，退款，发货等业务过程，相对应的时间属性分别有下单时间、付款时间、退款时间、发货时间等；快照型则表示非事件动作的周期性度量，比如在贷余额、库存等，这种类型的时间属性仅为观察时点。

3.2.2 数据表映射

业务过程一般会与数仓维度建模过程中的事实表进行关联，比如：事务型业务过程会对应事务事实表或累计快照事实表，快照型业务过程则一般对应周期快照事实表。业务过程与事实表之间一般为一对一的关系，也有一对多或多对一的特殊情况，比如：多事务事实表和累计快照事实表就会将多个业务过程产生的事实在一张表中表达，因此在构建过程中，不仅需要维护与事实表的关系，还要添加“约束条件”解决此类问题。

3.2.3 数据流程图

日常工作中，业务人员总会通过绘制业务流程图来说明整个业务逻辑流向，帮助开发总览业务全貌，厘清业务细节。数据分析师，要做到数据驱动业务发展，不仅需要熟知业务流程，也需要熟知数据流程，即将业务流程转化为数据流程。基于此我们在系统中实现了特定业务场景下的“业务过程”以业务流程图的形式呈现出来，帮助数据使用方更加明确业务过程在整个业务域中所处的节点和与其关联事实表的触发场景。

3.3 维度管理

维度是业务过程（或事件）发生时所处的环境，用来反映业务的一类属性。因此，如果要对特定“业务过程”充分描述，就需要满足与其关联的事实表要冗余足够多的维度属性。在当前以 Hadoop 等大数据框架为主要构建方式的数仓体系中，为了降低事实表使用时的资源消耗，提升计算效率，事实表大多以冗余维度属性的宽表形式存在，但是大量的维度冗余也带来了模型稳定性的降低。因为维度的属性是有可能发生变化的，如果属性已经冗余到事实表中，那么维度属性就与事实一起被记录到事实表中。如果后续维度属性值改变，由于事实表已经生成，事实表的内容基本不会再做改变，这样就会出现已记录的维度属性与真实的维度属性不一致，导致数据错误的情况。因此，维度属性冗余带来的收益与弊端要综合考虑。

那么我们如何在事实表不冗余属性的基础上充分描述业务过程呢？我们通过在业务过程上构建“衍生属性”和“关联维度”的功能，进行属性的扩充。

• 衍生属性：通过 SQL 表达式对业务过程所关联事实表中已有的事件属性进行二次加工，产生一个新的属性值。
• 关联维度：在业务过程中通过已有事件属性与维度表关联，将维度表中的属性扩充到该业务过程中。

业务过程和维度管理的维护，不仅真正实现了数据对业务的准确描述，另外也给数据赋予了“灵魂”，提高了数仓主题表的可懂性和易用性，为其有效推广带来了很大帮助。

3.4 指标设计

3.4.1 定义

指标就是业务运转过程中产生的度量事实，指标设计是为了在企业内外部使指标的命名、计算方式、业务理解达到一致，避免不同部门同一个指标的数据存在理解不一致的情况。指标定义则是针对业务过程，从不同维度的量化过程。这个过程进一步抽象就是包含两部分：量化和维度。

• 量化：也就是指标的统计规则定义。
• 维度：则是从事件的不同角度进行细化分析。

3.4.2 原子指标

关于指标的量化，我们在系统中提供了“原子指标”的概念，它是基于某一业务过程下的度量，是业务定义中不可再拆解的指标，具有明确的业务含义。原子指标的核心功能就是对指标的聚合逻辑进行了定义。

3.4.3 派生指标

原子指标因为没有统计粒度（及承载指标的实体维度），因此也就不会有特定的数据与其对应，而只有在原子指标的基础上添加了粒度等信息，才能和具体数据对应，而这就是“派生指标”。如果说原子指标只是一个抽象的逻辑定义，那么派生指标则具象化后的实际度量值。派生指标是由原子指标、维度属性、限定属性组合而成。之前提到的“每日 IOS 端金融 APP 注册用户数”指标就是派生指标，对其进行拆解如下图所示：

原子指标和派生指标的定义，通过派生指标继承原子指标业务场景、关联事件、统计逻辑、描述信息等元属性，进一步收敛了指标定义口径，提高了指标一致性。如果以软件工程举例：原子指标可以理解为父类。派生指标代表继承“原子指标抽象类”的实体类。原子指标无法直接构造对象，只能通过派生指标构造，但派生指标必须依赖于某原子指标。

3.4.4 指标逻辑解析

基于设计即开发的思想，我们可以总结发现在完成“业务过程”、“原子指标”和“派生指标”整个指标定义流程之后，该指标的逻辑便以数据分析师们最熟悉的“统一语言”呈现了出来，通过 SQL 实现了指标口径的一致性约束。

• 业务过程定义了指标的数据源表（与其相关的事实表及关联维度表）及星型模型关联关系。
• 原子指标定义了指标的聚合逻辑（sum/avg/count）。
• 派生指标定义了指标的分组（group by）和限定（where）逻辑。

四、实践应用

4.1 指标项目构建

完成指标标准化定义后，我们已经实现了指标定义的统一收口，保证了指标的可见、可查、可信，但是还缺少应用层面的统一收口。如果在应用层面没有统一收口，那么前期的指标定义更像是“空中楼阁”，还是无法从实际应用角度解决指标一致性问题。

如下图，在没有实现应用统一收口的时候（重构前），指标系统只是起到了指标注册和口径描述功能，调度开发时只是会以指标系统的口径为参考，并未完成定义与开发的统一（如“指标 B”的建设逻辑还是会冗余在两个 JOB 中），整个研发过程还是属于“面向需求”的烟囱式，这不仅破坏了数据一致性原则，也缺乏复用能力，增加了资源浪费和后期维护成本。

因此，我们基于配置即开发的原则，通过系统保证了指标与任务的统一。开发流程由原来的“面向需求开发”转变为“面向指标开发”，实现了指标任务间的解耦，一个指标只对应一个任务，提升了开发运维效率。同时，我们构建了“指标项目”模块。该模块对粒度相同的相关指标进行自定义归纳，完成与需求的一一对应，保证了应用层面的统一收口。

4.2 指导建模

上面我们提到，指标的统计逻辑来源于数仓中的事实表和维度表。而这两类表正是数仓维度建模理论的最终呈现。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此具体建模过程中，需要对哪些业务从哪些维度进行建模，可以通过指标定义倒推出来。基于该系统的指标定义功能，其实就是维度建模的过程。下图为两者对比：

可以发现，我们在指标定义过程中，数据域定义、业务过程拆解、维度细化等方面完全和维度建模的总线矩阵构建流程相符。另外，由于该系统实现了指标定义 sql 的展示，因此数据分析人员就可以很容易的找到与其相关的事实表和维度表，并通过业务过程的数据表映射功能，了解事实表的落地场景和含义，非常有利于数仓模型的推广，从而提升主题表的复用性，减少重复计算造成的资源浪费。

4.3 业务梳理与数据调研

“懂业务”是数据工作的基石，数仓建设者即是技术专家，也应该是“大半个”业务专家。因为唯有理解业务，才能发挥数据最大的价值，准确的量化和驱动业务。

但是很多数据分析人员由于“离数据太近，离业务太远”而往往很难厘清数据背后的业务流程。针对这个难题，我们通过指标系统“业务过程”这个模块，帮助数据分析人员去做业务和数据调研，发现业务和数据之间的关联关系，真正做到“用数据描述和驱动业务”。

五、总结

数仓工作中最难的部分并非涉及编码的 ETL 开发工作，而是如何从繁杂的中寻找到准确、可信的数据，并用这些数据来准确的描述业务，或者说将业务流程转化为数据流程。因此，我们遵从“工作流程化、流程工具化”的原则，以系统的形式将这部分工作规范起来，实现了业务数据调研、指标定义与应用的标准化收口，带来了以下收益：

• 降低了数据调研成本，将调研成果以更为友好的方式呈现出来，让数据人员更懂业务、业务人员轻松了解数据。
• 指标定义流程与数仓“维度建模”理论高度吻合，实现了业务模型与数据模型的统一。
• 降低了数据使用成本，减少了指标冗余，提升了数据开发与运维效率。

作者简介

Chao，携程资深数据分析经理，关注数据治理、数据仓库和数据分析领域。致力于数据使用效率及价值提升。

本文转载自：携程技术（ID：ctriptech）

原文链接：干货 | 用数据描述和驱动业务，携程指标标准化管理实践