我们需要解决报警频繁且误报严重的问题,并希望看到简短、内容清晰的报警(如图1所示)。
图1
监控方案整体流程,如图2所示:
图2
有了整体的方案流程后,我们还需要考虑以下几个问题:
01
监控粒度
移动端游戏跟页游业务不一样,每款游戏有着大量的子包,只针对单个游戏或者整个充值大盘的监控无法定位到具体子包的充值是否异常,所以监控粒度需要精确到单个子包。
02
模型输入和输出
报警是根据每个时间区间的订单数对比来做监控,所以模型的输入是时间区间或者时间点,例如2019-04-14 12:10,模型的输出为每10分钟往前1小时的订单量。这样考虑相对于固定使用每一小时的订单量来说,可以及时使用最新的订单量来判断下降趋势。
03
模型算法选择
我们需要预测的是监控时间点的订单量,订单量是连续型的数据,因此是个回归问题,回归算法的选择会在模型算法选择详细描述,最终选择的是xgboost算法。
04
模型迭代更新
由于模型预测存在一定的损失,而且特征太少对于未来的订单趋势预测并不是非常准确,所以需要定期使用最新的数据来更新模型,最终采用每天拉取前2周的订单数据来更新模型,让模型学习最新的订单趋势来做预测。
05
监控阀值
由于每个子包投放的渠道量级不一,不同的子包充值量各异,因此监控阈值不能设置为同一个,需要在不同的订单量区间设置不同的监控阈值。
回归模型的评价指标主要有平均绝对误差(MAE)、平均方差(MSE)及R平方值等指标,这里使用MSE来评估算法,MSE可以评价数据的变化程度,MSE的值越小,说明预测模型描述实验数据具有更好的精确度,MSE的公式如图3所示。
图3
模型必须要有较好的鲁棒性,即能够在预测集上MSE达到最小,其次需要有较快的执行速度,因为子包的数量大需要模型快速的返回结果。这里选择对比了决策树、随机森林、GBDT、xgboost四种回归算法在其中一个子包数据集上模型鲁棒性及算法执行时间,对比数据如图4所示。
图4
从图中可以看出xgboost算法MSE最小即模型鲁棒性更好,虽然决策树算法耗时最小,但是监控业务需要优先考虑的是模型的鲁棒性,因为模型损失越大越难以到达监控的目的,因此我们选择xbgoost算法来实现。
xgboost算法思想是将许多弱分类器模型集成在一起合成一个强分类器模型,算法通过不断的添加一个个弱分类器来拟合上一次的残差,最终集成一个强分类器模型,而且xgboost的基学习器可以是CART或者线性分类器,既可以用于分类也可用于回归。算法通俗一点理解如图5所示,例如模型最终需要预测的值是9,f(1)~f(3)代表3个弱分类器模型,f(1)弱分类器模型预测的结果5与真实值9残差为4,f(2) 弱分类器模型需要尽可能的拟合残差4使得损失最小,最终f(2) 弱分类器模型预测结果得到残差1,f(3)弱分类器模型尽可能的拟合残差1,最终三个弱分类器模型合成为一个强分类器模型,即f(1)+f(2)+f(3)=9。
图5
xgboost算法广泛应用于数据科学竞赛及工业界,它有着很多优点:
1)算法目标优化函数(loss function),对每个弱分类器模型进行了正则项惩罚防止模型过拟合
2)对弱分类器乘上缩减权重η,使得每个弱分类器影响不大,留下更大的空间给后面弱分类器去优化模型
3)支持并行化,模型训练速度快等等优点
目前充值监控还存在着一些不足之处,后续将针对如下2种情况进行优化:
01
订单量偏少
由于投放渠道量级不一,存在订单量非常少的子包,例如订单量少于10,非常难以监控到充值问题,目前针对这种订单量非常少的子包处理方法是预测值-真实值大于10则报警。未来将考虑通过延长监控区间来处理,例如预测2小时内订单量甚至1天内订单量。
02
订单量暴增
游戏内活动造成订单量的暴增,由于模型每天都在定时更新,容易造成没有活动的时候预测订单量也偏高的情况从而导致报警。未来将考虑通过增加特征来处理,例如增加游戏内当天是否有活动或者某类型活动等特征来实现预测。
——THE END——
以下技术文章,你可能也感兴趣:
●排版 | 川芮