CN110297699B - 调度方法、调度器、存储介质及系统 - Google Patents
调度方法、调度器、存储介质及系统 Download PDFInfo
- Publication number
- CN110297699B CN110297699B CN201810244746.5A CN201810244746A CN110297699B CN 110297699 B CN110297699 B CN 110297699B CN 201810244746 A CN201810244746 A CN 201810244746A CN 110297699 B CN110297699 B CN 110297699B
- Authority
- CN
- China
- Prior art keywords
- job
- job request
- node
- data
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/903—Querying
- G06F16/9032—Query formulation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/903—Querying
- G06F16/90335—Query processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Computational Linguistics (AREA)
- Mathematical Physics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本公开提供了一种调度方法、调度器、存储介质及系统,属于通信技术领域。该方法包括:获取关联关系图和数据分布信息,关联关系图中每个节点指代一条数据,每条有向边用于表示根据源节点指代的数据进行计算得到目的节点指代的数据的作业请求;按照预设节点排序策略,依次将以遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中;将至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中。通过以关联关系图来表示数据之间的关联关系以及作业请求与数据的对应关系,以数据分布信息来表示数据分布情况,可以减少跨节点的数据传输,进而缩短整体作业请求的作业执行时间,提高计算效率,提升系统性能。
Description
技术领域
本公开涉及通信技术领域,特别涉及一种调度方法、调度器、存储介质及系统。
背景技术
伴随着数据规模的增长和数据多样性的发展趋势,数据分析和处理技术也在不断进行着改进,目前已出现了多种数据分析处理架构,如Hadoop/MapReduce(分布式计算/映射归并)架构、基于内存计算的大数据处理框架Spark等。基于这些数据分析处理架构开发的大数据应用,能够提高大数据分析处理的效率,一定程度上满足了大数据分析处理对于实时性的需求。
大数据应用具体实现时需要构建具有一定规模的计算集群,并根据需求动态调整计算集群内部的计算资源。为了满足上述需求,通常会将大数据应用部署在云计算系统,通过云计算系统可以实现统一的管理以及更加灵活的管理调度。然而,云计算系统为大数据应用带来很多便利条件的同时,也面临着亟需解决的诸多问题,其中用户最为关注的就是性能问题,即云计算系统整体的作业执行时间的问题。
参见图1,其示出了一种云计算系统的架构示意图,该云计算系统包括作业层和平台层,作业层包括调度器,平台层包括多个服务器,这些服务器可以作为存储节点来存储数据,还可以作为计算节点来根据存储的数据进行计算。目前云计算系统通常会采用作业层调度策略,即终端提交作业请求,作业层的调度器会将接收到的多个作业请求添加到调度队列,并按照预设排序策略对调度队列中的多个作业请求进行排序,按照排列的顺序依次将每个作业请求调度到服务器上,由调度的服务器按照该作业请求并根据该作业请求对应的数据进行计算。而在上述调度过程中,数据的存储位置固定不变。综上所述,云计算系统采用了固定数据、移动计算的调度方式。
计算过程会受到数据分布情况的影响,例如,如果某一作业请求所需的数据分布在不同的服务器上,当某一服务器在按照该作业请求进行计算的过程中,需要从其他的服务器传输所需的数据,这会导致跨节点的数据传输。而上述调度过程中数据的存储位置固定不变,调度效果只能依赖于初始的数据分布情况,如果初始的数据分布情况不佳,就会导致计算过程存在着大量的跨节点的数据传输,进而导致作业执行时间过长,计算效率低下,影响了云计算系统的性能。
发明内容
本公开提供了一种调度方法、调度器、存储介质及系统,以解决上述问题。所述技术方案如下:
第一方面,提供了一种调度方法,应用于云计算系统的调度器中,所述云计算系统包括所述调度器以及多个服务器,所述多个服务器用于存储数据,所述方法包括:
获取关联关系图和数据分布信息,所述关联关系图包括多个节点以及至少一条有向边,每个节点指代一条数据,每条有向边具有一个源节点和一个目的节点,所述有向边由所述有向边的源节点指向所述有向边的目的节点,所述有向边用于表示根据所述有向边的源节点指代的数据进行计算得到所述有向边的目的节点指代的数据的作业请求,所述数据分布信息包括每条数据所在的服务器;
根据所述关联关系图和所述数据分布信息,按照预设节点排序策略遍历所述关联关系图中的节点,依次将遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中,所述节点对应的作业请求是指以所述节点作为源节点的有向边表示的作业请求;
将所述至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中。
在一种可能实现方式中,所述预设节点排序策略为按照度数从大到小的顺序进行排序的策略,所述度数是指节点连接的有向边的数量,所述根据所述关联关系图和所述数据分布信息,按照预设节点排序策略遍历所述关联关系图中的节点,依次将遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中,包括:
按照所述预设节点排序策略遍历所述关联关系图中的节点,将所述关联关系图中当前度数最大的节点确定为所述遍历到的节点;
将所述遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中;
将以所述遍历到的节点作为源节点的有向边删除;
继续按照所述预设节点排序策略遍历所述关联关系图中的节点,将所述关联关系图中当前度数最大的节点确定为所述遍历到的节点,对所述遍历到的节点进行所述定位作业请求的步骤和所述删除对应有向边的步骤,直至所述关联关系图中所有节点的度数均不大于1为止。
在另一种可能实现方式中,所述获取关联关系图和数据分布信息之前,所述方法还包括:
获取日志记录,所述日志记录包括作业请求记录和数据处理记录;
根据所述作业请求记录构建随机排队模型,基于所述随机排队模型确定所述作业请求记录中的每个作业请求的输入数据和输出数据;
根据所述数据处理记录构建数据关联模型,所述数据关联模型中包括多个节点,每个节点指代所述数据处理记录中的一条数据;
确定所述每个作业请求的输入数据对应的源节点和输出数据对应的目的节点,在所述数据关联模型中添加由所述源节点指向所述目的节点的有向边,得到所述关联关系图。
在另一种可能实现方式中,所述获取关联关系图和数据分布信息之前,所述方法还包括:
计算作业请求记录中多个作业请求均执行结束所需的执行轮数W;
根据每个作业请求的作业执行频率和作业执行时间,计算每个作业请求的优先度,所述优先度与所述作业执行频率和所述作业执行时间正相关;
按照优先度从高到低的顺序对所述多个作业请求进行排序,将排名第nW+m位的作业请求和排名第(n+2)W+1-m的作业请求的执行轮次确定为m,m为正整数,且m不大于W,n为整数;
所述将所述至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中,包括:根据每个作业请求的执行轮次,将所述至少一个作业请求依次调度至所定位的服务器中。
在另一种可能实现方式中,所述方法还包括:
初始化每个作业请求的集群规模,所述作业请求对应的数据占用的服务器数量与所述作业请求的集群规模正相关;
计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模;
继续计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模,直至作业执行时间最长的作业请求的集群规模对应的服务器数量等于所述云计算系统中的服务器总数量时为止。
在另一种可能实现方式中,每个作业请求包括映射map任务、混洗shuffle任务和归并reduce任务,所述计算每个作业请求在当前的集群规模下的作业执行时间,包括:
采用以下公式,计算任一作业请求在当前的集群规模下的作业执行时间:
其中,Lj(r)表示第j个作业请求的作业执行时间,r表示第j个作业请求当前分配的机架数量,k表示一个机架中的服务器数量,表示第j个作业请求输入文件的大小,表示第j个作业请求输出文件的大小,表示第j个作业请求的shuffle文件的大小,μmap表示map任务的单机平均处理效率,μreduce表示reduce任务的单机平均处理效率,表示第j个作业请求的reduce任务的数量,V表示过载率,B表示服务器的带宽。
在另一种可能实现方式中,所述继续计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模,直至作业执行时间最长的作业请求的集群规模对应的服务器数量等于所述云计算系统中的服务器总数量时为止之后,所述方法还包括:
确定所述关联关系图中当前长度最大的关系链,所述关系链为一个第一节点以及由任一第二节点到达所述第一节点所经过的节点及有向边组成的集合,所述第一节点为不存在以所述第一节点为源节点的有向边的节点,所述第二节点为存在至少两条以所述第二节点为源节点的有向边的节点,或者为存在一条以所述第二节点为源节点的有向边且不存在以所述第二节点为目的节点的有向边的节点,所述关系链的长度由所述关系链中包含的有向边个数确定;
按照集群规模从大到小的顺序,对所述当前长度最大的关系链中的有向边表示的作业请求进行排序,将集群规模最大的作业请求确定为指定作业请求;
按照所述指定作业请求的集群规模,将所述指定作业请求对应的数据定位到数量与所述指定作业请求的集群规模匹配的服务器中,并按照所述当前长度最大的关系链中其他有向边表示的作业请求的集群规模,将所述其他作业请求对应的数据定位到所述指定作业请求所定位的且数量与所述其他作业请求的集群规模匹配的服务器中;
将所述当前长度最大的关系链删除;
继续确定所述关联关系图中当前长度最大的关系链,对确定的关系链进行所述定位数据的步骤,直至所述关联关系图中的每条有向边表示的作业请求对应的数据定位完成。
在另一种可能实现方式中,所述方法还包括:
当作业请求执行结束后,对日志记录进行更新,所述日志记录包括作业请求记录和数据处理记录;
根据更新后的日志记录,对所述关联关系图进行更新。
在另一种可能实现方式中,所述关联关系图中每条有向边的请求数量指代对应的作业请求的个数,每条有向边的权重指代对应作业请求的执行频率,根据更新后的日志记录,对所述关联关系图进行更新,包括:
根据更新后的作业请求记录,确定更新后的多个作业请求以及每个作业请求更新后的执行频率;
根据所述更新后的多个作业请求,对所述关联关系图中的有向边进行更新,并对每条有向边的请求数量进行更新;
根据所述每个作业请求更新后的执行频率,对所述关联关系图中每条有向边的权重进行更新。
第二方面,提供了一种调度器,应用于云计算系统,所述云计算系统包括所述调度器以及多个服务器,所述多个服务器用于存储数据,所述调度器包括:
获取模块,用于获取关联关系图和数据分布信息,所述关联关系图包括多个节点以及至少一条有向边,每个节点指代一条数据,每条有向边具有一个源节点和一个目的节点,所述有向边由所述有向边的源节点指向所述有向边的目的节点,所述有向边用于表示根据所述有向边的源节点指代的数据进行计算得到所述有向边的目的节点指代的数据的作业请求,所述数据分布信息包括每条数据所在的服务器;
请求定位模块,用于根据所述关联关系图和所述数据分布信息,按照预设节点排序策略遍历所述关联关系图中的节点,依次将遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中,所述节点对应的作业请求是指以所述节点作为源节点的有向边表示的作业请求;
调度模块,用于将所述至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中。
在一种可能实现方式中,所述预设节点排序策略为按照度数从大到小的顺序进行排序的策略,所述度数是指节点连接的有向边的数量,所述请求定位模块,包括:
确定单元,用于按照所述预设节点排序策略遍历所述关联关系图中的节点,将所述关联关系图中当前度数最大的节点确定为所述遍历到的节点;
定位单元,用于将所述遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中;
删除单元,用于将以所述遍历到的节点作为源节点的有向边删除;
所述确定单元、所述定位单元和所述删除单元还用于继续按照所述预设节点排序策略遍历所述关联关系图中的节点,将所述关联关系图中当前度数最大的节点确定为所述遍历到的节点,对所述遍历到的节点进行所述定位作业请求的步骤和所述删除对应有向边的步骤,直至所述关联关系图中所有节点的度数均不大于1为止。
在另一种可能实现方式中,所述调度器还包括:
日志获取模块,用于获取日志记录,所述日志记录包括作业请求记录和数据处理记录;
模型构建模块,用于根据所述作业请求记录构建随机排队模型,基于所述随机排队模型确定所述作业请求记录中的每个作业请求的输入数据和输出数据;
数据关联模型构建模块,用于根据所述数据处理记录构建数据关联模型,所述数据关联模型中包括多个节点,每个节点指代所述数据处理记录中的一条数据;确定所述每个作业请求的输入数据对应的源节点和输出数据对应的目的节点,在所述数据关联模型中添加由所述源节点指向所述目的节点的有向边,得到所述关联关系图。
在另一种可能实现方式中,所述调度器还包括:
轮数计算模块,用于计算作业请求记录中多个作业请求均执行结束所需的执行轮数W;
优先度计算模块,用于根据每个作业请求的作业执行频率和作业执行时间,计算每个作业请求的优先度,所述优先度与所述作业执行频率和所述作业执行时间正相关;
轮次确定模块,用于按照优先度从高到低的顺序对所述多个作业请求进行排序,将排名第nW+m位的作业请求和排名第(n+2)W+1-m的作业请求的执行轮次确定为m,m为正整数,且m不大于W,n为整数;
所述调度模块,还用于根据每个作业请求的执行轮次,将所述至少一个作业请求依次调度至所定位的服务器中。
在另一种可能实现方式中,所述调度器还包括:
集群规模设置模块,用于初始化每个作业请求的集群规模,所述作业请求对应的数据占用的服务器数量与所述作业请求的集群规模正相关;
集群规模调整模块,用于计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模;继续计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模,直至作业执行时间最长的作业请求的集群规模对应的服务器数量等于所述云计算系统中的服务器总数量时为止。
在另一种可能实现方式中,每个作业请求包括映射map任务、混洗shuffle任务和归并reduce任务,所述集群规模调整模块,还用于采用以下公式,计算任一作业请求在当前的集群规模下的作业执行时间:
其中,Lj(r)表示第j个作业请求的作业执行时间,r表示第j个作业请求当前分配的机架数量,k表示一个机架中的服务器数量,表示第j个作业请求输入文件的大小,表示第j个作业请求输出文件的大小,表示第j个作业请求的shuffle文件的大小,μmap表示map任务的单机平均处理效率,μreduce表示reduce任务的单机平均处理效率,表示第j个作业请求的reduce任务的数量,V表示过载率,B表示服务器的带宽。
在另一种可能实现方式中,所述调度器还包括:
排序模块,用于确定所述关联关系图中当前长度最大的关系链,所述关系链为一个第一节点以及由任一第二节点到达所述第一节点所经过的节点及有向边组成的集合,所述第一节点为不存在以所述第一节点为源节点的有向边的节点,所述第二节点为存在至少两条以所述第二节点为源节点的有向边的节点,或者为存在一条以所述第二节点为源节点的有向边且不存在以所述第二节点为目的节点的有向边的节点,每条关系链的长度由对应的关系链中包含的有向边个数确定;按照集群规模从大到小的顺序,对所述当前长度最大的关系链中的有向边表示的作业请求进行排序,将集群规模最大的作业请求确定为指定作业请求;
数据定位模块,用于按照所述指定作业请求的集群规模,将所述指定作业请求对应的数据定位到数量与所述指定作业请求的集群规模匹配的服务器中,并按照所述当前长度最大的关系链中其他有向边表示的作业请求的集群规模,将所述其他作业请求对应的数据定位到所述指定作业请求所定位的且数量与所述其他作业请求的集群规模匹配的服务器中;
删除模块,用于将所述当前长度最大的关系链删除;
所述排序模块、所述数据定位模块和所述删除模块还用于继续确定所述关联关系图中当前长度最大的关系链,对确定的关系链进行所述定位数据的步骤,直至所述关联关系图中的每条有向边表示的作业请求对应的数据定位完成。
在另一种可能实现方式中,所述调度器还包括:
更新模块,用于当作业请求执行结束后,对日志记录进行更新,所述日志记录包括作业请求记录和数据处理记录;
所述更新模块,还用于根据更新后的日志记录,对所述关联关系图进行更新。
在另一种可能实现方式中,所述关联关系图中每条有向边的请求数量指代对应的作业请求的个数,每条有向边的权重指代对应作业请求的执行频率,所述更新模块,包括:
第一更新单元,用于根据更新后的作业请求记录,确定更新后的多个作业请求以及每个作业请求更新后的执行频率;
第二更新单元,用于根据所述更新后的多个作业请求,对所述关联关系图中的有向边进行更新,并对每条有向边的请求数量进行更新;
第三更新单元,用于根据所述每个作业请求更新后的执行频率,对所述关联关系图中每条有向边的权重进行更新。
第三方面,提供了一种调度器,包括:至少一个处理器和存储器,所述存储器中存储有至少一条指令,所述指令由所述至少一个处理器加载并执行以实现第一方面描述的方法中所执行的操作。
第四方面,提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有至少一条指令,所述指令由处理器加载并执行以实现第一方面描述的的方法中所执行的操作。
第五方面,提供了一种计算机程序,所述计算机程序由处理器或计算机执行以实现第一方面描述的方法中所执行的操作。
第六方面,提供了一种云计算系统,所述云计算系统包括多个服务器和第二方面或第三方面描述的调度器。
本公开实施例达到的有益效果是:
本公开实施例提供的方法,通过以关联关系图来表示数据之间的关联关系以及作业请求与数据的对应关系,以数据分布信息来表示数据分布情况,根据关联关系图和数据分布信息,遍历每个节点,将以遍历到的节点作为源节点的有向边表示的作业请求定位到遍历到的节点指代的数据所在的任一服务器中,进而实现了对作业请求的定位,充分利用了平台层与作业层的特征,同时打破了跨层调度器之间的信息隔阂,加强了跨层资源的感知与关联,可以减少跨节点的数据传输,进而缩短整体作业请求的作业执行时间,提高计算效率,提升系统性能,优化整合了全平台资源。
并且,根据作业请求记录和数据处理记录生成关联关系图,该关联关系图可以表示作业层和平台层之间的跨层依赖关系,同时具备数据流的静态特性及作业流的动态特性,根据该关联关系图进行调度时,可以充分考虑到作业请求的排序策略以及数据分布情况,从而制定出合理的调度策略,减少作业执行时间,提高计算效率,进而提升云计算系统的性能。
并且,通过对关联关系图进行更新可以使关联关系图可以随着作业请求的调度过程的进行而及时更新,以保证关联关系图与作业流变化及时匹配,能更及时地应对作业请求的突发状况,既可以适用于作业流较为稳定的场景,也可以适用于作业流突发现象频繁的场景,如节点故障、网络线路变化、新类型应用加入或者作业请求瞬间突发等情况,提高了抗突发的能力。
并且,通过将每个作业请求的集群规模初始化后再根据作业执行时间进行调整,能够持续调整当前作业执行时间最长的作业请求的集群规模,增加该作业请求的并发程度,减小该作业请求的作业执行时间,进而统一了多作业请求的作业执行时间。
并且,考虑到同一关系链中的数据之间具有关联关系,在作业执行过程中很可能会同时使用,因此利用数据之间的关联关系,将可能会同时使用的数据定位到相同的服务器中,便于后续的数据处理,实现了精度极高的数据最优分布,尽可能避免了数据在不同服务器之间的传输,优化了通信开销,减少了通信能力的浪费,优化了大数据服务的计算能力和通信能力。且通过关联关系图,将数据调度策略与作业调度策略相结合,充分利用了数据与作业请求之间的跨层关联关系,可以实现作业流与数据流的协同调度,实现了全局资源的优化整合。另外,考虑到关联关系图中包含多条关系链,关联关系较为复杂,且关系链的长度越大,复杂度越高,数据分布情况对系统整体性能的影响越大,因此,以关系链的长度进行排序,优先对长度最大的关系链进行定位,可以减小定位复杂度,并尽可能避免数据分布不合理对后续的数据处理过程造成的影响。
并且,考虑到度数较大的节点对应着较多的作业请求,关联关系较为复杂,需要优先进行定位才能将尽可能多的作业请求定位到该节点指代的数据所在的服务器中,因此按照节点的度数大小进行排序,优先对度数最大的节点对应的作业请求进行定位,减小定位复杂度,完成了作业请求与数据的一一映射,并尽可能避免数据分布不合理对后续的数据处理过程的影响。
并且,按照优先度从高到低的顺序对多个作业请求进行排序,将排名第nW+m位的作业请求和排名第(n+2)W+1-m的作业请求的执行轮次确定为m,根据每个作业请求的执行轮次,将至少一个作业请求依次调度至所定位的服务器中,可以保证不同轮次中所执行的作业请求的优先度相差不大,每2W轮的作业请求调度结束后,每轮的作业请求整体规模近似相等,从而近似实现作业请求在云计算系统的所有机架上的平铺。
并且,通过启发式方法,将每个作业请求的执行轮次进行初始化,实现了每轮并发执行的作业请求可以占用全部的集群能力,避免计算能力的浪费,提高执行效率。
附图说明
图1是相关技术提供的一种云计算系统的架构示意图;
图2是本公开实施例提供的一种云计算系统的架构示意图;
图3是相关技术提供的调度策略示意图;
图4A是本公开实施例提供的一种终端用户画像系统的架构示意图;
图4B是本公开实施例提供的一种调度器的结构示意图;
图5是本公开实施例提供的一种调度方法的流程图;
图6是本公开实施例提供的一种关联关系图创建流程示意图;
图7是本公开实施例提供的一种关联关系图的生成和更新过程示意图;
图8是本公开实施例提供的一种调度方法的流程图;
图9是本公开实施例提供的一种集群规模与作业执行时间的关系示意图;
图10是本公开实施例提供的一种调度方法的流程图;
图11是本公开实施例提供的一种数据定位的示意图;
图12是本公开实施例提供的一种调度方法的流程图;
图13是本公开实施例提供的一种作业请求定位的示意图;
图14是本公开实施例提供的一种确定执行轮次的示意图;
图15是本公开实施例提供的一种操作流程图;
图16是本公开实施例提供的三种方案下终端用户画像系统的作业请求完成比例的变化示意图;
图17是本公开实施例提供的三种方案下终端用户画像系统的提速百分比的变化示意图;
图18是本公开实施例提供的一种调度器的结构示意图;
图19是本公开实施例提供的一种调度器的结构示意图。
具体实施方式
为使本公开的目的、技术方案和优点更加清楚,下面将结合附图对本公开实施方式作进一步地详细描述。
图2是本公开实施例提供的一种云计算系统的架构示意图,参见图2,该云计算系统包括:作业层和平台层,作业层包括调度器201,平台层包括多个服务器202。
多个服务器202用于作为存储节点来存储数据,还用于作为计算节点来根据数据和作业请求进行计算,且多个服务器202之间相互连接,可以进行数据传输。
调度层201用于将接收到的作业请求调度至某一个或多个计算节点(服务器202)上,从而在计算节点上根据数据和作业请求进行计算。
因此,用户设备、应用服务器等设备接入作业层后,可以向作业层提交作业请求,该作业请求用于根据对应的数据进行计算。调度器201将接收到的作业请求存储至调度队列,并从调度队列中调度至服务器202中,从而在服务器202中根据调度的作业请求以及作业请求对应的数据进行计算。
相关技术的调度方案中,平台层的数据调度与作业层的作业请求调度是互为黑盒、相互不感知的,参见图3,采用的调度策略包括两种:作业层调度策略和平台层调度策略。
作业层调度策略采用固定数据、移动计算的调度方式,即数据的存储位置固定不变,作业层的调度器会按照预设排序策略对调度队列中的多个作业请求进行排序,按照排列的顺序依次将每个作业请求调度到服务器上,由调度的服务器按照该作业请求并根据该作业请求对应的数据进行计算。作业层调度策略包括基于关联的排序策略或者基于权值的排序策略等。
作业层调度策略会假设数据的分布服从默认的均匀分布或已知分布,并假设在整个调度过程中数据分布保持恒定不变,因此在调度过程中对底层数据的实时分布状况不感知,因此调度效果往往受到数据初始分布的影响。但是,由于数据与作业请求之间存在着复杂的跨层关联关系,会进一步影响调度的结果,如果数据初始分布状况不佳,即便作业层调度策略可以实现各服务器的负载均衡,但仍会导致大量的跨节点数据传输,整体的作业执行效率依然受到影响。在异构性强的集群环境中,纯作业层的调度策略无法达到完美的资源分布效果。
平台层调度策略采用固定计算、移动数据的调度方式,即引入了数据关联关系,在执行作业请求的过程中会判断哪些数据会被相同的作业请求同时读取,进而将这些数据进行关联,之后,改变传统的数据均匀分布的方案,将相关联的数据部署到相同的服务器中,从而实现数据分布的动态调整,在特定的作业流分布下优化数据的本地化程度,在执行作业请求的过程中尽可能减少跨节点的数据传输,提高大数据服务的性能。平台层调度策略包括基于数据关联的调度策略、基于数据访问频率的调度策略或基于设备性能的调度策略等。
由于移动数据比移动计算的开销要大,因此平台层调度策略一旦确定了数据分布情况后,短时间内也不会频繁进行调整,这个特性导致了平台层调度策略的灵活性欠佳。并且,平台层调度策略对作业流的情况无法感知,因此无法与作业流变化及时匹配,不能及时根据作业流的突发状况调整数据分布情况,从而恶化了大数据服务的性能,通常不适用于作业流突发现象频繁的场景,而仅适用于用户行为相对稳定,即作业流较为稳定的场景。
而本公开实施例打破了平台层与作业层的调度策略之间的隔阂,基于数据与作业请求之间的跨层关联关系,对作业流和数据流进行协同调度,进一步实现全局资源的优化整合,提高执行效率。相对于作业层调度策略,本公开实施例融入了平台层因素,调度策略的稳态性能更优,而相对于平台层调度策略,本公开实施例考虑了作业流的突发特性,瞬态收敛性更强。并且相对于这两种策略的简单结合,本公开实施例充分利用了数据与作业请求之间的跨层关联关系,优化了数据分布,减小了作业执行过程中的通信开销。
本公开实施例应用于大规模数据中心的应用场景中,在大规模数据中心中,多个设备并发执行大数据服务,会提交多个作业请求,且数据与作业会进行频繁地交互,则采用本公开实施例的调度策略可以对整个作业执行过程中作业请求和数据的流向进行统一地规划调度。
云计算系统中调用大数据应用时,从作业请求到达到作业请求执行完毕的过程包括作业请求调度、数据装载和作业请求执行三个阶段,这三个阶段的执行耗时决定了大数据应用的整体性能。
平台层的工作在于数据装载阶段,平台层的研究主要为应用的数据在存储平台上提供相应的部署策略。使用平台层的数据在存储平台的优化部署方案,可以提高大数据应用的数据向不同计算节点的装载速率,优化数据装载阶段的时间跨度。
作业层的工作在于作业请求调度阶段,作业层的研究主要为根据不同服务的性能需求以及约束条件,对作业请求进行调度。在平台层优化了数据分布的基础上,作业层的作业请求调度策略更进一步规划了多个作业请求的执行顺序以及作业请求向数据的分流方式。
例如,参见图4A,本公开实施例可以应用于终端用户画像系统中,该终端用户画像系统在工作过程中,用户数据需要以Hadoop分布式文件系统(Hadoop Distribute FileSystem,简称HDFS)文件、Hive(基于Hadoop的一个数据仓库工具)表格、Redis(一种键值存储系统)索引等不同格式进行存储,且数据流动非常频繁。同时不同格式的数据都需要由Spark SQL计算集群(一种用来处理结构化数据的spark组件)读取,并进行不同类型的大数据运算,如表项生成、标签生成、应用推荐等操作,因此应用与数据之间形成了复杂的关联关系。其中,HDFS中包括NameNode(名字节点)和DataNode(数据节点),Spark SQL计算集群中包括Master节点(主节点)和Worker节点(工作节点)。该场景适合采用本公开实施例提供的方法,对数据流和作业流进行统一调度管理。
参见图4B,本公开实施例的调度方法,可以在现有大数据系统的经典调度器的基础上进行扩展而实现,如Apache Hadoop YARN、Apache Mesos等,主要是在传统调度器中保留了传统调度器的作业请求调度功能,作为新的调度器的子模块,另外加入数据平面的特征,引入了具有数据部署功能的子模块,两个子模块互不干扰,独立工作,并通过在底层引入跨层的细粒度关联关系图,将两个子模块使用的信息进行紧密关联,从而可以统一规划两个子模块的运作,实现数据流和作业流的协同调度,达到全局最优组合调度。例如,若由于整个云计算系统的底层环境是HDFS文件系统,则本公开实施例可以通过对ApacheHadoop YARN调度器进行修改拓展而实现。本公开实施例的具体过程详见下述实施例。
图5是本公开实施例提供的一种调度方法的流程图,应用于上述实施例所示的调度器中,本公开实施例对获取关联关系图的过程进行说明。参见图5,该方法包括:
501、获取日志记录,日志记录包括作业请求记录和数据处理记录。
其中,作业请求记录中包括本次作业执行过程中需要执行的作业请求,根据大数据应用提供的不同类型的功能,作业请求记录中可以包括不同类型的作业请求,例如应用推荐请求、网页浏览请求等。另外,该作业请求记录中还可以包括每个作业请求的请求频率,每个作业请求的执行时间等,这些参数可以通过对每个作业请求的历史执行过程进行统计得到。
而数据处理记录中包括多条数据,根据该数据处理记录不仅可以确定之前处理过哪些数据,而且这些数据可以认为是本次作业执行过程中所需的数据。
调度器可以每次接收到作业请求时,将该作业请求存储至作业请求记录中,如将接收到的作业请求存储至调度队列中。并且,还会根据作业执行过程中处理过的数据可以生成数据处理记录。
502、根据作业请求记录构建随机排队模型,基于随机排队模型确定作业请求记录中的每个作业请求的输入数据和输出数据。
调度器读取作业请求记录后,可以根据作业请求记录对作业请求的执行过程进行抽象建模,构建随机排队模型,该随机排队模型可以模拟多个作业请求排队等候执行的过程,则基于该随机排队模型可以确定每一个作业请求的输入数据和输出数据,该输入数据是指作业请求执行时所需的数据,输出数据是指按照作业请求对输入数据进行计算后得到的数据。
503、根据数据处理记录构建数据关联模型,数据关联模型中包括多个节点,每个节点指代数据处理记录中的一条数据。
504、确定每个作业请求的输入数据对应的源节点和输出数据对应的目的节点,在数据关联模型中添加由源节点指向目的节点的有向边,得到关联关系图。
调度器可以将数据处理记录中的每条数据作为一个节点,从而构建包括多个节点的数据关联模型,该数据关联模型可以表示数据之间的关联关系,而每个作业请求在该数据关联模型中会存在输入数据对应的源节点和输出数据对应的目的节点,因此在数据关联模型中添加由每个作业请求对应的源节点指向目的节点的有向边,该有向边用于表示根据源节点对应的输入数据进行计算得到目的节点对应的输出数据的作业请求,也即是该有向边可以表示输入数据与输出数据之间的关联关系。
在数据关联模型中添加有向边完成后,即可得到关联关系图,该关联关系图包括多个节点以及至少一条有向边,每个节点指代一条数据,每条有向边具有一个源节点和一个目的节点,有向边由有向边的源节点指向有向边的目的节点,每条有向边用于表示根据有向边的源节点指代的数据进行计算得到有向边的目的节点指代的数据的作业请求,能够将数据流和作业流综合起来,可以表示数据和作业请求之间的关联关系。
其中,可以根据数据处理记录进行抽象建模,得到有向无环图(DirectedAcyclical Graphs,简称DAG)模型,再根据DAG模型和作业请求记录构建关联关系图。
在一种可能实现方式中,考虑到多个作业请求可能会具有相同的输入数据和输出数据,因此会在数据关联模型中添加相同的有向边,则可以根据数据关联模型中节点的拓扑结构,在同一个节点上对多个作业请求进行聚合,形成初始的关联关系图,之后为关联关系图中的每条有向边设置请求数量和权重,该请求数量指代有向边对应的作业请求的数量,该权重指代有向边对应的作业请求的执行频率,可以根据作业请求记录中作业请求的执行频率确定。
例如,参见图6,根据作业请求记录创建马尔科夫链,该马尔科夫链中以调度队列的不同状态作为不同的节点,每个节点中的数量指代调度队列中作业请求的数量,λ表示作业请求的到达速率,μ表示作业请求的处理速率,Δt表示不同状态之间的时间间隔,该马尔科夫链可以表示作业流。并且,生成数据关联图,该数据关联图以不同的数据作为不同的节点,节点与节点之间的边表示由源节点对应的数据计算得到目的节点对应的数据的作业请求。根据该马尔科夫链和该数据关联图可以生成关联关系图,在该关联关系图中以不同的数据为不同的节点,并在同一个节点上连接不同的作业请求所对应的有向边,每个有向边具有权重,以权重来表示对应作业请求的执行效率。
本公开实施例提供的方法,可以根据作业请求记录和数据处理记录生成关联关系图,该关联关系图可以表示作业层和平台层之间的跨层依赖关系,同时具备数据流的静态特性及作业流的动态特性,根据该关联关系图进行调度时,可以充分考虑到作业请求的排序策略以及数据分布情况,从而制定出合理的调度策略,减少作业执行时间,提高计算效率,进而提升云计算系统的性能。
需要说明的是,本公开实施例中,调度器可以对日志记录进行更新,并根据更新后的日志记录,对关联关系图进行更新。该更新过程包括:根据更新后的作业请求记录,确定更新后的多个作业请求以及每个作业请求更新后的执行频率,该更新后的多个作业请求可以是去除已经执行完成的作业请求后剩余的作业请求,且有些剩余的作业请求可能会由于在本次作业执行过程中已经执行过而导致执行频率发生变化,因此要对执行频率进行更新,或者本次作业执行过程结束后,该更新后的多个作业请求可以为下次作业执行过程需要执行的作业请求。之后根据更新后的多个作业请求,对关联关系图中的有向边进行更新,对每条有向边的请求数据进行更新,并根据每个作业请求更新后的执行频率,对每条有向边的权重进行更新。
上述更新过程可以周期性执行,或者在每次作业执行过程结束后执行,例如,当前周期结束但本次作业执行过程还未结束,还存在未执行完成的作业请求时,则对作业请求记录中的作业请求以及执行频率进行更新,并重新读取作业请求记录,对关联关系图中的有向边的权重进行更新,在剩余的执行过程中应用更新后的关联关系图。之后当本次作业执行过程结束时,根据本次作业执行过程中每个作业请求的执行情况更新关联关系图。
关联关系图的生成和更新过程可以如图7所示,通过上述更新过程,在整个作业执行期间内周期性对关联关系图进行更新,从而使得跨层关联关系图的有向边信息可以随着调度的进行而及时更新,以便更及时地应对作业请求的突发情况。每次更新后有向边的权重的有效期为更新周期,在有效期内调度器认为各个应用的作业流保持不变。
图8是本公开实施例提供的一种调度方法的流程图,应用于上述实施例所示的调度器中,本公开实施例对确定作业请求集群规模的过程进行说明,该确定作业请求的集群规模的过程可以在数据上传至云计算系统时执行。参见图8,该方法包括:
801、初始化每个作业请求的集群规模。
其中,作业请求对应的数据占用的服务器数量与作业请求的集群规模正相关,例如可以将作业请求对应的数据占用的服务器数量确定为与集群规模相等,也即是该集群规模为作业请求对应的数据占用的服务器数量,或者可以以集群规模r来表示机架的数量,而每个机架包含的服务器数量均为k,则作业请求对应的数据占用的服务器数量为rk。
每个作业请求对应的数据可以构成多个数据副本,并分别部署在多个服务器中,所部署的服务器数量较多时,可以在执行作业请求的过程中减少跨节点的数据传输,从而减少作业请求的作业执行时间。因此针对每个作业请求来说,集群规模较大时作业执行时间较短。而从全局出发,需要综合考虑每个作业请求的作业执行时间,以便合理确定每个作业请求的集群规模。
为此,调度器可以先初始化每个作业请求的集群规模,后续再对某些作业请求的集群规模进行调整。例如,初始化时可以将作业请求记录中的每个作业请求的集群规模设置为第一数值,该第一数值可以为正整数,可以为1或者其他数值。
802、计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模。
调度器可以先根据每个作业请求的集群规模对每个作业请求的执行过程进行模拟,确定每个作业请求在当前的集群规模下的作业执行时间。则针对作业执行时间最长的作业请求,将该作业请求的集群规模增大,可以减少该作业请求的作业执行时间。增大该作业请求的集群规模时,可以将该作业请求的集群规模加1或者增加其他数值。
在一种可能实现方式中,作业请求可以划分为映射map任务、混洗shuffle任务和归并reduce任务,则作业请求的执行过程包括上述三种任务的执行过程,作业请求的作业执行时间可以由上述三种任务的执行时间决定。调度器可以建立性能模型,基于该性能模型计算每个作业请求在当前的集群规模下的作业执行时间。
该性能模型的参数定义如下:
S:输入文件的总大小,包含多个作业请求的输入文件;
J:作业请求的集合;
R:机架的总数量;
k:一个机架里中面服务器的数量;
B:服务器的带宽;
V:过载率(over subscription ratio),跨机架传输时使用;
Lj(r):第j个作业请求的作业执行时间(在r个机架中执行该作业请求);
r:第j个作业请求被分配的机架的数量,即计算集群的规模;
Jij:第j个作业请求是否部署在第i个机架上执行;
Rj:第j个作业请求被分配在相应机架上,即(J1j,J2j,…,JRj)的集合
μmap:Map任务的单机平均处理效率;
μreduce:Reduce任务的单机平均处理效率。
每个作业请求可以看作是一个MapReduce作业,包括map任务、shuffle任务和reduce任务,执行时间由map任务、shuffle任务和reduce任务三阶段的执行时间决定,即:
而shuffle任务的执行阶段中每轮的执行时间取决于机架内传输和跨机架传输的最大时间,有:
跨机架传输场景中,每个计算节点有(r-1)/r比例的数据需要跨机架传输,因此跨机架传输过程所需的时间为:
跨机架传输场景中,每个计算节点有1/r比例的数据不需要跨机架传输,因此机架内传输过程所需的时间为:
因此Shuffle任务执行阶段跨机架传输时间占主导情况的情形为:
即,当集群规模大于1个节点时,跨节点传输成为MapReduce作业请求中Shuffle任务的执行阶段的瓶颈。
结合节点的计算性能,作业请求在集群中的作业执行时间量化如下:
也即是,调度器可以采用以下公式,计算任一作业请求在当前的集群规模下的作业执行时间:
当作业执行时间取得极值时,集群规模为:
即,集群规模为2个机架时,作业请求的作业执行时间取得极大值,之后集群规模越大,作业请求的作业执行时间越短。则根据性能建模结果得到的初步结论是,综合考虑MapReduce集群的计算性能和通信性能,集群规模越大则MapReduce作业的执行时间跨度越短。此结论在后续协同调度方法设计时,会用于对集群规模的优化调整操作中,另外,在数据初始分布操作中,也会使用该性能模型的结果。
803、继续计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模,直至作业执行时间最长的作业请求的集群规模对应的服务器数量等于所述云计算系统中的服务器总数量时为止。
在增大作业执行时间最长的作业请求的集群规模之后,该作业请求的作业执行时间减少,此时重新执行步骤802,也即是重新计算该作业请求在增大后的集群规模下的作业执行时间,并与其他的作业请求在当前的集群规模下的作业执行时间进行对比,重新确定作业执行时间最长的作业请求,并增大当前作业执行时间最长的作业请求的集群规模,以此类推,直至当前作业执行时间最长的作业请求的集群规模增大之后,该集群规模所对应的服务器数量等于云计算系统中的服务器总数量时为止。
在第一种可能实现方式中,集群规模等于作业请求对应的数据占用的服务器数量时,当前作业执行时间最长的作业请求的集群规模增大之后,该集群规模等于云计算系统中的服务器总数量时停止调整集群规模。
在第二种可能实现方式中,集群规模为作业请求对应的数据占用的机架数量r,每个机架包含的服务器数量均为k,作业请求对应的数据占用的服务器数量为rk,则当前作业执行时间最长的作业请求的集群规模r增大之后,rk等于云计算系统中的服务器总数量时停止调整集群规模。
需要说明的是,本公开实施例中以服务器作为计算节点的最小单位,服务器部署于机架中,则以服务器为粒度进行集群规模的调整或者以机架为粒度进行集群规模的调整,而在其他实施例中服务器也可以采用其他方式进行部署,则可以采用其他粒度进行集群规模的调整,具体可以根据部署需求确定。
通过采用上述调整集群规模的方式,持续调整当前作业执行时间最长的作业请求的集群规模,可以增加该作业请求的并发程度,减小该作业请求的作业执行时间,重复执行之后可以保证所有作业请求的作业执行时间会被调整到大致相同的情况,如图9所示。
图10是本公开实施例提供的一种调度方法的流程图,应用于上述实施例所示的调度器中,本公开实施例对定位数据的过程进行说明,该定位数据的过程可以在确定作业请求的集群规模之后执行。参见图10,该方法包括:
1001、确定关联关系图中当前长度最大的关系链,按照集群规模从大到小的顺序,对当前长度最大的关系链中的有向边表示的作业请求进行排序,将集群规模最大的作业请求确定为指定作业请求。
在获取到关联关系图,并且确定每个作业请求的集群规模之后,可以确定每条数据要定位的服务器,也即是每条数据要部署的位置。
关联关系图中,根据节点连接关系可以获取到多条关系链,关系链为一个第一节点以及由任一第二节点到达第一节点所经过的节点及有向边组成的集合,第一节点为不存在以第一节点为源节点的有向边的节点,第二节点为存在至少两条以第二节点为源节点的有向边的节点,或者为存在一条以第二节点为源节点的有向边且不存在以第二节点为目的节点的有向边的节点,每条关系链的长度由关系链中包含的有向边个数确定。当确定关联关系图中的第一节点和第二节点后,可以从第二节点处进行分割,得到多条关系链,确定关联关系图中每条关系链的长度,即每条关系链中包含的有向边的个数,并确定当前长度最大的关系链。当前长度最大的关系链不仅包含多个节点,还会包含不同节点之间的有向边,这些有向边对应于作业请求,可以认为在当前长度最大的关系链中存在至少一个作业请求,则按照每个作业请求的集群规模从大到小的顺序进行排序,将集群规模最大的作业请求确定为指定作业请求。
1002、按照指定作业请求的集群规模,将指定作业请求对应的数据定位到数量与指定作业请求的集群规模匹配的服务器中。
确定指定作业请求后,确定该指定作业请求的集群规模匹配的服务器数量,则将指定作业请求对应的数据定位到数量与该匹配的服务器数量相等的服务器中。
其中,数据定位是指确定数据的目标服务器,将数据存储至目标服务器中,后续数据处理过程中该目标服务器可以作为计算节点,对该数据进行处理,或者该目标服务器可以将该数据发送给其他的计算节点,由其他的计算节点对该数据进行处理。
在第一种可能实现方式中,集群规模等于作业请求对应的的数据占用的服务器数量,则将指定作业请求对应的数据定位到数量与该集群规模相等的服务器中。
在第二种可能实现方式中,集群规模为作业请求对应的数据占用的机架数量r,每个机架包含的服务器数量均为k,作业请求对应的数据占用的服务器数量为rk,则将指定作业请求对应的数据定位到r个机架中,也即是定位到rk个服务器中。
1003、按照当前长度最大的关系链中其他有向边表示的作业请求的集群规模,将其他作业请求对应的数据定位到指定作业请求所定位的且数量与其他作业请求的集群规模匹配的服务器中。
指定作业请求对应的数据定位完成后,再定位当前长度最大的关系链中其他有向边表示的作业请求对应的数据,且定位时每个作业请求对应的数据定位到数量与集群规模匹配的服务器中,并且每个作业请求对应的数据应当优先定位到该指定作业请求所定位的服务器。在一种可能实现方式中,每个作业请求对应的数据应当优先定位到所在关系链中其他已定位的作业请求所定位的服务器中,这样可以保证同一关系链中的作业请求对应的数据尽可能定位到相同服务器中。
举例来说,参见图11,关联关系图中长度最大的关系链为“-B7-B9-B10”,该关系链中的三个作业请求依次为J1、J2、J3,其中J1的集群规模r1最大,J2的集群规模r2次之,J3的集群规模r3最小,则将J1对应的数据定位到r1个机架中,将J2对应的数据定位到r2个机架中,将J3对应的数据定位到r3个机架中,且这r2个机架和这r3个机架均属于之前定位的r1机架的部分机架,且这r3个机架属于这r2个机架的部分机架,这样可以保证J1对应的数据和J2对应的数据可以位于相同的r2个机架上,J1对应的数据、J2对应的数据和J3对应的数据可以位于相同的r3个机架中。
1004、将当前长度最大的关系链删除。
1005、继续确定关联关系图中当前长度最大的关系链,对确定的关系链进行所述定位数据的步骤,直至关联关系图中的每条有向边表示的作业请求对应的数据定位完成。
当前长度最大的关系链中的有向边表示的作业请求对应的数据定位完成后,即可将该数据定位完成的关系链删除,之后判断删除之后的关联关系图中是否还有需要定位的数据对应的节点,如果还有需要定位的数据对应的节点,则根据删除之后的关联关系图继续重复上述步骤进行定位,也即是重新确定关联关系图中当前长度最大的关系链,对确定的关系链中的有向边表示的作业请求对应的数据进行定位,直至每个作业请求对应的数据定位完成,此时没有需要定位的数据对应的节点,即已确定所有数据定位的服务器位置,已经完成最终的数据分布,得到了数据分布信息,该数据分布信息包括每条数据所在的服务器,实现了数据分布信息的初始化。
本公开实施例中,考虑到同一关系链中的数据之间具有关联关系,在作业执行过程中很可能会同时使用,因此利用数据之间的关联关系,将可能会同时使用的数据定位到相同的服务器中,便于后续的数据处理,尽可能避免了数据在不同服务器之间的传输,优化了通信开销,减少了通信能力的浪费。且考虑到关联关系图中包含多条关系链,关联关系较为复杂,且关系链的长度越大,复杂度越高,数据分布情况对系统整体性能的影响越大,因此,以关系链的长度进行排序,优先对长度最大的关系链进行定位,可以减小定位复杂度,并尽可能避免数据分布不合理对后续的数据处理过程造成的影响。
图12是本公开实施例提供的一种调度方法的流程图,应用于上述实施例所示的调度器中,本公开实施例对调度作业请求的过程进行说明,该调度作业请求的过程在数据分布信息确定之后执行。参见图12,该方法包括:
1201、获取关联关系图和数据分布信息。
其中,关联关系图包括多个节点以及至少一条有向边,每个节点指代一条数据,每条有向边具有一个源节点和一个目的节点,有向边由有向边的源节点指向有向边的目的节点,每条有向边用于表示根据有向边的源节点指代的数据进行计算得到有向边的目的节点指代的数据的作业请求。
其中,数据分布信息包括每条数据所在的服务器,例如数据分布信息可以包括每条数据所在的服务器标识,该服务器标识用于唯一确定对应的服务器,可以为服务器的地址信息或者顺序编号等。
1202、根据关联关系图和数据分布信息,按照预设节点排序策略遍历关联关系图中的节点,依次将遍历到的节点对应的作业请求定位到遍历到的节点指代的数据所在的任一服务器中,节点对应的作业请求是指以节点作为源节点的有向边表示的作业请求。
调度器可设置预设节点排序策略,根据预设节点排序策略可以对关联关系图中的节点进行排序,根据排序可以依次对每个节点对应的作业请求进行定位。其中,对作业请求进行定位是指在云计算系统的多个服务器中确定作业请求的计算节点,该计算节点用于执行该作业请求,也即是按照该作业请求并根据该作业请求对应的数据进行处理。
进行定位时,会按照预设节点排序策略确定的节点排列顺序进行遍历,以每次遍历到的节点作为源节点的有向边表示的作业请求即为当前要定位的作业请求,此时由于数据分布信息中已经表明遍历到的节点指代的数据所在的服务器,且该作业请求在执行过程中需要使用该数据,则为了尽可能避免数据在不同服务器之间的传输,将该作业请求定位到该数据所在的任一服务器中。采用上述定位方式可以确定每个作业请求所定位的服务器,即每个作业请求的计算节点。
在一种可能实现方式中,预设节点排序策略为按照度数从大到小的顺序进行排序的策略,度数是指节点连接的有向边的数量,则进行定位时,先确定关联关系图中每个节点的度数,并按照度数从大到小的顺序进行排序,确定当前度数最大的节点,即为遍历到的节点,将遍历到的节点对应的作业请求定位到遍历到的节点指代的数据所在的任一服务器中,将以遍历到的节点作为源节点的有向边删除,之后重复执行上述步骤,针对度数大于1的节点所对应的作业请求继续进行定位,也即是继续按照度数从大到小的顺序遍历到下一个节点,将遍历到的节点作为源节点的有向边表示的作业请求定位到遍历到的节点指代的数据所在的任一服务器中,将以遍历到的节点作为源节点的有向边删除,以此类推,直至关联关系图中所有节点的度数均不大于1为止。
例如,参见图13,关联关系图中节点B4的度数最大,则优先将以节点B4为源节点的两个作业请求定位到节点B4对应的数据所在的服务器中,再定位其他节点对应的作业请求。
考虑到度数较大的节点对应着较多的作业请求,关联关系较为复杂,需要优先进行定位才能将尽可能多的作业请求定位到该节点指代的数据所在的服务器中,因此按照节点的度数大小进行排序,可以优先对度数最大的节点对应的作业请求进行定位,减小定位复杂度,完成了作业请求与数据的一一映射,并尽可能避免数据分布不合理对后续的数据处理过程的影响。
1203、将至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中。
定位完成之后,即可将每个作业请求依次调度到所定位的服务器中,从而在调度到的服务器中执行相应的作业请求。
其中,调度时可以采用多种策略来确定作业请求的调度顺序,进而确定作业请求的执行顺序。例如针对吞吐率优先型的大数据应用采用最短队列分配策略(Join theShortest Queue,简称JSQ)、针对响应时间优先型的大数据应用采用最小期望延时路由策略(Shortest Expected Delay Routing,简称SEDR)策略、针对作业突发性强的大数据应用采用Myopic Max Weight策略。
任一作业请求执行完成之后,如果作业请求记录中的所有作业请求均执行完毕,则作业流调度完成,而如果作业请求记录中还存在未执行完毕的作业请求,则对关联关系图进行更新,将更新后的关联关系图应用到后续调度过程中继续进行调度和执行。
更新时可以对作业请求的到达速率和执行速率等参数进行反馈,更新关联关系图中有向边的权重,并根据关联关系图中的节点拓扑结构,修正节点与有向边的连接关系。并且,还可以根据实际需求更新后续调度过程中所用的服务器集合,或者调度过程中采用的周期等。
本公开实施例提供的方法,通过以关联关系图来表示数据之间的关联关系以及作业请求与数据的对应关系,以数据分布信息来表示数据分布情况,根据关联关系图和数据分布信息,将以当前节点作为源节点的作业请求定位到当前节点指代的数据所在的任一服务器中,可以减少跨节点的数据传输,进而缩短整体作业请求的作业执行时间,提高计算效率,提升系统性能。
在一种可能实现方式中,考虑到存在多个作业请求时,需要执行多轮才能将多个作业请求执行完成,如果每轮内执行的至少两个作业请求需要由同一服务器执行,会导致该服务器的负载较大,而其他服务器的负载较小,这反而会造成计算能力的浪费,导致执行效率降低。因此,作业请求的执行轮次也会影响执行效率,进而影响系统性能。
为此,调度器在对多个作业请求进行调度时,可以先确定每个作业请求的执行轮次,根据每个作业请求的执行轮次,将至少一个作业请求依次调度至所定位的服务器中,以使多个作业请求可以分多轮执行,每轮执行至少一个作业请求。
而确定每个作业请求的执行轮次时,可以计算作业请求记录中多个作业请求均执行结束所需的执行轮数W,该执行轮数W表示了在理想情况下所有作业请求执行完成需要服务器执行多少轮,之后根据每个作业请求的作业执行频率和作业执行时间,计算每个作业请求的优先度,按照优先度从高到低的顺序对多个作业请求进行排序,将排名第nW+m位的作业请求和排名第(n+2)W+1-m的作业请求的执行轮次确定为m,也即是将排名第nW+m位的作业请求和排名第(n+2)W+1-m的作业请求设置为在第m轮执行,m为正整数,且m不大于W,n为整数。
其中,作业请求的优先度与作业执行频率和作业执行时间正相关,例如可以为作业执行效率与作业执行时间的乘积。作业请求的作业执行效率越高,优先度越高,可以优先执行,而作业请求的作业执行时间越长,表示需要花费较长的时间才能处理完成,此时将作业请求的优先度设置为较高的数值可以保证该作业请求可以优先执行,即使该作业请求花费的时间较长,后续仍可以与多轮的其他作业请求并行执行,以免延长整体的作业执行时间。
通过上述方式,可以保证不同轮次中所执行的作业请求的优先度相差不大,每2W轮的作业请求调度结束后,每轮的作业请求整体规模近似相等,从而近似实现作业请求在云计算系统的所有机架上的平铺。
参见图14,J1、J2……Jj的优先度依次降低,则将前W个作业请求J1至JW依次调度到第1至W轮,将第JW+1至J2W个作业请求依次调度到第W至1轮(逆向调度),以此类推,每2W个作业请求调度结束后,每轮作业请求的整体规模近似相等。
本公开实施例中,通过启发式方法,将每个作业请求的执行轮次进行初始化,实现了每轮并发执行的作业请求可以占用全部的集群能力,避免计算能力的浪费,提高执行效率。
本公开实施例提供的方法可以包括如下几个步骤:
1、关联关系图的生成与更新;
2、作业请求的集群规模的确定;
3、数据分布情况的调整;
4、作业请求的定位和调度;
5、作业与数据的反馈。
本公开实施例提供的方法的操作流程图可以如图15所示,参见图15,针对已到达的作业请求,生成关联关系图后,确定每个作业请求的集群规模,并确定数据分布情况,之后根据关联关系图、每个作业请求的集群规模和对应数据的所在位置,对作业请求进行定位和调度,从而执行作业请求。之后将执行过程中的执行频率、作业执行时间等参数进行反馈,从而更新关联关系图。
其中,上述步骤1和步骤4可以在整个调度过程中执行,直至调度结束,主要完成关联关系图的实时更新和作业流的实时调度。而步骤2和步骤3仅在调度开始阶段执行一次,主要完成数据流的调度,由于数据流的重定向会带来严重的通信开销,因此步骤2和3不宜频繁执行。步骤5在作业执行结束时触发,主要为下一轮调度修正信息。五个步骤相互协作,最终实现对于大数据应用的作业流及数据流的协同调度。
本公开实施例的技术方案引入了平台层与作业层的跨层关联关系,促进了数据流与作业流之间的信息整合,相比于单独的相关技术的方案以及相关技术的方案的简单结合,本公开实施例的协同调度方法会使大数据应用得到进一步的性能优化。
图16是本公开实施例提供的三种方案下终端用户画像系统的作业请求完成比例的变化示意图,图17是本公开实施例提供的三种方案下终端用户画像系统的提速百分比的变化示意图。
其中,这三种方案包括:本公开实施例的方案、作业层采用延迟调度(DelayedScheduling)策略平台层采用ActCap的方案(作业层调度策略与平台层调度策略简单结合,不感知作业请求与数据之间的关联关系)以及ShuffleWatcher方案(采用平台层调度策略)。
由图16可以发现,由于同时考虑了作业流与数据流,本公开实施例的调度策略与其他两种方案相比,作业请求完成情况相对较好,数据流和作业流都得到了优化调度;而本公开实施例的调度策略进一步引入了跨层关联关系,优化了作业流与数据流的协同整合,更合理地利用了全局资源,因此使得优先的平台资源容纳了更多的作业请求。
由图17可以发现,本公开实施例的调度策略进一步引入了跨层关联关系,优化了作业流与数据流的协同整合,使得大数据作业获得更优的提速,进一步优化了平台的全局资源整合,使得终端用户画像系统得到了最优的性能提速。
图18是本公开实施例提供的一种调度器的结构示意图,参见图18,该调度器应用于上述实施例示出的云计算系统中,该调度器包括:
获取模块1801,用于获取关联关系图和数据分布信息,关联关系图包括多个节点以及至少一条有向边,每个节点指代一条数据,每条有向边具有一个源节点和一个目的节点,有向边由有向边的源节点指向有向边的目的节点,有向边用于表示根据有向边的源节点指代的数据进行计算得到有向边的目的节点指代的数据的作业请求,数据分布信息包括每条数据所在的服务器;
请求定位模块1802,用于根据关联关系图和数据分布信息,按照预设节点排序策略遍历关联关系图中的节点,依次将遍历到的节点对应的作业请求定位到遍历到的节点指代的数据所在的任一服务器中,节点对应的作业请求是指以节点作为源节点的有向边表示的作业请求;
调度模块1803,用于将至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中。
在一种可能实现方式中,预设节点排序策略为按照度数从大到小的顺序进行排序的策略,度数是指节点连接的有向边的数量,请求定位模块1802,包括:
确定单元,用于按照预设节点排序策略遍历关联关系图中的节点,将关联关系图中当前度数最大的节点确定为遍历到的节点;
定位单元,用于将遍历到的节点对应的作业请求定位到遍历到的节点指代的数据所在的任一服务器中;
删除单元,用于将以遍历到的节点作为源节点的有向边删除;
确定单元、定位单元和删除单元还用于继续按照预设节点排序策略遍历关联关系图中的节点,将关联关系图中当前度数最大的节点确定为遍历到的节点,对遍历到的节点进行定位作业请求的步骤和删除对应有向边的步骤,直至关联关系图中所有节点的度数均不大于1为止。
在另一种可能实现方式中,调度器还包括:
日志获取模块,用于获取日志记录,日志记录包括作业请求记录和数据处理记录;
模型构建模块,用于根据作业请求记录构建随机排队模型,基于随机排队模型确定作业请求记录中的每个作业请求的输入数据和输出数据;
数据关联模型构建模块,用于根据数据处理记录构建数据关联模型,数据关联模型中包括多个节点,每个节点指代数据处理记录中的一条数据;确定每个作业请求的输入数据对应的源节点和输出数据对应的目的节点,在数据关联模型中添加由源节点指向目的节点的有向边,得到关联关系图。
在另一种可能实现方式中,调度器还包括:
轮数计算模块,用于计算作业请求记录中多个作业请求均执行结束所需的执行轮数W;
优先度计算模块,用于根据每个作业请求的作业执行频率和作业执行时间,计算每个作业请求的优先度,优先度与作业执行频率和作业执行时间正相关;
轮次确定模块,用于按照优先度从高到低的顺序对多个作业请求进行排序,将排名第nW+m位的作业请求和排名第(n+2)W+1-m的作业请求的执行轮次确定为m,m为正整数,且m不大于W,n为整数;
调度模块,还用于根据每个作业请求的执行轮次,将至少一个作业请求依次调度至所定位的服务器中。
在另一种可能实现方式中,调度器还包括:
集群规模设置模块,用于初始化每个作业请求的集群规模,作业请求对应的数据占用的服务器数量与作业请求的集群规模正相关;
集群规模调整模块,用于计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模;继续计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模,直至作业执行时间最长的作业请求的集群规模对应的服务器数量等于云计算系统中的服务器总数量时为止。
在另一种可能实现方式中,每个作业请求包括映射map任务、混洗shuffle任务和归并reduce任务,集群规模调整模块,还用于采用以下公式,计算任一作业请求在当前的集群规模下的作业执行时间:
其中,Lj(r)表示第j个作业请求的作业执行时间,r表示第j个作业请求当前分配的机架数量,k表示一个机架中的服务器数量,表示第j个作业请求输入文件的大小,表示第j个作业请求输出文件的大小,表示第j个作业请求的shuffle文件的大小,μmap表示map任务的单机平均处理效率,μreduce表示reduce任务的单机平均处理效率,表示第j个作业请求的reduce任务的数量,V表示过载率,B表示服务器的带宽。
在另一种可能实现方式中,调度器还包括:
排序模块,用于确定关联关系图中当前长度最大的关系链,关系链为一个第一节点以及由任一第二节点到达第一节点所经过的节点及有向边组成的集合,第一节点为不存在以第一节点为源节点的有向边的节点,第二节点为存在至少两条以第二节点为源节点的有向边的节点,或者为存在一条以第二节点为源节点的有向边且不存在以第二节点为目的节点的有向边的节点,每条关系链的长度由关系链中包含的有向边个数确定;按照集群规模从大到小的顺序,对当前长度最大的关系链中的有向边表示的作业请求进行排序,将集群规模最大的作业请求确定为指定作业请求;
数据定位模块,用于按照指定作业请求的集群规模,将指定作业请求对应的数据定位到数量与指定作业请求的集群规模匹配的服务器中,并按照当前长度最大的关系链中其他有向边表示的作业请求的集群规模,将其他作业请求对应的数据定位到指定作业请求所定位的且数量与其他作业请求的集群规模匹配的服务器中;
删除模块,用于将当前长度最大的关系链删除;
排序模块、数据定位模块和删除模块还用于继续确定关联关系图中当前长度最大的关系链,对确定的关系链进行定位数据的步骤,直至关联关系图中的每条有向边表示的作业请求对应的数据定位完成。
在另一种可能实现方式中,调度器还包括:
更新模块,用于当作业请求执行结束后,对日志记录进行更新,日志记录包括作业请求记录和数据处理记录;
更新模块,还用于根据更新后的日志记录,对关联关系图进行更新。
在另一种可能实现方式中,关联关系图中每条有向边的请求数量指代对应的作业请求的个数,每条有向边的权重指代对应作业请求的执行频率,更新模块,包括:
第一更新单元,用于根据更新后的作业请求记录,确定更新后的多个作业请求以及每个作业请求更新后的执行频率;
第二更新单元,用于根据更新后的多个作业请求,对关联关系图中的有向边进行更新,并对每条有向边的请求数量进行更新;
第三更新单元,用于根据每个作业请求更新后的执行频率,对关联关系图中每条有向边的权重进行更新。
图19是本公开实施例提供的一种调度器的结构示意图,参见图19,该调度器应用于上述实施例示出的云计算系统中,该调度器包括:存储器1901和处理器1902,存储器1901与处理器1902连接,存储器1901存储有至少一条指令,处理器1902用于调用指令,执行上述实施例中调度器所执行的操作。
本公开实施例还提供了一种计算机可读存储介质,计算机可读存储介质中存储有至少一条指令,该指令由处理器加载并执行时,使得计算机执行如上述实施例中的调度器所执行的操作。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本公开的可选实施例,并不用以限制本公开,凡在本公开的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本公开的保护范围之内。
Claims (21)
1.一种调度方法,其特征在于,所述方法包括:
获取关联关系图和数据分布信息,所述关联关系图包括多个节点以及至少一条有向边,每个节点指代一条数据,每条有向边具有一个源节点和一个目的节点,所述有向边由所述有向边的源节点指向所述有向边的目的节点,所述有向边用于表示根据所述有向边的源节点指代的数据进行计算得到所述有向边的目的节点指代的数据的作业请求,所述数据分布信息包括每条数据所在的服务器;
根据所述关联关系图和所述数据分布信息,按照预设节点排序策略遍历所述关联关系图中的节点,依次将遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中,所述节点对应的作业请求是指以所述节点作为源节点的有向边表示的作业请求;
将所述至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中。
2.根据权利要求1所述的方法,其特征在于,所述预设节点排序策略为按照度数从大到小的顺序进行排序的策略,所述度数是指节点连接的有向边的数量,所述根据所述关联关系图和所述数据分布信息,按照预设节点排序策略遍历所述关联关系图中的节点,依次将遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中,包括:
按照所述预设节点排序策略遍历所述关联关系图中的节点,将所述关联关系图中当前度数最大的节点确定为所述遍历到的节点;
将所述遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中;
将以所述遍历到的节点作为源节点的有向边删除;
继续按照所述预设节点排序策略遍历所述关联关系图中的节点,将所述关联关系图中当前度数最大的节点确定为所述遍历到的节点,对所述遍历到的节点进行所述定位作业请求的步骤和所述删除对应有向边的步骤,直至所述关联关系图中所有节点的度数均不大于1为止。
3.根据权利要求1所述的方法,其特征在于,所述获取关联关系图和数据分布信息之前,所述方法还包括:
获取日志记录,所述日志记录包括作业请求记录和数据处理记录;
根据所述作业请求记录构建随机排队模型,基于所述随机排队模型确定所述作业请求记录中的每个作业请求的输入数据和输出数据;
根据所述数据处理记录构建数据关联模型,所述数据关联模型中包括多个节点,每个节点指代所述数据处理记录中的一条数据;
确定所述每个作业请求的输入数据对应的源节点和输出数据对应的目的节点,在所述数据关联模型中添加由所述源节点指向所述目的节点的有向边,得到所述关联关系图。
4.根据权利要求1所述的方法,其特征在于,所述获取关联关系图和数据分布信息之前,所述方法还包括:
计算作业请求记录中多个作业请求均执行结束所需的执行轮数W;
根据每个作业请求的作业执行频率和作业执行时间,计算每个作业请求的优先度,所述优先度与所述作业执行频率和所述作业执行时间正相关;
按照优先度从高到低的顺序对所述多个作业请求进行排序,将排名第nW+m位的作业请求和排名第(n+2)W+1-m的作业请求的执行轮次确定为m,m为正整数,且m不大于W,n为整数;
所述将所述至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中,包括:根据每个作业请求的执行轮次,将所述至少一个作业请求依次调度至所定位的服务器中。
5.根据权利要求1所述的方法,其特征在于,所述方法还包括:
初始化每个作业请求的集群规模,所述作业请求对应的数据占用的服务器数量与所述作业请求的集群规模正相关;
计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模;
继续计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模,直至作业执行时间最长的作业请求的集群规模对应的服务器数量等于云计算系统中的服务器总数量时为止。
6.根据权利要求5所述的方法,其特征在于,每个作业请求包括映射map任务、混洗shuffle任务和归并reduce任务,所述计算每个作业请求在当前的集群规模下的作业执行时间,包括:
采用以下公式,计算任一作业请求在当前的集群规模下的作业执行时间:
7.根据权利要求5所述的方法,其特征在于,所述继续计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模,直至作业执行时间最长的作业请求的集群规模对应的服务器数量等于所述云计算系统中的服务器总数量时为止之后,所述方法还包括:
确定所述关联关系图中当前长度最大的关系链,所述关系链为一个第一节点以及由任一第二节点到达所述第一节点所经过的节点及有向边组成的集合,所述第一节点为不存在以所述第一节点为源节点的有向边的节点,所述第二节点为存在至少两条以所述第二节点为源节点的有向边的节点,或者为存在一条以所述第二节点为源节点的有向边且不存在以所述第二节点为目的节点的有向边的节点,所述关系链的长度由所述关系链中包含的有向边个数确定;
按照集群规模从大到小的顺序,对所述当前长度最大的关系链中的有向边表示的作业请求进行排序,将集群规模最大的作业请求确定为指定作业请求;
按照所述指定作业请求的集群规模,将所述指定作业请求对应的数据定位到数量与所述指定作业请求的集群规模匹配的服务器中,并按照所述当前长度最大的关系链中其他有向边表示的作业请求的集群规模,将所述其他作业请求对应的数据定位到所述指定作业请求所定位的且数量与所述其他作业请求的集群规模匹配的服务器中;
将所述当前长度最大的关系链删除;
继续确定所述关联关系图中当前长度最大的关系链,对确定的关系链进行所述定位数据的步骤,直至所述关联关系图中的每条有向边表示的作业请求对应的数据定位完成。
8.根据权利要求1-7任一项所述的方法,其特征在于,所述方法还包括:
当作业请求执行结束后,对日志记录进行更新,所述日志记录包括作业请求记录和数据处理记录;
根据更新后的日志记录,对所述关联关系图进行更新。
9.根据权利要求8所述的方法,其特征在于,所述关联关系图中每条有向边的请求数量指代对应的作业请求的个数,每条有向边的权重指代对应作业请求的执行频率,根据更新后的日志记录,对所述关联关系图进行更新,包括:
根据更新后的作业请求记录,确定更新后的多个作业请求以及每个作业请求更新后的执行频率;
根据所述更新后的多个作业请求,对所述关联关系图中的有向边进行更新,并对每条有向边的请求数量进行更新;
根据所述每个作业请求更新后的执行频率,对所述关联关系图中每条有向边的权重进行更新。
10.一种调度器,其特征在于,所述调度器包括:
获取模块,用于获取关联关系图和数据分布信息,所述关联关系图包括多个节点以及至少一条有向边,每个节点指代一条数据,每条有向边具有一个源节点和一个目的节点,所述有向边由所述有向边的源节点指向所述有向边的目的节点,所述有向边用于表示根据所述有向边的源节点指代的数据进行计算得到所述有向边的目的节点指代的数据的作业请求,所述数据分布信息包括每条数据所在的服务器;
请求定位模块,用于根据所述关联关系图和所述数据分布信息,按照预设节点排序策略遍历所述关联关系图中的节点,依次将遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中,所述节点对应的作业请求是指以所述节点作为源节点的有向边表示的作业请求;
调度模块,用于将所述至少一条有向边表示的至少一个作业请求依次调度至所定位的服务器中。
11.根据权利要求10所述的调度器,其特征在于,所述预设节点排序策略为按照度数从大到小的顺序进行排序的策略,所述度数是指节点连接的有向边的数量,所述请求定位模块,包括:
确定单元,用于按照所述预设节点排序策略遍历所述关联关系图中的节点,将所述关联关系图中当前度数最大的节点确定为所述遍历到的节点;
定位单元,用于将所述遍历到的节点对应的作业请求定位到所述遍历到的节点指代的数据所在的任一服务器中;
删除单元,用于将以所述遍历到的节点作为源节点的有向边删除;
所述确定单元、所述定位单元和所述删除单元还用于继续按照所述预设节点排序策略遍历所述关联关系图中的节点,将所述关联关系图中当前度数最大的节点确定为所述遍历到的节点,对所述遍历到的节点进行所述定位作业请求的步骤和所述删除对应有向边的步骤,直至所述关联关系图中所有节点的度数均不大于1为止。
12.根据权利要求10所述的调度器,其特征在于,所述调度器还包括:
日志获取模块,用于获取日志记录,所述日志记录包括作业请求记录和数据处理记录;
模型构建模块,用于根据所述作业请求记录构建随机排队模型,基于所述随机排队模型确定所述作业请求记录中的每个作业请求的输入数据和输出数据;
数据关联模型构建模块,用于根据所述数据处理记录构建数据关联模型,所述数据关联模型中包括多个节点,每个节点指代所述数据处理记录中的一条数据;确定所述每个作业请求的输入数据对应的源节点和输出数据对应的目的节点,在所述数据关联模型中添加由所述源节点指向所述目的节点的有向边,得到所述关联关系图。
13.根据权利要求10所述的调度器,其特征在于,所述调度器还包括:
轮数计算模块,用于计算作业请求记录中多个作业请求均执行结束所需的执行轮数W;
优先度计算模块,用于根据每个作业请求的作业执行频率和作业执行时间,计算每个作业请求的优先度,所述优先度与所述作业执行频率和所述作业执行时间正相关;
轮次确定模块,用于按照优先度从高到低的顺序对所述多个作业请求进行排序,将排名第nW+m位的作业请求和排名第(n+2)W+1-m的作业请求的执行轮次确定为m,m为正整数,且m不大于W,n为整数;
所述调度模块,还用于根据每个作业请求的执行轮次,将所述至少一个作业请求依次调度至所定位的服务器中。
14.根据权利要求10所述的调度器,其特征在于,所述调度器还包括:
集群规模设置模块,用于初始化每个作业请求的集群规模,所述作业请求对应的数据占用的服务器数量与所述作业请求的集群规模正相关;
集群规模调整模块,用于计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模;继续计算每个作业请求在当前的集群规模下的作业执行时间,并增大作业执行时间最长的作业请求的集群规模,直至作业执行时间最长的作业请求的集群规模对应的服务器数量等于云计算系统中的服务器总数量时为止。
15.根据权利要求14所述的调度器,其特征在于,每个作业请求包括映射map任务、混洗shuffle任务和归并reduce任务,所述集群规模调整模块,还用于采用以下公式,计算任一作业请求在当前的集群规模下的作业执行时间:
16.根据权利要求14所述的调度器,其特征在于,所述调度器还包括:
排序模块,用于确定所述关联关系图中当前长度最大的关系链,所述关系链为一个第一节点以及由任一第二节点到达所述第一节点所经过的节点及有向边组成的集合,所述第一节点为不存在以所述第一节点为源节点的有向边的节点,所述第二节点为存在至少两条以所述第二节点为源节点的有向边的节点,或者为存在一条以所述第二节点为源节点的有向边且不存在以所述第二节点为目的节点的有向边的节点,所述关系链的长度由所述关系链中包含的有向边个数确定;按照集群规模从大到小的顺序,对所述当前长度最大的关系链中的有向边表示的作业请求进行排序,将集群规模最大的作业请求确定为指定作业请求;
数据定位模块,用于按照所述指定作业请求的集群规模,将所述指定作业请求对应的数据定位到数量与所述指定作业请求的集群规模匹配的服务器中,并按照所述当前长度最大的关系链中其他有向边表示的作业请求的集群规模,将所述其他作业请求对应的数据定位到所述指定作业请求所定位的且数量与所述其他作业请求的集群规模匹配的服务器中;
删除模块,用于将所述当前长度最大的关系链删除;
所述排序模块、所述数据定位模块和所述删除模块还用于继续确定所述关联关系图中当前长度最大的关系链,对确定的关系链进行所述定位数据的步骤,直至所述关联关系图中的每条有向边表示的作业请求对应的数据定位完成。
17.根据权利要求10-16任一项所述的调度器,其特征在于,所述调度器还包括:
更新模块,用于当作业请求执行结束后,对日志记录进行更新,所述日志记录包括作业请求记录和数据处理记录;
所述更新模块,还用于根据更新后的日志记录,对所述关联关系图进行更新。
18.根据权利要求17所述的调度器,其特征在于,所述关联关系图中每条有向边的请求数量指代对应的作业请求的个数,每条有向边的权重指代对应作业请求的执行频率,所述更新模块,包括:
第一更新单元,用于根据更新后的作业请求记录,确定更新后的多个作业请求以及每个作业请求更新后的执行频率;
第二更新单元,用于根据所述更新后的多个作业请求,对所述关联关系图中的有向边进行更新,并对每条有向边的请求数量进行更新;
第三更新单元,用于根据所述每个作业请求更新后的执行频率,对所述关联关系图中每条有向边的权重进行更新。
19.一种调度器,其特征在于,所述调度器包括:处理器和存储器,所述存储器中存储有至少一条指令,所述指令由所述处理器加载并执行以实现如权利要求1至9任一项所述的方法中所执行的操作。
20.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有至少一条指令,所述指令由处理器加载并执行以实现如权利要求1至9任一项所述的方法中所执行的操作。
21.一种云计算系统,其特征在于,所述云计算系统包括多个服务器和如权利要求10至18任一项所述的调度器。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810244746.5A CN110297699B (zh) | 2018-03-23 | 2018-03-23 | 调度方法、调度器、存储介质及系统 |
EP19770974.4A EP3770774B1 (en) | 2018-03-23 | 2019-01-30 | Control method for household appliance, and household appliance |
PCT/CN2019/074017 WO2019179250A1 (zh) | 2018-03-23 | 2019-01-30 | 调度方法、调度器、存储介质及系统 |
US17/021,425 US11190618B2 (en) | 2018-03-23 | 2020-09-15 | Scheduling method, scheduler, storage medium, and system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810244746.5A CN110297699B (zh) | 2018-03-23 | 2018-03-23 | 调度方法、调度器、存储介质及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110297699A CN110297699A (zh) | 2019-10-01 |
CN110297699B true CN110297699B (zh) | 2021-09-14 |
Family
ID=67986645
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810244746.5A Active CN110297699B (zh) | 2018-03-23 | 2018-03-23 | 调度方法、调度器、存储介质及系统 |
Country Status (4)
Country | Link |
---|---|
US (1) | US11190618B2 (zh) |
EP (1) | EP3770774B1 (zh) |
CN (1) | CN110297699B (zh) |
WO (1) | WO2019179250A1 (zh) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110297699B (zh) * | 2018-03-23 | 2021-09-14 | 华为技术有限公司 | 调度方法、调度器、存储介质及系统 |
US11533268B2 (en) * | 2018-03-30 | 2022-12-20 | Intel Corporation | Methods and apparatus to schedule service requests in a network computing system using hardware queue managers |
US10820057B2 (en) | 2018-11-07 | 2020-10-27 | Nvidia Corp. | Scalable light-weight protocols for wire-speed packet ordering |
US11108704B2 (en) | 2018-12-04 | 2021-08-31 | Nvidia Corp. | Use of stashing buffers to improve the efficiency of crossbar switches |
CN111953614B (zh) * | 2020-08-07 | 2023-10-24 | 腾讯科技(深圳)有限公司 | 数据传输方法、装置、处理设备及介质 |
CN112615846B (zh) * | 2020-12-14 | 2022-03-22 | 重庆邮电大学 | 一种基于dag的区块链系统认证门限的更新方法 |
US20220197707A1 (en) * | 2020-12-17 | 2022-06-23 | EMC IP Holding Company LLC | System and method for efficient data collection based on data access pattern for reporting in large scale multi tenancy environment |
CN112817770B (zh) * | 2021-03-09 | 2024-01-30 | 皖西学院 | 一种提高分布式边缘计算系统负载均衡的方法 |
CN113377540A (zh) * | 2021-06-15 | 2021-09-10 | 上海商汤科技开发有限公司 | 集群资源调度方法及装置、电子设备和存储介质 |
CN114168198B (zh) * | 2022-02-10 | 2022-04-26 | 北京创新乐知网络技术有限公司 | 线上处理流程调整方法、系统及配置中心、服务端 |
US11770215B2 (en) | 2022-02-17 | 2023-09-26 | Nvidia Corp. | Transceiver system with end-to-end reliability and ordering protocols |
CN114816715B (zh) * | 2022-05-20 | 2022-11-22 | 中国地质大学(北京) | 一种面向跨地域的流计算延迟优化方法及装置 |
CN116562054B (zh) * | 2023-07-06 | 2023-10-13 | 西安羚控电子科技有限公司 | 一种多实体协同实时仿真系统的构建方法及装置 |
Family Cites Families (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8102788B2 (en) * | 2003-11-05 | 2012-01-24 | Interdigital Technology Corporation | Method and wireless transmit/receive unit for supporting an enhanced uplink dedicated channel inter-node-B serving cell change |
US7496912B2 (en) * | 2004-02-27 | 2009-02-24 | International Business Machines Corporation | Methods and arrangements for ordering changes in computing systems |
US7870556B2 (en) * | 2006-05-16 | 2011-01-11 | Ab Initio Technology Llc | Managing computing resources in graph-based computations |
US9424315B2 (en) * | 2007-08-27 | 2016-08-23 | Teradata Us, Inc. | Methods and systems for run-time scheduling database operations that are executed in hardware |
AU2009322602B2 (en) * | 2008-12-02 | 2015-06-25 | Ab Initio Technology Llc | Mapping instances of a dataset within a data management system |
WO2010093933A1 (en) * | 2009-02-13 | 2010-08-19 | Ab Initio Technology Llc | Communicating with data storage systems |
US10673952B1 (en) * | 2014-11-10 | 2020-06-02 | Turbonomic, Inc. | Systems, apparatus, and methods for managing computer workload availability and performance |
CN101710286A (zh) * | 2009-12-23 | 2010-05-19 | 天津大学 | 面向dag数据驱动型应用的并行编程模型系统和实现方法 |
CN101916162B (zh) * | 2010-08-05 | 2012-11-28 | 中国工商银行股份有限公司 | 一种基于有向图的动态界面生成方法、服务器及系统 |
CN102591712B (zh) | 2011-12-30 | 2013-11-20 | 大连理工大学 | 一种云计算中依赖任务的解耦并行调度方法 |
CN104714753A (zh) * | 2013-12-12 | 2015-06-17 | 中兴通讯股份有限公司 | 一种数据访问存储方法及装置 |
US9838478B2 (en) * | 2014-06-30 | 2017-12-05 | International Business Machines Corporation | Identifying a task execution resource of a dispersed storage network |
AU2015312016B2 (en) * | 2014-09-02 | 2019-09-19 | Ab Initio Technology Llc. | Executing graph-based program specifications |
CN104636204B (zh) * | 2014-12-04 | 2018-06-01 | 中国联合网络通信集团有限公司 | 一种任务调度方法与装置 |
WO2016095187A1 (en) * | 2014-12-19 | 2016-06-23 | Intel Corporation | Apparatus and method for adding nodes to a computing cluster |
CN106325756B (zh) * | 2015-06-15 | 2020-04-24 | 阿里巴巴集团控股有限公司 | 一种数据存储、数据计算方法和设备 |
US9934071B2 (en) * | 2015-12-30 | 2018-04-03 | Palo Alto Research Center Incorporated | Job scheduler for distributed systems using pervasive state estimation with modeling of capabilities of compute nodes |
CN105912383A (zh) | 2016-05-05 | 2016-08-31 | 中国人民解放军国防科学技术大学 | 一种高可靠性的依赖任务调度与资源配置方法 |
CN106610866A (zh) * | 2016-06-17 | 2017-05-03 | 四川用联信息技术有限公司 | 云存储环境下一种服务价值约束的任务调度算法 |
CN106201356B (zh) * | 2016-07-14 | 2019-07-19 | 北京理工大学 | 一种基于链路可用带宽状态的动态数据调度方法 |
CN107688488B (zh) * | 2016-08-03 | 2020-10-20 | 中国移动通信集团湖北有限公司 | 一种基于元数据的任务调度的优化方法及装置 |
CN106331150B (zh) * | 2016-09-18 | 2018-05-18 | 北京百度网讯科技有限公司 | 用于调度云服务器的方法和装置 |
US10261837B2 (en) * | 2017-06-30 | 2019-04-16 | Sas Institute Inc. | Two-part job scheduling with capacity constraints and preferences |
CN109218355B (zh) * | 2017-06-30 | 2021-06-15 | 华为技术有限公司 | 负载均衡引擎,客户端,分布式计算系统以及负载均衡方法 |
CN111079942B (zh) * | 2017-08-30 | 2023-03-24 | 第四范式(北京)技术有限公司 | 执行机器学习的分布式系统及其方法 |
CN107590254B (zh) * | 2017-09-19 | 2020-03-17 | 华南理工大学 | 具有合并处理方法的大数据支撑平台 |
US10606640B2 (en) * | 2017-12-23 | 2020-03-31 | International Business Machines Corporation | Rescheduling high performance computing jobs based on personalized sanity checks and job problem resolution classification |
CN110297699B (zh) * | 2018-03-23 | 2021-09-14 | 华为技术有限公司 | 调度方法、调度器、存储介质及系统 |
-
2018
- 2018-03-23 CN CN201810244746.5A patent/CN110297699B/zh active Active
-
2019
- 2019-01-30 WO PCT/CN2019/074017 patent/WO2019179250A1/zh active Application Filing
- 2019-01-30 EP EP19770974.4A patent/EP3770774B1/en active Active
-
2020
- 2020-09-15 US US17/021,425 patent/US11190618B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
WO2019179250A1 (zh) | 2019-09-26 |
EP3770774A4 (en) | 2021-05-26 |
US20200412835A1 (en) | 2020-12-31 |
CN110297699A (zh) | 2019-10-01 |
EP3770774A1 (en) | 2021-01-27 |
US11190618B2 (en) | 2021-11-30 |
EP3770774B1 (en) | 2022-09-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110297699B (zh) | 调度方法、调度器、存储介质及系统 | |
Cai et al. | APPM: adaptive parallel processing mechanism for service function chains | |
CN114138486B (zh) | 面向云边异构环境的容器化微服务编排方法、系统及介质 | |
CN108566659B (zh) | 一种基于可靠性的5g网络切片在线映射方法 | |
CN109617826B (zh) | 一种基于布谷鸟搜索的storm动态负载均衡方法 | |
CN109582448B (zh) | 一种面向关键度和时效性的边缘计算任务调度方法 | |
CN103530182A (zh) | 一种作业调度方法和装置 | |
CN113490279B (zh) | 一种网络切片配置方法及装置 | |
CN113672391B (zh) | 一种基于Kubernetes的并行计算任务调度方法与系统 | |
CN111597043A (zh) | 一种全场景边缘计算方法、装置及系统 | |
CN115134371A (zh) | 包含边缘网络算力资源的调度方法、系统、设备及介质 | |
EP4170491A1 (en) | Resource scheduling method and apparatus, electronic device, and computer-readable storage medium | |
CN107483355B (zh) | 面向数据中心的在线场景低带宽开销流量调度方案 | |
CN117097806A (zh) | 一种微服务调用图部署和请求路由联合优化方法及系统 | |
CN110048966B (zh) | 基于截止时间的最小化系统开销的Coflow调度方法 | |
Naik | A processing delay tolerant workflow management in cloud-fog computing environment (DTWM_CfS) | |
CN106407007B (zh) | 面向弹性分析流程的云资源配置优化方法 | |
Tao et al. | Congestion-aware traffic allocation for geo-distributed data centers | |
CN116302404B (zh) | 面向资源解耦合数据中心的服务器无感知计算调度方法 | |
Patel et al. | An improved approach for load balancing among heterogeneous resources in computational grids | |
CN114090239A (zh) | 一种基于模型的强化学习的边缘资源调度方法和装置 | |
Setia et al. | Literature survey on various scheduling approaches in grid computing environment | |
CN111245906A (zh) | 一种业务请求分配方法 | |
Bolodurina et al. | Dynamic routing algorithms and methods for controlling traffic flows of cloud applications and services | |
CN116795545B (zh) | 基于网算容器的信息物理生成系统及其管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |