一种面向机器学习框架的流量调度方法与流程

文档序号:15845998发布日期:2018-11-07 09:01阅读:341来源:国知局
一种面向机器学习框架的流量调度方法与流程

本发明涉及数据中心网络中一种提高机器学习应用流量调度性能的方案,属于计算机网络领域。

背景技术

近年来机器学习领域的技术突破使得越来越多的大型商业公司加大了对其人工智能应用的投入研发。为了推进研发进度,各个公司推出了不同的机器学习框架来充分利用物理计算机集群的计算资源。集群内资源的调度对高效的完成机器学习任务十分重要,其中网络资源的分配尤为关键。机器学习任务完成过程中通常会产生大量流量,这些流量进入集群网络(数据中心网络)容易引发网络拥塞进而延长任务的完成时间。网络拥塞产生主要有两方面的原因:(1)缺乏应用语义感知机制,传统的数据中心网络由于无法区分不同应用对于网络的差异化需求,其所提供的公平服务会导致使得网络成为应用性能提升的瓶颈;(2)传统的网络传输速率控制机制不适用于数据中心网络,数据中心网络中的流量汇聚模式容易引发数据包丢失,从而降低传输性能。

在机器学习任务占据集群的大量工作负载之前,组流已经被证明是一种有效的提升数据中心中分布式计算框架的网络性能的有效模型。基于组流的调度方案优于传统的基于流的方案的原因在于,组流包含了分布式应用对网络的实时需求。举个例子来讲,有来自同一个分布式应用的多条流经过不同链路到达同一个接收方,并且应用要求接收方在完成所有流的传输后才能进入下一个计算阶段;此时其中一条流所在链路发生拥塞,那么在基于流的调度方案中,一条流的拥塞信号只能对这条流本身的速率控制机制产生影响;而对于将上述多条流逻辑上看作为一个组流的组流调度方案来讲,则会适当地降低其他流的速率来避免不必要的带宽占用。

因此,可以预期,实现分布式机器学习框架组流层面的流量调度将带来极大的网络性能提升。

但是,遗憾的是,如果缺乏流信息的组流方案则效果有限。这是因为,实现分布式机器学习框架组流层面的流量调度后,组流调度策略决定了拥塞发生时的组流调度性能。不同于基于流的调度方案,组流本身的定义决定了其具备最优的调度策略:组流的优先级由组流内最慢的流决定,这是因为组流的完成时间取决于最后一个流的完成。现有技术因缺乏流信息的有效组流方案,因此效果有限,其需要依据流发送数据包的数量来预测流的大小并将其置于不同的优先级队列,调度性能依赖于预测的准确性同时流的速率控制无法进行显式控制。



技术实现要素:

本发明的目的是为了解决组流方案的问题,提出一种面向机器学习框架的流量调度方法。

本发明所述的面向机器学习框架的流量调度方法中,所述机器学习用于通过数据并行模型在大规模的数据集下获得不同的机器学习模型;在所述机器学习中,大规模的数据集被划分到多个分布式结点进行存储;运行于分布式结点的工作实例依据本地的部分数据集训练并得到模型参数的梯度值,并发送到超参数服务器进行模型的更新;超参数服务器汇合多组梯度值进行模型训练,并将更新后的模型参数下发回给工作实例;其特征在于,将多个工作实例发往同一个超参数服务器的流组织成一个组流,将超参数服务器发往多个实例的流组织成为另一个组流,实现分布式机器学习框架在组流层面的流量调度。

进一步地,还包括组流信息推测机制,用于在尽可能快的检测出组流的潜在拥塞能力,组流信息推测机制包括如下步骤:s1、在机器学习任务开始后,基于组流调度框架通过统计活跃流的数量来获取到一个组流内流的个数n;s2、随机挑选组流内的一个流作为探测流并保证其尽快完成数据包的传输,从而得到其流的大小f;s3、结合机器学习组流的自相似性,一个组流的大小可由n*f得到;该组流的大小被等价为对于共享的转发结点的潜在拥塞能力,并被作为判定一个组流的优先级的一个依据;s4、进行优先级更新。

更进一步地,来自于新产生的机器学习任务中组流需要经过信息推测才能被添加到活跃的组流集合中;在信息推测过程中,依据接收端超参数服务器所属的边缘交换机随机选取新任务中多个组流中的一个组流;对于被选取的组流,依据发送端工作实例所处的物理主机随机选取一个流作为探测流。

更进一步地,来自探测流的数据包被打上标记进入探测队列,享有最高优先级;探测流由随机选择得到的组流中随机指定,即探测流的选取采用双重随机设计。

更进一步地,探测流的最高优先级结合弹性速率控制算法以确保探测流发送速率的快速增长。

更进一步地,在优先级更新启动前,来自新任务的非探测流进入活跃队列,以确保其本身在当前网络配置下不被饿死的最低发送速率进行发包。

更进一步地,当流优先级更新定时器超时,所有的非探测流,包含未完成的组流,依据其所属的探测流的探测结果进入相应的优先级队列;探测流大小通过影响组流大小的推测来决定非探测流的优先级,优先级更新确保短作业优先的调度策略。

更进一步地,弹性速率控制算法包括:在有足够可用带宽的情况下,流的速率呈倍增加来快速的占用可用带宽来提升链路利用率。

更进一步地,在端系统采集组流内各个流所经过的链路的rtt信息来估计可用的带宽,实现基于端系统的速率控制;并通过类似设置发送窗口大小的方式来与现有tcp/ip协议兼容。

更进一步地,对于一个流f,目标速率即下一个周期所希望发送的数据包数目,由如下公式计算得到:

elastic_gain*f.max_rtt/f.min_rtt

其中预设值elastic_gain决定了流的最低发送速率,f.max_rtt表示链路中所能接受的最大队列长度,其大小与网络配置相关;f.min_rtt表示上一个测量周期内链路中的队列长度。

本发明还包括一种面向机器学习框架的流量调度系统,用于实现上述的方法,包括控制器,用于接收发送端周期性的上报的最新的流信息,实现组流语义分析功能;控制器中包含组流信息采集模块、通信模式匹配模块以及组流大小推测模块;组流信息采集模块用于依据现有流信息将来自机器学习任务的流组织成组流,并识别来自不同训练周期的组流;通信模式匹配模块用于记录已完成的组流来匹配当前的未完成的组流;匹配成功的组流则不必进入组流大小推测模块,其所属的流直接使用匹配的结果向接收端下发决策;组流大小推测模块用于实现上述的组流信息推测算法,将新的组流划分为探测流与非探测流并依据组流信息采集模块的结果来更新非探测流的优先级;

进一步地,控制器还用于周期性的向接收端下发调度决策;位于终端的模块通过弹性流调度来实现所接收到的组流策略,其中包含优先级标注模块、测量结果更新模块以及传输层速率控制模块;优先级标注模块收到控制器对于组流内各个流的优先级更新信息后,对每个流的数据包标注相应的优先级并确保其进入操作系统内的多级反馈优先级队列来实现短作业优先策略;测量结果更新模块采集端到端之间链路的rtt信息以及上一个周期内的发送包数量和接收包数量,来为下一步的传输层速率控制模块提供数据基础;传输层速率控制模块用于计算下一个周期内的发送包数量,并在速率限速器的帮助下,确保有对应的发送包从网卡处正常的发出。

与现有技术相比,本发明提出了一种高效的数据中心中分布式机器学习框架流量调度机制,在无法获取应用流信息的场景下,在组流的层面上实现了高效的调度策略。

进一步地,该机制将流的速率控制与流量调度进行有机结合,通过及时的速率控制帮助了有效的流信息推测在流传输过程中的完成,同时基于推测结果的调度策略合理的引导了流在不同网络环境下的速率控制。

附图说明

图1是分布式机器学习框架在数据中心中的部署以及数据中心网络典型拓扑示意图;

图2是本发明一个实施例中分布式机器学习框架中的组流示例示意图;

图3是本发明实施例组流信息推测流程示意图;

图4是本发明实施例基于链路队列的速率控制策略示意图;

图5是本发明实施例弹性速率控制流程示意图;

图6是本发明实施例模型框架示意图;

图7a-7c是本发明实施例组流调度算法示例图。

附图标记:tn:编号为n的边缘交换机;hn-m:编号为m的接入第n个边缘交换机的物理主机;vm1:编号为1的虚拟主机,d1:基于hadoop的1号的工作实例;s1:基于spark的1号的工作实例。

具体实施方式

下面结合具体实施方式并对照附图对本发明做进一步详细说明。其中相同的附图标记表示相同的部件,除非另外特别说明。应该强调的是,下述说明仅仅是示例性的,而不是为了限制本发明的范围及其应用。

分布式机器学习框架在数据中心中的部署以及数据中心网络拓扑如附图1所示:一个物理主机h通常以虚拟机vm的方式运行多个分布式工作实例(比如来自于计算框架hadoop的d,或者spark的s);同一个物理主机内的多个工作实例共享物理资源,比如cpu、内存、硬盘以及网络带宽;每个物理主机通过边缘交换机t接入内部网络(数据中心内部网络指的是由边缘交换机接入,内部由多个高性能交换机构建的网络组织),同时边缘交换机向所属的物理主机分发来自内部网络的流量。

通常认为内部网络不会发生拥塞,拥塞主要发生在数据中心中由边缘交换机和物理主机构成的网络部分,即外部网络。常见的数据中心网络拥塞可以分为发送端拥塞和边缘交换机拥塞。前者是由于单个主机中运行的多个工作实例对带宽的抢占导致数据包无法离开主机进入网络;后者则是因为来自内部网络的流量超过了边缘交换机的转发能力,使得数据包在路由路径中的最后一跳被丢弃。

结合上述组流的例子可以看到,如果我们能够将来自同一个物理主机的多个工作实例的流组织为一个组流,或者,将到达同一个边缘交换机的多条流组织为一个组流,就可以充分发挥组流的调度优势。

幸运的是,分布式机器学习框架的计算语义支撑组流调度方案。大多数主流的分布式机器框架基于如附图2所示的超参数服务器模型进行构建。在这些系统中,机器学习任务的目标是通过数据并行模型在大规模的数据集下获得不同的机器学习模型。大规模的数据集被划分到多个分布式结点进行存储;运行于分布式结点的工作实例依据本地的部分数据集训练并得到模型参数的梯度值,并发送到超参数服务器进行模型的更新;超参数服务器汇合多组梯度值进行模型训练,并将更新后的模型参数下发回给工作实例。由于超参数服务器需要等到一定量梯度结果才能开始模型训练,而工作实例需要等到超参数服务器的最新模型参数的下发完毕才能开始新一轮的梯度计算,我们可以将多个工作实例发往同一个超参数服务器的流组织成一个组流(来自任务1的组流),将超参数服务器发往多个实例的流组织成为一个组流(来自任务2的组流)。对比上述我们提到的数据中心网络中的拥塞类型可以看到,前者有利于解决超参数服务器端下行链路的边缘交换机拥塞,后者有利于解决超参数服务器端上行链路的发送端拥塞。

本发明人发现,不同于其他分布式应用的组流,机器学习组流有如下几个具备极大潜在价值的特征:1、不像其他多阶段的应用任务,从上述例子可以看到,机器学习任务只具备两个阶段,这决定了组流的终端不会因为阶段不同而发生迁移从而保证了组流结构(每个流的发送端和接收端)的稳定性;2、应用的语义是相似的并且一个机器学习任务中划分后的数据块大小是固定的,因此在不同的训练周期中流的大小是一致的;3、由于在超参数服务器模型中,一个超参数服务器所负责的模型参数是等量划分的,每个超参数服务器所对应的同类型组流之间是相互类似的。以上特征可以为被统称为机器学习组流的自相似性。

本发明人发现,机器学习组流的自相似性有利于简化组流策略的设计。本发明实施例就是利用这些发现,构建了高效的数据中心中分布式机器学习框架流量调度机制。具体说明如下:

1.组流信息推测机制

组流信息推测机制的目的在于在尽可能快的检测出组流的潜在拥塞能力。考虑到短作业优先是目前已知的缩短任务完成时间的最优算法,在假定流的发送速率稳定不变的前提下,这里我们将最大的组流作为为最有可能引发拥塞的组流。

如何计算组流内最长的流完成时间是设计高效的组流调度方案的核心问题。传统的组流方案需要在已知组流内每个流的大小的场景下结合可用的带宽来计算目标结果,并依据结果更新每个流的速率。这种方案难以适用于流信息未知的场景,并且依赖于带宽探测的准确度,同时大规模的更新流发送速率将带来极大的资源开销。

由于机器学习框架内的组流结构具有稳定性,我们可以在机器学习任务开始后,基于现有的组流调度框架通过统计活跃流的数量来获取到一个组流内流的个数n。如果我们随机挑选组流内的一个流作为探测流并保证其尽快完成数据包的传输,从而得到其流的大小f,结合机器学习组流的自相似性,一个组流的大小可由n*f得到。由于组流的大小被等价为对于共享的转发结点的潜在拥塞能力,因此组流大小被作为判定一个组流的优先级的主要依据。

信息推测和优先级更新是组流信息推测算法中的两个核心部分,如附图3所示。来自于新产生的机器学习任务中组流需要经过信息推测才能被添加到活跃的组流集合中。在信息推测过程中,依据接收端(超参数服务器)所属的边缘交换机随机选取新任务中多个组流中的一个组流。对于被选取的组流,依据发送端(工作实例)所处的物理主机随机选取一个流作为探测流。来自探测流的数据包被打上标记进入探测队列,享有最高优先级。探测流由随机选择得到的组流中随机指定(见图3中步骤2、3);探测流选取的双重随机设计是为了尽量避免探测流之间发生碰撞竞争带宽。探测流的最高优先级能够确保其本身数据包测量的链路往返延迟(rtt)最低,这一点结合弹性速率控制算法能够确保探测流发送速率的快速增长。

在优先级更新启动前,来自新任务的非探测流进入活跃队列,以确保其本身在当前网络配置下不被饿死的最低发送速率进行发包。当流优先级更新定时器超时,所有的非探测流(包含未完成的组流)依据其所属的探测流的探测结果进入相应的优先级队列。探测流大小通过影响组流大小的推测来决定非探测流的优先级,因此结合短作业优先的调度原则来看,探测流大小越小的非探测流的优先级越高。优先级更新确保了短作业优先的调度策略的实施,因为当探测流的大小不断增长时,其所决定的非探测流的优先级会逐步下调(见图3中步骤9)。

组流推测机制支持组流调度方案实现高效的调度策略。相较于传统的通过流发送数据量的多少来判定组流优先级的方式(las),探测流提供的探测结果能够实现理论上更优的短作业优先策略(sjf),如附图7a所示。在示例中有两个同时出现的工作任务j1、j2,其中j1包含两个组流c1和c2,c1包含三个大小为1的流共享一个接收端h1,其他的组流结构参见图7a,不再赘述。假设链路每个时间单位处理一个单位的数据,从组流完成时间的角度来看,本专利所提出调度sjf方案(如图7c)要优于传统的las调度策略下方案(如图7b)。这是因为las需要在t=3时才能区分服务来自不同任务的组流,而sjf能够在t=2时就通过j1中到h1和j2中到h3的探测流区来更早的组流大小上j2要大于j1。

2.弹性速率控制算法

探测流和非探测流对速率控制策略提出了不同的要求。理想的速率控制策略如附图4所示。探测流承担着组流大小推测的使命,传统的速率控制中加性增显然不如乘性增有效。因此在有足够可用带宽的情况下,流的速率应呈倍增加来快速的占用可用带宽来提升链路利用率。如图4中带宽探测部分所示,当上一个探测周期内流的发送的数据包个数为m时没有出现丢包,则该周期内发送的数据包个数可以增大到2*m。与此同时,较高的速率不应该受到随机的网络波动,比如少量的数据包丢弃,而大幅度降低,从而导致速率的大幅度波动;合理的策略应该是感知到链路中出现的队列较小后适当的降速,来保护当前的速率水平。如图4中速率保护部分所示,当流上一个周期内丢包数目为n时,该该周期内发送的数据包个数可以调整为到m-n。相反的,探测流的目标是尽可能的将自身速率与链路中的可用带宽相匹配。探测流能够接受大幅度的速率波动来避免拥塞,尤其是当链路中存在占用大量带宽的探测流时。如图4中拥塞避免部分所示,当流上一个周期内发送的m个数据包的发送平均要等待n个数据包的传输,该该周期内发送的数据包个数可以调整为到m/n。

本专利提出的弹性速率控制算法能够在较小的额外开销的情况下尽可能的满足上述要求,如附图5所示。由于机器学习组流共享同一个接收端(或发送端),我们可以在端系统采集组流内各个流所经过的链路的rtt信息来估计可用的带宽。基于端系统的速率控制避免了集中式速率计算所带来的计算与通信开销,而且可以很好的通过类似设置发送窗口大小的方式来与现有tcp/ip协议兼容,从而降低开发成本。需要注意的是,流的发送速率的上限这里没有做强制限制。

弹性速率控制算法将任意复杂的链路看作是具备相同rtt大小和瓶颈带宽的直连链路。对于一个流f,f.max_rtt表示链路中所能接受的最大队列长度,其大小与网络配置相关;f.min_rtt表示上一个测量周期内链路中的队列长度,这是因为在现代高速数据中心网络中数据包的转发延迟、处理延迟和传输延迟相较于队列带来的排队延迟可以忽略不计。当前发送速率可以逻辑上等价于表示在上一个周期中发送端所发送的数据包数目(由于周期大小是固定不变的,发送的数据包越多表示发送的速率越快);当前接受速率表示上一个周期中接收端所接受的数据包数目,以实现速率保护策略;目标速率表示下一个周期所希望发送的数据包数目,由图5中公式(见图5中步骤1)计算得到:

elastic_gain*f.max_rtt/f.min_rtt

其中预设值elastic_gain决定了流的最低发送速率,因为当链路中的队列达到上限时,f.max_rtt/f.min_rtt=1;最后算得的发送速率表示下一个周期实际拟发送的数据包数目,其中multi_gain表示带宽探测的激进程度。

本实施例通过组流信息推测机制,避免了组流调度方案对提前获取组流信息的依赖,对机器学习组流自相似性的挖掘降低了调度方案设计的复杂度,并简化了现有的组流调度框架从而便于部署,弹性速率控制在优化调度策略的性能同时提高了链路的利用率,降低了机器学习组流的平均完成时间。

本方案需要对现有的集中式组流调度框架进行简化,并将部分模块迁移至接收端实现,如附图6所示。

附图3所示算法位于图6中组流语义分析模块,附图5所示算法位于图6中弹性流调度模块。控制器主要实现组流语义分析功能,其中包含组流信息采集模块,通信模式匹配模块以及组流大小推测模块。发送端周期性的向控制器上报最新的流信息,组流信息采集模块依据现有流信息将来自机器学习任务的流组织成组流,并识别来自不同训练周期的组流。通信模式匹配模块负责记录已完成的组流来匹配当前的未完成的组流;匹配成功的组流则不必进入组流大小推测模块,其所属的流直接使用匹配的结果向接收端下发决策。组流大小推测模块主要实现上述的组流信息推测算法,将新的组流划分为探测流与非探测流并依据组流信息采集模块的结果来更新非探测流的优先级。

控制器周期性的向接收端下发调度决策。位于终端的模块通过弹性流调度来实现所接收到的组流策略,其中包含优先级标注模块,测量结果更新模块以及传输层速率控制模块。优先级标注模块收到控制器对于组流内各个流的优先级更新信息后,对每个流的数据包标注相应的优先级并确保其进入操作系统内的多级反馈优先级队列来实现短作业优先策略。测量结果更新模块采集端到端之间链路的rtt信息以及上一个周期内的发送包数量和接收包数量,来为下一步的传输层速率控制模块提供数据基础。传输层速率控制模块主要实现附图5所示算法所描述的功能,计算下一个周期内的发送包数量并在速率限速器的帮助下,确保有对应的发送包从网卡处正常的发出。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的技术人员来说,在不脱离本发明构思的前提下,还可以做出若干等同替代或明显变型,而且性能或用途相同,都应当视为属于本发明的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1