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

1,009次阅读

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

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

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% 准确率，可能会牺牲模型的泛化性。因此，我们需要从整体的角度进行评估和调整，寻求整体最优。

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

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

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