数据治理实践——YY 直播业务指标治理实践

一、问题背景

1.1 问题场景

1.2 问题小结

二、治理方案

2.1 治理目标

2.2 团队协同，共建规范

2.3 指标管理的定位

2.4 指标管理的目标及思路

2.5 指标管理，规范内容落地

2.6 数仓设计-关联指标维度

2.7 数据报表开发-配置口径说明

2.8 业务用户检索数据资产

2.9 指标自主分析

2.10 业务指标治理全流程回顾

三、治理成效

四、未来演进

原文大佬的这篇指标治理实践有借鉴意义，这里摘抄下来用作学习和知识沉淀。

一、问题背景

1.1 问题场景

第一部分，我们先来还原一下问题的场景：这几个场景是我们数据需求方，比如产品、运营、数据分析师及技术开发工程等角色给我们反馈的主要问题：

场景一，报表数据口径差异：我们的需求方经常会跟我们咨询，“为什么a报表和bb报表命名和描述是差不多的，但是出来的数据不一样，那到底哪一个报表的口径才是准确的？”
场景二，找不到想要的数据：我们在对接需求方的需求时，经常会发现报表系统中已经有了现成的报表或者数据看板，但是类似的需求还是会被重复地提过来，沟通下来发现是因为需求方无法快速找到自己想要的数据。
场景三，新增报表的需求排期太长：从业务方的体感来讲，一个新增的报表需求通常需要排期短则数天，长则要一两周才能交付。

1.2 问题小结

带着这些问题，从我们数据产品的视角深入分析，得到以下几个总结：

指标管理层面：因为没有对指标进行统一管理，必然会存在同名不同义或同义不同名；指标口径描述基本分散在报表的备注信息里，没有一个统一功能页面来检索查找指标，更谈不上指标的统一分类层级。
数据报表层面：因为互联网业务发展特别快，我们大量的报表都是由业务方根据他们当时的取数需求驱动来构建的，这些报表从来不考虑生命周期管理，时间一长就造成了线上的大量报表无序堆积，用户在检索存量报表时很难找到目标数据。
数据模型的层面：普通存在同样的指标，但计算口径不一致的现象；部分核心模型对应计算任务的依赖关系极其复杂；这导致要迭代模型中的指标或维度时会相当困难。

总结以上问题，我们的理解是：业务在高速发展阶段，其快速地响应业务方需求的优先级是最高的，而指标体系的总体规划和体系化建设则放在比较低的优先级。

我们要做就是规划并重构一套相对规范的业务指标管理体系，做到既能适业发展节奏、高效地满足需求；同时也能减少重复建设，提高产研效率。

二、治理方案

2.1 治理目标

在展开具体方案之前，先说一下我们的治理目标。

在用数体验方面：希望给用户提供“规范统一”的指标体系，并且具备“快速检索”的能力；
在产研效率方面：希望能显著的提升交付效率；
在资源消耗方面：希望能降低计算及存储资源的无序增长。

用数体验的提升能够最明显地提升业务方的感知。其次提高产研效率也能改善业务方的实际体验。虽然资源消耗降低这一目标的实施难度最大，但在当前行业环境下里，我们需要做到既增效，又降本。

2.2 团队协同，共建规范

要完成上述的目标，需要多团队进行协作投入，这里列举一些主要的角色及实施内容：

数据产品，毫无疑问是整个工作的牵头者，指标管理这个环节的 owner，负责梳理迭代指标、构建指标体系、同时还要推动其他团队形成统一的认知，统一管理思路。
数据研发，是整个数据生产和报表开发交付环节的owner，负责将规范化的指标体系应用到数据模型构建发布、数据报表及看板开发迭代的工作中。
业务用户，在数据地图和数据洞察中触达数据资产，包括数据模型和数据报表；需要他们在使用中及时反馈，来帮助产研团队持续迭代优化指标规范。

2.3 指标管理的定位

下图就是我们 YY 自研大数据平台的产品功能框架简版。

这里主要讲两点：

从流程管理的角度来看，指标定义及维度定义的管理是放到数据开发及报表开发的环节之前的，是数据开发及报表开发等工作开展的前置条件。

从数据流向的角度来看，指标管理系统提供统一的指标口径信息服务，对接数据开发、数据治理及数据分析系统：一是用来配置数据模型中的字段定义；二是用来配置数据报表中的口径说明。而数据消费用户群体是在数据地图和数据洞察中接触到这些信息。

整体来说，我们希望从数据产品的角度，以业务指标管理为治理抓手，将规范化的指标体系贯穿到数据生产及数据消费的环节。下面我们围绕这些主要的角色，讲一下在整个过程中的具体策略、使用的一些工具以及实操步骤。

2.4 指标管理的目标及思路

首先如图所示：首先是数据产品负责的指标管理环节，从管理目标出发：

第一点是如何构建一套指标的命名和描述规范；
第二点是如何能够形成清晰易检索的指标分类；
第三点是如何能够梳理清晰指标间的依赖和继承关系；
最后一点就是如何能让指标的生命周期管理运转起来。

上图右侧是我们具体的数据产品的实施步骤。

具体实施步骤和目标拆解为：

第一步，梳理指标命名及定义，作为规范共识的讨论基础；
第二步，构建指标的分类索引，方便后续用户快速检索指标；
第三步，配置指标间依赖关系，让用户能清晰地了解指标间的来源及继承关系。

这样实施下来，就形成初步的指标说明文档，以这些文档为基础，就可以开展讨论。

而达成共识的推进策略可以拆解成以下步骤：

第一步，数据产品团队内部互评互验，针对命名规范、描述规范、分类规范进行充分讨论和碰撞，形成大家都认可的落地规范；
第二步，数据产品与数据研发进行跨团队评审校验，形成数据产研团队间的共识及规范，使得大家对业务语义的认知是一致的；
第三步，数据产品将规范后的指标体系应用在数据需求对接流程中；

比如说，我们会要求业务用户在提需求前，先检索一下数据地图，看是否能找到想要的指标，当前版本的业务定义是否能满足需求？是否要迭代当前版本的定义？是否要新增全新的指标或维度？

最后还要考虑指标的生命周期管理机制。比如梳理了存量指标，还会有新增的，得把生命周期机制运转起来。按照先登记，然后评审，接下来系统间去引用，出现了口径变化就迭代，如果整个业务场景已经不再用该指标了，就通过一些技术手段或者管理手段让该指标下线。（变更迭代---> 评审上线---> 下线）

以上，我们都会落地相应的产品功能，去把整个管理流程去给固化下来。

2.5 指标管理，规范内容落地

接下来介绍一下数据产品经理在这一阶段的具体的一些产出结果。

第一部分是层级分类：指标的分类至少会分成三个层级，第一层先划分相对独立的业务域，在业务域下面再划分业务过程、业务子过程。

为什么这么划？数据分析师有自己的分类规则，数据研发也有自己的分类规则。从分析师角度来看，一般按OSM原则去建立指标体系，但是从数据研发的角度出发，数据应该基于实体领域去分类，这样大家无法达成共识。由于我们层级分类的目标是服务于指标检索的，那么层级分类要按照大家能够公认的规则划分。如还原实际的用户路径，包括用户怎么观看直播，怎么打赏，主播怎么开播，怎么签约，怎么获得收入，按照客观的业务过程去划分这个指标集。后续用户通过这套层级分类去检索指标时，仅凭非常简单的直播业务常识，就能快速找到对应指标。

第二部分是关于命名规范或描述规范的撰写。之前做了很多调研，也找了其他团队进行交流。大家的共识是，要非常严谨的描述是很难实施推广的。因此我们定下一些底线的原则，先给出一些参考案例，指标名称，通过业务限定加原子指标的组合方式命名，但是同时要保留一些细节，比如原先指标的常用命名，把它作为别名信息保存下来，后续检索时虽然指标名字可能换了一个相对正式规范的名字，但是用户还是可以通过别名去找到想要的指标。同样，描述也尽可能按照业务场景加业务限定加度量加聚合方式的方式去描写，出来的结果看起来就比较规范，给人感觉是一个团队做的事情，而不是各干各的。同样地，维度名称、维度的描述以及枚举值也要按同样的方式统一规范地管理起来。

第三部分就是指标血缘，使用可视化的方式去把指标间的依赖关系以及继承关系给表达出来。如图中截图所示，指标 c 就是由指标a和指标b复合生成的。只要把指标 a 和指标 b 的业务定义描述清楚，通过指标血缘追溯下来，那指标 c 也是非常清晰的。

以上就是第一阶段在指标管理环节的具体产出。

2.6 数仓设计-关联指标维度

接下来就需要数据研发上场了，他们需要在数据生产环节中规范引用的指标和维度。

第一个场景中，数据研发在进行数据模型设计时，关联引用规范的指标和维度作为字段的标准定义。第二个场景中，是在规范化工作建设之前有很多存量模型，筛选梳理出来有复用价值的模型，使用数据发布功能，关联规范的指标和维度，然后发布到数据地图上面供用户去检索使用。

2.7 数据报表开发-配置口径说明

在数据报表开发时，需要写清楚每个指标的定义口径以及说明。原先的功能是使用输入框，开发人员在输入框中输入。现在改变方式，能选的尽量去选。根据这个原则提供弹窗，用户直接规范的指标定义。要迭代某一个指标或者维度的定义，只需要在指标管理系统里进行发版迭代，所有的引用都会同步更新。

2.8 业务用户检索数据资产

做了这么多工作，目的都是服务于业务。从业务用户的视角来看，除了可以通过报表和数据模型的字段信息了解到规范的指标体系，还可以通过指标检索的方式查找可用的数据资源。如下图所示，是指标详情页的截图：

在指标粒度Tab里，可以看到所有引用这个指标的数据模型，结合维度组合进一步筛选，可以找到特定维度组合的模型，进一步自助分析取数。

在引用报表Tab里，可以看到所有引用这个指标的报表，进一步点击查看报表，就进入报表的详情页。

通过向用户推广这种数据资产检索的方式，基本上解决了口径不一致的问题以及不容易找到想要的数据的问题。以上这些是关于指标治理的一个基础过程。

2.9 指标自主分析

为了进一步提升业务用户的用数体验。我们去构建了一个指标自助分析应用。依托可视化分析能力，构建了一个低门槛、可视化的分析应用。

用户只需要去选指标定维度就完成需求输入了。以前还需要先找报表和数据模型，现在只需要选择想要的指标，确定分析维度，剩下来就可以交给系统，系统会自动匹配数据模型或视图，然后自动地拼接生成查询 SQL，最后进行自助取数和可视化分析来满足用户的需求。从流程来看的话，用户很大一部分场景的需求不再依赖研发排期了，可以自助完成，效率提升是非常明显。用户具体是怎么操作这个功能的？这里放了一些功能截图。

第一步，系统提供了划分层级的指标卡列表，右下角有一个购物车，用户可以通过层级分类查找指标，关键字搜索指标，找到目标指标后，单击指标卡上的加入购物车功能。

第二步，所有想要的指标之后，点击购物车就进入下一级页面，在这个页面里选定分析维度，临时提供不了的分析维度，可以提需求来去添加。

接下来确定数据的时间范围。点击可视化分析按钮，系统就会拉起一个可视化分析的页面，用户可以在这里进行拖拉拽，使用可视化图表组件进行分析，可以把分析图表导出贴到报告上，也可以把数据导出再加工。

相较于其他数据的检索方式来说，这个应用操作上会更加直观简单，效率和体验上也会更优。

2.10 业务指标治理全流程回顾

第一步，由数据产品牵头进行指标统一管理，聚焦在业务语义层面梳理和分类构建，并推进团队间形成统一管理，规范共识；

第二步，由数据研发牵头对存量的数据资产进行盘点，包括数据模型，数据报表的盘点，使用统一指标命名和定义说明关联；

第三步，重构业务指标的管理流程，遵循“先登记后引用”的基本原则，加强生命周期管理，重构数据需求的对接生产流程；

在这个基础上，数据产品牵头对数据报表进行体系化重构，主要整合原有报表，搭建体系化数据分析看板等；

与此同时构建指标自助分析应用，用于满足大部分用户自助取数及可视化分析的需求。整个过程中持续收集数据用户的反馈，形成闭环。

三、治理成效

接下来我们简单叙述一下，这几年的具体工作成效。

用数体验方面，因为有了体系化的指标，可以用帮助用户快速检索以及自助分析取数，效率显著提升；
产研效率方面，通过优化检索的方式，避免了很多重复需求的对接和开发，并且把部分需求的开发交付周期由天级下降到小时级，产研效率的提升也是很明显的；
最后是比较难的目标，得益于整合下线大量的长尾数据报表、数据模型及计算任务，同时辅以其它技术手段也达成了降低资源无序增长的目标。

四、未来演进

大语言模型表现出来的语义理解和输出能力是极其强大的，现在业界有各种方案的，我们的实践就是通过一个行业知识库结合大语言模型来实现。

如图所示：

知识库数据可以由指标的业务定义、计算口径、呈现方式及分析场景等构成，通过上述的指标治理工作，这些数据已经进行了有效的收集和关联。结合知识库，基于 LLM 的多轮对话能力，系统应该能更好地理解用户的数据分析需求。接下来，使用 LLM 的格式化输出能力对接下游的执行器，比如：计算 SQL 对接 olap 引擎进行数据查询，图表推荐对接可视化引擎进行图表选择及数据渲染，布局推荐对接可视化看板进行图表组件的布局排版。最终生成一个完整的分析报表呈现给用户，还可以进一步收集用户的反馈，去持续迭代知识库的内容。

参考文章：

YY 直播业务指标治理实践