用数据特征排除数据波动假警告
在灰度包数据问题当中,经常出现数据波动超过了正常范围,但是无法查找到相关原因。第二天或者第三天,随着数据放量,数据波动恢复到了正常范围以内。根本上说这是数据量比较少导致的现象,这里探讨一种方法来判断这种警告是否可靠。[原文链接][原文链接]
问题
在灰度包数据问题当中,经常出现数据波动超过了正常范围,但是无法查找到相关原因。第二天或者第三天,随着数据放量,数据波动恢复到了正常范围以内。
根本上说这是数据量比较少导致的现象,有时候也可能是灰度到的用户群体带有一定特殊性,导致数据失真。一个非常显著的例子是有时候个别用户会疯狂分享上千次,最多五千次,导致灰度数据暴涨。当然,这个例子其实也是数据样本不够大,只要足够大,这个暴涨的数据在巨大的基数上也微不足道。然而灰度本身就是希望现在小样本上做试验,确认效果以后再推广到全部数据,所以不能完全靠数据放量来进行判断。
那么有没有可能根据当前灰度数据(样本)判断它是否可靠?对于可靠性低的样本反应出来的异常波动可以重新发灰度或者等一等数据放量,对于可靠性高的样本反应出来的异常波动就需要认真排查。
解决思路
数据应该满足一定分布方式,如果样本数据严重偏离这个分布方式,就认为样本不可靠。比如在学校随机选择学生访问,如果全部是男生那么这个样本有问题的可能性很大,男女生比例应该接近1:1。
在下面的描述当中,使用分享数据作为例子,显然灰度数据不存在好像男生女生一样1:1的简单比例,看起来也找不到正态分布的数据,那么:
灰度数据应该满足什么分布?
观察apm数据的图表,基本每天的都是如下图形: 这是随着时间变化的分享次数数量,当出现bug的时候,可能分享平台比例有变化,可能某些分享数量会降低,但是同一个逻辑的分享数据,很难改变用户在什么时候分享。所以在这里选择 时间-次数 的关系图形作为标准分布,期望灰度数据也可以满足这个分布图形。
在这里没有做条件限制,实际使用的时候是具体数据有问题,比如出现QQ数据偏差,那么可以对分布数据和样本数据都限制为QQ数据然后进行比较,这样更加精确,确实QQ的分布情况和大盘的分布情况不太一样。但是带来的问题是数据量缩小可能导致判断不准确。根据经验,21点的数据不应该少于200,最好能多于1000个,这样比较可靠。
怎么描述这个分布?
述图形是很不规律的,无法用简单的函数进行描述。可以使用最小二乘法逼近一个函数出来,不过在这里我们简单处理,
1、对全部分享的每天的数据,每小时求和,得到S1…S24
2、从中取得最大值Smax
3、用Ri = Si/Smax,得到R1…R24
4、理想的灰度数据按照相同的方式处理以后得到的R1..R24应该和上述数据一致
实际计算21点最多为1,其他比例从0.07 - 1之间。因为灰度数据一般在周一和周二,所以选择了最近四周的周一周二一共八天,计算比例以后求平均值如下:
[0:0.3401366175169934, 1:0.1861001156380886, 2:0.10706734635811115, 3:0.07250220823703654, 4:0.07431978413956412, 5:0.136710199297124, 6:0.2697665388808243, 7:0.358382774809046, 8:0.42053193670871464, 9:0.4944465748090594, 10:0.5622043101012557, 11:0.6023667672832733, 12:0.6880661656315542, 13:0.6697479553558153, 14:0.5965930339537727, 15:0.5874068054395511, 16:0.5964191765794082, 17:0.6306011447003349, 18:0.6831739276417802, 19:0.7587048965272791, 20:0.9088487380987144, 21:1.0, 22:0.8840385602760035, 23:0.5996796741915665]
这里虽然使用的是全部数据,但是也不是一个理想的比例,所以不会完全一样。
怎么衡量灰度数据与这个分布的偏差?
平时的灰度数据不可能是理想的灰度数据,我们参考标准差计算公式来衡量灰度数据和这个分布的偏差。
设分布数据是R1..R24,灰度数据是H1..H24,那么有:
delta = Sqrt(Sum((Ri - Hi)^2) / N) N = 24
理想情况下delta 应该为0,选择全部数据的时候计算出来的delta在0.01左右,说明R1..R24还是很可靠的。选择200万的灰度版本计算出来的delta在0.05 - 0.12之间。
那么,如果灰度数据的偏差超过0.1 我们可以认为是比较大的。
sql语句和脚本文件
这里是对灰度版本1.1.20.302的QQ平台获取数据,设定在4.24 - 4.27四天。如果是获取全部数据,应该修改天数并且删除版本号限制。
可能也可以通过查询数据然后使用Excel的数据透视图的方式来计算,不用groovy脚本这样写程序来计算。
使用时间序列-百分比变化图形
我的同事wangyudong提出可以直接使用时间序列-百分比变化图形,虽然目前这个图形的原理是什么还不清楚,但是在最近两次经验判断比较准
使用两个灰度版本+最近的大盘版本,三条曲线应该尽量接近。可能使用一小时作为时间单位会比较合适。
验证和举例
在偏差很大的情况下,可以直接认为数据不可靠,如果能定位不可靠原因,那么该灰度数据还是可以有结论的;如果不能定位不可靠原因,要么等待积累更多数据偏差变小,要么重新发灰度。偏差比较小的情况下,结合数据总量和偏差量的变化趋势,也能帮助说明一定问题。
分平台:私信分享pv,成功次数 涨幅异常
分平台:pv,成功次数,uv 涨幅异常
QQ数据异常,不存在明显头部数据现象,但是随着时间逐步正常了;私信数据确实存在异常。
QQ数据在三天时间里面分别是0.081 → 0.079 → 0.072 逐步变小,变化不显著,但是可以注意到,这三天数据也在变少,一般数据变少差异变大,这里出现相反的情况,说明数据质量提高的幅度应该超过了0.081 到0.072。
分平台:成功次数,人均分享次数 涨幅异常
这个版本入视频详情页的分享中台SDK出现问题,暂时关闭开关,之后多次使用灰度版本验证,很久才确认没有问题发版。如果用这个方式来检测灰度样本偏差成都,首先使用短视频数据作为基准数据:
然后以1.4.30.140版本为例:
这样计算出来的偏差是 0.057, 0.065, 0.070 是比较小的,那么实际不用那么晚才确认数据可靠。
QQ分享 - 分平台:成功次数,人均分享次数,pv 波动异常
这个版本判断是正常波动,用该工具计算结果也是正常波动,使用时间序列-百分比变化也是正常波动,出现异常的那一天偏离较大
分享-直播分享,qq和微信分享指标异常:pv,成功次数,uv 波动异常
这个版本判断暂时认为是正常波动,因为8号、10号数据正常,但是9号数据异常。可是使用该工具计算,9号可靠度更高,8号其次,10号最不可靠。
使用时间序列-百分比变化的结论是8号、10号数据可靠,9号数据不可靠:
8号数据:
9号数据:
10号数据:
目前的不足和改进方向
首先,可以发掘更多的指标,这里只用了时间-次数的关系,如果能增加其他指标共同判断,会更有说服力;
第二,使用的数学工具有待改进,现在只用了平均数和标准差计算,而且衡量灰度数据和分布数据的计算其实还不是标准差,如果使用更好的数学工具可能进一步增加数据说服力;方法上也可以引入其他方式,比如尝试其他抽样方式例如Bootstrap等
第三,再多用现有灰度计算,置信范围可以比<0.1更精确一些
第四,除了“标准差”计算以外,可以引入数据数量结合判断,小数据量而且标准差小的样本应该是质量更高的样本
标签集合/Tag clouds
C++
Symbain
轻松汇编
算法
论文学习
资治通鉴
Delphi
编程之美
Poco
MFC
Linux
IFC
知乎
汇编
数据分析
交叉编译
poco
j2me
android
XML
Java
DTD
飞信
零宽断言
诺基亚
联系人
编程
真值表
池西木
正则表达式
多线程
命令行
优化
stream
configure
cmake
VIM
UiAutomator
TDD
Symbian
Sqlite
SourceInsight
Python
MPAndroidChart
Kotlin
Flutter
Dokka
Chatgpt