数据离散程度算法

2015-07-27 11:33:33 +08:00
 iyaozhen

我有一批数据,简单来说就是客户端上报的 crash 记录的时间。

现在需要评估这些时间的离散程度,毕竟如果扎堆 crash 的话就说明出事情了。

数学没学深入,找不到合适的算法。现在比较挫的做法是没小时(分钟)聚合数据,看看哪个时间段发生的 crash 数量是否占了大多数(30%+)。

4813 次点击
所在节点    程序员
23 条回复
Comdex
2015-07-27 12:40:58 +08:00
计算标准差离散系数,方差或协方差?
iyaozhen
2015-07-27 12:46:25 +08:00
@Comdex 嗯,我也想过标准差什么的,但这些是表示数据的离中程度,感觉不太对。
Xs0ul
2015-07-27 13:01:13 +08:00
lz 现在的方法遇到了什么问题?或者说需求是什么?
1、如果需要一个实时预警(比如数据不断更新,发现大量用户crash,需要提醒),根据以往的数据设定一个绝对的阈值可能比较合适;
2、如果只是分析以往的数据,我觉得lz 可能需要可视化的工具,比如画个折线图。
retopara
2015-07-27 13:01:49 +08:00
@iyaozhen 那就用K=1~N的K-means逐个分一下类,然后看一下每个类中的方差?
BUPTGuo
2015-07-27 13:11:39 +08:00
霍普金斯统计量,当时看聚类评估的时候,有书上提到用这个量来判断数据的随机程度,判断是否有聚类趋势
theoractice
2015-07-27 13:19:22 +08:00
使命召唤里判断机枪枪管是否过热的算法用在这里挺合适的。具体不解释了,玩过的都知道
ca1123
2015-07-27 13:23:00 +08:00
我来个土鳖思路
你定个时间间隔T
对于这个间隔: 连续测量/记录时间间隔内的crash事件的发生数量
用全部历史数据训练一个泊松分布出来
之后每一个新的测量都和这个泊松统计比较 看看这么多crash是什么概率的事件
如果crash数量多到是个小概率时间(你定的概率 5% 3% 1% 0.1% 都可以) 就说明你摊上大事了
ca1123
2015-07-27 13:25:15 +08:00
但是你的时间间隔T得足够长 使得通常这个间隔内有至少40次crash 不然泊松分布训练不出来
iyaozhen
2015-07-27 13:29:23 +08:00
@Xs0ul 是统计昨天的数据。需求就是看看是否有 crash 扎堆的情况。要程序给出结论,自动定位用。
iyaozhen
2015-07-27 13:30:18 +08:00
@BUPTGuo 谢谢,这个我看看。

@ca1123 谢谢,我看看。
iyaozhen
2015-07-27 13:31:49 +08:00
@theoractice 解释下呗,玩过一会儿就没玩了。
ca1123
2015-07-27 13:34:17 +08:00
@iyaozhen 你弄个散热模型比如指数衰减散热 每打一发 增加50度 超过500度报警 没crash就冷下来了 不停crash温度就上去了 然后就该报警了
ca1123
2015-07-27 13:35:10 +08:00
或者牛顿冷却定律也可以
iyaozhen
2015-07-27 13:42:21 +08:00
@ca1123 原来如此,也有点类似网络拥塞控制中用的算法了。以后可以考虑用用,现在用不上,不需要实时报警,只要算下昨天的数据,马后炮分析。

不过也可以模拟实时的步骤,看看昨天数据是否异常。
ca1123
2015-07-27 13:49:51 +08:00
@iyaozhen 这哥们提的和我说的可以互相转化 他的温度就是我的小概率 统计学的东西基本就是那么回事
iyaozhen
2015-07-27 14:08:21 +08:00
@ca1123 我看了下泊松分布是用来描述某个固定单位时间内的概率事件。好像有点不符合。
ca1123
2015-07-27 14:18:17 +08:00
@iyaozhen 哪里困扰呢?你的普通crash是符合泊松分布的 你现在不就是想知道什么时候泊松分布失效么(摊上大事了) 就是过热的时候 或者出现小概率情况
iyaozhen
2015-07-27 16:08:24 +08:00
@ca1123 时间窗口设置的问题。我是计算一天的泊松分布还是某个小时的?

一天的肯定不行,计算某个小时的话是可以看出今天的某个小时是否符合泊松分布(是否异常),这应该是可以的。

但是我目前的需求并不关心今天的 crash 是否和之前相比是否异常,更多的是需要看看今天的 crash 是否在某个时间段扎堆。(我是统计某个端的所有数据,端上某个时间扎堆 crash 的话可能是那个时刻 server 端出了问题。crash 是举个例子)
ca1123
2015-07-27 16:37:46 +08:00
@iyaozhen 时间窗口越小越好 越小越接近"时刻"的概念 这个里面有个trade-off的地方 你选择的时间窗口越长 统计模型越准确 报警时越是应该实际的警报 但是你的时间分辨率就不行了 最好的情况是你的试验频率足够高(namely 使用的人足够多) 这样可以同时满足时间分辨率和报警精度 经验的说 时间窗口内有大约40个events就能满足要求了

另外 俗话说叫"扎堆" 用数学语言描述就叫和模型的背离程度 而你的模型怎么来的? 当然是经验来的, 这个经验可能是你自己的(就像我说的你自己训练一个泊松分布) 或者别人的经验 (你想象的 直接判定是否扎堆) 就算是别人的经验 也需要你的全局情况 不定义一般就定义不了特殊

另外的话 要注意你的events可能有潮汐 比如白天人多一些 晚上人少一些 这就要求你进一步修正模型 要把异常events 用使用频率来normalize一下 不然很可能系统没故障 只是用得人多了 正常导致故障events多了 你却产生了系统故障的错觉
iyaozhen
2015-07-27 17:09:16 +08:00
@ca1123 非常感谢,我再研究研究。我也是突然想用数学(统计学)的一些东西来分析目前的数据,希望更科学一点,少一些拍脑门的、想当然的统计方法。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/208594

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX