混部数据中心负载特征及其任务调度优化分析*

王济伟，葛浙奉，蒋从锋，张纪林，俞 俊，林江彬，闫龙川，任祖杰，万 健

(1.杭州电子科技大学计算机学院，浙江 杭州 310018；2.阿里云计算有限公司，浙江 杭州 311121； 3.国网电力信息通信有限公司，北京 100053；4.之江实验室，浙江 杭州 311121； 5.浙江科技学院信息与电子工程学院，浙江 杭州 310023)

1 引言

随着各类互联网应用的快速增长，企业及个人用户对云计算服务的需求与日俱增。互联网数据中心IDCs(Internet Data Centers)作为承载云计算服务的基础设施，发挥了越来越重要的作用。数据中心提供的服务可简单分为在线(如浏览型请求、交易型业务和支付型业务等)和离线(如科学计算、统计报告和数据处理等)2类。在线类服务要求较低的延迟，而离线批处理类任务要求具有较高的吞吐量。另外，由于任务时延过长或任务失败重试会影响用户体验，因此在线类服务往往不可降级。而批处理任务相对于在线任务，对时延不敏感，可以接受任务失败重试。

用户任务负载的动态性和多样性，使得数据中心内服务器资源的使用也会动态变化，既具有一定的周期性，又具有一定的波动性。为提高数据中心资源利用率，降低数据中心运行成本，云计算服务提供商逐步将在线服务和离线批处理任务在数据中心进行混合部署(以下简称混部)[1,2]。因此，在混部场景下，如何同时满足在线服务和离线批处理任务的不同要求，在提高资源利用率的同时，尽量降低2类任务之间的干扰，是目前互联网数据中心任务调度面临的关键挑战。

目前，大型互联网公司，如谷歌[3]、脸书[4]、微软[5]和阿里巴巴[6,7]等，都采取了在线服务与离线任务混部的方式以提高数据中心的资源利用率。但是，由于在线服务和离线任务的资源需求和资源使用特性的差异，数据中心集群调度器将服务器资源在不同业务间复用和共享的同时，需要在资源竞争时优先保证高优先级业务的资源需求。以阿里巴巴的集群管理系统为例，阿里巴巴的多个数据中心于2015年逐步开始混部，通过逐年提高集群中机器的混部比例，以确保其在实际生产环境中的可靠性。

阿里巴巴混部集群调度管理系统主要由Sigma和Fuxi 2种调度器组成[8]。其中Sigma调度器负责Pouch容器[9](在线服务)的调度，Fuxi负责离线批处理作业的调度。由于同一集群上同时存在Sigma和Fuxi，机器上的CPU、内存、磁盘、网络带宽等资源会被这2种调度器争抢。为了避免机器上的资源被一方过度占用导致另一方无法正常工作，或者资源被闲置，无法得到充分利用，集群管理系统中设置了Level0模块来协调资源的分配。目前阿里巴巴采用混部的服务器已经达到数万台以上，将原来的单一在线原生集群的日均资源利用率从10%提高到了40%，并在“双十一”等特殊促销时期，将离线批处理任务进行业务降级处理，以满足激增的在线任务的资源需求。通过混部，在确保数据中心服务质量的同时，节省了30%以上的成本[6]。如果能够对数据中心负载特征进行更深入的分析，如负载的时间、空间特征及资源使用维度，则可以进一步挖掘集群的混部潜力，进而提高混部集群的资源利用率，降低数据中心运行成本。

本文根据阿里巴巴2018年12月公开的具有4 034个结点的混部集群的任务调度日志数据(cluster-trace-v2018)[8]，系统分析了典型混部数据中心的负载特征，并提出了相应的任务调度优化策略。本文工作如下所示：

(1)对离线批处理作业与在线应用的资源使用进行了分析，发现单个在线应用所包含的容器数量符合Zipf分布，表明混部集群中在线应用的规模都具有明显的倾斜现象(Task Skew)。该发现有助于集群调度相关领域学者与研究人员建立更为合理的调度优化模型。

(2)计算并绘制了离线批处理作业的DAG(Directed Acyclic Graph)关系图和每个作业的关键路径，计算了任务等待时间、作业通信时间等指标，并指出了可能的任务调度优化空间。

2 数据集概述

2018年12月，阿里巴巴面向公众开放了一个具有4 034个结点的混部集群运行日志数据cluster-trace-v2018(以下简称trace-2018)，图1是阿里巴巴混部集群调度管理系统示意图。与阿里巴巴2017年首次公开的混部集群数据集cluster-trace-v2017(以下简称trace-2017)相比，trace-2018的数据更丰富，具体体现在：(1)时间跨度更长，服务器数量更多。trace-2018中记录了混部集群中4 034台机器连续8天的运行状况，而trace-2017数据集仅包含1 300台机器在1天内的运行日志；(2)trace-2018包含了以DAG形式表示的离线批处理作业中任务间的依赖信息。

Figure 1 Architecture of the Alibaba co-located cluster management system图1 阿里巴巴混部集群管理系统架构示意图

trace-2018数据包含6个csv表格数据，涵盖机器、离线批处理作业、在线容器3类主体。每个主体包含1份静态信息表与1份运行信息表，如表1所示。接下来分别对机器、离线批处理作业、在线容器这3类主体的数据进行分析。

Table 1 Data tables in trace-2018表1 trace-2018数据构成

2.1 机器

trace-2018中的机器指混部集群中的物理服务器，这些机器既运行离线批处理作业，也作为容器宿主机，运行在线服务。machine_meta.csv表记录了机器静态配置信息，主要包括机器编号(machine_id)、容错等级(disaster_level_1和disaster_level_2)、CPU核心数量(cpu_num)、内存容量(mem_size)和状态(status)。该表包含每台机器1个或多个时间戳上的配置信息，记录了不同时间点机器的配置情况(但全表中未出现机器配置变化)。

machine_usage.csv记录了机器的实时运行信息数据，包括时间戳、CPU利用率(cpu_util_percent)、内存利用率(mem_util_percent)和硬盘带宽利用率(disk_io_percent)等。

2.2 离线批处理作业

离线批处理作业具有作业-任务-实例3层结构，即job-task-instance(为方便和数据集中字段参照，下文中将作业和job，任务和task，实例和instance交叉使用)。1个作业包含1个或多个任务，同一个作业的任务可能会有先后执行顺序的约束。1个任务包含1个或多个实例，同一个任务的实例没有先后执行顺序，每个实例可以被分配到不同的机器上以并行执行。图2给出了ID为j_87的作业的“job-task-instance”3层结构。

Figure 2 Internal structure of batch job j_87图2 批处理作业j_87的内部结构

2.3 在线服务容器

容器用于承载在线任务，常用于用户端内容搜索、电商平台交易等业务。在线任务具有很强的时延敏感性，其服务质量将直接影响在线服务的用户体验。因此，在线任务具有很高的优先级。1台机器上通常部署多个容器且不间断地运行。

container_meta.csv记录了容器的静态配置信息，包括容器编号(container_id)、容器所在机器编号(machine_id)、容器所属的应用组(app_du)、容器状态(status)、请求CPU核心数量(cpu_request)、CPU核心使用数量限制(cpu_limit)和容器请求的内存使用量(mem_size)。container_usage.csv表记录了容器的实时运行信息，包括CPU资源使用率(cpu_util_percent)、每指令时钟周期(cpi)、每千条指令缓存缺失次数(mpki)、内存使用率(mem_util_percent)、内存带宽使用率(mem_gps)、磁盘IO使用率(disk_io_percent)、接收网络数据包数量(net_in)和发送网络数据包数量(net_out)。

3 作业调度特征

离线批处理作业拥有“job-task-instance”3层结构，我们将job、task和instance的数量进行统计，如表2所示。

Table 2 Number of elements in “job-task-instance” hierarchy表2 “job-task-instance”层次结构中的元素数量

根据同一个job的task之间的依赖关系，可以将所有task分为3种类型，如表3所示。

Table 3 Example of DAG task names表3 DAG任务命名示例

(1)无DAG关系：该类task所属的job无DAG结构，其执行可以完全并行化。该类task的名称有2种形式：①以“task_”加上一段随机数字与字母组成的字符串，并以“==”结尾，本文称之为task_xxxx型；②“MergeTask”，本文称之为MergeTask型。

(2)有DAG关系、有依赖：该类task有1个或多个前驱依赖。其名称是单个大写字母与该task在job内序号的组合，加上“_”，后跟其依赖的task的job内序号构成。1个task可以有多个依赖。如表3中的示例J3_1_2表示job内序号为3的task“J3_1_2”依赖于job内序号为1和2的task。

(3)有DAG关系、无依赖：该类task所属的job有DAG结构，但是该任务本身不依赖于任何其它task。此类task可能成为其所属job包含的其余task的依赖。另外，存在task名称中包含“_Stg”的特殊情况。如名为“M9_Stg4”的task，此处的“_Stg4”不指代任何task。

表4给出了3类任务的占比。在所有的task中，只有少部分不具有DAG关系(15.98%)，且具有前驱依赖的task的数量几乎占总数的一半(47.07%)。

Table 4 Classification and statistics of tasks according to DAG dependencies表4 任务分类(有无DAG依赖)

图3展示了作业j_2041的任务依赖示意图。为了计算上的便利，我们添加了start和end节点；每个节点表示job中的1个task，节点中的数字表示的是task在job内的编号；图3中带箭头的有向边(x→y)表示2个task之间的依赖关系，如图3中task 1、2、3、5都依赖于task 4，而task 6依赖于task 1、2、3、5，有向边上的数字表示的是所依赖的task的实际执行时间，如有向边4→1上的值为5，表示task 4的执行时间为5 s，即task 1需要等待5 s(task 4执行完)才能开始执行。由于数据集中缺乏相关数据，我们没有考虑task间数据传输、任务调度等带来的其他时间开销，即仅考虑理想情况下的DAG图；图3中用灰色显示的节点及虚线有向边代表此DAG图中的关键路径，在该路径上的task执行时间之和最大。

Figure 3 DAG example of job j_2041图3 作业j_2041的DAG图

instance是离线作业中最细粒度的调度单位，我们根据其所属的task是否含有DAG关系，将所有instance划分为2类，如表5所示。在表5中，含DAG关系的task的instance调度次数占总调度次数的96.91%，这与前述的含DAG关系的task占总task数量的84.02%有一定差别。说明包含DAG关系的任务的规模大小不同，导致其中instance的调度次数不同。

Table 5 Scheduling numbers of DAG and noDAG instances表5 DAG型与noDAG型实例的调度数量

如表6所示，通过计算DAG型task与noDAG型task包含instance数量的均值，发现上述现象是由包含DAG关系的task平均包含更多数量的instance引起的。从表6可以直观地看出，noDAG型的task不仅没有依赖关系，在体积上也更为轻量，其包含的平均instance数量只有DAG型task的0.16倍，全体task均值的0.19倍。

Table 6 Number of instances in each type of task表6 各类型任务包含的实例数量

为了研究DAG型和noDAG型任务在调度instance到机器的过程中是否存在偏好，本文对所有机器上运行的DAG型和noDAG型实例进行了统计，发现在运行较多实例的机器上，接受的DAG型实例调度次数处于同一数量级，而noDAG型实例的调度情况则有所不同。由表7可见，在数据集所记录的时间范围内，machine_id为m_1455的机器曾接受过133 522次noDAG型实例的调度，是所有机器中最多的。machine_id为m_3761的机器所接受的noDAG型实例调度次数位列第二，然而其数量为14 313次，仅占机器m_1455的10.72%。可见，在阿里巴巴混部集群中调度器会设置特殊分工的机器，该类机器相较于集群中的其他机器，会接受更多的来自于noDAG型task的instance调度。

Table 7 Number of scheduled instances on machine m_1455 and m_3761表7 机器m_1455与m_3761上运行的instance数量

为了对比DAG型与noDAG型2种task的调度特征，本文将二者包含的instance在机器上的调度次数的分布按照DAG型task包含的instance调度次数升序排序，如图4所示。由于noDAG型task包含的instance总数较少，本文将其分布进行归一化处理，分别以2种instance在机器上的最大调度次数为基准(noDAG型不含前述的m_1455机器)。从图4中可以看出，DAG型task包含的instance调度数量与noDAG型在机器上的分布较为相似。为了进一步确认，计算得出两者的相关系数为0.75，表明调度器对有无DAG关系没有明显偏好(除m_1455机器)。另外，在图4放大部分中，无论DAG型还是noDAG型task，其中instance的调度次数在机器上的分布都有较为明显的区间分布。

Figure 4 Distribution of scheduled tasks of DAG and noDAG (normalized to the maximum value of each type)图4 DAG型与noDAG型task包含的 instance的调度分布(以各自类型的最大值归一化)

图5中图例data表示原数据的散点，其纵轴为单个应用组上容器的数量出现的频次，横轴坐标为该频次的排名。在图5a中，从排名第1的数据点开始拟合，得到分布参数α为0.579，C为9.49E2，决定系数R2为0.858。从第10位的数据点开始拟合，得到分布参数α为0.729，C为2.270E3，决定系数R2为0.941。图5表明，不论是否去除排名前10的重量型在线应用，混部集群中所有在线应用的容器规模都具有明显的倾斜现象，其分布符合Zipf分布。

Figure 5 Zipf distribution on container number in a single online application group图5 在线应用组的容器规模的Zipf分布

混部集群中在线应用任务规模(应用中容器数量)的倾斜现象的定量分析，可以为集群调度相关领域研究人员建立合理的在线任务调度模型提供参考。混部集群中的这一倾斜现象，同本文作者之前发现的未混部的淘宝生产集群中的数据倾斜现象相类似[10]。

4 调度优化

本文使用多种衡量集群调度效率的指标，用以评价混部集群管理系统的可优化潜力。本文选择的评价指标将任务的生命周期划分为多个阶段，通过分析各个阶段的开销，可以推断相应的性能影响因素，有助于确定混部集群的优化方向。

4.1 实例开始延迟

实例开始延时SD(Start Delay)是指某instance开始时间与其所属task中的第1个开始的instance的开始时间之间的差值。1个task的平均SD(meanSD)指的是该task中所有instance的SD平均值，最大SD(maxSD)指的是该task中所有instance的SD的最大值，1个task的第i个instance的开始延时tSD_i如式(1)所示：

tSD_i=Tinst_i_start-Tinst_first_start

(1)

其中，Tinst_i_start表示第i个instance的开始时间,Tinst_first_start表示此task的第1个instance的开始时间。

图6将具有相同instance数量的task的平均SD和最大SD通过取平均值来聚合，研究trace-2018中1个task的instance的数量对instance的调度效率的影响。其中横轴是1个task的instance数量(取数量大于或等于2的task)，纵轴是以秒为单位的开始延时。

Figure 6 Relationship between instance start delay and number of instances图6 实例开始延时与其数量之间的关系

因为包含大量instance的task数量占比较少，所以在图6中，平均SD和最大SD在横轴103～105的区域发生了较大的波动。但是，整体趋势仍然可以看出，随着task的instance数量的增长，task的平均SD与最大SD都有所上升(在横轴为2时，平均SD与最大SD相交。因为除去最早开始的instance外，只会剩下1个instance用于求SD，此时平均SD等于最大SD)。

在理想情况下，1个task中的所有instance是同时开始执行的，所以SD可以衡量1个task中instance的并行效率。我们发现，随着task中包含的instance数量增加，调度器对于instance的调度效率不断下降。

4.2 任务间隙时间

当前驱依赖的task执行完毕，后继task并不会立即执行，需要等待前驱task数据传输、系统调度等，本文将这段时间记为task的间隙时间。间隙时间可以反映有前后依赖的task之间实际上未执行计算任务的时间。间隙时间越长，则表明调度器的效率越低，所以该指标可以用于探究集群调度有依赖task开始执行的效率。2个有依赖关系的task的间隙时间为当前task的开始执行时间与其所依赖的task的结束时间之间的差值。2个有依赖关系的task的间隙时间tinterval的计算如式(2)所示：

tinterval=Tstart-Tdep_end

(2)

其中，Tstart表示当前task的实际开始执行时间，Tdep_end表示当前task所依赖的task的实际结束时间。

本文将间隙时间分为2种情况：

(1)情况1：当job的所有task只有1个前驱依赖的时候，则任意2个有依赖关系的task的间隙时间是由数据传输、调度引起的，如图7a所示；

(2)情况2：当1个task有多个前驱依赖的时候，且其中1个前驱依赖的task的执行时间又特别长时，则另外的前驱task与当前task之间的间隙时间会变长，如图7b所示。

Figure 7 Interval time of two cases图7 2种情况间隙时间示意

为了对2种情况的间隙时间作说明，对DAG图进行扩展，在有向边上增添了2个task的间隙时间，有向边上括号外的数值表示task的执行时间，括号内的数值表示2个task的间隙时间，如图7a有向边1→2的标签为“69(3)”，表示task 1的执行时间为69 s，task 1与task 2的间隙时间为3 s。图7a中job(j_1084)的任意2个task的间隙时间完全是由数据传输、调度等所造成的；而图7b中job(j_2959)的task 4同时依赖于task 1和task 3，task 4需要等待task 1和task 3执行完才能执行，而task 1的执行时间为233 s，task 3的执行时间为2 s，所以task 3很快就执行完，而task 1仍需执行相当一段时间，造成task 3与task 4的间隙时间为239 s，此间隙时间不仅由数据传输、调度等造成，还与等待task 1执行完有关。

4.3 任务等待时间

batch_task.csv表中字段start_time记录的是每个task在job master的注册时间，而task实际开始执行的时间为该task中首个instance开始执行的时间，将task实际开始时间与注册时间之间的差值定义为task的等待时间twaiting：

twaiting=Tfirst_inst_start-Tregister

(3)

其中，Tfirst_inst_start表示该task中最早开始的instance的时间，即task的实际开始时间，Tregister表示task的注册时间。

Task的等待时间是由于此task的前驱task的执行所耗费的时间、task间的数据通信及调度等带来的时间开销所造成的，所以task的等待时间可以视为衡量task调度效率的指标，task的等待时间越长则说明调度效率越低。

4.4 作业通信时间

由于job的task间含有DAG关系，有前驱依赖的task需要等待其所依赖的task完成后才能执行，而前驱依赖的task执行完之后，并不会立即执行当前task，当前task需要等待前驱task数据传输、系统调度等，才能开始执行。所以，完整执行1个job的时间由2部分组成：(1)job中task的执行时间(关键路径长度)；(2)task间通信、调度等带来的时间开销。为此我们定义job的通信时间为关键路径上task之间的数据通信、调度等时间开销。该指标可以反映job执行效率，缩短作业通信时间可在很大程度上缩短job的持续时间。

作业通信时间tcomm通过计算job的总耗时与关键路径上的所有task的执行时间之间的差值得到：

tcomm=tjob-tcritical

(4)

其中，tjob表示1个job的总执行时间，tcritical表示DAG图中关键路径上的task的执行时间之和。

4.5 作业执行时间

1个作业的总执行时间为其关键路径上所有任务的总执行时间(关键路径长度)与作业的通信时间之和。为了分析job的总执行时间与上述二者之间的关系，给出了如图8所示的job执行时间、关键路径长度和job通信时间的累积分布函数CDF(Cumulative Distribution Function)图，并对三者进行比较,结果如表8所示。

Figure 8 CDF of job execution time,critical path length,and job communication time图8 job执行时间、关键路径长度和job通信时间CDF图

表8 关键路径长度、job通信时间和job执行时间对比 s

图8给出了作业执行时间、关键路径长度和作业通信时间的CDF图，其中纵轴为累积分布，实线为job执行时间，点划线为关键路径长度，虚线为job通信时间。从图8可以看出，横坐标在0～500左右处，job执行时间和关键路径长度的CDF曲线近似直线，说明在该时间段内job执行时间和关键路径长度分布得较为均匀，而job通信时间主要分布在0～25 s左右区间内。

从表8可以发现，关键路径的最大值(175 453)与job执行时间的最大值(175 460)较为接近，它们都出自j_2724077，而j_2724077的通信时间仅为7 s；job通信时间的最大值为4 691 s，与关键路径和job执行时间最大值相差较大。可以推测job通信时间与job中关键路径上的task执行的总时间长短并没有直接关系。关键路径长度平均值为134.97 s(占job平均执行时间71.20%)，而job通信时间平均值为54.59 s(占job平均执行时间28.80%)，表明大多数job的通信时间较短，job执行时间的增长主要是由于关键路径长度增长导致的，但仍有一部分job的通信时间相当长，有潜在的优化空间以减少job的总执行时间。

4.6 任务执行优化

为了研究task等待时间与其前驱task的执行时间与间隙时间之间的关系，给出了如图9所示的task等待时间、执行时间和间隙时间的CDF图。

Figure 9 CDF of task interval time图9 间隙时间的CDF图

上文介绍间隙时间时，提出了2种间隙时间情况：(1)情况1：job中所有task只依赖一个task；(2)情况2：job中存在task依赖多个task。图9a为间隙时间为情况1的CDF图，图9b为间隙时间为情况2的CDF图。根据图9a发现，当task等待时间较小时(约3 s)，task等待时间与间隙时间CDF曲线非常接近，而当等待时间逐渐增大时，间隙时间的CDF曲线高于等待时间的CDF曲线，即此时task间隙时间对等待时间影响逐渐减小；而图9b中等待时间和间隙时间的曲线保持高度一致，但需注意的是情况2的间隙时间受所依赖task的执行时间影响，即task间的间隙时间会由于其中一个依赖task的执行时间过长而变长，从而导致task等待时间变长。因此可以得出结论，task等待时间受task执行时间和间隙时间共同影响，但task执行时间受task规模或者处理逻辑的极大影响，很难直接减少task的执行时间。所以，有必要重视对task间隙时间的优化，以减少整体task的等待时间。且由于离线批处理作业对时效不敏感，我们可以调整其执行顺序，通过将多个job联合考虑以提升整体完成效率。

5 相关工作

对数据中心运行日志的分析一直都是研究服务器性能瓶颈和优化潜力的重要环节。针对阿里巴巴2017年发布的数据集trace-2017，多位学者给出了相应的混部集群特征分析结果[11 - 15]。本文根据2018年发布的数据集trace-2018，针对出现的新特性，进一步丰富了混部集群的相关研究。

除了阿里巴巴公开的混部集群数据集，目前还有大量利用自有数据中心运行日志分析结果进一步优化调度性能的案例。Jiang等[16,17]使用模拟的混合负载测试多种虚拟化平台，利用运行日志充分比较各平台之间的优势与劣势，为数据中心调度系统设计者提供了重要参考。Qiu等[18]设计了一种结合了日志采集的简化虚拟机调度框架，节省了37.07%～49.98%的服务器功耗。

为了促进业界与学术界对于集群调度的研究，Google于2012年公开了其异构集群的跟踪数据集(clusterdata-2011-2)[19]，包含了集群内12 500台服务器在29天内的负载数据[20]。作为Google目前正在使用的大规模集群管理系统，Borg采用了类似于Alibaba集群管理系统的混部机制。该调度器隐藏了2种负载间资源分配与错误处理的细节，让开发者能够专注于业务的开发[21]。Borg是少数几个在万台服务器以上规模集群获得较高弹性与可靠性的系统。Google部署Borg至今已经超过10年，混部比例高达98%。Google曾经统计过，如果不使用这样的机制，应对相同的工作负载，机器的数量需要额外增加20%～30%[3]。

由于大规模集群跟踪数据集的稀缺性，该数据集成为了许多相关领域科研人员的研究对象。据统计，已经有超过450篇发表的论文在实验过程中使用到了Google的跟踪数据集[22]。许多研究工作通过分析该数据集，对大型集群的负载特征、故障处理、调度机制等进行了深入探究[23,24]。

除此之外，由于Google数据集在权威性、数据量方面的优势，众多的研究工作利用Google跟踪数据集来评估算法或系统的性能。其中，Islam等[25]提出了一种基于循环神经网络RNN(Recurrent Neural Network)的集群故障预测算法，利用Google数据集进行实验测试，预测准确率达到了87%。Han等[26]将Google跟踪数据集作为参考，设计出了可以产生不同类型负载的基准工具，用以研究云服务的性能瓶颈。Xu等[27]利用真实电价与Google跟踪数据集等数据，测试提出的基于区块链的去中心化资源管理系统在降低电力成本方面的效果。Dabbagh等[28]针对过度承诺资源的云服务，设计出一套高效能的虚拟机预测与迁移框架，并在Google数据集的测试下证明该框架能够显著降低电力消耗。此外，还有很多资源分配方面的研究利用Google数据集，提出了有价值的资源调度算法[29 - 33]。

大型集群的运行日志数据对于推动相关领域的研究是大有裨益的。然而，Google跟踪数据集已经公开将近7年，整个互联网环境都发生了较大的变化，使用该数据集得出的结论对于当今的环境是否适用有待考证。并且，大量的集群调度研究工作集中在单一的数据集上，容易使研究结论陷入过拟合的误区。如果要进一步得出有价值的研究成果，选择更为多样、更为新颖的数据集是很有必要的。因此，本文的分析工作对于研究目前的混部集群的任务负载特征和调度优化具有较高的参考价值。

6 结束语

作为开放集群跟踪项目(Open Cluster Trace Program)的一部分，阿里巴巴继2017年开放实际生产中的混部集群日志cluster-trace-v2017后，于2018年末开放了时间跨度更长、机器数量更多、包含离线批处理任务间依赖关系的cluster-trace-v2018。

在本文中，我们分析了cluster-trace-v2018的新特性，详细介绍了在“job-task-instance”3层结构下DAG形式的task间依赖的表达方式。对数据集中静态、动态运行情况下的调度情况进行了统计分析。基于混部集群运行时特征，使用了开始延时、间隙时间、等待时间等多种指标来评价含有DAG形式依赖关系的批处理作业调度效率，并分析对其进一步优化的方向与可能性。最后，在未来的工作中，希望可以根据本文中分析的混部集群特性与可优化潜力，提出DAG形式离线任务在混部场景下的优化方案，可以在不同混部搭配条件下有效提升机器硬件资源使用率。