2022华为软件精英挑战赛比赛经历
提示：本文为本博主与@QianjunYunyu共同创作
文章目录
- 前言
- 一、软挑的基本形式与内容
- 二、初赛阶段的赛题与方案介绍
- 1. 赛题介绍
- (1) 题目介绍
- (2) 约束条件
- (3) 优化目标
- 2. 方案介绍
- (1) 思路分析
- (2) 初步方案设计
- 1. 排水法
- 2. 网络流
- (3) 方案验证与分析
- 1. 训练赛阶段
- 2. 正式赛阶段
- 三、复赛阶段的赛题与方案介绍
- 1.赛题介绍
- 2.方案介绍
- (1) 思路分析
- (2) 初步设计方案
- (3) 方案验证与分析
- 3.主要困难点与细节问题
- 四、决赛阶段的赛题与方案介绍
- 1.赛题介绍
- 2.方案介绍
- (1) 思路分析
- (2) 初步设计方案
- (3) 方案验证与分析
- 3.主要困难点与细节问题
- 总结
前言
本文主要是介绍本人与队友在参加2022年的华为软件精英软件挑战赛（后续内容简称软挑）的比赛过程与思路，前后共历时累计一个半月的时间，拿到了初赛阶段粤港澳赛区第8名，复赛阶段粤港澳赛区第4名，全球总决赛阶段第27名的成绩，并获得了华为公司所有软件相关岗位的主管面直通资格。正文先是介绍软挑的基本比赛形式，以及2022软挑的基本比赛内容，然后再分别对初赛、复赛以及决赛的比赛内容与代码方案进行介绍，最后总结整个比赛的经验与教训。由于初赛、复赛、决赛的赛题是层层递进的，所以我们会比较详细的介绍初赛的赛题与思路，然后复赛阶段和决赛阶段的赛题与思路仅仅针对变更点进行详细阐述。
代码点击参见github链接：https://github.com/Little9CUI/2022CodeCraft/tree/master
一、软挑的基本形式与内容
- 赛制：软挑的整个比赛形式分为初赛、复赛、决赛三个阶段；每个阶段先是进行10天左右的训练赛，选手可以线上提交代码，然后根据官方的判题器进行评分并排名（训练赛阶段的排名仅仅作为参考，可以方便选手知道自己代码方案的优劣从而合理选择代码迭代方向）；正式赛阶段时间较短（初赛阶段的正式赛为3天，复赛与决赛均为3小时），相较于训练赛，会进行小的题目变更，选手需要在短时间内调整代码方案并进行有效的版本迭代。
- 奖励：2022年的软挑共分了8大赛区，共3291支队伍。初赛阶段，每个赛区的前32名可以获得进入复赛的机会，并拿到华为的机试绿卡（免除机试），前64名可以获得参赛证书；复赛阶段，每个赛区的前4名（因为意外情况，今年临时增加了复活赛，每个赛区额外增加了2个决赛名额）可以进入决赛，并可获得华为的面试绿卡（免除华为两轮技术面试）与一部华为手机；决赛阶段，前8名可以获得奖金。
- 赛题：此次赛题以华为云视频直播服务流量调度问题为基础，并进行一定的抽象调整和简化，关注如何实现云上资源的最优规划和调度问题。赛题的核心类似于边缘计算的任务卸载问题，需要尽量降低任务计算成本。赛题要素主要包含：N个边缘计算节点，以及M个用户节点；时间离散化为T个时刻；每个时刻中，不同用户有多个不同的任务需求；成本计算主要围绕“95分位”这一概念进行梯度计算，因为计算规则比较复杂，所以后续再对这一点具体展开介绍。
二、初赛阶段的赛题与方案介绍
1. 赛题介绍
(1) 题目介绍
假设共有M个客户节点与N个边缘节点，现按照时间线进行流量调度。每个时刻，客户都会有不同大小的流量需求。现需要给出一种流量调度策略，在每个时刻给出一种流量分配方案，在满足给定限制条件下，总的边缘节点代价最小。在任意一个时刻，每个客户节点的需求可以分配到任意多个边缘节点上。同时，每个边缘节点也可以满足多个客户节点的需求。
下图为题目示意图。
(2) 约束条件
a. 客户节点方面的限制：每个客户节点在每个时刻都有固定的流量需求，给出的分配方案必须刚好满足该客户在对应时刻的流量需求。
b. 边缘节点方面的限制：每个边缘节点都有自己的带宽上限，要求分配方案中，每个时刻，分配到该边缘节点的总流量不能超过其流量上限。
c. 客户节点与边缘节点之间的限制：每个客户节点与每个边缘节点之间都有固定的时延。在制定流量调度分配的策略时，为某个客户节点选择某个边缘节点分配流量时，他们之间的时延不能超过给定的时延上限。
(3) 优化目标
a. 定义95百分位带宽：对一个边缘节点所提供的的带宽的值序列进行升序排序，以其95%位置（向上取整）的带宽值作为该节点的95百分位带宽。
示例：假设一个节点的带宽序列长度为8928。首先对这8928个带宽值升序排列。其95%位置是8481.6，向上取整为8482。则以排序序列中第8482个点的带宽值，作为这个节点的95百分位带宽 ( Ps:这里的带宽序列中的每一个值都是对应时刻边缘节点的总带宽请求)
b. 优化目标为：使所有边缘节点的95百分位带宽之和最小。
2. 方案介绍
该方案获得了粤港澳赛区第8的成绩，并进入复赛。初赛的整体方案为，先充分利用零成本时刻进行分配尽量多的数据流 ，然后第二阶段对于剩余的未分配的数据流，按照从大到小的顺序，尽可能的使得所有边缘节点中分配的数据流总量相近。第三阶段，对初始方案进行优化调整，通过降低95分位对应的数值，以及置换零成本时刻，获得较大的的优化效果。
(1) 思路分析
- 对赛题的理解：我们需要在每个时刻给出一个流量分配的方案，满足所有的限制条件，并且尽可能的使边缘节点的开销最小。
- baseline思路：只需要给出一个解即可，在满足限制条件的情况下，给出每个客户节点的流量去向。能想到的解法有：制定一个固定的分配策略、最大网络流算法分配策略、粒子群优化算法。
- 后续优化思路：优化思路主要是想着要朝着如何利用95计费这一点来考虑，具体的方案演进会在后续的方案验证与分析那里考虑。
(2) 初步方案设计
1. 排水法
此版本为我们的baseline思路，目的是求出一个解。
该策略在不考虑降低成本的情况下，为每一时刻的所有客户节点分配流量。分配策略为：按照连接的边缘节点顺序开始分配，如果一个边缘节点分配满了就换下一个边缘节点。
如果所有连接的边缘节点都达到了流量上限，启动“排水”算法，把流量看成水流，服务器看做是水桶，将满了的边缘节点里的水（流量），经过该流量所属的客户节点排到该客户节点所连接的其他桶（边缘节点）里。
这种策略可以保证能求得一个解，但是不保证优化效果。
2. 网络流
此问题可以建模为一个经典的网络流问题，
- 假设有一个无限流量的源节点和一个目标节点，中间为客户节点和边缘节点。将源节点和所有客户节点之间建边，目标节点与所有边缘节点建边，每个客户节点与时延小于时延限制的边缘节点之间建边。
- 源节点与客户节点之间的边容量为当前时刻的客户节点的流量需求，客户节点与目标节点之间的边容量无上限，目标节点与边缘节点之间的边上限为对应边缘节点的带宽上限。
- 使用最大网络流算法，同时记录每条边分配的流量，这样客户节点与边缘节点之间的边上分配的流量进行输出，就是所得的分配方案。
最大网络流算法参考学习笔记: https://zhuanlan.zhihu.com/p/122375531
(3) 方案验证与分析
此模块中中记录了我们初赛以及正式赛期间大的优化点
1. 训练赛阶段
- 方案1 baseline结果.
- 方案2 baseline结果
- 优化1
(1) 方案2优化思路：可以使用最小代价最大网络流，对网络的代价进行定义，套用该算法，由于时间问题，我们没有深入研究该算法，所以在这里不做过多介绍。
(2) 方案1优化思路：对选边缘节点的策略进行优化，充分利用95计费的规则，定义每个边缘节点都有5%的白嫖时刻，即开了这个服务器，不管用多少流量都不花钱。
具体思路见下图
提交结果有明显优化
- 优化2
在得到初始解之后进行动态调整。
具体过程：对每个边缘节点的分配结果进行排序，找到第95%个时刻，尝试将这个时刻的“水”排到其他边缘节点里，同时还能不提高其他边缘节点的95时刻值，直到该时刻降低到前一个时刻的值；然后同时尝试降低该时刻和前一个时刻，目标是降低到再往前一个时刻的值，不断重复这个过程，直到某一个时刻降低不了了。示意图图下：
提交结果有一定优化
至此训练赛阶段结束，排名粤港澳赛区45名
2. 正式赛阶段
正式赛沿用训练赛的分配策略版本，即排水算法（白嫖边缘节点+动态调整）
- 新的数据集直接提交
- 优化1
此优化针对动态调整部分，在之前的版本基础上，如果发现某一个时刻降不下去了，尝试降低白嫖时刻的值，降低到95时刻以下，同样降低的前提是不能提高其他边缘节点的95时刻值，这一步的目的是，初始解里对每一个边缘节点白嫖时刻的选择可能不是最优解，在这里可以对边缘节点的白嫖时刻进行重新选择，也给整个动态调整的过程增加了更多的操作空间。示意图如下：
优化有明显效果
- 优化2
此优化针对初始解的求解部分，白嫖部分的目的是要充分利用边缘节点的免费时刻，尽可能的满足更多的客户需求，这样需要费用的边缘节点的流量就会减小。
之前的策略是对所有时刻的客户总需求进行排序，然后从需求最大的峰值时刻开始进行分配，这样的问题是，可能在峰值时刻打开了某个边缘节点，但是它所连接的客户节点的总需求并不是很多，这样就会造成一定的资源浪费。
我们的解决方案是：如果从边缘节点的角度出发，分配的顺序定为，需求最大的那个边缘节点对应的需求最大的时刻开始进行分配，这样可以保证每个边缘节点的白嫖时刻都能分配最多的流量值。
(1) 分配开始，记录每个边缘节点每个时刻所连接的客户的总需求，对其进行排序，由于这个数据结构在分配过程中需要不断进行调整，我们只需要拿到每个边缘节点最大需求的那个时刻，所以这里对每个边缘节点建立一个堆，里面存储着这个边缘节点所有时刻的客户总需求。
(2) 在分配过程中，不断维护每个边缘节点的堆结构，如果某个客户节点在某个时刻的流量得到了分配，需要将其影响到的所有边缘节点的堆结构进行调整，以保证堆顶元素永远都是边缘节点最大的需求时刻。
最终的算法结构为：
(1) 最大白嫖：按照前面提到的顺序，将所有边缘节点的白嫖时刻全部用完。这一步之后，再打开任何一个边缘节点都要产生开销。
(2) 按照之前的分配策略，优先放满已经打开的边缘节点，集中分配的原则，即尽可能少的打开需要花钱的边缘节点。
(3) 动态调整策略：先降低95时刻以及95时刻之前的时刻，然后降低白嫖时刻的值。
优化有明显效果
最终正式赛粤港澳赛区第8名，进入复赛
三、复赛阶段的赛题与方案介绍
1.赛题介绍
复赛赛题相较于初赛的赛题，主要有两方面的变动
- 在每个时刻，会有若干种视频直播的数据流。在任意时刻，每个客户节点对于每种流会有带宽需求，为了实现流的流向端到端可追溯，在每个时刻，一个客户节点对一种流的带宽需求需要不可拆分地分配到一个边缘节点。
- 成本计算中，每个边缘节点额外增加了基础成本；同时，边缘节点的成本不再随着承载流量总值的增加而线性上升。具体的成本计算方式如下：
先介绍一下成本计算的步骤：
额外增加的限制条件——不可拆分的流分配
2.方案介绍
该方案获得了粤港澳赛区训练赛第4，正式赛第4的成绩。复赛的方案整体上基于初赛的算法框架，先是采用贪心的策略，利用“95分位”这一点，尽量分配更多的任务到边缘计算节点的免费时刻；在第二步，修改策略为，每次分配的时候，将任务卸载到产生cost最小的边缘计算节点之上；第三步的优化调整，进行了符合条件的代码更新，使得在调整任务分配情况时，是整个任务块进行调整位置。
(1) 思路分析
- 不可拆分的问题：由于数据流不可拆分，因此初赛时所考虑的网络流解法不再适用。因为网络流算法涉及到反向边这一概念，从最终结果上来看，会导致数据流的拆分。
- 由于依然使用“95分位”这一概念，所以贪心策略的方法依然可以尝试。
- 由于成本计算不再是所有边缘计算节点的“95分位”对应数值的累加和，所以贪心的目标需要进行较大的改动。一方面，一旦某个边缘节点被卸载了数据流，那么只要其“95分位”对应数值在V以下的增长都不会带来成本的提升；另一方面，数值超出V的成本计算，与边缘节点容量以及当前已分配数据量有关，边缘节点容量越大，已分配数据量越少，再分配数据产生的新成本就会越低。
- 初赛中调整优化的部分也需要较大的变动，因为每次调整需要调整一个完整的数据流，而不再是可以按照数值比较随意的调整，这带来了很大的限制。
(2) 初步设计方案
- 与初赛第一阶段思路相同，先尽可能的利用零成本的5%时刻点进行分配更多的数据流。这一部分主要是包含选择边缘节点，以及对边缘节点所连接的数据流进行分配这两个子部分。尝试了多种贪心的策略，主要包括：
a. 计算不同时刻，不同边缘节点分别所连接的数据流大小总和，然后进行排序，按照排序后的结果，选出连接数据流总量最大的，且有剩余零成本时刻的边缘节点。然后对于该边缘节点，按照其所连接数据流的大小，由大到小向该边缘节点进行分配。之后，不考虑已经分配的数据流，重复上述步骤，直至所有的边缘节点不再剩余零成本时刻。
b. 分别计算不同时刻总的数据流总量，排序，然后将前5%对应的时刻作为所有边缘节点的零成本时刻，并将对应时刻的所有数据流随意分配即可。
c. 跳过这一步。 - 第二阶段的思路为，分别将所有时刻的所有边缘节点分配内容填充到V这一总值。
- 第三阶段的思路为，将所有剩余的未分配的流进行排序，然后由大到小进行分配，分配的具体过程为，分别计算该数据流分配至所连接的边缘节点的成本，选择成本最低的进行分配。这一阶段进行排序后分配的考虑，主要是认为小的数据流，可以更方便的对不同边缘阶段的分配效果进行微调，类似于用瓶子装石头与沙子的问题，先装石头后装沙子可以装下更多。
- 优化调整部分：该部分依然沿用初赛的整体设计思路，包括两个核心部分：降低95分位节点的数值、压低已分配的零成本时刻数值实现零成本时刻的置换优化。但是在设计的时候，需要单个完整的数据流进行调整。但是，对于复赛的成本计算方式，我们对该阶段进行了一点的优化。成本越高的边缘节点，其一定程度上弹出一个数据流能带来更大的成本的降低，因此，在调整的时候，我们优先去降低成本更高的边缘节点。
(3) 方案验证与分析
- 第一阶段，采用a方案可以取得较b方案更高的效果；采用c方案的想法，主要是考虑将更多的数据流按照第三阶段的成本计算的方式进行分配，或许能达到更好的分配效果，但是存在的问题是，如果没有第一阶段将大量的流进行分配，那么第三阶段，每个流都需要进行多次计算cost，会导致代码运行超时。
- 对于阶段b，其效果主要是可以在第三阶段之前分配更多的流，大量减少第三阶段的时间，但是该阶段的负面效果是，其将大量的小数值的流进行了分配，不利于不同边缘节点成本利用小流进行微调。所以是否跳过这一阶段，均需要正式赛的尝试。
- 对于第三阶段和第四阶段，则没有过多的思路上不同的方案。
训练赛阶段的最终成绩为第四名
正式赛中，题目变更为：可以自主选择10个边缘节点，其成本计算的数值采用90分位，其余的依然采用95分位。正式赛仅仅三个小时，我们没有做太多的变更，仅仅是选择了95分位与90分位对应值差别最大的10个边缘节点。最终正式赛的成绩同样为第四名。
3.主要困难点与细节问题
- 时间优化问题：复赛阶段，我们花费了很多的时间在时间优化上，主要是为了能使得优化调整部分进行更多次的调整，从而对所求得的初始解进行更优的改进。主要是包含了几个部分：a. 在第一阶段选择边缘节点的时候，由于每次选择一个之后就需要更新排序，所以这个部分采用了大顶堆的策略，降低寻找最大值的时间复杂度；b. 优化调整部分，每次降低了95分位对应数值之后，需要重新排序，为了降低复杂度，我们采取了局部排序与整体排序交替的策略，每次排序仅仅对95分位前后长度为m的序列值进行重新排序，并在进行了n次排序之后进行整个序列的排序，只要保证m与n满足一定的关系，则可以保证这种策略排序后的95分位数值是正确的。
- 优化调整部分的死循环：复赛阶段每次调整一整个数据流，会在逻辑上导致一种死循环——对于两个边缘节点A，B，如果其存在某一时刻t1均为两个边缘节点的零cost时刻，并存在某一时刻t2均为两个边缘节点的非零cost时刻。那么，就会存在导致动态调整在 t1的A节点->t1的B节点->t2的B节点->t2的A节点->t1的A节点 的循环中不断地优化调整。为了解决这一问题，在每个边缘节点的实例中，增加了一个bool类型的数组为属性ifCanDown，一旦某边缘节点的某一时刻，是在“压低已分配的零成本时刻数值实现零成本时刻的置换优化”过程中被判定为零cost时刻，则将对应时刻的值置为true，后续降低零成本时刻的节点的数据流分配量时，先判断ifCanDown属性的对应时刻是否为false，如果是则直接跳过。通过这种方式，能打破死循环，并加快了优化调整的单次过程。
四、决赛阶段的赛题与方案介绍
1.赛题介绍
决赛赛题基于复赛赛题进行改动，主要是变动如下：
- 额外增加了中心节点这一要素，是边缘节点的上一层网络节点。边缘节点从中心节点获取流满足客户节点的带宽需求。在分配的时候需要同时考虑中心节点产生了cost。
- 额外增加了cache这一要素，当前时刻的分配结果，会连续对后续多个时刻产生影响。
具体差异如下所述：
- 在每个时刻，边缘节点会根据客户节点向该边缘节点请求流的情况从中心节点获取流。如果只有一个客户节点请求某个流，边缘节点向中心节点请求该流所需的带宽大小等于客户节点该流的带宽需求；如果多个客户节点向同一个边缘节点请求同一个流时，边缘节点向中心节点请求该流所需的带宽大小为这些带宽需求当中的最大值。某个时刻边缘节点和中心节点为客户节点分配的带宽资源示意图如下：
- cache的问题：因缓存机制，前一个时刻边缘节点所占用的带宽的 5%（下取整）会叠加到下一个时刻的带宽用量。为了简化问题，这部分叠加的带宽不会影响下一个时刻向中心节点请求的带宽量，只影响边缘节点的可用带宽。每个时刻，边缘节点占用的带宽总量为从客户节点接收的带宽需求加上来自于上一时刻叠加的带宽用量，不超过其带宽上限。
- 边缘节点的成本计算方式
- 中心节点的成本计算方式
在每个时刻，边缘节点会根据客户节点向该边缘节点请求流的情况从中心节点获取流。如果只有一个客户节点请求某个流，边缘节点向中心节点请求该流所需的带宽大小等于客户节点该流的带宽需求；如果多个客户节点向同一个边缘节点请求同一个流时，边缘节点向中心节点请求该流所需的带宽大小为这些带宽需求当中的最大值
- 总的成本优化目标
2.方案介绍
该方案获得了全球总决赛训练赛第13，正式赛第27的成绩。决赛的方案整体上基于复赛的算法框架，先是采用贪心的策略，利用“95分位”这一点，尽量分配更多的数据流到边缘计算节点的免费时刻，不过为了处理cache这一条件，分配连续的零成本时刻窗口，而不是离散的零成本时刻点；在第二步，考虑到中心节点的成本问题，修改策略为，每次分配的时候，将任务卸载到产生cost最小的边缘计算节点之上，但是数据流的分配顺序考虑到类型差异；第三步的优化调整，在复赛的基础上，优化调整时增加限制——“不抬高中心节点的成本”。
(1) 思路分析
决赛的变动点，导致题目非常的复杂，主要的问题如下：
- 对于缓存机制这一限制：初赛与复赛阶段，选手的策略大多是不同时间的分配方案上相互解耦的，而缓存机制的引入，则使得之前的方案需要发生较大的变动，甚至需要放弃之前的思路。这一限制有两个思考方向，一是按照时刻的先后顺序进行分配，这样就可以在对某一时刻t进行分配的时候，直接计算出前一时刻对该时刻的缓存，从而避免超出边缘节点的上限；另一个思考方向就是，每次分配某一时刻的边缘节点，就将该时刻的分配方案对后续多个时刻产生的影响进行分析，并将利用数组记录对后续时刻带来的缓存影响。
- 中心节点成本：针对这一问题，我们的考虑是，尽量在同一个边缘节点中放置同种类型的数据流。但是这个部分会考虑起来会比较复杂，因为同一类型的流往往会存在很多个较大的流，放在同一个边缘节点中就会导致边缘节点的成本比较高。因此，降低边缘节点的成本和中心节点的成本似乎是一个矛盾点。针对这个问题，我们只能是采用做一些测试的方法，验证如何才能更好的降低
(2) 初步设计方案
- 第一阶段：由于第一阶段主要是充分利用零成本时刻进行分配，之前的方案会将该边缘节点的容量充满，所以在这个地方需要进行缓存的计算。以下是几个思考方向
a. 最直接的思路变更为：每分配一个时刻，就计算该时刻对后续时刻造成的影响，降低后续时刻的可容纳带宽。主要是利用递归的方案进行缓存的计算，直到当前时候的分配对后续第n个时候的影响为0，则停止递归。
b. 按照时间顺序从前往后进行设计分配方案
c. 利用窗口的形式，设计连续的零成本时刻窗口，窗口内部按时序进行分配。、
另外，在选定了边缘节点之后，针对其进行分配时，考虑中心节点的成本，按同类型优先分配的策略。 - 第二阶段：原本的思路是，在分配时，在复赛的版本上，计算分配某一数据流所增加的边缘节点与中心节点成本之和。但是计算中心节点的成本，需要记录每个边缘节点在每个时刻对每种类型的流的分配情况，这一数据结构占用空间过大，不可行。因此，该部分，我们简化为只考虑边缘节点的成本。
- 第三阶段：优化调整时，测试了一下如果按照原本的思路，只考虑边缘节点的话，虽然通过调整会降低边缘节点的成本，但是会导致中心节点成本上升，所以必须增加对中心节点的限制
(3) 方案验证与分析
- 对于第一部分：我们首先排除了b，因为如果从0时刻开始遍历的话，相当于放弃了初赛复赛的思路，难以充分利用5%的零成本时刻。首先考虑的是a方案：a方案可以成功的应对题目的变更，可以依然没有比较不错的结果，整体成绩在训练赛的阶段始终是中等靠后，经过对线下数据集以及自己造的数据集的分配结果进行分析，我们发现缓存带来的影响很大，如果我们充分利用5%时刻的零成本时刻，那么这些时刻的带宽则会被抬得很高，就会对我们预计的非零成本时刻产生较大的初始分配量（缓存量），导致结果中边缘节点成本难以通过后续分配算法降低下去。如果进行简单的零成本时刻预留，最直接的方案那就是仅仅利用一半的零成本时刻，另一半为这些高分配量的下一时刻。通过这种方式，就可以使得，在下一阶段开始时，95分位的分配量为0.不过这种分配方案的问题在于，没有充分利用零成本时刻，仅仅使用了一半的零成本时刻。因此，我们考虑采用窗口的形式。窗口形式的好处是，我们可以控制，使用几个窗口，就可以预留几个零成本时刻。窗口内部采用按时间顺序处理的方式，即分配完某一时刻，直接计算造成的下一时刻的缓存值。而且通过这种方式，可以避免计算前面n个时刻对当前所分配时刻的缓存影响的问题，大大提高算法效率，为后面的优化调整预留更多的时间。具体而言，是引入超参数N，表示使用的窗口数量， 则窗口数量为W=（总的离散时间数量*5%-N）/ N。计算不同边缘节点的连续W时刻所连接的数据流的总值，然后排序，选数据流总量最大的进行窗口进行分配，分配时候，按照类型进行分配，从而实现对中心节点的控制。
- 对于第二部分，则采用复赛版本的计算方式进行处理
- 对于第三部分的优化调整，则是通过限制中心节点和边缘节点成本升高的基础上进行调整的。为了降低计算中心节点成本所需记录的信息，我们在这一步进行了宽限制。我们使用一个三维数据，记录了每个时刻，有哪些边缘节点对每类流产生了中心节点的成本，这种记录仅仅需要记录每个边缘节点每个时刻分配的每种流的最大值。然优化调整的时候，如果每个边缘节点内某个流被转移走，并不降低对应其分配的该类流的最大值，仅仅对转移进来数据流，超出对应记录的最大值时，将该值抬高。
训练赛阶段，我们是在倒数第二天才将第一阶段采用窗口式分配的策略写出来，并将排名从第35名提升到了第13名。但是，由于最终版本直到倒数第二天才写出来，后续补充了一些优化，以及更新了第三阶段的优化调整部分，却没来得及提交验证，最终在训练赛结束的时候是第三名。
正式赛阶段，题目变更点为缓存机制，每个时刻可以选择10个边缘节点，其对下一节点的缓存余量与该时刻分配值的1%，其余未做变动。我们将训练赛代码提交上去之后拿到了第10的初始排名，但是由于训练赛结束后补充的代码提交上去后发现有些问题，因此分出一名队员去改进之前所优化的代码，另外一个队员针对变更点进行更改算法，以及另外一名成员编写我们自己的判题器。可是由于缓存机制在我们的代码中过分复杂，导致三个小时内只写出了一个针对正式赛变更点的优化版本，最终很遗憾的只拿到了正式赛第37的成绩。
3.主要困难点与细节问题
- 缓存计算时的进位问题：在递归计算缓存时，因为题目中要求缓存进位的问题，而我们又不能预知递归时某一层的后续分配流量总值，所以需要在递归的时候预留1的空间。
- 第一阶段得时间优化问题：计算连续窗口内所连接数据流总量的时候，采用双指针的方法进行处理，是leecode中计算数组连续位置最大和的经典题目；然后在分配完一个窗口之后，在进行重新计算不同窗口覆盖数据流总值的时候，依然采用双指针的方法进行处理，不过是利用双指针的方法进行一定的减法处理，同时利用大顶堆的方案，调整计算新的窗口覆盖最大值。
- 缓存的多时刻影响问题:我们处理某一边缘节点的某一时刻，不能仅仅只看前一时刻的分配值，因为不仅仅前一时刻的分配值会导致该时刻有一定的缓存，前n个时刻进行分配数据流，都会间接的给当前时刻带来缓存，这是一个很复杂的过程，需要利用递归的方法计算，也就是说，所分析节点的某一时刻的可分配数据流上限，需要先计算前n个时刻造成的缓存，而且n还不是定值，这种分析会大大降低算法效率。
总结
回想整个比赛的过程，确实是挺有压力，也挺疲惫的，但是也学到了很多。
通过这场比赛，我进一步认识到了平时刷题，以及学习数据结构和算法的意义。自认为，这场比赛所考验的，首先是良好的思维能力与分析能力，需要能对题目求解有一定的想法以及准确地求解大方向；其次是良好的语言基础与代码思维，能设计具有合理的时间复杂度以及空间复杂度的代码，比如合理的数据结构的设计，以及双指针、大顶堆等算法；然后比较重要的是，代码能力要比较强，能够实现比较快的版本迭代和算法实现，在训练赛中，很难直接找到良好的求解思路，需要对许多思路尝试，对尝试的思路进行优化，在正式赛中，又要在很短的时间内针对变更点要进行算法更新；最后，要有一定的问题分析能力，能针对现有的结果，以及存在的问题分析并提出有效的优化方向。达到以上这几点，应该可以成功的进入到复赛。
感觉进入复赛的有很多大佬，一度想放弃，感谢队友的打气才让我们坚持了下来。所以，对于复赛的感受，首先要提的就是坚持。10天的时间，大家都在刷榜，看着榜单起伏，一天天的在会议室内讨论思路，分析问题，真的很难熬，尤其是成绩不佳的情况下。另外，从能力角度来说，复赛的体验告诉我们，在初赛编写初始代码方案的时候，要做好代码的版本管理，以及功能封装，这样子在版本迭代的时候会非常方便并且准确；另外，一定要仔细分析总结，捋清楚思路中的可提升点与潜在问题之后再去写代码，复赛想拿到靠前的名词，除了代码能力和运气之外，一定是要有清晰地思路，而不是单纯的思路尝试。
进入到决赛，真的是有一定的运气成分。在后面的交流中发现大家初赛复赛的主体思路基本一样，可能只在某些细节上处理方案不同，最终幸运的凭借略微的优势进入到决赛。其实决赛阶段还挺快乐，我们终于返校，能线下交流方案了。并且进入决赛并拿到绿卡，对今年要找工作的我们而言已经满足了，所以决赛过程大家没有太大的心理压力。
2022的软挑，我们承受了很多的压力，付出了很多的努力，但是每当有突破点的时候，那种兴奋令人印象深刻…决赛的体验，也是非常棒，华为为决赛选手组织的活动，真实很愉快的一次体验，尤其是今年是游轮体验，给我们队伍一次很好的出游体验。
从2021年上半年参加软挑没有拿到获奖证书，到2021暑假进入嵌入式大赛的复赛，到今年软挑进入决赛，再到今年的嵌入式用三天时间做出一个进入复赛的方案…真是的感受到了我们队伍几个人的成长与默契的提升，很庆幸。
2022华为软件精英挑战赛比赛经历相关推荐
- 2019华为软件精英挑战赛比赛经验分享（初赛，复赛，决赛）
比赛成果: 初赛(700+):西北赛区第3. 复赛(32):西北赛区第3.(华为手机v20,华为面试绿卡,西北赛区二等奖,小礼物若干) 决赛(32):全国16强,具体排名13.(没有奖金,纪念品若干, ...
- 2021华为软件精英挑战赛（附赠线下判题器链接）——经历
2021华为软件精英挑战赛(附赠线下判题器链接)--经历 1.题目解析 本次赛题源自现实的互联网企业面临的问题,怎样购买与部署服务器最便宜! 服务器:不相同型号的服务器有着不同的CPU与不同的内存,每 ...
- 2022年华为软件精英挑战赛区域初赛解读（基于数学规划模型附代码）
0 写在前面的 本文是对2022年华为软件精英挑战赛(普朗克计划)区域初赛的一个解读.首先说明的是本文的算法无法直接拿来参赛的,因为区域初赛的要求是不能调用其它的算法包,python的话只能用nump ...
- 2017华为软件精英挑战赛参赛过程回顾与心得
参赛队名:武长区 枪林弹雨 2017年4月26日,一波三折的复赛终于结束了,我们队最终没能进入决赛.虽然在意料之中,不过还是有些小失望.已经为这个比赛忙了一个月,突然之间不知道干什么好了,干脆写一写自 ...
- 2023华为软件精英挑战赛，探寻软件人才与科技创新的最优解
作者 | 曾响铃 文 | 响铃说 今天,软件行业正呈现出江河入海一般的大汇流趋势. 一方面是技术的汇流,诸如人工智能等前沿技术与软件行业的深度融合,正全面颠覆软件产品的开发模式和服务逻辑. 另一方面则 ...
- 2016华为软件精英挑战赛：赛题及其答疑汇总
注:本文文字均摘自官方指定网站和论坛,权威且可信,答疑见中间部分,非常全,众玩家可放心阅读. 同时文末给出了包括自己在内的诸多玩家的解法. 前言 赛题源自"未来网络"业务发放中的路 ...
- 2021华为软件精英挑战赛（杭厦第20名）
写在前面 距离华为软件精英挑战赛结束也有一段时间了 我是浙工大投降战队的队长,第一次参加这种比赛能打到复赛我还是比较满意的 这次比赛我最大的收获就是认识了好多厉害的大佬 希望我们杭厦赛区晋级的战队总决 ...
- 2017华为软件精英挑战赛小结
// 2017华为软件精英挑战赛小结 // 不说废话,直接上货!希望对目前的参赛者,或日后学习的人,提供一些参考和思路. #include <赛题说明.pdf> // 见附录文件 ...
- 2018华为软件精英挑战赛
今天12点,历时一个多月的2018华为软件精英挑战赛训练赛结束了,最后分数215.597(总分300),很遗憾,前64都没能进,不过还算尽力坚持到最后. 3月初,华为软赛开始一周后,看到师兄他们在弄, ...
- 2021华为软件精英挑战赛总结分享
2021华为软件精英挑战赛总结分享 随着大赛的结束,自己的2021软挑也落下了帷幕,很幸运在自己学业生涯的最后几个月能够再参加一次华为软挑,虽然成绩不是特别好,但已经满足了.这是自己第二次参加华为的比 ...
最新文章
- Python基础23_os,sys,序列化,pickle,json
- matlab中conv滤波,其中是Matlab（imfilter）和TensorFlow中偶数滤波器（6x6）的中心像素(转速表nn.conv2d)?...
- 网络请求之get post
- Java虚拟机学习（4）：JDK可视化监控工具
- P2601 [ZJOI2009]对称的正方形（二维哈希）（二分）
- 修改 input 框里的字体、颜色
- java bytearrayoutputstream 文件_Java ByteArrayInputStream和ByteArrayOutputStream示例
- matlab机器学习安装,机器学习（一）：学习环境搭建
- iOS 常见的JS与iOS交互的需求与解决方案
- 前端工具类项目规范化-使用TS
- 快速了解SOLIDWORKS Simulation的有限元分析法
- Android10支持dcip3,dcip3 相当于多少srgb
- Mac上好用的音乐软件是哪个？MacOS专业音乐制作软件推荐
- javax.mail.MessagingException: Unknown SMTP host: smtp.163.com;
- Boyd 凸优化课后习题 求共轭函数
- 安卓手机格式化怎么弄_安卓手机怎样进入格式化？
- 定制化删除ES索引数据
- 当当李国庆谈“刘强东案”：虽煞风景，但划得来
- Webbench源码分析之多进程（三）
- 字符串匹配的三种算法