腾讯数据采集治理之质量篇-从合规到合理
导读数据采集从广义上讲就是将真实的客观世界数字化并记录下来，俗话说数据采集的深广准决定了数据应用的上限，所以数据治理要从采集源头开始。当前数据采集治理面临的最大挑战就是质量和效率，本文是质量篇，将深度剖析如何才能真正看清甚至掌控数据质量。本文先提出了一个将数据质量从合规提升到合理的观念，然后介绍了一套质量审查工具并解析其中的关键技术。
主要内容包括以下几个部分：
-
看清数据质量
-
质量审查工具体系
-
关键技术解析
-
总结展望
-
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）关键在于相对性
合理的关键在于强调相对性，一切合理性都来源于对比。
我们再次回顾这个 Case：
通过这张图，你内心中至少默默做了三次对比：
√ 内部对比：枚举值占比 TOP10，使你了解参数内部有哪些值以及它们的占比情况。
√ 日期对比：日环比、周同比，使你了解过去一段时间内趋势是否稳定。
√ 双端对比：Adnroid 与 iOS 之间是否存在差异，这里发现了不一致。
正是这些对比，使你对这个参数的质量轮廓有了一个比较全面的认识，也让你最终做出判断。
（其实还有一个外部对比，就是当前的分布情况与你过去的认知对比，是否依然合理。比如：_NULL 表示未登录，占比会那么高吗？）
所以，合理分析的过程其实就是不断对比的过程，而质量审查工具本质上就是一个方便快速对比的工具。
先来看一下质量审查的全景：
这样的可视化图表有几百张，展示的只是冰山一角，实际上我们每天产出几十万的指标，覆盖了全部终端的公参、事件、页面、元素以及它们的参数，还有后台上报，并已开始从质量领域延伸到成本和链路。
- 一切可视化都是为了对比
前面提到一切合理性都来源于对比，那么在质量审查中一切可视化都是为了对比。
主要有：时间对比 、版本对比 、双端对比 、内部对比 、相关对比 、外部对比等等，你都能在上图中找到一些例子。
- 只关心当下和未来
所有指标都只算线上主流版本 和最新灰度版本，灰度发布自动感知。
因为过去的已然无法改变，留下来只会干扰看清当下的质量。
（2）质检类型与质检指标
质量审查就像是给一份数据的健康体检报告，那么针对不同的数据，该如何规划体检项目呢？
这里我们引入质检类型 和质检指标。如图：
质检类型：
- 数据类型是从存储角度看待数据，而质检类型是从质量角度。质检类型可由人工标注，或由自动探测工具完成初始打标。
- 每个质检类型会对应若干质检指标，每个质检指标都会至少对应一张可视化图表，而它们是快速看清数据质量的关键。比如：
- 质检类型是可以根据业务特点进行扩展的，比如：有效阅读时长型。
质检指标：
- 质检指标的本质是质量特征，质检指标的生产过程其实就是数据质量领域的特征工程。
- 对终端上报来讲，还有事件、页面、元素等级别的特定质检指标，比如：元素点击渗透率、页面进出残缺率。
- 为什么质检指标多数都是 XX 率 或 XX 分布？------ 还是相对性，可以让不同体量的对象也能对比，比如灰度小流量与线上主流版本。
- 智能判定：让机器自动发现问题
我们先来看一些智能判定结果的示例，下图是某应用某天的结果列表：
每一行代表一个问题，可解读为：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）一些有用的小工具
- 对比工具
让用户可以自由对比任意两个质检指标，问题或许就在一次次对比中逐渐清晰。如图：
- 维度下钻
可以按任意参数进行下钻，并且可视化（3D）。
- 样本提取
每个问题给少量明细数据，作为快速参考。
- SQL 模版
自动生成多种 SQL 查询模版，让非数据同学也能快速上手分析数据。
（2）用户行为诊断
有一些疑难杂症，到最后必须要追踪单个用户的具体行为才能进一步诊断，这时候用户行为诊断就能派上用场。如图：
- 可视化：以甘特图为基础，时间轴可以伸缩拖动，既能一览行为全貌，又能放大局部细节，同时还有联动的统计和明细数据，体验丝滑。
- 应用场景：除了用于数据问题诊断，还可以追查如推荐问题、AB 实验问题、业务运营问题等。
03关键技术解析
在技术路线上，合理分析的技术要求更高，能力上是合规检查的超集，也理应走得更远。
- 样本库技术
基本原理：在接收网关中，按设备1%抽样并旁路到样本流，样本流落盘就是样本库。
样本库的关键在置信度：
- 抽样是一门学问，就质量审查来讲，按设备抽样具有比较好的表现。对比全随机抽样和按设备抽样与原始数据的差异：
- 总会有差异，简单量化，持续评估：置信度 = PV差值比较 * 50% + UV差值比较 * 50%
- 若置信度最高到 99%，判定精度也只能到 1% (= 1 - 99%)，不过在质量领域更在乎大局变化。
- 后台上报多数都没有设备 ID，只能全随机抽样，置信度会差一点（具体情况具体分析）。
样本库的收益：
- 样本库额外消耗主数仓约 1% 的资源，但换来的是大量的计算资源节省和查询速度，非常划算。单纯就质量审查一个项目，每天 10w 的计算任务，就已经够本且节省了大量资源。
- 想象空间：数据分析时可先用样本库进行快速洞察，有眉目了再用原始数据给出准确结果；用于数仓加工的测试库；用户个人行为诊断等。
- 强烈建议每个有一定规模的业务都应标配一个样本库。
- 三层分离架构
设计思路：把传统的监控规则一拆为三：计算规则、判定规则、告警规则，并以此扩展为三层分离架构。
设计原则：抽象、轻量、开放、面向全域数据的架构设计。
- 计算层
职责：把各种介质的异构数据计算提取为无差别的质检指标。
最大挑战：利用计算同质化的特点，想尽办法（合并、编排、错峰、抽样、甚至边缘计算）最大幅度得降低成本。
无差别的质检指标 = 资源域 + 资源 ID + 指标域 + 指标 ID + 时间分区 + 各自不同的维度。
- 判定层
职责：从各种质检指标中挖掘出数据问题，人来挖就是质量审查，机器来挖就是智能判定。
最大挑战：不断提升判定规则的表达能力，从而能跟上日益丰富的人类或 AI 的想象力。
- 告警层
职责：把数据问题人性化地通知到各个生产方和消费方。
最大挑战：建立数据问题的收集、告警、跟进和度量体系，持续评估告警的回执率（消费方）和解决率（生产方），并赢得信任（=不放垃圾箱）。
- 判定引擎与指标存储
- 判定引擎
第一代判定引擎，DSL 采用 Golang 的 gengine，并提供了在线编写、调试、管理、运维等配套功能。每天 60w+ 判定任务，表达力、性能、稳定性都不错。缺点在于：上手难度较大，不支持 ML。
未来第二代 DSL 或将直接用 Python 语言，支持安装第三方 Lib 和数据集，看起来 Jupyter 是个不错的编写和调试底座。
- 指标存储
在众多时序数据库中，我们最终选择了腾讯云的 CTSDB（基于 ElasticSearch），除了稳定和高效的运维服务外，最打动我们的还是其 Schema Free 的设计。
04总结展望
本文介绍的质量审查思想以及工具，已在腾讯内部多个业务进行实践，正在发挥着越来越重要的作用，希望能给你带来一些启发～
以后有机会再分享数据采集治理中的效率篇，先展望一下：
- 极致成本：分级上报 + 列式打包 + 配置下发
- 上报模型：标准口径 + 参数级联 + 自动采集
- 测试工具：可视化联调 + 实时校验 + 测试库
- 流程效率：轻流程 + 清交付 + 智能面板
05Q&A
Q1：样本库的效果如何？主要是关于置信度的问题吗？在进行概率抽样时，如何判断抽取的数据是否存在问题？
A1：确实，样本库的效果主要体现在其置信度上。我们对置信度进行了简化的评估，虽然不可能对每一个维度进行详细评估，但根据我们的简化评估方法，当前样本库的置信度普遍超过 99%。这意味着，尽管概率抽样带来一定的不确定性，我们的样本库仍然能提供可信的结果，到目前为止，还没遇到过因样本库偏差而引起误报的案例。
当然，不同的业务场景可能对数据准确性和置信度有不同的要求。因此，这里提供的信息可以作为一种参考，具体应用时可能需要根据业务需求和环境进行专门的评估。
Q2：如何提升准召率中的准确率？
A2：这是一个很好的问题。实际上，提升准确率是一个颇具挑战的任务。我们知道，准确率和召回率不可能同时达到 100%，在优化过程中，需要平衡泛化性和准确性。
通常，在评估准确率时，我们不能仅仅看单一案例。如果只追求单一案例的 100% 准确率，可能会牺牲模型的泛化性。因此，我们需要从整体的角度进行评估和调整，寻求整体最优。
目前，调整准确率的基本方法是调整配置阈值和门槛。但要更深入地优化，就需要调整使用的算法。例如，我在演讲中提到的三类算法可能还需要进一步拓展。此外，还需要关注对比思路的变化，从数据的纷繁变化中找到不变的要素，这些不变的要素若发生变化，则可能指示着问题的存在。
总的来说，没有统一的标准来提升准确率，这需要我们根据经验和具体情况进行摸索和优化。往往既懂技术又熟悉业务的开发者能更好地处理这些问题。
以上就是本次分享的内容，谢谢大家。
