坚持是胜利的硬道理，2022华为软件精英挑战赛冠军分享比赛经验

5月21-22日，2022第八届华为软件精英挑战赛-“普朗克计划”总决赛及颁奖典礼在深圳成功举办。 大赛吸引了来自国内外826所高校、3291支队伍、2万余名大学生报名参赛，历时两个多月的激烈角逐，经过八大赛区区域初赛、区域复赛、全球总决赛等环节的层层考验，最终，来自粤港澳赛区的“我们啥也不会”队获得全球总决赛冠军。赛队撰文分享比赛经验。

一、比赛初衷

我们是2022华为软件精英挑战赛冠军队伍--我们啥也不会队。“我们啥也不会”却拿了冠军，听起来有点凡尔赛。但在我们队伍刚开始报名参赛的时候，是完全没有预知到冠军这份意外之喜的。毕竟，当初我们只是抱着重在参与的心态，想通过华为举办的这场大型的全球性的比赛，看一看自己的编码水平与顶尖高手的差距，然后以此激励自己不断学习进步，这是我们队伍参加华为软件精英挑战赛的真实的初衷。

二、回顾初赛

回顾这两个月的比赛经历，一些场景恍如昨日。印象深刻也是让我感觉最难的时候是在初赛阶段，因为成绩不太理想，我们三个人可以用“寸步不离”来形容每一次的参赛方案讨论。在实验室做比赛的时候在讨论，去食堂吃饭在讨论，排队做核酸在讨论，回去寝室了还打电话讨论。接着尝试各种想法，但是收效甚微。不夸张地说，那段时间晚上睡觉闭上眼，都是想着怎么优化。我感觉我们随时会输掉比赛，但是我们没有放弃。

在距离比赛结束还剩三天的时候，我感觉大家都身心疲惫了。我们在提交完20次代码之后，都想赶紧回寝室休息了，所以那天晚上是我们初赛以来最早离开实验室的一天。在回去寝室的路上，我们讨论出了一个彼此都认为会有很大优化效果的方案。我们感觉，这次方案即将迎来了一次较大的突破。经过不断的编码验证，快到凌晨两点的时候，效果出来了，同时我们也真正地看到了希望。同时也明白一个道理，大脑需要足够的休息它才能正常的工作。所以当你越迫切想做出突破的时候，最好的方法就是在这之前，到户外走走。

三、从复赛到总决赛现场

最终我们是团队第十名的成绩从初赛晋级到复赛。那时候和队友打趣说：我们现在起码少了一半的竞争对手，竞争激烈程度减少一半。而且在经过了初赛的磨练，我们对赛题有了一定的了解，同时信心也大增，很多优化方案也是在这个时候不断涌现出来。仿佛幸运之神眷顾我们，最终我们通过复活赛晋级到了总决赛。

5月22号，在总决赛现场，对我们来说是最难忘最惊心动魄的一天。总决赛赛题在复赛赛题上有小改动，我们讨论完之后写了第一个版本，我队友把代码提交了上去，得到的结果选手程序运行失败。大家整体紧张了起来。然后队友试图转移压力，把代码发给我让我改，但我改完前后提交了三次，结果分别是选手程序运行失败，方案分配不合法，方案输出格式错误。脑袋嗡嗡作响，神经紧绷。二十次提交机会已经用掉了四次，难道我们要止步于此了？队友跟我说要沉住，在认真排查bug之后，我提交了第五版代码，终于成功运行拿到了100多万的分数，暂排在了10几名。此时三人都松了一口气。不知道是紧张还是兴奋，在我起身去拿水果的时候，拿水果叉的手都还在微微发抖。

在这之后，我们又讨论了几个可以降分的方案，逐步将分数降到90万分，84万分，暂列第一。在知道我们暂列第一时，组里雀跃了一下，我紧绷的神经放松下来，其中一个队友已经开始哼起了好运来，但我另一个队友明显还是特别紧张，喝了好几杯茶，一瓶矿泉水，期间还把茶水打翻洒在了键盘上。好家伙，不是说把压力转移给我吗？竟然比我还紧张。再之后经过几轮持续的讨论和编码之后，我们最终将分数降到了79万。此时已经用完了所有的提交次数，我们也感觉自己交了目前最好的答卷了。只能说尽人事听天命了。

四、总决赛颁奖，我们是第一名

和贪心算法本质一样，在比赛封榜前我们看到自己仍是第一名的位置，就越期待自己能如愿第一，贪心一回。我们进会场走红毯的时候看到了放在中间的第一名的奖杯，我心里在祈祷：We are the champions!（如果你们也听过皇后乐队这首歌）最后，是的，我们如愿了！当华为云CTO张宇昕公布第一名是“我们啥也不会”队的时候，我们如愿了！回顾这充满奇迹的两个多月，我们不仅学到了如何去团队合作，还明白了互相鼓励的重要性，坚持就是胜利的硬道理。最后引用一句在华为云组织的出海游玩的轮渡上听魔术师在表演结束时说的一句话：当你相信奇迹的时候，奇迹才会发生!

五、决赛方案及分析

全球总决赛的变更点是从第二个时刻起，在每个时刻，选手可以从 site_bandwidth.csv 中，任意选取20个边缘节点。这些被选中的边缘节点，前一时刻所占用带宽向当前时刻的缓存叠加比例由 5%（下取整）调整为 1%（下取整）。

该变更点一出，我就发现，每个时刻任意选取的20个边缘节点只会占用下一时刻1%的缓存，此为问题的关键点。由于边缘节点采用 95 计费规则 , 那我们就应该充分的利用不计费的那 5%个时刻，而不同的边缘节点不计费的那5%个时刻的重复出现概率低，且某个时刻为不计费的边缘节点超过二十个的概率更低。因为这是带宽请求的数据特性决定的，若是所有边缘节点的95分位数都是接近或达到自身带宽上限，那并没有优化的必要，需要做的是开更多的边缘节点。而根据极端平均的带宽请求计算，20个边缘节点不计费的5%时刻都不相同情况下，这些时刻才能凑足整个时间序列，而如果每个时刻有20个边缘节点是白嫖尽量多的带宽，那么就要使用400个边缘节点，实际上题目给出的边缘节点个数小于等于135个。并且也可以从客户节点个数小于等于35个，带宽值不大于80,000MB，而边缘节点个数小于等于135个，提供带宽上限不大于1,000,000MB，进行侧面估算是否有较多同时刻为不计费的5%时刻的边缘节点。

在计算成本时，某个边缘节点的不计费的5%时刻都使用满的100万带宽，则因为5%的缓存叠加到下一时刻，该边缘节点最少有一个时刻带宽的大于等于5w，则95分位数也会大于等于5w，大部分情况下是无法接受的（针对不同数据集也有特例），而减少免费使用5%的时刻，变成免费使用大于等于2.5%小于等于5%的时刻，也会导致有更多的请求带宽流分流到各个服务器的95分位数，并且会导致中心节点成本增加。而现在将这些不计费的5%时刻缓存叠加比例由 5%调整 1%，可以考虑填满更多不计费的5%时刻，也不会导致95分位数计算成本过大，并因带宽流能更好的聚合而降低中心节点成本。而95分位数（尽量小于V=2,000MB）及以下的带宽的5%的缓存叠加和1%的缓存叠加的差异并不大，并不需过于考虑。

不过在赛场上为了保险起见，是先将选择到20个边缘节点，尽量填满选择的不计费5%时刻，并计算缓存时叠加比例为 1%，结果出来成本为1016805，排名靠前，想法得到验证和代码没有bug后，将20个边缘节点增加到40个甚至50个，成本进一步降低，最终达到79w。

而实际输出时选择哪些边缘节点为缓存叠加比例为1%的答案是，只需每个时刻（从大到小排序得到）使用最大带宽的20个边缘节点作为下一时刻的输出即可，根据上述的估算与运行结果证明某时刻最大带宽的20个边缘节点已经必定包括了该时刻的所有的为大于95分位数的服务器。

能取得这样好的成绩，通过比赛总结下来最宝贵的经验就是“坚持”二字，我们视赛场为战场，废寝忘食，分工协作，不断优化代码，取得了最后的胜利！