数据质量管理理论大纲与实践

2022-12-05 13:14 浏览量:491

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

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

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

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

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

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

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

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

 

01 关于数据质量期望

 
 

 

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

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

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

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

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

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

第一组:获得质量期望

 

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

 

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

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

 

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

质量期望的沟通,在什么时机最合适?

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

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

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

 

02 关于数据质量测量

 
 

 

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

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

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

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

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

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

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

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

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

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

 

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

 

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

比如【传输丢失率<某阈值】这条规则中,【传输丢失率】为规则指标,【<某阈值】为规则判定。

规则指标分类及举例:

 

规则判定分类:

 

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

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

 

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

初始化测量:

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

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

验收测量:

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

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

生产测量:

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

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

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

 

03 关于数据质量保障

 
 

 

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

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

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

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

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

 

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

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

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

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

在这个case中:

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

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

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

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

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

 

1)流程保障

为何要有流程?

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

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

数据准入:

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

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

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

经由准入流程分配的属性值,须做双向绑定验证(上报侧与埋点管理侧)。

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

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

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

 

发布变更:

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

 

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

 

2)制度保障

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

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

我们对分级的定义,会从以下几个方面来评估:

涉及财报、营收、资损

涉及业务重大决策

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

涉及有关部门监管内容

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

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

资损的量级

客诉的量级

数据异常的幅度和时长

数据的可恢复性

数据异常的影响PV、UV

数据修复的人力工时成本

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

3)监控保障

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

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

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

2. 测量:即我们在前文所指的质量测量;

3. 督促:促使相关责任方去处理问题;

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

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

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

 

4)资源保障

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

物理资源:CPU和内存,磁盘容量,带宽等。

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

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

 

把上述四类保障建设完成,那么我们的数据质量保障体系就完成了从「0」到「1」的过程。

 

04 关于数据质量运营

 
 

 

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

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

发现异常

拦截异常

处理异常

由此可见,它的基础标准应当是:

确实发现了异常

确实拦截了异常

确实处理了异常

以达到最终节点规避异常的目的。

 

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

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

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

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

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

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

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

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

 

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

降低事故损失

提升保障效率

 

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

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

 

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

(一)制定保障标准

标准是一个执行参照。

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

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

服务SLA标准

测试/监控覆盖标准

异常响应时效标准

资源划分标准

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

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

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

(二)设计执行策略的具体规则

规则是标准展开的细则。

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

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

10分钟内无响应,会上升至技术LD;

收到告警后,先通知到能够做灾备切换的人员(最快、最短链路),再将信息同步到该项目的应急响应群;

异常处理人说明异常原因,评估修复耗时;

根据该项目的灾备启动条件,灾备执行人判断是否启动灾备方案;

修复问题;

切回主方案。

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

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

需要有全链路的监控覆盖

需要有灾备方案

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

(三)提供工具能力

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

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

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

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

 

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

 

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

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

 

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

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

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

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

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

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

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

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

标准:定义有效告警的标准

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

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

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

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

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

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

误告:未命中规则,工具误触发告警。

告警缺失:发生异常,但无告警。

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

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

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

 

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

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

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

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

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

来源:数据社

上一篇:有效的数据治理,元数据该怎么管?

下一篇:告诉老默,我想要数据治理的“杀手级应用”

  • 分享:
龙石数据
咨询电话: 0512-87811036,18013092598
联系我们
商务联系微信

商务联系微信

0512-87811036,

18013092598

咨询电话