Fork me on GitHub

腾讯数据采集治理之质量篇-从合规到合理

以下文章来源于 https://zhuanlan.zhihu.com/p/680431007

导读数据采集从广义上讲就是将真实的客观世界数字化并记录下来,俗话说数据采集的深广准决定了数据应用的上限,所以数据治理要从采集源头开始。当前数据采集治理面临的最大挑战就是质量和效率,本文是质量篇,将深度剖析如何才能真正看清甚至掌控数据质量。本文先提出了一个将数据质量从合规提升到合理的观念,然后介绍了一套质量审查工具并解析其中的关键技术。

主要内容包括以下几个部分:

  1. 看清数据质量

  2. 质量审查工具体系

  3. 关键技术解析

  4. 总结展望

  5. Q&A

分享嘉宾|韩钰 腾讯 数据上报系统负责人

编辑整理|胡回

内容校对|李瑶

出品社区|DataFun


01看清数据质量

1.用一个 Case 看清数据质量



假设你是⼀位数据科学家,需要使⽤⼀个终端⾏为⽇志的公参 login_type(登录类型),除了参数的中英⽂名外,你对它⼀⽆所知,你想⽤但⼜担⼼质量问题,不太敢⽤,请问你会怎么做?

--- 请思考⼀下 ---

可能你的方式有很多,比如问人、查元数据平台、捞几条数据看看等。

而本文给出的⽅式是 ------ 利用可视化图表做质量审查:



这是一张参数 login_type 的枚举值占比的双端趋势百分比堆叠图,从图中我们可以看出:

  • 这个参数是枚举型,枚举值不多,含义都能猜得出来(例如微信、QQ、手机等)。
  • 在过去的⾄少两周内没有⼤的波动,趋势是比较稳定的。
  • 双端的分布也⼤致相同,但 Android ⼤写,iOS ⼩写,需要注意!

最终你可能会认识到:

  • 公参 login_type 是被认真填充的,语义明确,趋势稳定,但存在双端⼤⼩写不⼀致问题。
  • 不管你做出的是可用或不可用的决策(结果不重要),都是基于你对这个参数客观而真切的理解。这一份眼见为实的真切要胜过一切耳听为虚的疑虑**。**
  • 最关键的是:从⼀⽆所知到做出决策,整个过程可能不会超过两分钟~

为什么会那么快?------ 因为这张图看似简单,但其实它的信息密度很高,使你在不自觉间做了一次数据质量的合理分析。

2.数据质量的合规与合理

在数据领域,人们通常将数据质量分为五个评估维度:完整性、有效性、准确性、一致性和及时性。

而本文站在数据质量的认知维度,将它们归纳为:合规和合理,如图:



(及时性通常是在运维体系中监管,与数据内容无关,不在本文讨论范围。)

合规:

  • 合规就是符合设计者设定的规范
  • 完整性和有效性,其实都是检查数据是否合规。比如:参数是否必填?超出数值范围?超出枚举范围?。
  • 合规检查的结果通常是绝对的,对就是对,错就是错。我们甚⾄在⽣产数据之前就能定义好数据的规范。

合理:

  • 合理就是合乎常理,从各个⽅⾯都说得通,能自洽。
  • 准确性和⼀致性都需要通过数据分析来判断数据是否合理。这主要是因为我们不可能拿着数据去与客观实体做⼀⼀⽐对,只能从仅有的数据中找出⼀点蛛丝⻢迹。
  • 合理分析没有统⼀的标准,因为我们不可能把所有⽅⾯都验证个遍。结果也不像合规检查那样客观,往往只有深谙业务的"⾼⼿"才能发现一些不合理的"端倪"。

一些不合理的"端倪":

  • ⽐如某个元素的 CTR(点击 PV 与 曝光 PV 的比值)超过了 1,与常理不符。
  • ⼜⽐如某个点击事件的⼈均 PV,android ⽐ ios 多 10 倍,这与⼀般认知不符,很可能有⼀个端有问题。
  • 再⽐如某个⻚⾯的⼈均时⻓在最新的灰度版本中,⽐当前线上版本下降了50%,有问题的坏味道。

对于一份数据来说,合规是最低要求,但只有合规是远远不够的,还必须要合理。一份数据只有经历了来自各个方面的分析验证,才能说是合理的,我们也才有充足的信心相信它的质量是可靠的。

那么如何去做合理分析呢?------ 答应是借助质量审查工具体系。

02 质量审查工具体系



质量审查工具体系主要由 质量审查、智能判定、自助诊断 三部分组成,下面分别进行介绍。

  1. 质量审查:让人看清数据质量

(1)关键在于相对性

合理的关键在于强调相对性,一切合理性都来源于对比。

我们再次回顾这个 Case:



通过这张图,你内心中至少默默做了三次对比:

√ 内部对比:枚举值占比 TOP10,使你了解参数内部有哪些值以及它们的占比情况。

√ 日期对比:日环比、周同比,使你了解过去一段时间内趋势是否稳定。

√ 双端对比:Adnroid 与 iOS 之间是否存在差异,这里发现了不一致。

正是这些对比,使你对这个参数的质量轮廓有了一个比较全面的认识,也让你最终做出判断。

(其实还有一个外部对比,就是当前的分布情况与你过去的认知对比,是否依然合理。比如:_NULL 表示未登录,占比会那么高吗?)

所以,合理分析的过程其实就是不断对比的过程,而质量审查工具本质上就是一个方便快速对比的工具。

先来看一下质量审查的全景:



这样的可视化图表有几百张,展示的只是冰山一角,实际上我们每天产出几十万的指标,覆盖了全部终端的公参、事件、页面、元素以及它们的参数,还有后台上报,并已开始从质量领域延伸到成本和链路。

  • 一切可视化都是为了对比

前面提到一切合理性都来源于对比,那么在质量审查中一切可视化都是为了对比。

主要有:时间对比版本对比双端对比内部对比相关对比外部对比等等,你都能在上图中找到一些例子。

  • 只关心当下和未来

所有指标都只算线上主流版本最新灰度版本,灰度发布自动感知。

因为过去的已然无法改变,留下来只会干扰看清当下的质量。

(2)质检类型与质检指标

质量审查就像是给一份数据的健康体检报告,那么针对不同的数据,该如何规划体检项目呢?

这里我们引入质检类型质检指标。如图:



质检类型:

  • 数据类型是从存储角度看待数据,而质检类型是从质量角度。质检类型可由人工标注,或由自动探测工具完成初始打标。
  • 每个质检类型会对应若干质检指标,每个质检指标都会至少对应一张可视化图表,而它们是快速看清数据质量的关键。比如:


  • 质检类型是可以根据业务特点进行扩展的,比如:有效阅读时长型。

质检指标:

  • 质检指标的本质是质量特征,质检指标的生产过程其实就是数据质量领域的特征工程。
  • 对终端上报来讲,还有事件、页面、元素等级别的特定质检指标,比如:元素点击渗透率、页面进出残缺率。
  • 为什么质检指标多数都是 XX 率 或 XX 分布?------ 还是相对性,可以让不同体量的对象也能对比,比如灰度小流量与线上主流版本。
  1. 智能判定:让机器自动发现问题



我们先来看一些智能判定结果的示例,下图是某应用某天的结果列表:



每一行代表一个问题,可解读为:xx 应用的 xx 资源的 xx 质检指标,在 xx 这一天的 xx 端的 xx 版本中,通过 xx 思路 和 xx 算子 发现了问题。

  • 示例一:


问题:"Tab 按钮"元素的曝光区间分布,在 11.09 这一天的 Android 端的最新灰度 x.x 版本 中,通过灰度主流对比和曼哈顿距离算子发现了问题。

处理:经过业务的评估,当天的灰度中确实调整了该元素曝光策略,所以评估结论为"业务特性",处理方式为"不做处理"。

  • 示例二:




问题:"终端曝光失败"事件的渗透率,在 3.24 这一天的 android 端的主流版本中,通过主流日期对比和差值修正算子发现了问题。

处理:经过评估,这是一个纯技术故障,建工单并转给相关技术同学。(虽然有四个图,但判定只看渗透率,其他是用来辅助分析的)

(1)判定规则与判定库

智能判定的底层原理是:将质量审查中的对比想法转化为程序代码,让机器帮我们盯着。

基于此,我们设计了判定规则:



①判定思路(定义谁跟谁对比)

  • 主流日期环比:主流版本当天与过去 N 天均值对比,对于无版本或长期不发版的情况必不可少。
  • 灰度主流对比:当天灰度与当天主流对比,对于灰度早期发现问题很重要。
  • 灰度双端对比:当天灰度一端与当天主流另一端对比,发现双端不一致问题。
  • 灰度灰度对比(TBD):当天灰度与过去某一次类似的灰度对比,发现特殊灰度中的问题。

②判定算子 (定义如何对比)

  • 距离类算子:曼哈顿距离及其加权变种,适用于分布指标。
  • 对曼哈顿距离的直观理解:代表两种分布的差异程度,取值范围[0,2],0 表示完全一样,2 表示面目全非。
  • 比如:两个枚举值分布 { 1: 90%, 0: 10% } 与 { 1: 20%, 0: 50%, _NULL: 30% } 的距离 D = |0.9 -- 0.2| + |0.1 -- 0.5| + |0 -- 0.3| = 1.4
  • 差值类算子:差值修正及其加权变种,适用于比值指标。
  • 合规类算子:各种合规检查算子,用于需要绝对保障的地方。

③判定配置/阈值/门槛 (微调对比细节)

  • 配置:增加规则的灵活度和可复用度。
  • 阈值:三个阈值等级,提示/问题/致命。
  • 门槛:预设前置门槛条件,控制误报。

规则库是存放判定规则的地方,让规则可以共享复用,用户可以从中挑选或扩展成合适自己的规则。如图:



(2)有一点智能,但不多

没有 AI,没有机器学习,甚至连个周期函数都没有,为啥敢叫智能判定?

  • 因为在不扩展规则的情况下,不需要冷启动,直接从接收告警、评估处理开始,几乎零工作量就能获得一个还不错的质量助手。
  • 这要归功于强大的通用规则库,自动生成的通用规则覆盖了大部分资源的常见质量问题。
  • 没有引入 AI 是因为暂时不需要,当前规则的底层逻辑是对比,需要可解释性。很难想象拿到一个问题但是却无法跟开发同学解释。
  • 未来考虑引入 AI,一用于让规则模型更有想象空间,二用于自动生成和调优判定规则。

即使是加扩展规则,也是一件很简单的事情。

  • 忘记什么算子、阈值,只需定义出你关心的指标口径,比如 "非 wifi 下某场景某页面的视频播放拖动次数分布",然后一路默认配置下来,你就得到了一个还不错的自定义扩展规则。
  • 在未来的问题跟进中,你自然会学习如何去评估和改进它。

数据采集中智能判定的主要目标是:拨开业务运营波动的迷雾,发现属于数据采集的质量问题。这与业务运营指标监控不同点在于,后者主要目标是观察并找寻指标波动的相关性。

"迷雾"中,存在一些比较顽固的干扰因素:

  • 运营活动效应,比如:双 11 搞活动导致元素点击来源页占比剧烈变化。
  • 首灰当天效应,比如:下午发灰度只有半天的行为数据,对于一些早晚活跃的 App 来讲,人均 PV 会下降一半。
  • 灰度铁粉效应,比如:只在 App 铁杆粉丝群里发的灰度,这批用户活跃度比均值高很多。
  • 极端用户效应,比如:在流量很小的时候,一些作弊用户、测试账号等可能造成指标失真。

(3)关注准召率

召回率 是最终目标,但成败的关键却在准确率这就好像对于一个社交 App 来讲,日活跃用户数是业务目标,但决定 App 能不能起来的关键是留存率。

准确率达到 80% 之前,不要打扰,不要推广;达到 80% 之后,再琢磨如何提升召回。

提升召回率的主要手段,就是增加扩展规则,要结合业务特点,寻找泛化性,警惕过拟合,否则永远都是"事后诸葛亮"。

工具建设方最好也能对准召率负责,与业务站在一起,持续评估,持续改进。



(4)先做审查,再做判定

传统数据监控工具,通常具有告警准确率低、配置规则滞后的问题。通常会在某次线上故障之后补上一个监控规则,典型的事后诸葛亮。而若要强行给每份数据对象都配上监控,往往也都是盲配、瞎配。

本文提倡先做审查,再做判定,因为:

  • 在配判定之前先把数据质量看清楚,做到心中有数之后,再去配判定规则准确率才会高。
  • 智能判定只是把人的想法变成代码而已,如果一个问题连人在做质量审查时都看不出来,那机器也发现不了。
  • 对判定结果的评估,其实就是再一次审查,若没有审查也就没办法评估。
  1. 自助诊断:让人快速诊断问题



(1)一些有用的小工具

  • 对比工具

让用户可以自由对比任意两个质检指标,问题或许就在一次次对比中逐渐清晰。如图:



  • 维度下钻

可以按任意参数进行下钻,并且可视化(3D)。

  • 样本提取

每个问题给少量明细数据,作为快速参考。

  • SQL 模版

自动生成多种 SQL 查询模版,让非数据同学也能快速上手分析数据。

(2)用户行为诊断

有一些疑难杂症,到最后必须要追踪单个用户的具体行为才能进一步诊断,这时候用户行为诊断就能派上用场。如图:



  • 可视化:以甘特图为基础,时间轴可以伸缩拖动,既能一览行为全貌,又能放大局部细节,同时还有联动的统计和明细数据,体验丝滑。
  • 应用场景:除了用于数据问题诊断,还可以追查如推荐问题、AB 实验问题、业务运营问题等。

03关键技术解析



在技术路线上,合理分析的技术要求更高,能力上是合规检查的超集,也理应走得更远。

  1. 样本库技术

基本原理:在接收网关中,按设备1%抽样并旁路到样本流,样本流落盘就是样本库。



样本库的关键在置信度:

  • 抽样是一门学问,就质量审查来讲,按设备抽样具有比较好的表现。对比全随机抽样和按设备抽样与原始数据的差异:


  • 总会有差异,简单量化,持续评估:置信度 = PV差值比较 * 50% + UV差值比较 * 50%
  • 若置信度最高到 99%,判定精度也只能到 1% (= 1 - 99%),不过在质量领域更在乎大局变化。
  • 后台上报多数都没有设备 ID,只能全随机抽样,置信度会差一点(具体情况具体分析)。

样本库的收益:

  • 样本库额外消耗主数仓约 1% 的资源,但换来的是大量的计算资源节省和查询速度,非常划算。单纯就质量审查一个项目,每天 10w 的计算任务,就已经够本且节省了大量资源。
  • 想象空间:数据分析时可先用样本库进行快速洞察,有眉目了再用原始数据给出准确结果;用于数仓加工的测试库;用户个人行为诊断等。
  • 强烈建议每个有一定规模的业务都应标配一个样本库。
  1. 三层分离架构

设计思路:把传统的监控规则一拆为三:计算规则、判定规则、告警规则,并以此扩展为三层分离架构。

设计原则:抽象、轻量、开放、面向全域数据的架构设计。



  • 计算层

职责:把各种介质的异构数据计算提取为无差别的质检指标。

最大挑战:利用计算同质化的特点,想尽办法(合并、编排、错峰、抽样、甚至边缘计算)最大幅度得降低成本。

无差别的质检指标 = 资源域 + 资源 ID + 指标域 + 指标 ID + 时间分区 + 各自不同的维度。

  • 判定层

职责:从各种质检指标中挖掘出数据问题,人来挖就是质量审查,机器来挖就是智能判定。

最大挑战:不断提升判定规则的表达能力,从而能跟上日益丰富的人类或 AI 的想象力。

  • 告警层

职责:把数据问题人性化地通知到各个生产方和消费方。

最大挑战:建立数据问题的收集、告警、跟进和度量体系,持续评估告警的回执率(消费方)和解决率(生产方),并赢得信任(=不放垃圾箱)。

  1. 判定引擎与指标存储

  • 判定引擎

第一代判定引擎,DSL 采用 Golang 的 gengine,并提供了在线编写、调试、管理、运维等配套功能。每天 60w+ 判定任务,表达力、性能、稳定性都不错。缺点在于:上手难度较大,不支持 ML。



未来第二代 DSL 或将直接用 Python 语言,支持安装第三方 Lib 和数据集,看起来 Jupyter 是个不错的编写和调试底座。

  • 指标存储


在众多时序数据库中,我们最终选择了腾讯云的 CTSDB(基于 ElasticSearch),除了稳定和高效的运维服务外,最打动我们的还是其 Schema Free 的设计。

04总结展望

本文介绍的质量审查思想以及工具,已在腾讯内部多个业务进行实践,正在发挥着越来越重要的作用,希望能给你带来一些启发~

以后有机会再分享数据采集治理中的效率篇,先展望一下:

  • 极致成本:分级上报 + 列式打包 + 配置下发
  • 上报模型:标准口径 + 参数级联 + 自动采集
  • 测试工具:可视化联调 + 实时校验 + 测试库
  • 流程效率:轻流程 + 清交付 + 智能面板

05Q&A

Q1:样本库的效果如何?主要是关于置信度的问题吗?在进行概率抽样时,如何判断抽取的数据是否存在问题?

A1:确实,样本库的效果主要体现在其置信度上。我们对置信度进行了简化的评估,虽然不可能对每一个维度进行详细评估,但根据我们的简化评估方法,当前样本库的置信度普遍超过 99%。这意味着,尽管概率抽样带来一定的不确定性,我们的样本库仍然能提供可信的结果,到目前为止,还没遇到过因样本库偏差而引起误报的案例。

当然,不同的业务场景可能对数据准确性和置信度有不同的要求。因此,这里提供的信息可以作为一种参考,具体应用时可能需要根据业务需求和环境进行专门的评估。

Q2:如何提升准召率中的准确率?

A2:这是一个很好的问题。实际上,提升准确率是一个颇具挑战的任务。我们知道,准确率和召回率不可能同时达到 100%,在优化过程中,需要平衡泛化性和准确性。

通常,在评估准确率时,我们不能仅仅看单一案例。如果只追求单一案例的 100% 准确率,可能会牺牲模型的泛化性。因此,我们需要从整体的角度进行评估和调整,寻求整体最优。

目前,调整准确率的基本方法是调整配置阈值和门槛。但要更深入地优化,就需要调整使用的算法。例如,我在演讲中提到的三类算法可能还需要进一步拓展。此外,还需要关注对比思路的变化,从数据的纷繁变化中找到不变的要素,这些不变的要素若发生变化,则可能指示着问题的存在。

总的来说,没有统一的标准来提升准确率,这需要我们根据经验和具体情况进行摸索和优化。往往既懂技术又熟悉业务的开发者能更好地处理这些问题。

以上就是本次分享的内容,谢谢大家。




本文地址:https://www.6aiq.com/article/1706532921516
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出