B站的数据质量管理——理论大纲与实践

故事的开头，是一位业务部门的同事找到我们，咨询了一个经典问题：

「需求方经常说我们做的报表看起来数据不准，有什么办法吗？」

为了解释这个问题，我以我们团队在数据质量管理中积累下来的方法，为他写下四行字：

• 数据质量期望——业务需求想要把数据质量保障到什么样的标准

• 数据质量测量——怎么评估数据质量水平的高低、是否达到标准

• 数据质量保障——为提升质量水平，达到质量期望，具体的保障实施动作和内容

• 数据质量运营——如何通过数据化运营，提高保障的成果与效率

这四行字，概括了我们在数据质量管理执行中的理论大纲。

「你在需求沟通时，了解对方的数据质量期望么？」

数据质量是由需求定义的。它没有绝对的对与错，只有定性、定量的标准。我们需要事先了解需求方的质量期望，才能与需求方就「质量达标」的标准达成细节上的共识。

我举个例子，我们经常遇到一种情况：我们明知这份数据存在问题，但依然选择使用它。只要我们把这份数据的问题点抛出，下游消费者理解并接受它的问题、并做好兜底方案即可。这种方式，是通过主动降低质量期望来避免数据事故。

要如何知晓对方的质量期望？

最好不要直接询问：「你需要怎样的保障，怎样的监控？」因为需求方不一定是专业的开发人士，他们可能会遗漏，或者，他们无法用运维语言来表达。

于是我们设计了以下三组问题，在日常的数据需求沟通中，主动向需求方提问确认：

第一组：获得质量期望

第二组：评估可能存在的风险

当然，对于风险的评估，上述问题只是冰山一角。

第三组：与需求方沟通一下业务知识认知

这些问题很容易想当然，同时，也是相当致命的。比如说，需求方需要视频稿件的CTR，恰巧我们早已做好了CTR指标，便直接提供给他使用了。但如果这位需求方理解的CTR和我们的统计口径不一致呢？他得到了他期望的数据吗？

质量期望的沟通，在什么时机最合适？

从实践中我们得出，获得质量期望的最佳时机，是在需求沟通阶段。这个阶段还没有大量资源、人力的投入，发生需求变故的成本最小。

所以我们将质量期望的信息收集安排在需求预审环节。把上述三类问题组织成一个预审沟通模板，要求每一位参与需求预审的数据开发人员养成询问质量期望的习惯。

经此沟通，能够让需求方有准确的业务认知，能够建立我们与需求方、上游业务研发、下游消费者之间的质量期望与风险知晓的共识，能够引导需求方降低质量期望，或引导业务研发消除当前的风险。

「你知道怎么评估数据质量水平的高低，判断质量是否达标吗？」

既然数据质量没有绝对的对与错，只有可定性、定量的标准。那么表达数据质量水平的方法，就是与标准所包含的规则做测量对比。可以称之为数据质量测量。

既然要测量，我们首先要先设计测量规则。

规则的设计，决定了我们在质量测量过程中——能够发现哪些问题、不能发现哪些问题。我们首先要明确哪些问题的暴露是需要的，哪些是不需要的。我们将规则拆分为基础规则与个性化规则。

基础规则：指可对大部分数据通用的规则。如，条数为0监控、主键重复监控等，这类异常在大部分场景都应当被暴露。

基础规则通常无须自行设计，平台会提供统一的配置，来保障基础规则的覆盖。

个性化规则：指每一份数据根据实际用数情况，做针对性设计的规则。

个性化规则要从质量期望中去提炼。我们用一个真实（经脱敏修饰）的质量期望案例来说明这个提炼过程。

我们有一份源自客户端上报的【业务对象曝光与点击日志】，它的下游消费者众多，我们从消费者的质量期望中合并出一份最高期望（取规则的并集，且每个规则取要求最高的一项）。

【业务对象曝光与点击日志】质量期望与规则提炼实例：

总得来说，质量期望一般来源于（1）场景和对象的特殊性、（2）业务流程和数据生产逻辑、（3）数据标准、（4）数据自身特点、（5）某时某地的业务背景。所以我们的测量规则也基于这些提炼。

规则又可以拆解为两个部分：规则指标、规则判定。

比如【传输丢失率

规则指标分类及举例：

规则判定分类：

设计好规则，还要明确在什么时机做质量测量。

我们把测量的时机分成三种，对应三种测量形式：初始化测量、验收测量、生产测量。

为了让这三种时机融入到团队的开发工作中，我们将这三个时机与数据需求管理的流转步骤挂钩，要求需求流转的交付内容中包含三次测量的执行报告。

• 初始化测量：

  发生在数据需求的预审期、或开发前期。以一次性数据探查的形式，探查一份新数据、或老数据的新属性存在的潜在风险。这些风险可能是业务逻辑中的缺陷、或者未做标准化定义的隐患等，所以我们除了关注数据自身的测量结果，还要关注文档等上游信息输入。

  初始化测量，帮助我们规避低质量数据输入到我们的生产链路。

• 验收测量：

  发生在数据需求的验收期。不但全新的数据需要全方位验收，变更需求同样需要。根据我们的事故经验，超过90%的数据质量事故，是由变更发布带来的。

  验收测量，帮助我们规避变更发布带来的数据异常。

• 生产测量：

  生产测量的配置和首次执行发生在需求交付前观察期，日常执行发生在交付后的日常生产过程中。稳定的生产链路理论上有稳定的质量，但不可忽视偶发性的不稳定问题，比如底层组件异常、调度服务异常等。

  生产测量，帮助我们规避外界偶发性问题影响数据的产出。

有了质量测量，我们可以随时通过规则的统计与判定，来长期监控质量水平、及时发现异常问题。

「如果质量测量的结果不理想，要做哪些事才能提升质量水平？」

数据质量水平的提升，是经由数据质量保障的实施才能实现的。这个「保障」具体要保障什么？做哪些事来保障？

质量测量的规则是根据质量期望来设计，那么相应的，测量报告中的指标异常，也要能告诉大家哪一条期望没有达标。我们应当先针对未达标的期望来做保障的实施。

我们延续上一小节的【业务对象曝光与点击日志】，来说明发现问题后保障实施的过程。

在质量期望中，对f5这个属性有这样一条期望描述：

而在真实的数据中，测量报告表明f5属性的质量并没有达到期望。即，f5这个属性存在大量空值。

由于这是数据源日志，尚未经过ETL处理，可认为f5属性异常发生在数据上报和数据集成接收的环节，再加上其他判断条件，我们基本认定这个异常发生在上报环节。通过对异常数据的统计分析，进一步定位到这个异常只发生在某几个页面，其余页面都是正常的。接下来，我们就要做两项实施来修复异常且使它不再发生：

1. 根据埋点异常修复流程，由客户端修复这个上报异常。

2. 在测试环节补充这条测试用例，在后续的变更中，可通过该测试用例阻截异常。

在这个case中：

首先，我们有质量测量来监控数据的质量水平；

其次，我们有异常修复流程来修复它，解决本次问题，也有变更流程来测试它，避免同样的问题再次发生；

接着，我们有明确的责任制度，在上述流程中，各个责任方知晓自己的执行责任；

最后，我们的各个责任方，有拨冗相应的人力工时资源，来将这个埋点的监控、修复、测试工作落地。

我习惯将质量保障的实施分为四个类别，缺一不可。

1）流程保障

为何要有流程？

在安全管理领域，极度注重标准操作流程的制定和实施。飞机乘务员关闭舱门的操作、化工厂转运化学品的操作，都有严格的标准操作流程，而这些流程强大到能够保障人员的生命安全。可见，流程保障是一种强有力的保障措施。

在我们的流程保障中，需要重点讲述的是数据准入、发布变更这两个流程。

数据准入：

曾经发生过一个case，有一个新的产品A，在做埋点上报开发时，直接copy了另一个产品B的上报脚本，导致用以区分这两个产品的关键属性appid上报为同一个值，从而影响了产品B的核心指标。

在这次case的复盘中，我们提出，任由一个新产品、新场景随意接入既存的重要埋点，显然是不合适的。因此我们建立了数据准入流程。

准入流程的建立依赖几个必要条件：

1. 经由准入流程分配的属性值，须做双向绑定验证（上报侧与埋点管理侧）。

2. 经由准入流程分配的属性值，上报时须由SDK或公共组件（如播放器）收敛，不可由接入业务自行填值上报。

3. 未经准入的数据，须能限制上报、或在上报后被限制接收、使用。

最终实际的流程参考下图：

发布变更：

超过90%的数据质量事故是由变更带来的，这是我们在聊验收测量时提到的一个事实。为此，发布变更必须有一套流程来保障。

如图所示，是一个简略的埋点变更的流程。

2）制度保障

运维责任制度是必须存在的。它定义了每一份数据、每一类组件、每一项服务的责任归属认定逻辑，能够确保任何数据在各个环节都有其质量保障的执行负责人。

运维分级制度也是必须存在的。它定义了每一份数据在全生命周期的各个环节，能得到哪一层标准的保障，且高等级数据一定能获得比低等级数据更稳定的保障。

• 我们对分级的定义，会从以下几个方面来评估：

• 涉及财报、营收、资损

• 涉及业务重大决策

• 涉及线上功能服务与用户体验

• 涉及有关部门监管内容

事故处罚制度是可以选择的制度（当然我们推荐它存在）。它定义了异常发生后的过失成本。

我们的事故定义、事故等级的划分，会从多种指标来评估：

• 资损的量级

• 客诉的量级

• 数据异常的幅度和时长

• 数据的可恢复性

• 数据异常的影响PV、UV

• 数据修复的人力工时成本

此外，在新的周期，我们也吸收了前几个周期的经验，除了消极压力的处罚制度，还考虑增加积极鼓励的奖励制度。

3）监控保障

我们认为监控保障包含了四项工作：

1. 监视、监听：长时间观察数据生产的健康情况；

这个健康情况，包含大数据组件的稳定性、大数据资源使用用量、任务运行状态、数据产出结果的校验等。

2. 测量：即我们在前文所指的质量测量；

3. 督促：促使相关责任方去处理问题；

通常，通过群消息推送、企业微信告警、电话告警等不同等级的信息通知来实现。

4. 纠偏：辅助执行问题的处理。

告警原因分析、任务阻断等功能，就属于这一类。

4）资源保障

资源保障指的是针对不同运维等级的资源倾斜，且这里的资源包含两重意义：

• 物理资源：CPU和内存，磁盘容量，带宽等。

• 人力工时资源：测试、校验的执行排期、运维响应速度、异常修复顺序等。

继续回到【业务对象曝光与点击日志】这份数据，来看一看我们对它的上下游链路实施了哪些保障。

「单份数据可以人工跟进保障实施情况，但成千上万的数据，怎么知道每一份数据该怎么保障、有没有实施、实施效果好不好呢？」

我们来思考一下执行质量保障措施的目的是什么。质量保障的实施，其目的在于规避异常，它需要在每个上游环节中：

• 发现异常

• 拦截异常

• 处理异常

由此可见，它的基础标准应当是：

• 确实发现了异常

• 确实拦截了异常

• 确实处理了异常

我们继续思考，谁，在什么时机，通过什么方式，消耗多少人力工时，会造成多少损失？

任何一个人都希望能规避所有异常，且即使真的发生异常，也能在造成损失前处理完毕。那么，我们要进一步提升它的标准：

• 在有限的测试、验收工时里最大程度拦截异常发布

• 上游比下游先一步发现异常

• 异常的告警最早通知到能处理这个异常的人

• 在人力介入之前，系统率先自动拦截异常

• 处理人员以最短路径、最小成本处理异常

• 不让同样的问题再一次重复发生

可以看到，质量保障的基础要求体现在通过保障避免损失，进阶要求体现在保障效率的提升。我们由此得到数据质量运营的两个运营目标：

1. 降低事故损失

2. 提升保障效率

作为数据工作者，我们理所当然要通过数据化运营来实现我们的目标。为此，我们设计了质量运营的指标体系。

我们的质量运营指标体系是基于我们的治理指标体系建设模型，包含：治理目标、治理策略、治理评估。下述为我们最近几个周期质量运营指标体系的概图。

其中，治理策略矩阵代表着，我们需要对生命周期中每一个环节的事前、事中、事后，都去制定保障标准、设计执行策略的规则，以及提供相应的工具能力。

（一）制定保障标准

标准是一个执行参照。

告诉所有人怎样算达标，按什么流程最安全……等等。标准统一了我们在质量保障执行过程中的意识和行为，杜绝责任推诿。

保障标准来源于各类质量期望的汇总，其中公共的、通用的部分，应对所有用户公示。它可能会经历谈判、妥协，最终达成意见的一致。它包含并不限于：

• 服务SLA标准

• 测试/监控覆盖标准

• 异常响应时效标准

• 资源划分标准

标准需要分级，不同运维保障等级，映射到不同的保障标准值。

团队的人员精力、物理资源都是有限的，要在有限范围内保障最重要的部分。

比如我们在前文提到的【业务对象曝光与点击日志】这份数据，依照运维分级制度，属于P0级。作为P0等级的数据，其数据时效保障为1分，响应时效要求是15分钟。而其他P1级甚至更低等级的数据，时效标准就会逐级放低。

（二）设计执行策略的具体规则

规则是标准展开的细则。

比如我们将事件处理标准流程展开，当异常发生时，我们的标准流程是先止损、再修复。基于这个标准，假设【业务对象曝光与点击日志】这份数据在某个环节出现异常，我们的细化规则是：

1. 该环节的异常处理人必须直接收到告警，并在10分钟内响应；

2. 10分钟内无响应，会上升至技术LD；

3. 收到告警后，先通知到能够做灾备切换的人员（最快、最短链路），再将信息同步到该项目的应急响应群；

4. 异常处理人说明异常原因，评估修复耗时；

5. 根据该项目的灾备启动条件，灾备执行人判断是否启动灾备方案；

6. 修复问题；

7. 切回主方案。

这些规则使大家远离误操作，提高执行效率。也能让一个新人快速上手，降低执行难度。

另外从中我们也看到，这项事件处理规则有几个前提规则：

1. 需要有全链路的监控覆盖

2. 需要有灾备方案

3. 需要有告警升级机制和通知机制

（三）提供工具能力

目前，我们已经积累了一批工具，用于数据生命周期的各个环节，提供自动执行能力。

比如监控告警工具、基线管理工具、DQC管理工具、指标异动工具、运维操作工具等，可以在公众号的其他文章中获得详细了解。

策略的执行需要评估效果好坏，以随时调整策略规则、或改进工具能力。如何评估策略的执行效果，就需要我们做评估指标的设计。

评估指标的设计原则，一是必须从第一层目标指标拆解而来，二是能够暴露出现状中的问题点，三是能够评估治理策略的执行进度，四是能够评估效果收益。这样的设计，使运营工作处于一个从指标中发现问题-问题解决后体现在指标中的持续性循环中，不断逼近、最终完成目标。

在前面的质量运营指标体系概图中，我们先将目标指标（事故次数）拆解为与事故直接相关的事故定级指标。

定级指标的值幅度降低，则事故次数就降低。

那么，接下来我们要拆解定级指标的降低与哪些执行指标相关，这一步拆解，要与策略规则直接绑定。因为无法评估效果的规则，在执行上很难有说服力，不容易落地。

测试覆盖率，与测试用例的实施绑定；监控覆盖率，与监控配置的实施绑定；修复人时，与运维工具的提效优化绑定……诸如此类。

其中概念较抽象的指标，如监控覆盖率这一项，它贯穿全生命周期，且在不同环节有不同的口径定义。

比如在数据开发环节，我们要求所有P0级数据必须配置三大类监控告警（失败、延迟、内容异常），且告警形式为电话告警 + 部门内升级。这些配置规则缺一不可，只有全部完成，才计作这份数据的“监控覆盖完成”。通过每周审计监控覆盖率，来控制我们在数据开发环节的监控保障实施。

在这里，有一个告警有效性运营的真实案例，能够解释我们的数据化运营方式。

先介绍一下背景，我们认为，监控不是越多越好，且需要随着业务变化及时调整监控规则。告警太多，会干扰执行人员的运维关注点，对告警产生麻痹或抵触情绪，乃至错过关键告警，降低异常发现率。

我们首先要确定在这个运营事项中，一个可持续的循环是怎样的。根据前面提到的指标-问题-标准-实施循环图，我们简单列举一下这个循环：

• 指标：需要有指标来暴露无效、未响应、缺失、越级等告警缺陷

• 问题：将这些缺陷视为一个待治理的问题

• 标准：定义有效告警的标准

• 实施：制定降低告警缺陷、提升有效告警的策略

为了便于理解，我先解释一下告警效果的定义。

有效告警：命中规则，且确实命中异常，同时能促使处理人员快速介入。

无效告警：命中规则，但并未命中异常，通常是规则配错、或业务活动导致。

未响应告警：命中规则，且确实命中异常，但无人响应，或响应人员无法、无权介入处理。

越级告警：数据运维等级较低，但配置了标准较高的告警形式，使起夜次数虚高。

误告：未命中规则，工具误触发告警。

告警缺失：发生异常，但无告警。

第一步，制定告警反馈机制，督促owner对告警进行分级反馈。

第二步，建设告警模块的元数据主题数仓，制作告警缺陷统计报表，给出待治理明细清单，推送治理信息给清单中的数据owner。

第三步，制定有效告警标准、执行细则，督促owner给出治理优先级，确定短期长期治理目标。细则参考下图：

第四步，定期审计告警缺陷，更新待治理清单，分析执行进度、治理余量、新增量的情况，逐步完成头部高优的部分。

第五步，工具优化方案提出，阻截不合理新增量、自动化处理长尾余量部分。

经过一个季度的运营，我们的告警缺陷从每周2000+例降低到100例以下，极好地改善了异常遗漏、夜间起夜、告警反馈成本等问题。

至此，我们的数据质量管理理论大纲就基本讲述完毕了。而我们的数据质量管理必然还没有做到头，还有非常多的细节场景有待我们围绕这个大纲去逐个解决。

下个季度、下一年，我们会不断有新的质量话题拿出来讨论。也许可以扩展广度，比如将质量运营覆盖到链路更前端的业务数据；也许可以下探深度，对埋点、任务链路等具体的保障对象做专题展开。相信我们能做得更好。

以上是今天的分享内容，如果你有什么想法或疑问，欢迎大家在留言区与我们互动，如果喜欢本期内容的话，请给我们点个”在看”吧！