虎牙“数据服务+自助”产品化实践
导读： "数据服务+自助"产品是基于数据标准化去实现系统自动化生成代码，完成数据的落地生产。通过以上自动化的方式，降低数据使用和生产的门槛，让普通用户数据消费更简单。基于以上分享下虎牙在这方面的一些探索和实践，探讨企业未来数据服务的方向。
今天的介绍会围绕下面五点展开：
-
数据服务面临问题
-
怎样才是好的数据服务
-
数据自助产品
-
产品实践成果
-
后续演进
分享嘉宾｜邱智敏 虎牙 数据产品经理
编辑整理｜王凯慧 贝壳
出品社区｜DataFun
01/数据服务面临问题
首先和大家分享下数据服务面临的问题。
我们的数据服务主要是以人和平台的服务为主。人的服务是直接面向业务同学，为其完成报表建设、数据提取等业务需求。平台服务面向的是业务侧，为其提供分析型的数据产品，如 DAU、留存、用户画像以及竞品分析的平台型产品。在当前的数据服务中主要会有 3 个问题：
（1）及时性方面。数据需求难高效响应，数据获取周期长，业务无法快速获取数据决策；
（2）灵活性方面。数据分析门槛高且分析维度不灵活，一旦分析维度、指标发生变更，要重新提出需求；
（3）一致性方面。相同指标名口径不一，业务难甄别口径对错，数据可信度不高。
--
02/怎样才是好的数据服务
针对如上问题，我们会思考怎样才是好的数据服务？
**规范化定义指标。**指标口径是一致的，规范定义的，可被复用的，是规范定义指标的基石。
**自助式数据生产。**内容灵活多变的数据需求是能被快速响应的，数据生产使用门槛是比较低的。大多时候用户的数据需求在数仓中都有覆盖，但实际生产过程中，周期是较长的。可以说在数据生产的"最后一公里"，现有的数据方案仍是强依赖开发做数据搬运的工作，无法做到快速响应。
**自助服务多样化。**数据服务方式是多样的，能满足不同类型数据服务需求，比如报告、提数、数据对接等。产品化自助化是数据服务好坏的衡量标准。
--
03/数据自助产品
1. MVP 版本-数据自助
基于以上的思考，将过往对人和平台的服务，转变成围绕数据的服务。面向用户提供现有的维度和指标，让用户通过自助的方式去解决他的用数需求。进而推出了数据自助- MVP 版本，让零数据经验的用户可以轻松的查阅自己需要的维度和指标的数据。对于那些业务发展快速，数据诉求多变的情况，可以直接通过在平台上进行数据获取，减少数据排期的过程。缩短数据定义到数据生产到具体数据服务的时间。数据自助产品主流程共计 3 块：
（1）自定义指标。为用户提供标准化的指标定义模型；
（2）指标订阅。用户通过在产品上选择需要的指标和维度，即可生成一个订阅，系统自动构建调度任务完成数据生产；
（3）制作报表。针对具体的数据场景，通过现有的 BI 工具完成报表制作。
2. 项目挑战
① 面向零代码能力的产品运营人群，如何才能降低数据使用门槛？
在产品的搭建过程中，我们遇到了一些挑战，这里和大家分享下。首先就是如何做到低门槛。面对用户 SQL 能力低和数据表权限敏感等问题，将数据信息轻量化，转化为维度和指标。用户通过选择自己需要的维护和指标，即可获取数据内容，对应的底层就是数据表的表头。
② 维度和指标的数据从哪里来？
针对如上场景，最核心的问题就是数据如何获取。常规的做法是通过建设主题宽表、并搭配可视化工具来解决。但常规做法通常会遇到如下问题：
a. 用户分析维度指标多变，导致宽表粒度变更，需新建宽表来满足新需求；
b. 跨主题宽表的数据需求定制化强，强关联业务场景，且数据量大；
c. 指标口径变更频繁，且多用户多口径。
综上仍是强依赖于人的工作。所以我们提出一个设想，基于此去尝试自动化的数据生产是否可行？
③ 从什么视角切入来设计产品？
通过盘点近 200 个数据需求，在 5 个维度对需求进行分析：数据来源、应用场景、数据内容、指标定义、维度来源。基于分析我们发现以下 3 点：指标个性化程度高、指标定义逻辑固定、维度相对明确固定。如很多用户需要的就是某个端的 PV、UV 的数据，在客户端数据具备的情况下，用户事件模型会是比较好标准化定义指标的模型，能标准化格式化指标口径定义，让系统可识别。
④ 我们该打造怎样的一款产品？
首先是对需求的拆解：**提出需求、维度指标定义、定制数据 ETL 和个性数据服务。**在维度指标定义环节，抽象出元数据中心和指标系统模块；在定制数据 ETL 环节，抽象出指标订阅模块；在个性数据服务环节，抽象出自助服务模块。
3. 项目产出
① 数据产品架构概览
如上是产品的全景和流程。自下而上是元数据中心、指标系统、指标订阅和自助服务。
在元数据中心环节 ，通过对事件和维度的管理，实现对不同场景数据在同维度上的分析。同时提供衍生维度，用户可以通过正则解析的形式，将衍生维度解析出来。并支持多事件合并等场景。在指标系统和订阅环节 ，通过规范化定义指标，实现用户自助筛选指标，并完成订阅的过程。在自助服务环节，和公司内部系统打通，用户直接进行可视化数据操作。
② 产品实现细节
如上是客户端采集的事件明细数据。通过记录事件出发的时间、谁触发、在哪里触发、触发了什么、以及如何触发的信息。
③ 标准化指标定义模型概览
如上是标准化指标定义模型。以事件事实表为核心，通过不断补充主体维表扩展数据覆盖范围。进而在聚合指标、留存指标、二次聚合指标和指标四则运算角度完成标准化指标定义。
④ 指标定义过程拆解
如上是指标定义过程拆解概览。根据指标类型分为 4 部分。
a. 聚合指标定义。明确使用的事件、对象、方式和业务限定，即可生成对应的 SQL 逻辑，进而产出数据；
b. 留存指标定义。明确起始事件、留存事件和留存周期，即完成对留存指标的定义；
c. 二次聚合定义。是聚合指标的衍生指标，通过对聚合对象和方式的确认，完成二次聚合定义。
d. 指标四则运算。以 a/b 指标为例，去统计如事件的点击、曝光等数据。
⑤ 数据任务构建过程拆解
指标定义后，如果进行数据生产任务构建。核心是统一维度和指标，并通过元数据驱动数据生产进行任务构建。
Cube 元数据由四部分组成：基础信息、维度信息组合、指标信息组合、全局过滤条件限定组合，并支持数据访问权限控制。Cube 元数据在系统校验后，会生成实体表，例行构建任务作业、查阅数据集等。
--
04/产品实践成果
1. 业务层面
在当前业内，此类产品众多，虎牙自设计的数据自助产品效果如何呢？在业务层面，虎牙已经覆盖了 48% 的自助取数需求，且平均需求耗时控制在 16 分钟内。相较于传统的数据需求开发周期，极大的缩短了业务获取数据决策的时间。同时累计服务了 76 个用户，其中 90% 为产品运营人员，产品的使用门槛低。截止当前，自助产品累计创建指标量超过 2400 个，全自动化完成了 818 个数据集，并支持了 117 个报表数据消费。在业务用户层面收到了一致的好评！
2. 行业层面
在行业层面，数据自助产品开拓了一个新的方向。它在现有数据的基础上，借助工具在逻辑层面实现了维度和指标的统一。并围绕应用场景，简化数据建模过程，具备轻治理、短周期、低门槛的特性。同时产品加强了对元数据的约束管理，将指标定义标准化，实现了系统自动生成代码落地生产，摆脱手动作坊式的数据生产模式。最后是真正意义上让零数据开发经验的同学，可以通过简单的界面操作就可以独立完成"数据定义-数据生产-具体数据服务"，大大缩短业务获取数据的决策时间。
--
05/后续演进
虎牙的自助数据产品是 21 年建设的，为跑通产品流程，我们在很多方面做了取舍，下面几点是健全产品的设计方向：
（1）成本方面对算力的消耗。产品主要针对明细数据的扫描计算，面对直播行业本身数据体量庞大的特性。未来计划通过系统构建指标中间层，提高指标复用率，降低明细数据的重复运算。
（2）在效率方面，目前对复杂维度指标是很难覆盖的，**产品层面支持该类指标定义投入产出不高，计划通过数仓开播中间表维度指标接入模型，**助力复杂维度指标纳入自助范围。
（3）对数据质量监控上，在当前 MVP 版本产品中，已经完成了指标和维度的统一。从源头层对数据质量监控治理，无需在众多应用层设置质量监控。
（4）安全层面上，已经完成了统一的数据权限管理。在"数据生产"和"数据应用"的环节，集成统一数据权限卡控，实现一处定义，全局应用。
综上，即是虎牙在数据自助产品建设过程中的实践和总结。
--
06/问答环节
Q1：自定义指标让数据易用性很高，但现在很多业务和部门，针对同一个指标定义了不同的口径，这会导致多部门针对同一指标的看数结果不同，这类场景如何处理？
A1：这个问题在设计产品时也有考虑，在指标系统的层面会有一个强的系统校验。首先是对指标定义内容的强校验，如 A 用户和 B 用户针对同一个指标都进行定义，**系统会弹窗提示已经存在相同定义的某指标，请勿重复创建，确保指标不会被重复定义。**第二点是相同的指标名如果已经存在，是无法在系统上完成创建的。从而规避相同的指标不同的口径。
Q2：针对新的数字化转型的传统行业，数据自助这个模式能否适用？
A2：数字化转型的传统行业，相较于互联网企业，数据分散且数据规范标准不一。按传统模式治理转型，需要投入的人力及项目耗时都很长，往往是以年为单位。而数据自助这种模式，不局限于现有的数据质量，而是现有数据基础上进行元数据逻辑治理，并不改变原有的数据格式。比如 gid 和 gameid 是含义一样的，不需改动表物理层面的定义，而是在产品层面上标识逻辑一致，使系统可识别。同时借助数据自助这种生产模式，用户不用了解背后用的是什么表哪个字段，只需定义选择自己所需的维度指标并订阅，就可以解决自己的诉求。相对传统治理方式耗时长、人员要求高的缺点，会更加低门槛且见效快，企业自己的业务开发就可以完成这项工作。
Q3：超出我们产品之外的维度和指标，团队是如何进行高效的开发？
A3：这个问题主要涉及到我们的后续演进，对中间表的建设。在数据自助释放数仓很多面向应用数据需求的同时，数仓会更专注在中间模型上的开发，这类超出范围的复杂维度和指标将由数仓统一通用模型设计开发，降低开发复杂度。
今天的分享就到这里，谢谢大家。
分享嘉宾
**
