首页 > 天池大赛 > 阿里巴巴全球调度算法大赛
  • 状态 举办方 第 1 赛季截止日期 总奖池 参赛队

    阿里巴巴全球调度算法大赛

    进行中 2018/08/14 ¥200000 454

    报名参赛

文件名称 (报名后可下载)

文件格式

scheduling_preliminary_app_interference_20180606.csv

.csv (680KB)

scheduling_preliminary_app_resources_20180606.csv

.csv (13MB)

scheduling_preliminary_instance_deploy_20180606.csv

.csv (1MB)

scheduling_preliminary_machine_resources_20180606.csv

.csv (174KB)

scheduling_preliminary_submit_sample_20180606.csv

.csv (203B)

1440-天池-cn.jpg

阿里巴巴全球调度算法大赛

在百万级的宿主机规模环境下,资源调度/管理系统显得愈发重要,如何在保证数据中心业务运行性能的同时,提高资源利用率,降低基础设施的成本是我们要考虑的核心问题。

此次赛题来自阿里巴巴生产环境中的一个子场景,并做了相应的简化。优秀的解决方案会对我们解决这个场景以及其它场景下的问题带来极大的启发。我们期待优秀的你和你的团队能够投入进来!

重要更新:赛题在611日有一次更新(赛题描述和数据),旧版的赛题已经彻底下线,请所有参赛同学以你当前看到的版本赛题为准,7月初开始的评测工作将以目前版本为准。由此给各位选手带来的不便,深感歉意。但我们相信,目前这个版本的赛题无论对于初学者还是资深的研究者,都是很有趣的。

1 赛题描述

共约6K台宿主机(machine),包含了若干种型号,约68K个任务实例(instance),其中一部分已经部署在宿主机上,还有一部分没有被部署。

要求: 设计调度算法,在满足要求约束的前提下,通过将全部未被调度的任务实例调度到宿主机上以及腾挪部分已经部署的实例的方式,得到最优的部署方案。最优部署方案指实际使用宿主机数目尽可能少,且宿主机负荷不能过高。请参考“执行与评分(初赛)”部分来获得更多关于最优部署方案的说明。

在解释数据格式、约束条件之前,为防止概念混淆,先给出几个定义,全文出现的概念以此定义为准。

实例(instance):一个实例是可以被调度到一个机器上的对象,在实际生产中,一个实例可以是一个docker容器

应用分组(App:一个应用分组包括很多实例(instance)。属于同一个App下的所有实例,具备相同的约束条件。一个实例能且只能属于一个应用分组

机器(Machine):机器是集群中的服务器,一个实例被可以被调度到一个机器上

 1.1 约束描述

任务实例到宿主机的分配,需要满足下列约束:

·   每个实例都标明了CPUmemorydisk3个维度的资源需求,其中CPUmemory以分时占用曲线的形式给出,在任意时刻,任意一个宿主机A上,所有部署在宿主机A上的实例的任意资源都不能超过宿主机A的该资源容量

·   另外还有PMPM三类资源,定义了应用实例的重要程度,任意一台宿主机上的部署数目不能超过该类型宿主机能够容纳的重要应用数目上限

·   混部集群时刻处于复杂的干扰环境中,所以我们需要满足一些规避干扰约束,一条规避干扰约束被描述为<APP_A, APP_B, k>,代表若一台宿主机上存在APP_A类型的实例,则最多能部署kAPP_B类型的实例。注意,k可能为0APP_AAPP_B也可能代表同一个APPe.g. <APP_A, APP_A, k>),代表同一台机器上最多可以部署的该APP的实例的数目

1.2 数据描述

问题一共包含四份数据表:instance_deploy.csv, app_resources.csv, machine_resources.csv, app_interference.csv

·   instance_deploy.csv

o  实例id

o  实例所属应用

o  实例所属宿主机: 

§ 注:当前未分配的实例,实例所属宿主机列为空

·   app_resources.csv

o  应用id

o  cpu分时占用曲线(每个点由< | >隔开)

o  mem分时占用曲线(每个点由< | >隔开)

o  disk申请量(标量)

o  P

o  M

o  PM

·   machine_resources.csv

o  宿主机id

o  cpu规格

o  mem规格

o  disk规格

o  P上限

o  M上限

o  PM上限

·   app_interference.csv

o  应用id1

o  应用id2

o  最大部署量

1.3 结果提交

1.3.1 格式(初赛)

提交的结果是一系列对应用实例进行分配或迁移的决策动作,顺序由第一行开始,到最后一行,格式为: 

<实例ID>, <目标宿主机ID>

<实例ID>, <目标宿主机ID>

<实例ID>, <目标宿主机ID>

<实例ID>, <目标宿主机ID>

... ...

·   要求

o  最终所有实例都要部署到宿主机中

o  不能出现无效的实例id或宿主机id

o  请保存为submit_<YYMMDD_hhmmss>.csv<YYMMDD_hhmmss>是结果生成时的时间戳,这是我们建议的结果命名方式

例子,

<实例的UID>, <目标宿主机的UID>
<实例的UID>, <目标宿主机的UID>
<实例的UID>, <目标宿主机的UID>
<实例的UID>, <目标宿主机的UID>
... ...

 1.3.2 执行与评分(初赛)

·   可执行性

o  决策动作会按文件从上到下的顺序串行执行,若遇到不可执行的操作,评价程序会中断,并直接开始评价当前状态的得分

·   评分

o  根据执行完提交结果的最终状态,计算成本分数total_cost_score

屏幕快照 2018-06-11 下午3.04.22.png

1.3.3 对方案的评测

·   初赛成绩以提交结果的评分为准

·   复赛阶段会要求排名前10的队伍提交代码与文档,进行方案评测。同时参考提交结果的评分及方案,进入决赛,角逐冠军

·   方案评测的细节,会于复赛前公布,基本会遵循以下原则:

o  求解时间短(例如1小时以内,具体要求复赛确定)

o  鼓励策略性模型(可以快速输出部分决策,但效果是前提)

o  鼓励创新性

o  鼓励灵活性

1.3.4 推荐的复赛提交格式(暂定)

在第二阶段比赛(复赛)接近尾声时,我们会要求排行榜排名前10的队伍提交针对复赛题目的计算出迁移方案的代码,进行线下评测。迁移方案和线下评测的标准会在“评价标准”中说明,如果参赛队伍不能提供代码、或者提交代码与结果不匹配,相应的排行榜成绩无效。

下面是对提交代码的要求,建议参赛选手按照这个要求组织自己的代码,方便在取得好成绩以后进行提交(代码结构见注1)。

·   数据文件夹data/*.csv

o    选手无需提交数据文件,我们会把初赛复赛用到的所有原始文件(与官网上的文件和文件名一致)放到data文件夹下,选手生成的中间文件也放入该文件夹。注意的是,初始的时候data文件夹会被清空,并只放入原始文件

·   代码文件夹code/*.py (也可以用其他语言编写)

o    读入文件的路径尽量使用相对路径,比如../data/XX.csv

o    要有main.py或者main.ipynb去运行所有代码得到最后结果(或其它编程语言的main),并将结果保存到submit文件夹

·   结果输出文件夹submit/*.csv

o    存储提交的csv文件

o    提交文件名称submit_Ymd_HMS.csv(e.g.submit_20180203_040506.csv)

·   代码的随机

o    对于用到随机数的步骤,设定随机数。如果未设置随机数导致结果有随机性,将进行多轮运行取平均的方式,如果随机的误差大于提交结果与答案间的误差将被取消决赛资格。由于代码会运行多次,为避免覆盖结果文件,请选手将每次生成的结果文件以时间方式命名,如注2所示

1:提交文件夹结构

·    project

·    |--README.md

·    |--data

·    |--code

·       |-- main.py or main.ipynb or <其它语言代码>

·    |--submit

·       |-- submit_20180203_040506.csv

2:提交文件文件名代码

·    # java for example

·    import datetime

·   data.to_csv(("../submit/submit_"+datetime.datetime.now().strftime('%Y%m%d_%H%M%S') + ".csv"), header=None, index=False)

1.4 你可以用这份数据设计其它算法

下面的要求不是比赛的一部分,但同样是数据中心资源调度关心的目标。爱好者可以根据这份数据设计以下面需求之一为目的的调度算法。我们十分欢迎您与我们交流您的想法!

1.   同样是上述数据和问题,设计在线调度算法。所谓在线调度算法,是待调度的任务顺序地被调度器调度,而调度器不知道待调度任务序列中靠后的任务的信息。实践中,在线算法只能接近,但很难达到离线算法的效果。

2.   让算法更robustness。实际环境中,大量数据为建模预估产生的模型化数据,例如赛题中的cpu, mem分时占用曲线,如何在预估数据存在偏差的前提进行问题求解,或者如何在已知决策模型的前提下调整预估方法,也是充满挑战的问题。

3.   其它任何你能想到的使用这份数据可以设计的问题和算法。如果你对这个有兴趣,我们相信你会对我们第二阶段的比赛更加有兴趣,请保持关注并一定参加我们的正式比赛!