数据竞赛:记录3天进入比赛Top3%的全过程
原文首發(fā)于這里
這幾天花了3天時間嘗試了一個CCF比賽:大數(shù)據(jù)時代的Serverless工作負(fù)載預(yù)測。比賽鏈接:https://www.datafountain.cn/competitions/468/teams
這里簡單記錄一下如何利用三天時間進(jìn)入Top3%,雖然有2000多隊伍,很多人其實(shí)從來都沒有認(rèn)真做過,三天時間本身就超過80%的人了。所以Top3%,其實(shí)真沒什么難度,有巨大難度的是Top5,所以標(biāo)題黨了一下。
數(shù)據(jù)概覽
比賽類型為時間序列預(yù)測。背景:云計算時代,Serverless軟件架構(gòu)可根據(jù)業(yè)務(wù)工作負(fù)載進(jìn)行彈性資源調(diào)整,這種方式可以有效減少資源在空閑期的浪費(fèi)以及在繁忙期的業(yè)務(wù)過載,同時給用戶帶來極致的性價比服務(wù)。在彈性資源調(diào)度的背后,對工作負(fù)載的預(yù)測是一個重要環(huán)節(jié)。云計算,由于提交不同的任務(wù)需要調(diào)度的計算資源是不同的,為了提前應(yīng)對,需要計算不同隊列未來一段時間需要的資源。
預(yù)測任務(wù)是不同隊列未來5個時間點(diǎn)的CPU的利用率和隊列中的Job數(shù)。一共有以下隊列需要預(yù)測
不同隊列的趨勢確實(shí)幾乎完全不同,有可能需要針對某些隊列額外進(jìn)行調(diào)整
快速baseline
第一步,當(dāng)然是去GitHub搜索一下baseline。其實(shí)baseline的重要性比優(yōu)化還大多,假如滿分是100的話,很多baseline已經(jīng)做到80了,剩下的20分提升才是慢慢調(diào)優(yōu)。果然找到了一個很強(qiáng)的0.311baseline:https://github.com/siliconx/serverless/blob/main/baseline.ipynb
然后,先花了兩天時間,結(jié)合baseline看了一下數(shù)據(jù),也緩慢的調(diào)整到自己熟悉的代碼結(jié)構(gòu)里。我所習(xí)慣的保存方式是這樣:
這里我就花了兩天時間了,才算調(diào)整跑通一個baseline。所以最后一天才開始提交,而且只有3次提交機(jī)會,目標(biāo)是能跑贏baseline就行了。讀baseline時產(chǎn)生的一些優(yōu)化想法:
- 對ID和時間的認(rèn)識往往能夠提分,比如本題預(yù)測的就有同一隊列ID不同階段的預(yù)測。可能是采集數(shù)據(jù)的時候發(fā)生了異常,比如說把另一個區(qū)域的相同id的隊列數(shù)據(jù)混在了某個隊列中,選手需要自己做一些判斷哪個是原始的數(shù)據(jù)。
- 由于xgboost和lightgbm需要損失函數(shù)二階可微,而評價函數(shù)是自定義的不可微函數(shù),這里調(diào)整好也可以上分。
當(dāng)然模型融合也是直觀簡單的,尤其是樹模型和深度學(xué)習(xí)模型的融合。 - 預(yù)測目標(biāo)上可做的文章也很多,比如log變換,差分變換
優(yōu)化 - 在baseline的基礎(chǔ)上進(jìn)行優(yōu)化,優(yōu)化的方向主要有任務(wù)、數(shù)據(jù)、特征、模型(包括不同模型與同一模型的超參數(shù)、損失函數(shù)等)、驗(yàn)證、后處理等。在時間緊迫而且對數(shù)據(jù)不熟悉的基礎(chǔ)上,自然是要抓住主要矛盾,主要嘗試的就是新增特征了。本來應(yīng)該一開始就熟悉數(shù)據(jù)的,最后慢悠悠的也沒開始看數(shù)據(jù)。
第三天也就是比賽結(jié)束的最后一天下午四點(diǎn)鐘,終于第一次提交了一下:
第一次提交的排名是82/ 2392,四舍五入之后可以說自己排名Top3%。前排其實(shí)有不少小號隊伍,再加上肯定有人比我厲害,隨便提交也在我前面。大概可以得出結(jié)論,前面真正認(rèn)真對待比賽的不超過50個隊伍。即使認(rèn)真做,前十也不容易達(dá)到,但10-30這個區(qū)間只要早早參賽且不放棄的嘗試還是可以的。如果再互相組組隊,就更有機(jī)會了。但是要做好心理準(zhǔn)備,時間序列可能大坑,就是最終排行榜會劇烈抖動。
如果是某些傳統(tǒng)行業(yè)的公司,參加了數(shù)據(jù)比賽且排名前3%,已經(jīng)足夠?qū)懺诤啔v上了。大概,就是能從github上clone下代碼并跑通,并修改一下。但是真正幾斤幾兩,自己心里還是要有數(shù)的,baseline是0.311,我的提交加了幾個特征是0.320,第一的成績已經(jīng)到0.4了,差距巨大。
距離最后的提交時間不多了,已經(jīng)是下午四點(diǎn)鐘,還有兩次提交機(jī)會。第二次準(zhǔn)備加更多特征,第三次準(zhǔn)備從數(shù)據(jù)ID上看看做文章,或者嘗試新模型了。都這時候了,也不用管本地測試,不用管特征重要性了,就是梭,一把梭哈。萬一shake到我的好運(yùn)了呢,機(jī)會只給有準(zhǔn)備的人。當(dāng)然還是希望前面認(rèn)真分析數(shù)據(jù)、認(rèn)真搞特征的人能取得好成績。
剛開始想特征的時候要大開大合一點(diǎn),隨便加,能想到的都加上試試效果再說。然后再精細(xì)一點(diǎn),慢慢想,且開始思考word的為啥work,不work的為啥不work。這一次我又新增了特征,主要是時間序列特征:例如差值,比值,smooth。特征從89變成154
五點(diǎn)的時候再次提交。成績來到了0.32623446000,排名71/2399,已經(jīng)是2.959%,可以名正言順的說自己Top3%了。當(dāng)然,最后時刻肯定還是瞬息萬變的,尤其是這個位次,而且由于賽制的原因,有很多小號去參加評測,而且還很靠前。
還剩最后一次提交了,最后一次提交,突然覺得根據(jù)上一次的成績,搞一個系數(shù),然后直接提交。系數(shù)是用來決定趨勢的,首先判斷是大于1還是小于1,應(yīng)該根據(jù)數(shù)據(jù)來判斷,我也懶得判斷了。所以直接給第四天和第五天增加2%,再取整。 竟然也有0.0005的微小提高。不過總排名還是在不斷下降的,探榜的小號太多了,總隊伍已經(jīng)2409了。
最終B榜成績排名51
總結(jié)
-
由于是抱著娛樂的心態(tài)來參賽,所以完全沒有體會到那種跌宕起伏、那種巨大付出之后努力都付之東流的遺憾、那種中學(xué)時等待成績排行時的緊張感,這些心情上的東西都沒有體會很深。在年紀(jì)越來越大,心情越來越像流水一樣,本想借此回顧一下這種心情,沒想到知道時間不多而毫無壓力了。
-
代碼上的收獲是大致寫了個可復(fù)用的時間序列框架,以后如果再遇到多步的時間序列預(yù)測,可以很快的調(diào)整得以應(yīng)用到新數(shù)據(jù)上。不過只寫了lightgbm相關(guān),深度學(xué)習(xí)部分此次沒有嘗試。
-
特征導(dǎo)入部分分別嘗試了從原始數(shù)據(jù)直接pipeline一把梭的方式,以及每塊特征保存為pickle挨個加載這兩種方法。
-
時間序列比賽很容易被坑,由于包含外推的預(yù)測很可能發(fā)生概念漂移,導(dǎo)致以前的規(guī)律不準(zhǔn)確,排行榜特別容易shake,不建議新人一上來就打時間序列比賽。尤其這次的賽制,有點(diǎn)縱容小號,兩者疊加就完全不建議了。
-
由于時間以及能力原因,對數(shù)據(jù)和特征沒有很深的理解。極短時間參賽主要目的其實(shí)也是為了把框架性東西以及比賽流程熟悉一下,本次就暫告一段落了。
聯(lián)系方式
公眾號搜索:YueTan
總結(jié)
以上是生活随笔為你收集整理的数据竞赛:记录3天进入比赛Top3%的全过程的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Spring 异常处理三种方式
- 下一篇: mvc:annotation-drive