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

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

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 分布？—— 还是相对性，可以让不同体量的对象也能对比，比如灰度小流量与线上主流版本。

2. 智能判定：让机器自动发现问题

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

每一行代表一个问题，可解读为：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）先做审查，再做判定

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

本文提倡先做审查，再做判定，因为：

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

3. 自助诊断：让人快速诊断问题

（1）一些有用的小工具

• 对比工具

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

• 维度下钻

可以按任意参数进行下钻，并且可视化（3D）。

• 样本提取

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

• SQL 模版

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

（2）用户行为诊断

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

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

03

关键技术解析

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

1. 样本库技术

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

样本库的关键在置信度：

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

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

样本库的收益：

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

2. 三层分离架构

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

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

• 计算层

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

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

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

• 判定层

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

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

• 告警层

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

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

3. 判定引擎与指标存储

• 判定引擎

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

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

• 指标存储

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

04

总结展望

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

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

• 极致成本：分级上报 + 列式打包 + 配置下发

• 上报模型：标准口径 + 参数级联 + 自动采集

• 测试工具：可视化联调 + 实时校验 + 测试库

• 流程效率：轻流程 + 清交付 + 智能面板

05

Q&A

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

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

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

Q2：如何提升准召率中的准确率？

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

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

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

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

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

分享嘉宾

INTRODUCTION

韩钰

腾讯

数据上报系统负责人

硕士毕业于中国科学院计算机网络信息中心，曾先后就职于百度、滴滴、腾讯等公司，目前在腾讯数据中台负责数据上报系统，深耕数据采集治理，实现腾讯PCG的全业务覆盖。

往期文章阅读

往期推荐

点个在看你最好看