一种共享数据的处理方法、装置及服务器
技术领域
本申请涉及通信技术领域,尤其涉及一种共享数据的处理方法、装置及服务器。
背景技术
Spark是一种处理大规模数据的快速通用的计算引擎。如图1所示,为一种Spark架构图,该Spark架构采用了分布式计算中的主从(Maser-Slave)模型,包括主节点100和至少一个从节点200。主节点100和从节点200构成了一个集群,共同执行一个或多个应用(application)程序。
Spark在执行一个应用程序的过程中,主节点100启动驱动(Driver)程序(主节点也可以称为Driver节点)。从节点200分别启动各自的作业(Worker)程序(从节点也可以称为Worker节点)。其中,Driver程序是应用程序的执行起点,负责对应用程序的具体的任务(Task)分发。Worker程序分别为该应用程序创建专用的执行器(Executor)进程,并在该执行器进程中以多线程方式运行Driver程序分配的任务。
由此,无论从调度角度看(每个Driver程序调度自己的任务),还是从运行角度看(不同应用程序的任务都在运行在不同的执行器中),Spark中各个应用程序的执行是相互隔离的,换言之,Spark中各个应用程序间无法进行数据共享。
然而,在实际场景中,不同应用程序之间,例如同一个业务的不同应用程序之间,可能存在大量相同的数据。各个应用程序间无法进行数据共享,会造成spark会进行大量的重复运算,以及存储大量重复数据,这些都会影响spark的运算速度。
发明内容
本申请提供的一种共享数据的处理方法、装置及服务器,可以跨应用程序缓存共享数据,有利于跨应用共享数据,能够减少重复运算,有利于提升Spark架构的运算速度,提升运行spark架构设备的运行速度,提高设备性能。
第一方面,本申请提供的一种共享数据的处理方法,运用于服务器集群,该方法包括:
第一服务器接收第一指令;第一服务器为第一应用程序启动第一Spark环境,创建第一应用程序的有向无环图DAG,并在第一服务器的第一区域缓存第一应用程序的DAG;第一服务器接收第二指令;第一服务器为第二应用程序启动第二Spark环境,创建第二应用程序的DAG,并在第一服务器的第一区域缓存第二应用程序的DAG;第一服务器从第一区域读取m个DAG,m个DAG包括第一应用程序的DAG和第二应用程序的DAG;第一服务器根据m个DAG,确定待缓存的可共享弹性分布式数据集RDD,并将待缓存的可共享RDD缓存在服务器集群的内存中,其中,可共享RDD为m个DAG中至少两个DAG都包含的RDD。
由此,本申请实施例提供的方法,可以根据多个应用程序的DAG,确定并缓存这多个应用程序的DAG中可共享的RDD,即实现跨应用的缓存可共享的RDD。由于多个应用程序中DAG可共享的RDD更多,因此后续使用这些可共享RDD时,能极大减少Spark的重复计算量,提升Spark运算速度。
一种可能的实现方式中,第一服务器根据m个DAG,确定待缓存的可共享弹性分布式数据集RDD,并将待缓存的可共享RDD缓存在服务器集群的内存中包括:计算m个DAG中每个DAG中可共享RDD的数量;确定第一DAG以及第一DAG中可共享RDD,第一DAG为m个DAG中可共享RDD的数量最大的DAG;根据服务器集群内存的剩余空间,确定第一DAG中待缓存的可共享RDD,并缓存第一DAG中待缓存的可共享RDD;确定第二DAG以及第二DAG中可共享RDD,第二DAG为m个DAG中除第一DAG外,可共享RDD的数量最大的DAG;根据服务器集群内存的剩余空间,确定第二DAG中待缓存的可共享RDD,并缓存第二DAG中待缓存的可共享RDD。
由于先选择可重用RDD的数量最大的DAG,对该DAG中可重用RDD进行缓存。由于该DAG中可与其他DAG重用的RDD的数量最多,所以优先对该DAG中可重用的RDD进行缓存,能够极大的减少重复计算的次数,减少重复缓存的数据,有利于提升Spark的运算速度,节省缓存成本。
一种可能的实现方式中,根据服务器集群内存的剩余空间,确定第一DAG中待缓存的可共享RDD包括:
若服务器集群内存的剩余空间大于或等于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中所有的可共享RDD为待缓存的可共享RDD;若服务器集群内存的剩余空间小于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中部分的可共享RDD为待缓存的可共享RDD。
一种可能的实现方式中,确定第一DAG中部分的可共享RDD为待缓存的可共享RDD包括:
根据第一DAG中各个可共享RDD的大小、重用次数、计算时间、或依赖的父RDD的大小确定第一DAG中部分的可共享RDD为待缓存的可共享RDD;或者,确定第一DAG中查询到的可共享RDD为待缓存的可共享RDD。
一种可能的实现方式中,根据服务器集群内存的剩余空间,确定第一DAG中待缓存的可共享RDD还包括:
若服务器集群内存的剩余空间大于或等于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中所有的可共享RDD为待缓存的可共享RDD;若服务器集群内存的剩余空间小于第一DAG中所有的可共享RDD的大小总和,则从服务器集群的内存中,确定待替换RDD,并根据服务器集群内存的剩余空间,以及待替换RDD的大小,确定第一DAG中待缓存的可共享RDD。
一种可能的实现方式中,从服务器集群的内存中,确定待替换RDD包括:
根据服务器集群内存中缓存的各个可共享RDD的大小、重用次数、计算时间、或依赖的父RDD的大小,确定待替换RDD。
一种可能的实现方式中,根据服务器集群内存的剩余空间,以及待替换RDD的大小,确定第一DAG中待缓存的可共享RDD包括:
若服务器集群内存的剩余空间与待替换RDD的大小之和,大于或等于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中所有的可共享RDD为待缓存的可共享RDD;若服务器集群内存的剩余空间与待替换RDD的大小之和,小于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中部分的可共享RDD为待缓存的可共享RDD。
一种可能的实现方式中,确定第一DAG中部分的可共享RDD为待缓存的可共享RDD包括:
根据第一DAG中各个可共享RDD的大小、重用次数、计算时间、或依赖的父RDD的大小确定第一DAG中部分的可共享RDD为待缓存的可共享RDD;或者,确定第一DAG中查询到的可共享RDD为待缓存的可共享RDD。
一种可能的实现方式中,缓存第一DAG中待缓存的可共享RDD包括:
从服务器集群的内存中移出待替换RDD,并缓存第一DAG中待缓存的可共享RDD。
一种可能的实现方式中,该方法还包括:从m个DAG中确定第三DAG;
从服务器集群的内存中读取第三DAG中可共享RDD,并根据第三DAG中可共享RDD,将第三DAG转换为第四DAG;第四DAG和第三DAG的执行结果相同。
一种可能的实现方式中,第四DAG的执行时间小于第三DAG的执行时间。
第二方面、一种服务器,包括:处理器、存储器和通信接口,存储器、通信接口与处理器耦合,存储器用于存储计算机程序代码,计算机程序代码包括计算机指令,当处理器从存储器中读取计算机指令,以使得服务器执行如下操作:
接收第一指令;为第一应用程序启动第一Spark环境,创建第一应用程序的有向无环图DAG,并在第一服务器的第一区域缓存第一应用程序的DAG;接收第二指令;为第二应用程序启动第二Spark环境,创建第二应用程序的DAG,并在第一服务器的第一区域缓存第二应用程序的DAG;从第一区域读取m个DAG,m个DAG包括第一应用程序的DAG和第二应用程序的DAG;根据m个DAG,确定待缓存的可共享弹性分布式数据集RDD,并将待缓存的可共享RDD缓存在服务器集群的内存中,其中,可共享RDD为m个DAG中至少两个DAG都包含的RDD。
一种可能的实现方式中,根据m个DAG,确定待缓存的可共享弹性分布式数据集RDD,并将待缓存的可共享RDD缓存在服务器集群的内存中包括:
计算m个DAG中每个DAG中可共享RDD的数量;确定第一DAG以及第一DAG中可共享RDD,第一DAG为m个DAG中可共享RDD的数量最大的DAG;根据服务器集群内存的剩余空间,确定第一DAG中待缓存的可共享RDD,并缓存第一DAG中待缓存的可共享RDD;确定第二DAG以及第二DAG中可共享RDD,第二DAG为m个DAG中除第一DAG外,可共享RDD的数量最大的DAG;根据服务器集群内存的剩余空间,确定第二DAG中待缓存的可共享RDD,并缓存第二DAG中待缓存的可共享RDD。
一种可能的实现方式中,根据服务器集群内存的剩余空间,确定第一DAG中待缓存的可共享RDD包括:
若服务器集群内存的剩余空间大于或等于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中所有的可共享RDD为待缓存的可共享RDD;若服务器集群内存的剩余空间小于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中部分的可共享RDD为待缓存的可共享RDD。
一种可能的实现方式中,确定第一DAG中部分的可共享RDD为待缓存的可共享RDD包括:
根据第一DAG中各个可共享RDD的大小、重用次数、计算时间、或依赖的父RDD的大小确定第一DAG中部分的可共享RDD为待缓存的可共享RDD;或者,确定第一DAG中查询到的可共享RDD为待缓存的可共享RDD。
一种可能的实现方式中,根据m个DAG,确定待缓存的可共享弹性分布式数据集RDD,并将待缓存的可共享RDD缓存在服务器集群的内存中还包括:
若服务器集群内存的剩余空间大于或等于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中所有的可共享RDD为待缓存的可共享RDD;若服务器集群内存的剩余空间小于第一DAG中所有的可共享RDD的大小总和,则从服务器集群的内存中,确定待替换RDD,并根据服务器集群内存的剩余空间,以及待替换RDD的大小,确定第一DAG中待缓存的可共享RDD。
一种可能的实现方式中,从服务器集群的内存中,确定待替换RDD包括:
根据服务器集群内存中缓存的各个可共享RDD的大小、重用次数、计算时间、或依赖的父RDD的大小,确定待替换RDD。
一种可能的实现方式中,根据服务器集群内存的剩余空间,以及待替换RDD的大小,确定第一DAG中待缓存的可共享RDD包括:
若服务器集群内存的剩余空间与待替换RDD的大小之和,大于或等于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中所有的可共享RDD为待缓存的可共享RDD;若服务器集群内存的剩余空间与待替换RDD的大小之和,小于第一DAG中所有的可共享RDD的大小总和,则确定第一DAG中部分的可共享RDD为待缓存的可共享RDD。
一种可能的实现方式中,缓存第一DAG中待缓存的可共享RDD包括:
从服务器集群的内存中移出待替换RDD,并缓存第一DAG中待缓存的可共享RDD。
一种可能的实现方式中,该服务器还执行如下操作:
从m个DAG中确定第三DAG;从服务器集群的内存中读取第三DAG中可共享RDD,并根据第三DAG中可共享RDD,将第三DAG转换为第四DAG;第四DAG和第三DAG的执行结果相同。
第三方面、一种计算机存储介质,包括计算机指令,当计算机指令在服务器上运行时,使得服务器执行如第一方面及其中任一种可能的实现方式中所述的方法。
第四方面、一种计算机程序产品,当计算机程序产品在计算机上运行时,使得计算机执行如第一方面中及其中任一种可能的实现方式中所述的方法。
第五方面、一种服务器,包括一个或多个处理器,以及与该一个或多个处理器耦合的一个或多个存储器,所述一个或多个存储器用于存储计算机程序代码,所述计算机程序代码包括计算机指令,当所述一个或多个处理器从所述一个或多个存储器中读取所述计算机指令,使得所述服务器执行如前述方法实施例中所描述的各个步骤。
附图说明
图1为现有技术中一种Spark框架的网络结构图;
图2为现有技术中一种转换DAG的方法示意图;
图3为现有技术中一种存储RDD的方法示意图;
图4为现有技术中Spark运行应用程序的流程示意图;
图5A为现有技术中Spark运行多个应用程序的流程示意图;
图5B为本申请实施例提供的一种Spark运行多个应用程序的流程示意图;
图5C为本申请实施例提供的一种缓存可共享RDD的方法的流程示意图;
图6A为本申请实施例提供的一种服务器的结构示意图;
图6B为本申请实施例提供的一种RDD共享系统的框架示意图;
图7为本申请实施例提供的另一种缓存可共享RDD的方法的流程示意图;
图8为本申请实施例提供的一种判断两个RDD是否相同的方法示意图;
图9为本申请实施例提供的又一种缓存可共享RDD的方法的流程示意图;
图10为本申请实施例提供的一种使用可共享RDD的方法的流程示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。其中,在本申请实施例的描述中,除非另有说明,“/”表示或的意思,例如,A/B可以表示A或B;本文中的“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。
以下,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中,除非另有说明,“多个”的含义是两个或两个以上。
Spark是新一代大数据分布式处理的框架之一,可用于大规模的数据运算的场景中。例如:可应用于推荐类的业务、或者计算用户偏好类的业务中。举例来说,在服务器侧,可以根据大量的用户使用习惯的数据,例如观看某类或某个视频、收听某类或某个音乐或查看某类新闻的时长、时间段等信息确定出用户感兴趣的内容,以便向端侧的用户推送相关内容等。
在Spark中,创新性提出了一种弹性分布式数据集(Resilient DistributedDatasets,RDD)的概念。RDD是一个分布式对象集合,本质上是一个只读的分区记录集合。并且,每个RDD可以分成多个分区(Partition),每个分区就是一个数据集片段,并且一个RDD的不同分区可以被保存到集群中不同的节点上,从而可以在集群中的不同节点上进行并行计算。
为了更好的理解本申请实施例提供的技术方案,先对RDD的相关术语进行说明。
RDD的转换(transformation)操作:将数据源(文本文件、图表文件等)生成一个RDD,或者将一个已经存在的RDD(例如:RDD1)转换成另一个RDD(例如:RDD2)。其中,RDD1称为RDD2的父RDD,RDD2称为RDD1的子RDD。常见的transformation有映射(map)操作、过滤(filter)操作,宽映射(flatMap)操作、union操作、join操作、reduceByKey操作等。
有向无环图(Directed Acyclic Graph,DAG):RDD提供了许多转换操作,每个转换操作都会生成新的RDD。换言之,新的RDD依赖于原有的RDD,这种RDD之间的依赖关系形成了DAG。例如:参见图2所示,其中,DAG1为:先对文本文件(源数据)执行一次map操作,生成RDD1,再执行一次filter操作,生成RDD2。
RDD之间的依赖关系:RDD中不同的转换操作会使得不同RDD的分区产生不同的依赖关系。具体分为窄依赖(Narrow Dependency)与宽依赖(Wide Dependency)。其中,窄依赖表现为一个父RDD的分区对应于一个子RDD的分区,或多个父RDD的分区对应于一个子RDD的分区。宽依赖则表现为存在一个父RDD的一个分区对应一个子RDD的多个分区。RDD这种依赖关系的设计,使得RDD具有容错性,且有利于加快Spark的执行速度。
RDD的共享:在RDD的转换过程中,若两个或两个以上的DAG中存在相同的RDD,则该相同的RDD可供DAG重复使用,实现共享。该相同的RDD可称之为可共享的RDD,也可称之为可重用的RDD。例如:继续参见图2,比较DAG1和DAG2可知:DAG1和DAG2存在相同的部分,即从文本文件到RDD1的形成过程是一样的。为了不对该相同的部分进行重复计算,可以在文本文件经过map转换后生成RDD1时,对RDD1进行持久化(或缓存)。这样,在后续生成RDD2和RDD3时,可以直接对RDD1进行调用。其中,RDD1即为可共享的RDD,或可重用的RDD。
RDD的持久化:RDD的转换过程中,并不是每个RDD都会存储,如果某个RDD会被重复使用,或者计算其代价很高,那么可以通过显示调用RDD提供的persist( )或cache()方法,把该RDD存储下来。
RDD的存储:RDD数据都是以块(block)的形式存储于多台机器(可以是物理机、也可以是虚拟机等)上的。如图3所示,为Spark的RDD存储架构图,其中,每个Worker节点会启动一个从块管理器(BlockManagerSlave),管理一部分Block,而Block的元数据则由Driver节点的主块管理器(BlockManagerMaster)保存。BlockManagerSlave生成Block后向BlockManagerMaster注册该Block。BlockManagerMaster管理RDD与Block的关系,当RDD不再需要存储的时候,将向BlockManagerSlave发送指令删除相应的Block。
下面对Spark运行应用程序的流程先进行简单说明。如图4所示,为Spark运行应用程序的流程示意图,该流程包括:
步骤1、Driver程序在启动一个应用程序时,先构建该应用程序的运行环境,即启动Spark环境(SparkContext)。
步骤2、SparkContext向资源管理器申请资源,其中,资源管理器用于分配并监控资源使用情况。
其中,资源管理器也可称之为集群管理器(Cluster Manager),是集群中获取资源的外部服务。Spark支持不同的运行模式,包括Local,Standalone,Mesoses,Yarn模式。在不同运行模式下,资源管理器不同,例如:Standalone运行模式下,资源管理器为Spark原生的资源管理,由Master负责资源的调配。Hadoop Yarn运行模式下,资源管理器主要是指Yarn中的资源管理器(ResourceManager)。Apache Mesos运行模式下,资源管理器是与HadoopMapReduce兼容性良好的一种资源调度框架。
步骤3、资源管理器分配资源,多个worker程序中分别创建该应用程序专属的Executor。
步骤4、各个Executor向SparkContext申请任务。
步骤5、SparkContext从各个Executor中加载源数据(例如文本文件、图表文件等),创建RDD,构建DAG图。将DAG图中的RDD分解成Stage,再将Stage分解为Task,最后将Task和Task所依赖的数据序列化后发送给各个Executor。
其中,一个Stage中包含多组task,作为一个任务集(TaskSet)。
步骤6、各个Executor运行分配给自己的Task,运行结束后释放所有资源。
在现有技术中,在接收到启动应用程序的请求后,资源管理器为Driver节点分配一个容器(container)。然后,Driver节点在该容器中启动该应用程序的SparkContext。也就是说,资源管理器会为每一个应用程序分配一个容器,在一个容器中启动一个应用程序的SparkContext。换言之,不同的应用程序的SparkContext对应不同的容器,又由于不同的容器之间不能相互访问数据,使得不同应用程序的SparkContext之间不能共享数据。
例如:如图5A所示,为现有技术中Spark启动多个应用程序的示意图。其中,资源管理器分别为APP1分配容器1,为APP2分配容器2,以及为APP3分配容器3。而后,Driver节点分别在容器1中启动APP1的SparkContext1,容器2中启动APP2的SparkContext2,以及容器3中启动APP3的SparkContext3。由于SparkContext1、SparkContext2和SparkContext3位于不同的容器,故SparkContext1、SparkContext2和SparkContext3之间不同相互访问数据。后续,这三个SparkContext申请多个Worker节点(例如:作业程序A和作业程序B)的资源,并在这多个Worker节点中分别创建了三个Executor,各个Executor上执行各自应用程序对应的任务。可见,不同应用程序之间的数据是不同共享的。
然而,在实际场景中,多个应用程序之间也会存在大量重复数据,例如同一个业务(同属于视频类的业务,或同属于音乐类的业务,或同属于支付类的业务等)的不同应用程序之间通常都会存在大量相同的RDD。若不能实现不同应用程序之间的RDD共享,会造成有大量的重复计算,浪费计算资源。
为此,本申请实施例提供了一种数据共享的方法,可运行在Driver节点上,能够实现Spark中多个应用程序之间共享RDD数据,有利于减少大量重复计算,提升了Spark运算速度。
在本申请中,在资源管理器为Driver节点分配容器时,资源管理器会为这多个应用程序分配一个容器。然后,Driver节点在该容器中分别启动各个应用程序的SparkContext。换言之,同一个容器中启动有多个应用程序的SparkContext。由于同一个容器的SparkContext之间可以相互访问数据,那么,同一容器中的多个应用程序可以相互访问数据。换言之,Driver节点可以访问同一容器中不同应用程序的数据。例如:处于同一容器中不同应用程序的SparkContext创建的DAG。也就是说,Driver节点可以访问到同一容器中多个应用程序的DAG。这样,可以对同一个容器中多个应用程序的DAG进行集中处理,以实现多个应用程序共享数据,从而减少Spark的重复计算量,提升Spark运算速度。
其中,这多个应用程序可以为同一业务(或相似业务)的多个应用程序。由于这多个应用程序属于同一业务或相似业务,具有大量相同数据,采用相同或相似的运算,进而产生大量相同的RDD,这些相同的RDD即为可共享的RDD,也可称为可重用的RDD。显然,实现对这多个应用程序之间的RDD共享,能极大避免重复计算,提升这多个应用程序的运行速度,提升Spark系统的计算速度。可以理解的是,这多个应用程序还可以是其他相似或关联的应用程序,本申请实施例不限定这多个应用程序之间的关系。
例如:如图5B所示,为本申请中Spark启动多个应用程序的示意图。其中,资源管理器为APP1、APP2和APP3分配了容器1。而后,Driver节点在容器1中分别启动了APP1的SparkContext1、APP2的SparkContext2,以及APP3的SparkContext3。由于SparkContext1、SparkContext2和SparkContext3位于同一容器中,故SparkContext1、SparkContext2和SparkContext3之间可以相互访问数据。那么,SparkContext1构建的DAG、SparkContext2构建的DAG和SparkContext3构建的DAG也可以相互访问。
简单来说,后续,在对同一容器中的多个应用程序的DAG进行处理时,可以确定并缓存这多个应用程序的DAG中可重用的RDD。后续,根据已经缓存的可重用RDD,对这多个应用程序的DAG进行转换。转换后的DAG与转换前的DAG,计算结果是一样,但由于转换后的DAG在计算时可以直接调用已经缓存的可重用的RDD,极大了提升了运算速度。需要注意的是,由于本申请实施例中以多个应用程序的DAG为处理对象的,确定的可重用的RDD也是可以跨应用使用的,即能够实现Spark中多个应用程序之间共享RDD数据。
如图5C所示,为本申请实施例提供的一种缓存可共享RDD的方法流程图,可运行第一服务器(即Driver节点),具体包括:
S401、第一服务器接收第一指令。
其中,第一指令可以是请求第一服务器启动第一应用程序的指令。
S402、第一服务器为第一应用程序启动第一Spark环境(例如:SparkContext 1),创建第一应用程序的有向无环图DAG,并在第一服务器的第一区域缓存第一应用程序的DAG。
其中,第一服务器的第一区域第一服务器向资源管理器申请的资源,可理解为上文提到的资源管理器为第一应用程序分配的容器。
S403、第一服务器接收第二指令。
其中,第二指令可以是请求第一服务器启动第二应用程序的指令。
S404、第一服务器为第二应用程序启动第二Spark环境(例如:SparkContext 2),创建第二应用程序的DAG,并在第一服务器的第一区域缓存第二应用程序的DAG。
可理解为,第一服务器在资源管理器为第一应用程序分配的容器中,启动第二Spark环境,进而第二Spark环境创建的第二应用程序的DAG缓存在该容器中。也就是说,第一应用程序的DAG和第二应用程序的DAG缓存在同一个容器中。
S405、第一服务器从上述第一区域读取m个DAG,m个DAG包括第一应用程序的DAG和第二应用程序的DAG。
S406、第一服务器根据所述m个DAG,确定待缓存的可共享RDD,并将所述待缓存的可共享RDD缓存在第二服务器的内存中。
其中,所述可共享RDD为所述m个DAG中至少两个DAG都包含的RDD。
其中,第二服务器的内存为:第一服务器的内存,或者第二服务器的内存,或者为第一服务器的全部或部分内存与第二服务器的全部或部分内存之和。
需要说明的是,在Spark框架中,多个服务器之间内存是可以共享的,并且上文已提到,RDD的数据是以块(block)的形式存储于多台服务器(可以是物理机、也可以是虚拟机等)上。因此,第二服务器的内存是指该集群中多个服务器的总内存,不再具体区分哪一个或哪几个服务器的内存。
本申请实施例提供的数据共享的方法可应用于如图1所示的Spark的框架中,该Spark框架中包含有一个或多个Driver节点,以及一个或多个Worker节点。其中,Driver节点和Worker节点可以是相同或不同的服务器,例如:Driver节点和Worker节点可以是如图6A中所示的服务器300。
如图6A所示,为本申请实施例公开了一种服务器300的硬件结构示意图,服务器300包括至少一个处理器301、至少一个存储器302、至少一个通信接口303。可选的,服务器300还可以包括输出设备和输入设备,图中未示出。
处理器301、存储器302和通信接口303通过总线相连接。处理器301可以是一个通用中央处理器(Central Processing Unit,CPU)、微处理器、特定应用集成电路(Application-Specific Integrated Circuit,ASIC),或者一个或多个用于控制本申请方案程序执行的集成电路。处理器301也可以包括多个CPU,并且处理器301可以是一个单核(single-CPU)处理器或多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路或用于处理数据(例如计算机程序指令)的处理核。
在本申请实施例中,处理器301具体用于计算第一窗口中每个DAG的可重用RDD的数量,确定其中可重用数量最大的DAG为第一DAG,根据内存中剩余的空间,确定是否可缓存第一DAG中全部或部分的可重用的RDD,从已缓存的RDD中选择待替换的RDD进行标记等。
存储器302可以是只读存储器(Read-Only Memory,ROM)或可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(Random Access Memory,RAM)或者可存储信息和指令的其他类型的动态存储设备,也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-Only Memory,EEPROM)、只读光盘(Compact Disc Read-Only Memory,CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器302可以是独立存在,通过总线与处理器301相连接。存储器302也可以和处理器301集成在一起。其中,存储器302用于存储执行本申请方案的应用程序代码,并由处理器301来控制执行。处理器301用于执行存储器302中存储的计算机程序代码,从而实现本申请实施例中数据共享的方法。
在本申请实施例中,存储器302可用于存储可重用的RDD等。
通信接口303,可用于与其他设备或通信网络通信,如以太网,无线局域网(wireless local area networks,WLAN)等。
在本申请实施例中,通信接口303可具体用于每个Driver节点之间的通信,每个Worker节点之间的通信,以及Driver节点与Worker节点之间的通信等。
输出设备和处理器通信,可以以多种方式来显示信息。例如,输出设备可以是液晶显示器(Liquid Crystal Display,LCD),发光二级管(Light Emitting Diode,LED)显示设备,阴极射线管(Cathode Ray Tube,CRT)显示设备,或投影仪(projector)等。输入设备和处理器通信,可以以多种方式接收用户的输入。例如,输入设备可以是鼠标、键盘、触摸屏设备或传感设备等。
以下,结合附图对同一个容器中的多个应用程序的DAG进行数据共享的方法进行详细说明。
如图6B所示,为本申请实施例提供的一种RDD共享系统的框架示意图。该RDD共享系统可运行在Driver节点上,可以包括DAG等待队列、DAG匹配器、DAG转换器、分布式共享内存(可简称为共享内存)和磁盘。
在一些示例中,DAG等待队列可以包括第一窗口和第二窗口。其中,第一窗口中排列的DAG,是指当第二窗口中存在空缺时,可以从第一窗口中选择满足条件的DAG进行补位,即从第一窗口经过转换后,进入到第二窗口。第二窗口中排列的DAG是指等待Spark内核空闲时即可执行的DAG,例如:将DAG分解为Stage,将Stage分解为task,后分发给各个Worker节点,以便各个Worker节点运行task等。在另一些示例中,DAG等待队列还可以包括第三窗口,第三窗口是指排列在第一窗口后的待执行DAG。
其中,各个窗口的大小,可理解为各个窗口中包含的DAG数量或者数据量大小等,例如:第一窗口可排列的DAG的数量可以为103至105个。一些示例中,可以根据集群中运行的多个应用程序的业务类型(例如:视频类业务,音乐类业务、以及支付类业务等)进行确定各个窗口的大小。不同的业务类型,窗口大小可以不同。另一些示例中,也可以根据集群中服务器的硬件能力(例如内存、CPU运行速率等)以及服务器数量来确定各个窗口的大小。服务器数量越大,硬件能力越强的,各个窗口的大小越大。又一些示例中,还可以根据经验值或者根据用户的设置确定各个窗口的大小等,本申请实施例对此不做限定。
例如:参见图6B,第一窗口中排列有m个DAG,分别为DAGn+1,DAGn+2,……,DAGn+m。第二窗口中排列有n个DAG,分别为DAG1,DAG2,……,DAGn。第三窗口中排列有DAGn+m+1及其他待执行DAG。
DAG匹配器,用于从第一窗口中的DAG中确定出可重用的RDD,并将确定出的可重用的RDD缓存到共享内存中。在一些实施例中,当共享内存中的空间不足以存储待缓存的RDD时,可以选择将共享内存中的某些RDD存储到磁盘中,将原用于存储该RDD的空间,用于存储待缓存的可重用的RDD。
DAG转换器,用于从共享内存中读取出可重用的RDD,将第一窗口中的DAG根据该可重用的RDD进行转换,将转换后的DAG放入第二窗口,等待执行。
本申请提供的对RDD共享的方法可以包括缓存可重用RDD的过程和根据可重用RDD转换DAG的过程。下面分别对两个过程进行说明。
一、缓存可重用RDD的过程,如下:
如图7所示,为本申请实施例提供的一种缓存可重用RDD的方法的流程示意图,该缓存方法具体包括:
S101、第一窗口中有m个待执行的DAG,DAG匹配器计算这m个待执行的DAG中每个DAG可重用RDD的数量。
其中,第一窗口的大小,可理解为第一窗口中包含的DAG数量或者数据量大小等,例如:第一窗口可排列的DAG的数量可以为103至105个。一些示例中,可以根据集群中运行的多个应用程序的业务类型(例如:视频类业务,音乐类业务、以及支付类业务等)进行确定各个窗口的大小。不同的业务类型,第一窗口的大小可以相同或不同。另一些示例中,也可以根据集群中服务器的硬件能力(例如内存、CPU运行速率等)以及服务器数量来确定第一窗口的大小。服务器数量越大,硬件能力越强的,第一窗口的大小越大。又一些示例中,还可以根据经验值或者根据用户的设置确定第一窗口的大小等,本申请实施例对此不做限定。
S102、DAG匹配器从这m个待执行的DAG中,确定可重用RDD数量最大的DAG为第一DAG,并确定第一DAG中可重用的RDD。
在步骤S101和S102中,某个DAG可重用RDD,是指该DAG与第一窗口中其他DAG中具有相同的RDD,相同的RDD意味着执行的是相同的task,故可以重复使用。即对该可重用RDD进行缓存后,具有该可重用RDD的其他DAG在计算时,可以直接调用该可重用RDD,从而达到减少计算量,提升计算速度的效果。
在确定两个RDD是否相同时,当两个RDD满足以下条件,则认为这两个RDD是相同的,可确定为可重用RDD,如下:
条件1、分区(partition)一致。
由于每个RDD可以分成多个分区,每个分区就是一个数据集片段,是RDD并行执行的最小单位。并且一个RDD的不同分区可以被保存到集群中的不同worker上,从而可以在集群中的不同worker上进行并行计算。因此,在判断两个或两个以上的RDD是否相同时,需要确认这两个RDD的分区的数量是否相同,而后,进一步通过条件2、条件3、条件4去判断RDD中各个分区的内容是否相同。
条件2、依赖的前一个RDD相同。
上文已提到RDD是已存在的RDD经过转换操作得到的。在确定两个RDD是否相同时,需要确定这两个RDD所依赖的前一个RDD(即父RDD)是否相同。其中,前一个RDD可以是一个或多个。
条件3、前一个转换操作相同。
上文已提到RDD是已存在的RDD经过转换操作得到的。在确定两个RDD是否相同时,需要确定这两个RDD前一个转换操作是否相同。
条件4、读取的源数据相同。
由于在创建RDD时,先读取内存中的数据集(即源数据),创建第一个RDD,并由第一个RDD经过多个转换操作形成后续的RDD。因此,在判断两个或两个以上的RDD是否相同时,也需要判断一下读取的源数据是否相同。
例如:如图8所示,为DAG3的一个依赖关系的示意图。其中,RDDd包含有三个分区,其中,RDDd的分区1由RDDb的分区1以及RDDc的分区2,经过操作1(例如:join)得到的。RDDd的分区2由RDDb的分区2、RDDc的分区1以及RDDc的分区2,经过操作1(例如:join)得到的。RDDd的分区3由RDDb的分区3、RDDc的分区1以及RDDc的分区2,经过操作1(例如:join)得到的。
在判断某个RDD(例如:RDDe)是否与RDDd相同时,先确定出RDDe包含的分区数量,判断RDDe的分区数量是否和RDDd的分区数量是否相同。若相同,则认为RDDe和RDDd分区一致。确定出RDDe的依赖的上一个父RDD为RDDx和RDDy,进一步确定RDDx和RDDy是否分别与RDDb和RDDc相同。若相同,则认为RDDe和RDDd依赖的上一个RDD相同。确定出RDDe的上一个转换操作为操作z,进一步判断操作z是否与操作1相同。若相同,则确定则认为RDDe和RDDd前一个转换操作相同。确定出RDDe使用的源数据为源数据i、源数据j等,判断出RDDe使用的源数据(源数据i、源数据j等)是否分别与源数据1、源数据2、源数据3、源数据4和源数据5相同。若相同,则确定RDDe与RDDd的源数据相同。当这四个条件均满足时,可以确定RDDe与RDDd相同。
其中,某个DAG的可重用RDD的数量是该DAG与第一窗口中其他DAG一一比较后,确定的可重用RDD的总共个数。
例如:第一窗口中有m个DAG,分别为DAGn+1,DAGn+2,……,DAGn+m。对计算DAGn+1的可重用RDD的数量进行说明。示例性的,可将DAGn+1分别与第一窗口中其他m-1个DAG进行比较,确定是否具有可重用的RDD。假设DAGn+1与DAGn+2可重用的RDD有两个,分别为RDD3和RDD7;DAGn+1与DAGn+3可重用的RDD有两个,分别为RDD3为RDD5;DAGn+4与DAGn+1可重用的RDD为RDD2,DAGn+5与DAGn+1可重用的RDD为RDD6,其余DAG与DAGn+1均无可重用的RDD。那么,DAGn+1中可重用RDD的数量为5,分别为RDD3、RDD7、RDD5、RDD2和RDD6。此外现有技术。
以此类推,计算出第一窗口中其他DAG的可重用RDD的数量。假设DAGn+2中可重用RDD的数量为3,DAGn+3中可重用RDD的数量为2,其余DAG中可重用RDD的数量均为1。那么,可确定可重用RDD的数量最大的为DAGn+1,可以将DAGn+1中可重用的RDD(RDD3、RDD7、RDD5、RDD2和RDD6)进行缓存。
一些实施例中,可以先选择可重用RDD的数量最大的DAG,对该DAG中可重用RDD进行缓存。由于该DAG中可与其他DAG重用的RDD的数量最多,所以优先对该DAG中可重用的RDD进行缓存,能够极大的减少重复计算的次数,减少重复缓存的数据,有利于提升Spark的运算速度,节省缓存成本。
S103、DAG匹配器根据共享内存中剩余空间,确定是否可缓存第一DAG中的全部可重用RDD。若是,执行步骤S104,否则执行步骤S105。
具体的,DAG匹配器读取共享内存中剩余空间,与缓存第一DAG中的全部可重用RDD的需占用的总空间进行比较。若共享内存中剩余空间大于或等于第一DAG中的全部可重用RDD需占用的总空间,则确定可以缓存第一DAG中全部的可重用的RDD,简称为可以全部缓存。否则,确定不可缓存第一DAG中全部的可重用的RDD。
例如:仍然以DAGn+1为例进行说明。DAGn+1可重用RDD的数量为5,分别为RDD3、RDD7、RDD5、RDD2和RDD6。缓存DAGn+1中的全部可重用RDD的需占用的总空间,是指将RDD3、RDD7、RDD5、RDD2和RDD6全部缓存到共享内存时,所需要占用共享内存的空间大小。
在一些示例中,DAG匹配器还可以先确定下是否可以查询到第一DAG中全部的可重用的RDD,若能查询到,则可以进一步判断共享内存中剩余空间是否可以缓存全部的可重用的RDD。若有可重用的RDD未查询到,则直接可确定不可以缓存全部的可重用的RDD。进一步再确定是否可以缓存已经查询的,第一DAG中所依赖的部分的可重用的RDD,即执行步骤S105。
S104、DAG匹配器将第一DAG中可重用的RDD全部缓存到共享内存中。
而后,执行步骤S107。
S105、DAG匹配器从第一DAG中可重用的RDD中,确定待缓存的可重用的RDD。
具体的,DAG匹配器可以根据共享内存中剩余空间,从第一DAG中可重用的RDD中选择一部分的可重用的RDD,作为待缓存的可重用的RDD并进行缓存,即缓存第一DAG中部分可重用的RDD。也就是说,第一DAG中有至少一个可重用的RDD不缓存。
例如:仍然以第一DAG是DAGn+1为例进行说明。DAGn+1可重用RDD的数量为5,分别为RDD3、RDD7、RDD5、RDD2和RDD6。根据步骤S103中确定共享内存中剩余空间不足以缓存RDD3、RDD7、RDD5、RDD2和RDD6时,可以从RDD3、RDD7、RDD5、RDD2和RDD6中选择一些RDD进行缓存。缓存DAGn+1中部分可重用的RDD,是指可以缓存RDD3、RDD7、RDD5、RDD2和RDD6中任一个,或任两个,或任三个,或任四个。
一些实施例中,DAG匹配器从第一DAG中可重用的RDD中选择待缓存的可重用的RDD时,可以根据可重用RDD的使用频率(可重用的次数)、或可重用RDD的计算时间、或可重用RDD依赖的父RDD的大小,或可重用RDD的大小、或可重用RDD的权重等因素进行确定。DAG匹配器还可以选择已经查询的RDD进行部分缓存,本申请实施例对选择可重用RDD的方法不做限定。
示例性的,可以从第一DAG中可重用的RDD中选择使用频率较高的预定数量的可重用RDD,作为待缓存的可重用RDD。或者,可以从第一DAG中可重用的RDD中选择计算时间较长的预定数量的可重用RDD,作为待缓存的可重用RDD。或者,可以从第一DAG中可重用的RDD中选择所依赖的父RDD的大小较大的预定数量的可重用RDD,作为待缓存的可重用RDD。或者,可以从第一DAG中可重用的RDD中选择自身大小较大的预定数量的可重用RDD,作为待缓存的可重用RDD,或者,可以从第一DAG中可重用的RDD中选择权重较大的预定数量的可重用RDD,作为待缓存的可重用RDD。
例如:仍然以第一DAG为DAGn+1为例进行说明。DAGn+1可重用RDD的数量为5,分别为RDD3、RDD7、RDD5、RDD2和RDD6。步骤S103中已确定共享内存中剩余空间不足以缓存RDD3、RDD7、RDD5、RDD2和RDD6时,可以从RDD3、RDD7、RDD5、RDD2和RDD6中选择一些RDD进行缓存。假设:在第一窗口中,RDD3的可重用次数为6,RDD7的可重用次数为5,RDD5的可重用次数为4,RDD2的可重用次数为3,RDD6的可重用次数为2。可以选择可重用次数高的一个RDD进行缓存,例如:RDD3,也可以选择可重用次数高的预设数量个RDD进行缓存,例如:RDD3和RDD7,不再一一赘述。
其中,RDD的权重大小可以根据应用程序的业务类型进行确定,或者根据用户的设置进行确定,或者根据预定义的方法进行确定。以下,示例性给出一个计算RDD权重的方法,即根据公式1确定RDD的权重,如下:
其中,W(RDDi)为第i个RDD的权重,Parent(RDDi)为第i个RDD的所有父RDD的大小之和。c为第i个RDD的计算代价,可反映第i个RDD的计算复杂度,例如反映计算第i个RDD所耗用的时间。F为第i个RDD的使用次数,即可重用的次数。RDDsize为第i个RDD的大小。
其中,RDD的计算代价具体可以是RDD中转换操作的计算复杂度。不同的转换操作的计算复杂度不同。举例来说,上文以提到常见的转换操作有map、filter、flatmap、reduceByKey、join和union等。在这里对计算复杂度进行一个简单比较。其中:map、filter的计算复杂度差不多。flatmap和reduceByKey的计算复杂度差不多。map、filter的计算复杂度要低于flatmap、reduceByKey。而join和union的计算复杂度还根据具体包含的分区数量相关,分区数量越大,计算复杂度也越大。本申请对RDD的计算代价的具体算法不做限定。
还需要说明的是,公式1中,等式右边的参数可以包含Parent(RDDi)、c、F、RDDsize中任一个或任几个,或者包含更多的参数,本申请对计算RDD权重的方法不做限定。
例如:计算RDD权重的公式还可以是公式2至公式7中任一种,如下:
W(RDDi)=Parent(RDDi)×c×F (公式5)
W(RDDi)=Parent(RDDi)×c (公式6)
另一些实施例中,DAG匹配器可以预先设置待缓存的可重用RDD的数量,即静态指定待缓存的可重用的RDD的数量为预设数量,例如:一个或多个。DAG匹配器也可以根据共享内存中剩余空间,动态确定待缓存的可重用的RDD的数量。例如:先从第一DAG中选择一个待缓存的可重用的RDD,然后,根据共享内存中剩余空间和已选择的待缓存的可重用RDD的大小,确定是否可以缓存该待缓存的可重用的RDD,接着从第一DAG中选择下一个待缓存的可重用的RDD,依次类推,直到共享内存剩余空间在缓存已选择的待缓存的可重用RDD之后,不能再缓存第一DAG中更多的可重用的RDD。
S106、DAG匹配器将待缓存的可重用的RDD缓存到共享内存中。
S107、DAG匹配器从第一窗口中剩余m-1个待执行的DAG(除了第一DAG外)中,确定可重用RDD数量最大的DAG为第二DAG,以及第二DAG中可重用的RDD。
本步骤的具体实现可参考步骤S102,不再赘述。
S108、DAG匹配器确定缓存第二DAG中全部可重用RDD,或者缓存第二DAG中部分可重用RDD。
本步骤的具体实现可参考步骤S103至步骤S106,不再赘述。
以此类推,按照可重用RDD数量的大小的顺序,依次确定第一窗口中这m个DAG中每个DAG中可重用RDD是否可以全部缓存或部分缓存。当针对第一窗口中这m个DAG中的可重用RDD是否可以全部缓存或部分缓存确定完成后,本流程结束。在一些示例中,在DAG匹配器执行本流程的过程中,若确定共享内存的剩余空间达到一定阈值,可认为不足以缓存后续的可重用的RDD时,可停止本流程。
当第二窗口出现空位时,第一窗口中排列在前的DAG会经过DAG转换器的转换后进入第二窗口。此时,第一窗口也会出现空位,则第三窗口中排列在前的DAG会进入第一窗口。也就是说,第一窗口中的这m个DAG会一个个的进入到第二窗口,同时,第一窗口会出现从第三窗口一个个的补入新的DAG。
那么,DAG匹配器会针对第一窗口中排列的下一批的m个DAG,执行如步骤S101至S108相同的操作,在此不重复赘述。
在本申请的一些实施例中,DAG匹配器可以在下一批的m个DAG有部分DAG排列在第一窗口时,开始对下一批的m个DAG执行如步骤S101至S108相同的操作。DAG匹配器还可以在下一批的m个DAG全部排列在第一窗口时,才开始执行相应的操作。本申请实施例对此不做限定。
以此类推,DAG匹配器对第一窗口中的每m个DAG执行步骤如步骤S101至S108相同的操作,在此不重复赘述。
在另一些实施例中,当共享内存的剩余空间不够某个DAG中全部的可重用RDD时,可以用这些待缓存的可重用RDD去替换共享内存中原来缓存的一些不太重要的RDD作为待替换的RDD,例如权重小的RDD。换言之,上述实施例中步骤S104至S106可替换为步骤S201至S206。如图9所示,为本申请实施例提供的又一种缓存可重用RDD的方法的流程图,具体包括步骤S101至S104,以及步骤S201至S206,以及步骤S107。其中步骤S101至S104以及步骤S107可参考上文描述。步骤S201至S206具体如下:
S201、DAG匹配器从共享内存中已经缓存的RDD中,选择待替换的RDD并进行标记。
一些示例中,DAG匹配器可以选择一些不太重要的RDD作为待替换的RDD,其中,待替换的RDD可以是使用频率较低、或计算时间较小、或依赖的父RDD大小较小的RDD,或自身大小较大的RDD、或权重较小的RDD等,本申请实施例对此不限定。
S202、DAG匹配器根据共享内存中剩余空间和已标记的RDD的大小,确定是否可以缓存第一DAG中全部的可重用的RDD。若是,则执行步骤S204,否则,执行步骤S203。
S203、DAG匹配器确定是否可以缓存第一DAG中部分可重用的RDD。若是,执行步骤S204。否则,执行步骤S206。
具体的,DAG匹配器根据共享内存中剩余的空间和已标记的RDD的大小,确定是否可以缓存第一DAG中部分可重用的RDD。在从第一DAG中选择部分可重的RDD时,可参考步骤S105中相关描述,这里不再赘述。
S204、DAG匹配器将标记的RDD从共享内存中移除。
一些示例中,DAG匹配器可以从共享内存中中直接删除标记的RDD,或者也可以将标记的RDD存储到外部存储。例如磁盘中。
S205、DAG匹配器将第一DAG中全部的或部分的可重用的RDD缓存到共享内存中。
而后,执行步骤S107和之后的步骤。
S206、DAG匹配器从共享内存中已经缓存的RDD中,除已经标记的RDD外,选择下一个待替换的RDD并进行标记。
而后,执行步骤S202。
二、根据可重用RDD对DAG进行转换的过程,如下:
如图10所示,为本申请实施例提供的一种使用可重用的RDD方法的流程图,具体包括:
S301、当第二窗口中出现空位时,DAG转换器从共享内存中,读取第一窗口中位于第一位的DAG(可以记为第三DAG)对应的可重用的RDD。
其中,第一窗口中位于第一位的DAG,是指位于第一窗口中队列的开头,也即第一窗口中与第二窗口相邻的待执行的DAG。
S302、DAG转换器将第三DAG转换为第四DAG,并将第四DAG添加到第二窗口中等待执行。其中,第四DAG与第三DAG的计算结果相同。
具体的,根据共享内存中已经缓存的可重用RDD(即步骤S301中读取的可重用的RDD),对第三DAG进行转换,将第三DAG中与可重用RDD相同的部分替换为依赖该可重用RDD,得到第四DAG。
举例来说,以第三DAG为如图2所示的DAG1为例进行说明。第三DAG为:先对文本文件(源数据)执行一次map操作,生成RDD1,再执行一次filter操作,生成RDD2。其中RDD1为可重用的RDD,缓存在共享内存中。当DAG转换器读取到RDD1时,对DAG1进行转换,第四DAG为:对RDD1执行一次filter操作,即可生成RDD2。其中,RDD1为可重用的RDD。该操作是已有技术,不再赘述。
可见,第三DAG包含两次转换操作:一次map操作,一次filter操作。而第四DAG只包含一次filter操作。显然,计算第四DAG的时间会比计算第三DAG的时间减少。
S303、当Spark内核空闲时,执行第二窗口中位于第一位的DAG(可以记为第五DAG)。
其中,第二窗口中位于第一位的DAG,是指位于第二窗口中队列的开头,也即当前第二窗口中最先完成根据可重用RDD进行转换的,等待Spark内核执行的DAG。例如:在Spark内核空闲时,SparkContext对第二窗口中待执行的DAG中的RDD进行分解,分解为Stage,进一步分解为Task,分配给相应的Worker执行。
S304、在执行第五DAG后,第二窗口再次出现空位,DAG转换器从共享内存中,读取当前第一窗口中位于第一位的DAG(可以记为第六DAG)对应的可重用的RDD数据,并对第六DAG进行转换,补入第二窗口的队尾,等待Spark内核执行。
具体的操作可参考步骤S301至步骤S303,不再赘述。
依次类推,当Spark内核空闲时依次执行第二窗口中的DAG,当第二窗口有空位时,依次读取位于第一窗口中位于第一位的DAG,并对该DAG进行转换后,补入第二窗口的队尾,等待执行。
在一些示例中,在Spark内核执行完一批DAG后,可对这一批DAG对应的可重用的RDD进行删除,以释放共享内存中的空间,以供缓存第一窗口中其他DAG的可重用的RDD,以提升共享内存的利用率。例如:以第一窗口中的m个DAG为单位,当Spark内核执行完这m个DAG转化的DAG后,可以删除这m个DAG对应的可重用RDD。可选的,也可以在Spark内核执行完这n*m个DAG转化的DAG后(n为大于2的整数),可以删除这n*m个DAG对应的可重用RDD。
可以理解的是,上述终端等设备为了实现上述各方法实施例所描述的功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用程序和设计约束条件。专业技术人员可以对每个特定的应用程序来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明实施例的范围。
本申请实施例可以根据上述方法示例对上述终端等进行功能模块的划分,例如,可以对应各个功能划分各个功能模块,也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。需要说明的是,本发明实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
通过以上的实施方式的描述,所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用程序中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何在本申请揭露的技术范围内的变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。