腾讯数据采集治理之质量篇-从合规到合理
1. 看清数据质量
2. 质量审查工具体系
3. 关键技术解析
4. 总结展望
5. Q&A
分享嘉宾|韩钰 腾讯 数据上报系统负责人
编辑整理|胡回
内容校对|李瑶
出品社区|DataFun
看清数据质量
1. 用一个 Case 看清数据质量
这个参数是枚举型,枚举值不多,含义都能猜得出来(例如微信、QQ、手机等)。 在过去的⾄少两周内没有⼤的波动,趋势是比较稳定的。 双端的分布也⼤致相同,但 Android ⼤写,iOS ⼩写,需要注意!
公参 login_type 是被认真填充的,语义明确,趋势稳定,但存在双端⼤⼩写不⼀致问题。 不管你做出的是可用或不可用的决策(结果不重要),都是基于你对这个参数客观而真切的理解。这一份眼见为实的真切要胜过一切耳听为虚的疑虑。 最关键的是:从⼀⽆所知到做出决策,整个过程可能不会超过两分钟~
2. 数据质量的合规与合理
在数据领域,人们通常将数据质量分为五个评估维度:完整性、有效性、准确性、一致性和及时性。
(及时性通常是在运维体系中监管,与数据内容无关,不在本文讨论范围。)
合规:
合规就是符合设计者设定的规范。
完整性和有效性,其实都是检查数据是否合规。比如:参数是否必填?超出数值范围?超出枚举范围?。
合规检查的结果通常是绝对的,对就是对,错就是错。我们甚⾄在⽣产数据之前就能定义好数据的规范。
合理:
合理就是合乎常理,从各个⽅⾯都说得通,能自洽。
准确性和⼀致性都需要通过数据分析来判断数据是否合理。这主要是因为我们不可能拿着数据去与客观实体做⼀⼀⽐对,只能从仅有的数据中找出⼀点蛛丝⻢迹。
合理分析没有统⼀的标准,因为我们不可能把所有⽅⾯都验证个遍。结果也不像合规检查那样客观,往往只有深谙业务的“⾼⼿”才能发现一些不合理的“端倪”。
一些不合理的“端倪”:
⽐如某个元素的 CTR(点击 PV 与 曝光 PV 的比值)超过了 1,与常理不符。
⼜⽐如某个点击事件的⼈均 PV,android ⽐ ios 多 10 倍,这与⼀般认知不符,很可能有⼀个端有问题。
再⽐如某个⻚⾯的⼈均时⻓在最新的灰度版本中,⽐当前线上版本下降了50%,有问题的坏味道。
02
质量审查工具体系
质量审查工具体系主要由 质量审查、智能判定、自助诊断 三部分组成,下面分别进行介绍。
1. 质量审查:让人看清数据质量
(1)关键在于相对性
通过这张图,你内心中至少默默做了三次对比:
√ 内部对比:枚举值占比 TOP10,使你了解参数内部有哪些值以及它们的占比情况。
√ 日期对比:日环比、周同比,使你了解过去一段时间内趋势是否稳定。
√ 双端对比:Adnroid 与 iOS 之间是否存在差异,这里发现了不一致。
正是这些对比,使你对这个参数的质量轮廓有了一个比较全面的认识,也让你最终做出判断。
(其实还有一个外部对比,就是当前的分布情况与你过去的认知对比,是否依然合理。比如:_NULL 表示未登录,占比会那么高吗?)
所以,合理分析的过程其实就是不断对比的过程,而质量审查工具本质上就是一个方便快速对比的工具。
先来看一下质量审查的全景:
这样的可视化图表有几百张,展示的只是冰山一角,实际上我们每天产出几十万的指标,覆盖了全部终端的公参、事件、页面、元素以及它们的参数,还有后台上报,并已开始从质量领域延伸到成本和链路。
一切可视化都是为了对比
前面提到一切合理性都来源于对比,那么在质量审查中一切可视化都是为了对比。
主要有:时间对比、版本对比、双端对比、内部对比、相关对比、外部对比等等,你都能在上图中找到一些例子。
只关心当下和未来
所有指标都只算线上主流版本和最新灰度版本,灰度发布自动感知。
因为过去的已然无法改变,留下来只会干扰看清当下的质量。
(2)质检类型与质检指标
质检类型:
数据类型是从存储角度看待数据,而质检类型是从质量角度。质检类型可由人工标注,或由自动探测工具完成初始打标。
每个质检类型会对应若干质检指标,每个质检指标都会至少对应一张可视化图表,而它们是快速看清数据质量的关键。比如:
质检类型是可以根据业务特点进行扩展的,比如:有效阅读时长型。
质检指标:
质检指标的本质是质量特征,质检指标的生产过程其实就是数据质量领域的特征工程。
对终端上报来讲,还有事件、页面、元素等级别的特定质检指标,比如:元素点击渗透率、页面进出残缺率。
为什么质检指标多数都是 XX 率 或 XX 分布?—— 还是相对性,可以让不同体量的对象也能对比,比如灰度小流量与线上主流版本。
2. 智能判定:让机器自动发现问题
我们先来看一些智能判定结果的示例,下图是某应用某天的结果列表:
每一行代表一个问题,可解读为:xx 应用的 xx 资源的 xx 质检指标,在 xx 这一天的 xx 端的 xx 版本中,通过 xx 思路 和 xx 算子 发现了问题。
示例一:
示例二:
问题:“终端曝光失败”事件的渗透率,在 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)先做审查,再做判定
在配判定之前先把数据质量看清楚,做到心中有数之后,再去配判定规则准确率才会高。 智能判定只是把人的想法变成代码而已,如果一个问题连人在做质量审查时都看不出来,那机器也发现不了。 对判定结果的评估,其实就是再一次审查,若没有审查也就没办法评估。
3. 自助诊断:让人快速诊断问题
(1)一些有用的小工具
对比工具
维度下钻
样本提取
SQL 模版
(2)用户行为诊断
可视化:以甘特图为基础,时间轴可以伸缩拖动,既能一览行为全貌,又能放大局部细节,同时还有联动的统计和明细数据,体验丝滑。 应用场景:除了用于数据问题诊断,还可以追查如推荐问题、AB 实验问题、业务运营问题等。
03
关键技术解析
在技术路线上,合理分析的技术要求更高,能力上是合规检查的超集,也理应走得更远。
1. 样本库技术
基本原理:在接收网关中,按设备1%抽样并旁路到样本流,样本流落盘就是样本库。
样本库的关键在置信度:
抽样是一门学问,就质量审查来讲,按设备抽样具有比较好的表现。对比全随机抽样和按设备抽样与原始数据的差异:
总会有差异,简单量化,持续评估:置信度 = PV差值比较 * 50% + UV差值比较 * 50% 若置信度最高到 99%,判定精度也只能到 1% (= 1 - 99%),不过在质量领域更在乎大局变化。 后台上报多数都没有设备 ID,只能全随机抽样,置信度会差一点(具体情况具体分析)。
样本库额外消耗主数仓约 1% 的资源,但换来的是大量的计算资源节省和查询速度,非常划算。单纯就质量审查一个项目,每天 10w 的计算任务,就已经够本且节省了大量资源。 想象空间:数据分析时可先用样本库进行快速洞察,有眉目了再用原始数据给出准确结果;用于数仓加工的测试库;用户个人行为诊断等。 强烈建议每个有一定规模的业务都应标配一个样本库。
2. 三层分离架构
设计思路:把传统的监控规则一拆为三:计算规则、判定规则、告警规则,并以此扩展为三层分离架构。
设计原则:抽象、轻量、开放、面向全域数据的架构设计。
计算层
判定层
告警层
3. 判定引擎与指标存储
判定引擎
指标存储
04
总结展望
本文介绍的质量审查思想以及工具,已在腾讯内部多个业务进行实践,正在发挥着越来越重要的作用,希望能给你带来一些启发~
以后有机会再分享数据采集治理中的效率篇,先展望一下:
极致成本:分级上报 + 列式打包 + 配置下发
上报模型:标准口径 + 参数级联 + 自动采集
测试工具:可视化联调 + 实时校验 + 测试库
流程效率:轻流程 + 清交付 + 智能面板
05
Q&A
Q1:样本库的效果如何?主要是关于置信度的问题吗?在进行概率抽样时,如何判断抽取的数据是否存在问题?
A1:确实,样本库的效果主要体现在其置信度上。我们对置信度进行了简化的评估,虽然不可能对每一个维度进行详细评估,但根据我们的简化评估方法,当前样本库的置信度普遍超过 99%。这意味着,尽管概率抽样带来一定的不确定性,我们的样本库仍然能提供可信的结果,到目前为止,还没遇到过因样本库偏差而引起误报的案例。
当然,不同的业务场景可能对数据准确性和置信度有不同的要求。因此,这里提供的信息可以作为一种参考,具体应用时可能需要根据业务需求和环境进行专门的评估。
Q2:如何提升准召率中的准确率?
A2:这是一个很好的问题。实际上,提升准确率是一个颇具挑战的任务。我们知道,准确率和召回率不可能同时达到 100%,在优化过程中,需要平衡泛化性和准确性。
通常,在评估准确率时,我们不能仅仅看单一案例。如果只追求单一案例的 100% 准确率,可能会牺牲模型的泛化性。因此,我们需要从整体的角度进行评估和调整,寻求整体最优。
目前,调整准确率的基本方法是调整配置阈值和门槛。但要更深入地优化,就需要调整使用的算法。例如,我在演讲中提到的三类算法可能还需要进一步拓展。此外,还需要关注对比思路的变化,从数据的纷繁变化中找到不变的要素,这些不变的要素若发生变化,则可能指示着问题的存在。
总的来说,没有统一的标准来提升准确率,这需要我们根据经验和具体情况进行摸索和优化。往往既懂技术又熟悉业务的开发者能更好地处理这些问题。
以上就是本次分享的内容,谢谢大家。
分享嘉宾
INTRODUCTION
韩钰
腾讯
数据上报系统负责人
硕士毕业于中国科学院计算机网络信息中心,曾先后就职于百度、滴滴、腾讯等公司,目前在腾讯数据中台负责数据上报系统,深耕数据采集治理,实现腾讯PCG的全业务覆盖。
往期推荐
教育领域大模型技术与应用
滴滴大数据资产治理实践
大数据 AI 一体化解读
风控也在用大模型了
张俊林:揭去神秘面纱,Sora关键技术逆向工程图解
【文末赠书】大语言模型训练优化秘籍
十分钟验证一个高性能车联网数据平台解决方案
当AIGC的风吹到了电商领域
OLTP&OLAP超融合,揭秘新一代云原生数据库的设计之道
快手BI大数据分析场景性能优化实践
NVIDIA大语言模型落地的全流程解析
点个在看你最好看