导读
数据采集从广义上讲就是将真实的客观世界数字化并记录下来，俗话说数据采集的深广准决定了数据应用的上限，所以数据治理要从采集源头开始。当前数据采集治理面临的最大挑战就是质量和效率，本文是质量篇，将深度剖析如何才能真正看清甚至掌控数据质量。本文先提出了一个将数据质量从合规提升到合理的观念，然后介绍了一套质量审查工具并解析其中的关键技术。
1.
看清数据质量
2.
质量审查工具体系
3.
关键技术解析
4.
总结展望
5
.
Q&A
分享嘉宾｜
韩钰
腾讯
数据上报系统负责人
编辑整理｜胡回
内容校对｜李瑶
出品社区｜DataFun
看清数据质量
1.
用一个 Case 看清数据质量
假设你是⼀位数据科学家，需要使⽤⼀个终端⾏为⽇志的公参 login_type（登录类型），除了参数的中英⽂名外，你对它⼀⽆所知，你想⽤但⼜担⼼质量问题，不太敢⽤，请问你会怎么做？
可能你的方式有很多，比如问人、查元数据平台、捞几条数据看看等。
而本文给出的⽅式是 —— 利用可视化图表做质量审查：
这是一张参数 login_type 的枚举值占比的双端趋势百分比堆叠图，从图中我们可以看出：
-
这个参数是枚举型，枚举值不多，含义都能猜得出来（例如微信、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 算子 发现了问题。
问题：
“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，一用于让规则模型更有想象空间，二用于自动生成和调优判定规则。
即使是加扩展规则，也是一件很简单的事情。
数据采集中智能判定的主要目标是：
拨开业务运营波动的迷雾，发现属于数据采集的质量问题
。这与业务运营指标监控不同点在于，后者主要目标是观察并找寻指标波动的相关性。
“迷雾”中，存在一些比较顽固的干扰因素：
-
运营活动效应，
比如：双 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. 三层分离架构
设计思路：把传统的监控规则一拆为三：计算规则、判定规则、告警规则，并以此扩展为三层分离架构。
设计原则：抽象、轻量、开放、面向全域数据的架构设计。
职责：把各种介质的异构数据计算提取为无差别的质检指标。
最大挑战：利用计算同质化的特点，想尽办法（合并、编排、错峰、抽样、甚至边缘计算）最大幅度得降低成本。
无差别的质检指标 = 资源域 + 资源 ID + 指标域 + 指标 ID + 时间分区 + 各自不同的维度。
职责：从各种质检指标中挖掘出数据问题，人来挖就是质量审查，机器来挖就是智能判定。
最大挑战：不断提升判定规则的表达能力，从而能跟上日益丰富的人类或 AI 的想象力。
职责：把数据问题人性化地通知到各个生产方和消费方。
最大挑战：建立数据问题的收集、告警、跟进和度量体系，持续评估告警的回执率（消费方）和解决率（生产方），并赢得信任（=不放垃圾箱）。
3. 判定引擎与指标存储
第一代判定引擎，DSL 采用 Golang 的 gengine，并提供了在线编写、调试、管理、运维等配套功能。每天 60w+ 判定任务，表达力、性能、稳定性都不错。缺点在于：上手难度较大，不支持 ML。
未来第二代 DSL 或将直接用 Python 语言，支持安装第三方 Lib 和数据集，看起来 Jupyter 是个不错的编写和调试底座。
在众多时序数据库中，我们最终选择了腾讯云的 CTSDB（基于 ElasticSearch），除了稳定和高效的运维服务外，最打动我们的还是其 Schema Free 的设计。
04
总结展望
本文介绍的质量审查思想以及工具，已在腾讯内部多个业务进行实践，正在发挥着越来越重要的作用，希望能给你带来一些启发～
以后有机会再分享数据采集治理中的效率篇，先展望一下：
-
极致成本：分级上报 + 列式打包 + 配置下发
-
上报模型：标准口径 + 参数级联 + 自动采集
-
测试工具：可视化联调 + 实时校验 + 测试库
-
05
Q&A
Q1
：样本库的效果如何？主要是关于置信度的问题吗？在进行概率抽样时，如何判断抽取的数据是否存在问题？
A1：确实，样本库的效果主要体现在其置信度上。我们对置信度进行了简化的评估，虽然不可能对每一个维度进行详细评估，但根据我们的简化评估方法，当前样本库的置信度普遍超过 99%。这意味着，尽管概率抽样带来一定的不确定性，我们的样本库仍然能提供可信的结果，到目前为止，还没遇到过因样本库偏差而引起误报的案例。
