CCF大数据比赛--severless工作负载预测 0.33分方案分享


前言

最后结果
0.33743155分/46名(A榜) 0.33025664分/45名(B榜)
线上赛也已经结束很久了,就打算来分享一下自己的想法吧。因为课程要求第一次打这种数据科学类的竞赛,此前也没什么相关的知识储备。基本都是基于zhengheng大哥提供的baseline进行修改而成,后面都是个人的想法,想到什么就做了什么,如有不对轻喷。

赛题简述

大赛网址
背景:云计算时代,Serverless软件架构可根据业务工作负载进行弹性资源调整,这种方式可以有效减少资源在空闲期的浪费以及在繁忙期的业务过载,同时给用户带来极致的性价比服务。在弹性资源调度的背后,对工作负载的预测是一个重要环节。如何快速感知业务的坡峰波谷,是一个实用的Serverless服务应该考虑的问题。
任务:传统的资源控制系统以阈值为决策依据,只关注当前监控点的取值,缺少对历史数据以及工作负载趋势的把控,不能提前做好资源的调整,具有很长的滞后性。近年来,随着企业不断上云,云环境的工作负载预测成为一个经典且极具挑战的难题。
参考图片

简单的说就是给你过去五个时间点的服务器资源使用情况和提交到服务器上的job的情况,让你预测接下来五个时间点的CPU使用率和排队中的job数。


一、赛题理解

  • 赛题难点就在于上面那张图,到了某个点后接下来的趋势到底是怎样的?继续上升还是下降还是保持平稳。
  • 这道赛题让我们用过去五个点预测接下来五个点,按道理时序模型里面越近的时间点对当前时间点的预测意义越重,那么这里只有五个的话其实很难单个拎出来说哪个点的意义更大。
  • 一上来我先交了五个时间点CPU使用率和排队job数的平均值、最大值、最小值、中位数、最小三个数的平均值,其中平均值分数0.08左右,最小三个数的平均值分数在0.11左右,有一个忘记了,最高是0.12的。从这里还有评价指标可以看出,其实直接用平均值这些统计值对于预测意义已经不错了,像我最高分是在0.33,将近0.34,这个分数对比0.12算出来的精度其实就差几个百分点。
  • 根据很多大佬的言论以及我的总结觉得对于排队中的job数的预测过于玄学,而且占比不大,主战场还是CPU使用率,所以我后面的分享基本都是基于如何预测CPU使用率的。

二、数据分析

1.excel分析

  • 训练集数据间时间间隔基本都不是5分钟的,但大多数还是在3-30分钟内。其中极值甚至可以上千分钟。但训练集是严格5分钟的。
  • 训练集存在缺失值的情况,比如磁盘使用率,但是缺失值也不是很多。
  • 训练集里面很多队列在测试集都没出现的。
  • 测试集的大概15000条样本中光是297号队列就占了5710条,其次是21487和85153号队列,分别占了2235和1950条,记起来将近2/3。所以对这几个队列的预测精度可谓是提分大头。
  • 测试集的日期做了脱敏处理。

2.python分析

  • 做了折线图、散点图和条形图什么的最基本的统计图。可以看出其实大部分时候CPU的使用率都是偏低的,不管是平均值还是中位数基本都是在个位数。
  • 不同队列的分布相差较大,有的队列的CPU使用率基本都比一些其他队列大。

三、数据预处理

  • 针对缺失值问题我采用了直接删掉对应样本和补0两种方法,两种方法效果差不多,大概有几个千分点的提分。
  • 针对时间间隔不均匀的问题,在构造训练集时我设置了一个阈值,当前后两个时间点的时间间隔大于这个阈值时自动丢弃这个样本(比如t1-t0>阈值),但这个是掉分操作。
  • 针对时间间隔不均匀的问题,我一个朋友做了插值处理后重采样。但结果是掉分的。原因我分析大概是插值后增大了误差,因为插值出来的数据可能过于不准确。
  • 时间转化为了y-m-d格式。

四、特征工程

  • 因为heng哥的baseline是每个队列都建立不同的模型,所以删除每个队列都有相同数据列很合理,其中有
  • 根据前面的作图我发现一天当中的不同时段CPU的使用率分布还是有很大区别的,所以加入了 (hour*60+min)的时间特征。事实证明这个提分非常大,几个百分点的提分,在前期让我直接坐上榜二的位置。
  • 根据鱼佬的baseline的灵感,加入了滑窗统计值和衰减统计值以及组合特征,基本都是掉分的。

五、模型

  1. 选用模型:
    用的模型就是heng哥baseline的lgb模型,没有什么特别之处。
  2. 调参:
    对树深和K折交叉的参数都调大了,大概是1-2个百分点的提升。
  3. 模型融合时选用了xgboost和随机森林,分数分别在0.32和0.312。但是无论以加权平均数融合还是采用stacking融合都没有lgb单模高分(heng哥nb!),猜测原因是模型相似度太高且融合模型有点少。

六、后处理

  • 因为测试集的分布和训练集不一致,测试集的CPU使用率偏高一点,所以我给结果整体加/乘上了一个小常数 ,使它更好的拟合测试集,感觉这其实是玄学做法,但是有几个千分点的提分。
  • 对于排队中的job数这个预测值,我直接采用平均值。结果比我模型预测的高将近1个百分点吧。

七、一些别的发现和思考

  • 长时间上不了分后,我开始手动观察结果,发现我模型中的一些问题,比如我有一个很明显的误差很大的结果:
测试集CPU使用率CPU使用率预测值
852
851
911
911
901

这里很明显用肉眼都能观察出不合理,应该是过拟合导致,但是发现时已经是赛程末期,做了一下缓解过拟合的操作反而掉分了就放弃挣扎了。

  • 学业太忙一直没能把神经网络弄出来,结合一些大佬的言论,感觉应该是个上分点,有兴趣的可以试试。

总结

这道赛题出的业务场景还是很不错的。虽然我第一眼看上去很简单,但是实际做起来却还是蛮有讲究的。当然对于我这个方案,不足之处和可改善之处还很多,等学习了前排方案后我再来改进一下自己的方案吧。

致谢

首先感谢zhengheng大哥的baseline,没有这份baseline,对于我这种菜鸟新手真的不知从何开始,真的感谢!然后感谢我的导师和我的师兄还有给我提供过思路的队友以及朋友们,你们的支持是我继续打下去的动力!
最后献上我的代码:
开源代码

  • 2
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 4
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值