CN103631730B - 内存计算的缓存优化方法 - Google Patents

内存计算的缓存优化方法 Download PDF

Info

Publication number
CN103631730B
CN103631730B CN201310531246.7A CN201310531246A CN103631730B CN 103631730 B CN103631730 B CN 103631730B CN 201310531246 A CN201310531246 A CN 201310531246A CN 103631730 B CN103631730 B CN 103631730B
Authority
CN
China
Prior art keywords
rdd
internal memory
size
variable
data
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
Application number
CN201310531246.7A
Other languages
English (en)
Other versions
CN103631730A (zh
Inventor
陈康
艾智远
冯琳
周佳祥
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cleanergy Aike (Shenzhen) Energy Technology Co. Ltd
Original Assignee
Shenzhen Research Institute Tsinghua University
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Shenzhen Research Institute Tsinghua University filed Critical Shenzhen Research Institute Tsinghua University
Priority to CN201310531246.7A priority Critical patent/CN103631730B/zh
Publication of CN103631730A publication Critical patent/CN103631730A/zh
Application granted granted Critical
Publication of CN103631730B publication Critical patent/CN103631730B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Memory System Of A Hierarchy Structure (AREA)

Abstract

本发明提供一种内存计算的缓存优化方法,该方法包括:在Spark源程序中插入监听代码,对应用程序进行动态语义分析以构造DAG图;计算DAG中各顶点出度并筛选出出度大于1的顶点对应的RDD,筛选出的RDD为需要缓存至内存的RDD;根据贪心算法调整Action的执行顺序以优化RDD数据计算的访问顺序;计算RDD的权重,根据内存替换算法决定内存中被替换出的RDD;及根据多级缓存算法决定如何处理被替换出的RDD。应用本发明所述内存计算的缓存优化方法,无需程序员在编程时考量内存使用以及显示指定加载内存的RDD,降低程序员的编程负担,同时提高了内存的利用率进而提升大数据处理的速度。

Description

内存计算的缓存优化方法
技术领域
本发明涉及分布式大数据处理的领域,尤其涉及内存计算的缓存优化方法。
背景技术
Spark与Hadoop相似,是一个基于内存计算的开源集群计算系统,能够并行处理大数据集的计算,可以实现大数据的交互式查询以及优化迭代工作负载。Spark将数据集缓存在内存中,缩短了I/O访问延迟。但是随着数据量的激增以及人们对任务执行速度的要求越来越高,提高Spark的性能成为一个迫切的需求。通过对内存加速提高内存使用效率以提高运行速度,是提高Spark系统性能的一种方式。
目前,程序员需要在Spark中利用cache()方法将RDD显示载入内存,此种方式要求程序员对内存使用有一定的基础,而该方式使得内存利用率的高低很大程度依赖于程序员编写的代码质量的优劣,在有些情况下,仅通过优化代码本身无法提高内存使用率。
发明内容
鉴于上述内容,有必要提供一种内存计算的缓存优化方法,能够充分利用内存资源,提高内存使用率,降低程序员编程负担。
所述的内存计算的缓存优化方法,该方法包括:在Spark的源程序代码中插入监听代码,以样本数据作为输入预先执行应用程序,对应用程序进行动态语义分析,获取所有RDD函数操作的输入RDDID、操作类型、输出RDDID,根据获取的信息构造DAG;遍历上述DAG,计算各顶点的出度,筛选出出度大于1的顶点对应的RDD并建立RDD集合S,该集合S中的RDD为需要缓存至内存中的RDD;调整上述RDD集合S中所有RDD的Action执行顺序,以优化需要缓存至内存的RDD数据计算的访问顺序;计算所述RDD集合S中所有RDD的权重;当输入真正的作业数据执行应用程序时,根据优化的RDD数据计算的访问顺序,依次将RDD缓存至内存,若内存已满,根据内存替换算法决定从内存中被替换出的RDD;根据多级缓存算法确定被替换出的RDD是直接丢弃还是存储至磁盘。
相比于现有技术,本发明所述内存计算的缓存优化方法能够对Spark应用程序进行动态语义分析得出DAG图,调整Action执行顺序以优化RDD数据计算的访问顺序,计算RDD的权重,根据内存替换算法决定内存中被替换出的RDD以及根据多级缓存算法决定被替换出的RDD的处理方式。应用本发明所述内存计算的缓存优化方法,程序员无需在编程时显示指定加载内存的RDD以及考量内存使用情况,降低程序员的编程负担,同时提高了内存的利用率进而提升大数据处理的速度。
附图说明
图1是本发明所述内存计算的缓存优化方法的较佳实施例的方法流程图。
图2是本较佳实施例中进行动态语义分析的样例PageRank算法的伪代码。
图3是本较佳实施例中对PageRank算法进行动态语义分析后,构造的DAG的示意图。
图4是本较佳实施例中用于说明调整Action执行顺序可优化RDD访问顺序的Spark拉取模型样例的伪代码。
图5是本较佳实施例中分析Spark拉取模型样例代码得出的RDD访问顺序的示意图。
图6是本较佳实施例中调整Spark拉取模型代码的Action执行顺序后的RDD访问顺序的示意图。
图7是本较佳实施例中根据贪心算法调整Action执行顺序的伪代码。
图8是本较佳实施例中说明RDD权重影响的示意图。
图9是本较佳实施例中多级缓存算法的伪代码。
图10是不同操作类型对RDD的数据量大小影响的示意图。
具体实施方式
本发明所述内存计算的缓存优化方法(以下简称“内存优化方法”)是对现有开源项目Spark的优化,应用该内存优化方法,可以提高内存的利用率,进一步提升并行处理大数据的运行速度。
Spark利用Scala语言实现,是一个允许集群上对数据集进行交互式分析的有效、通用的编程语言框架。Scala语言是一种基于JVM(JavaVirtualMachine,Java虚拟机)的静态类型、函数式、面向对象的语言。其中,RDD(ResilientDistributedDataset,弹性分布式数据集)是Spark的一个重要的抽象概念,是分布在集群节点上的具有容错机制且进行并行操作的只读记录分区集合,可以将所有数据加载至内存,允许在大型集群上执行基于内存的计算。
本发明所述的内存优化方法,对Spark应用程序进行动态语义分析以构造DAG(DirectedAcyclicGraph,有向无环图),根据该DAG选取需要缓存至内存的RDD,利用贪心算法调整Action的执行顺序以优化RDD数据计算的访问顺序,根据内存替换算法决定被替换出内存的RDD以及根据多级缓存算法决定从内存中被替换出的RDD的处理方式。以下将具体结合附图,详细说明所述内存优化方法中各步骤的具体实现。
参阅图1所示,是本发明所述内存优化方法的流程图。
步骤S01,在Spark源代码中插入监听代码,以样本数据作为输入预先执行应用程序,对应用程序进行动态语义分析,获取所有RDD函数操作的输入RDDID、操作类型、输出RDDID,根据获取的信息构造DAG(DirectedAcyclicGraph,有向无环图)。
软件工程中,性能分析(PerformanceAnalysis或Profiling)是以收集程序运行时的信息为手段研究程序行为的分析方法,旨在根据运行时信息决定如何对程序优化从而提高程序运行速度或者内存使用率。本发明所述内存优化方法基于Profiling的思想,预先执行应用程序进行动态语义分析,获取所有RDD的函数操作的信息以构造DAG,根据该DAG进一步分析出在应用程序执行过程中需要加载内存的RDD并优化RDD数据计算的访问顺序(具体参见步骤S02、S03)。
需要说明的是,预先执行应用程序主要目的是为了获取程序运行时信息以优化内存使用,而大数据处理的数据集是TB级别的大规模数据量,故预先执行应用程序时输入的数据为数据量不大的模拟数据,本较佳实施例中,取作业数据(待处理的数据集)中一定大小的数据(例如256M的数据量)作为样本,以样本数据作为预先执行应用程序的输入数据。
RDD支持两种操作:转换(Transformation)和动作(Action,动作或行为)。其中,转换操作是根据现有数据集创建一个新的数据集,例如,属于转换操作类型的函数操作:map、filter、flatmap、ReduceByKey和join等;动作是在数据集运行计算后返回一个值给应用程序或向外部存储写入数据,例如,属于动作或行为操作类型的函数操作:save、count、collect等。
本较佳实施例中,在Spark源代码的类库中于RDD的各种函数操作的实现代码中插入监听代码,使得Spark的应用程序执行过程中(Spark的应用程序也称作驱动程序),当执行RDD的函数操作代码的同时,执行RDD函数操作的实现代码中插入的监听代码,实时获取RDD函数操作的输入RDDID、操作类型和输出RDDID,以输入RDDID和输出RDDID为顶点,输入和输出的RDD之间所进行函数操作的操作类型为边,构造DAG。
图2为本较佳实施例中进行动态语义分析的PageRank算法的伪代码,图3为对PageRank算法进行动态语义分析后构造的DAG,为了方便表示,以方框代替DAG的点,每个方框为一个RDD。以下结合图2、图3,详细说明DAG的构造过程。
图2所示代码的循环体中,contribs是links和ranks进行join和flatmap操作返回的数据集,如图3中顶点ranks0至顶点contribs0的边和顶点links至contribs0的边表示join和flatmap的操作;ranks是contribs进行reduceByKey和mapValue操作返回的数据集,如图3中顶点contribs0至顶点ranks1的边表示reduceByKey和mapValues操作。因为RDD是只读的,在进行RDD操作时,会产生新的数据集或是返回值,但不改变输入RDD的数据内容,如图2所示代码在每次循环时,contribs和ranks都会是新的数据集,对应图3中所示,ranks0至ranksN和contribs0至contribsN为每次循环过程中产生的新数据集,其中,ranksN和contribsN为循环结束时RDD变量ranks和contribs的最终数据集。
步骤S02,遍历步骤S01所构造的DAG,计算每个顶点的出度,筛选出所有出度大于1的顶点对应的RDD并建立RDD集合S,该RDD集合S中的RDD即为需要缓存至内存的所有RDD。
在内存命中的概念中,CPU对某变量或数据第一次读或写时,首次将该变量加载至内存,此次对该变量的读写操作为未命中,当后续若对该变量再次读或写时,该变量已加载至内存,则为命中。故,将多次访问或频繁读写的变量或数据缓存至内存可以提高内存命中率,无需多次进行I/O访问,提高程序的运行速度。
鉴于此,本较佳实施例中,遍历构造的DAG,计算每个顶点出度即该顶点对应的RDD的访问次数,筛选出出度大于1的所有RDD并建立RDD集合S,即该RDD集合S包含了访问次数大于1的所有RDD,且该集合S中的RDD缓存至内存可以提高程序的运行速度。
以图2、图3为例,图3中顶点links的出度大于1,其他RDD顶点的出度为1,则将该RDDlinks缓存至内存可以提高内存命中率。参考图2代码,程序员并未将RDDlinks加载至内存。而应用本发明所述内存优化方法,当输入作业数据执行应用程序时,会根据预先执行应用程序的分析结果,将RDDlinks缓存至内存。
如图4是本较佳实施例中用于说明调整Action执行顺序可优化RDD访问顺序的Spark拉取模型样例的伪代码,相比于图2的PageRank算法的伪代码,图4的代码是PageRank算法伪代码的一个修改版,所不同的是,图4代码的循环体中是计算两组RDD(contribs和ranks;contribs1和ranks1),图2仅计算了一组RDD(contribs和ranks)。结合图3可得出RDDlinks的顶点出度大于1,具有缓存价值,类比图2代码的DAG构造过程,分析图4代码可知,RDDlinks和RDDlinks1为出度大于1的顶点,具有缓存价值。
结合步骤S01、S02看,所述的内存优化方法预先执行应用程序,根据执行过程中RDD的访问次数决定RDD是否需要加载至内存,相比于现有做法中,由程序员通过.cache()方法指定应用程序中需要加载至内存的RDD,本发明更加合理及灵活,同时降低程序员负担。
步骤S03,根据贪心算法,调整步骤S02的集合S中所有RDD的动作(Action)执行顺序以优化RDD数据计算的访问顺序。
Spark中,应用程序的代码执行过程中,RDD的转换操作(是一种懒计算,lazilyevaluated)并没有对输入数据进行计算,只是计算了RDD的元数据,只有当执行Action操作时,才真正触发数据计算,回溯所需要的RDD计算操作或直接在内存中查询需要参与计算的RDD或从HDFS(HadoopDistributedFileSystem,Hadoop分布式文件系统)中获取。由上可知,RDD数据计算的访问顺序是由Action的执行顺序决定的。所述的RDD的元数据包括:RDD与其父RDD的依赖关系(即RDD从其他RDD衍生所需的相关信息)、RDD的分区信息和数据存放位置等信息。
需要说明的是,本发明所述内存优化方法为了提高内存利用率,需要考量的是被缓存至内存的RDD的访问顺序,即步骤S03中优化的是步骤S02创建的RDD集合S中所有RDD数据计算的访问顺序。
由步骤S02分析可知图4代码中需要缓存至内存的RDD为links和links1,以下具体分析这两个RDD在图4代码执行过程中的访问顺序。图5左侧所示为计算元数据时links和links1的访问顺序,其中,实线方框和虚线方框分别用于区分表示links和links1,图5右侧所示为真正数据计算时links和links1的访问顺序。图4代码中仅最后的ranks.save(dfs:…)和ranks1.save(dfs:…)为Action操作,会触发数据的真正计算,当执行ranks的Action操作时,回溯ranks的数据操作即真正执行循环体中ranks的数据计算,如图5右侧所示的反复访问links,当ranks存储后执行ranks1的Action操作时,同理,如图5右侧所示反复访问links1。由上看出,图5右侧所示的RDD数据计算时RDD的访问顺序真正影响程序执行速度以及内存使用情况。
假如,调整图4所示代码中最后两行代码(Action)的顺序为:ranks1.save(dfs:…);ranks.save(dfs:…);则调整Action执行顺序后的RDD访问顺序参考图6所示,图6左侧为RDD在元数据计算时的访问顺序,右侧为RDD在数据计算时的访问顺序。通过比对图5、图6可知,调整Action的执行顺序会改变RDD数据计算的访问顺序。
图8所示为RDD权重影响的示意图,图8是一个权值化的DAG,图8中实线方框表示RDD,虚线方框表示Action的计算结果,除指向虚线方框表示的箭头为Action操作外,其他箭头表示为转换操作。由图8明显可知,RDDA、B、C的出度大于1,需缓存至内存。
假设图8中Action的执行顺序为:A1、A4、A2、A5、A3,根据Action操作中对计算数据的回溯,RDD的访问顺序为:A、B、A、C、B、C、B,假设当前内存仅为一个区块,则根据以上访问顺序,RDD在内存中替换顺序:A、B、A、C、B、C、B;若Action的执行顺序为A1、A2、A3、A4、A5,RDD的访问顺序为:A、B、B、B、A、C、C,在相同内存情况下,RDD在内存中替换顺序为:A、B、A、C。由上述分析可知,不同的Action执行顺序会导致数据计算时不同的RDD访问顺序,进而导致RDD在内存中不同程度的替换频率,则有必要调整Action执行顺序以优化RDD访问顺序。
Action执行顺序的调整需要遵照两个原则:保持Spark应用程序的原有语义不变;优化后的Action执行顺序提高了应用程序执行效率。若要保证Spark应用程序的原语义不变,需要保持应用程序中有依赖关系的Action原有执行顺序,调整无依赖的Action执行顺序。所述有依赖关系的Action是某个Action操作的输出是另外一个或多个Action的输入,则表明这些Action之间存在依赖关系。
本较佳实施例中利用贪心算法,调整Spark应用程序中RDD的Action执行顺序。调整后的Action执行顺序O=[Ai,Aj,…,An]使得的值较小,提高了应用程序执行效率,其中,LC(RDDj)为RDD的生命周期,是RDD从建立到销毁期间的Action个数。
结合图7所示的伪代码,详细说明利用贪心算法调整Action执行顺序的具体过程:
a)查找步骤S02创建的RDD集合S中的所有RDD的Action,合并有依赖关系的Action为一个新Action,合并后的多个新Action与无依赖关系的Action共同形成一个Action集合A;
b)创建空集合R和空序列S
c)从Action集合A中任意选取一个ActionAi,将Ai加入序列S的末尾,将Ai对应的RDD加入到集合R;
d)迭代执行步骤c,直至集合A中的元素为空,序列S即为调整的Action执行顺序。
需要说明的是,在执行步骤d时,每次从集合A中选取ActionAi的依据是所选取的Ai对应的RDD与集合R的交集最大,其中,在第一次从集合A中选取ActionAi是随机抽取一个Action。需要指出的是,将有依赖关系的Action合并的新Action对应的RDD为多个。
步骤S04,计算步骤S02的集合S中所有RDD的权重,即计算所有需要缓存至内存的RDD的权重。
如图8所示,是本较佳实施例中说明RDD权重影响的示意图,若Action的执行顺序为A1、A4、A2、A5、A3,则RDD数据计算的访问顺序为:A、B、A、C、B、C、B,现在假设内存有两个区块用于缓存RDD且初始为空,以下考虑两种不同的内存替换算法(或称为页面置换算法),决定RDD实际的替换顺序(或称为置换顺序)。
若按照LRU替换算法(LeastRecentlyUsed,最近最少使用或最近最久未使用算法),是选择最近最长时间未访问的数据或页面淘汰,则根据该LRU算法,上述RDD的访问顺序在内存中的替换过程为:
A调入内存后内存情况为A、空区块,A第一次未命中;
B调入内存后内存情况为A、B,B第一次未命中,随后A命中;
当前内存情况为A、B且A最近被访问,则替换B出去且调入C,则C第一次未命中;
调入C后的内存情况为A、C,需要访问B且最近一次C被访问,则A替换出去且调入B,则B此次未命中;
访问顺序C、B,当前内存情况为C、B,则C、B各命中一次;
综上分析,A未命中一次,命中一次;B未命中两次,命中一次;C未命中一次,命中一次;即总共未命中四次。
若按照FIFO替换算法(FirstInputFirstOutput,先进先出置换算法),是优先淘汰或替换出最早缓存至内存的页面或数据,则根据该FIFO算法,上述RDD的访问顺序在内存中的替换过程为:
A调入内存后内存情况为A、空区块,A第一次未命中;
B调入内存后内存情况为A、B,B第一次未命中,随后A命中;
当前内存情况为A、B且A第一次被缓存,则替换A出去且调入C,则C第一次未命中;
调入C后的内存情况为B、C,访问顺序为B、C、B,则B命中两次,C命中一次;
综上分析,A未命中一次,命中一次;B未命中一次,命中两次次;C未命中一次,命中一次;即总共未命中三次。
若单从命中率考虑,这两种算法的命中率相差无几,但是,考虑到RDD的数据大小不同以及RDD操作的代价等因素,仅以命中率作为内存替换算法的选取依据和评价标准太过于片面。如图8所示,假设A、B、C的权重依次为5、10、1(权重是综合考虑到RDD大小、计算代价等因素后的值,具体参见以下说明的权重计算过程),则LRU算法的内存未命中的代价为:5×1+10×2+1×1=26,FIFO算法的内存未命中的代价为:5×1+10×1+1×1=16,则明显得出FIFO算法能够降低内存替换过程中的代价。有上述分析可知,引入RDD权重可以更好权衡内存替换算法的优劣。
需要说明的是,本较佳实施例中以样本数据作为输入预先执行应用程序,在执行过程中对应用程序进行动态语义分析以构造DAG,获取需要缓存至内存的RDD。在预先执行应用程序的同时,计算应用程序中所有RDD的权重,其中,需缓存至内存的RDD(即步骤S02中集合S中的RDD)的权重才会影响内存替换算法的选取,故步骤S04中强调指出计算集合S中RDD的权重。
由实验数据分析得出,RDD的权重(Weight,简写W)由RDD的计算代价(ComputeCost,简写CC)、RDD的大小(OuputSize,简写OS)、RDD的使用次数UT(UseTimes)和生命周期(LifeCycle,简写LC)四个主要因素决定。
本较佳实施例中,RDD的权重计算公式为:
其中,P(RDDi)表示RDDi的父RDD,IS(P(RDDi))为RDDi的父RDD的大小(InputSize,简写IS),f为用于归一化的校正参数,由实验数据得到的经验值。以下分别对上述四个影响权重的因素的计算过程进行详细说明。
1)计算RDD的大小OS(RDDi)
RDD的大小可以通过理论分析和动态采样两种方法进行计算。理论分析法是通过对RDD的操作类型和闭包的分析,估算出RDD的大小。RDD的操作中,不同的操作对数据集的数据量大小改变都有一定的规律,例如:对RDD进行filter操作后数据量变小,对RDD进行Join操作后数据量变大。不同操作对RDD的数据量大小的影响参见图10。图10中不同操作对RDD的数据量大小的影响是粗略的估计,该理论分析得出的结果仅作为参考,为了获取RDD的精确大小值,本较佳实施例中通过动态采样法进行计算。
该动态采样法包括:采样步骤,计算对象大小步骤,即是对象占用内存空间的大小,汇总计算步骤。所述对象包括各类型变量。RDD将分区以Java对象的形式缓存在不同节点的内存中,利用动态采样法计算RDD的大小时,首先获取采样数据,其次以采样数据作为输入,执行应用程序,在执行过程中计算RDD所有对象的大小,最后汇总RDD所有对象的大小即RDD的大小。
该采样步骤可以通过两种方法实现,一种是取作业数据(待处理的数据集)中一定大小的数据(例如256M的数据量)作为样本,第二种是使用Spark中的Sample方法对RDD的所有数据进行采样。第一种方法代价小,第二种方法的采样更具有代表性但是需要读取所有数据,代价大。鉴于此,本较佳实施例中,采用第一种方法进行采样。
Spark是利用Scala语言实现,所述Scala语言是一种基于JVM的面向对象的语言,继承了Java语言的所有特性。类似于Java中内存的回收是完全透明的,程序员无需了解内存中对象的大小,则Scala中的对象并没有类似C/C++中的sizeof()的方法以直接获取对象的大小。鉴于此,本发明所述内存优化方法中提供了两种不同解决方案用以计算对象大小。
本较佳实施例中,以采样的样本数据作为输入,执行应用程序,在程序执行过程中计算对象大小。计算对象大小可以通过两种方法实现:第一种方法是通过建立对象实例并同时观察Java虚拟机内存使用量,计算对象的大小;第二种方法是通过递归分析类内部的变量,得到所有变量的大小,经过叠加计算,得到类占用的内存空间。
第一种方法的具体实现是,建立对象的多个相同实例,同时观察Javascript虚拟机内存增长情况,平均计算对象的实例占用的内存使用量。该第一种方法必须建立多个对象实例以保证量测的精度,而对于使用一次或少量次数的对象不适用,其次,在计算的整个过程中必须要创建一个相对静止的环境,避免其他对象的创建和销毁引发测量误差。鉴于该第一种方法的弊端,本较佳实施例中使用第二种方法计算对象大小。
第二种方法计算对象大小的具体过程如下:
a)定义所有基础类型变量的大小,基础类型变量的大小是固定的,可以通过查阅Scala的说明文档以及观察虚拟机内存的方式制作一张记录各基础类型变量大小的查询表,需要注意的是,基础类型变量大小固定是针对某个特定的JVM来说,不同的JVM需要制作不同的查询表;
b)对象类型变量的大小等于其所有成员变量大小的累加值,对象类型变量(如类对象或是结构体等)一般包括三种类型的成员变量:基础类型变量(如int、float、double等)、数组类型变量(如inta[])等)和对象类型变量(如类、结构体等)。其中,若成员变量为基础类型变量,则根据步骤a中定义的各种基础类型变量的大小,累加各基础类型变量的大小;若成员变量为数组类型变量,根据步骤c进行计算数组类型的成员变量的大小;若成员变量为对象类型变量则迭代执行步骤b计算对象类型的成员变量的大小;
c)数组类型变量的大小等于数组长度乘以数组元素的大小,若数组元素为基础类型变量,根据步骤a计算数组元素为基础类型变量的大小,若数组元素为对象类型变量,根据步骤b计算数组元素为对象类型变量的大小;
d)汇总对象包括的所有各类型变量的大小。
以C语言的示例详细说明根据步骤b计算以下对象类型变量data的大小:
structdata{
inta;
intb;
floatc[];
structdata-otherdataOther;
}
对象类型变量data中包括有三种成员变量,分别是:基础类型变量a、b,数组类型变量c以及对象类型变量dataOther。对于成员变量为基础类型变量,累加各基础类型变量大小即sizeof(a)+sizeof(b)(sizeof为C语言中提供的获取基础类型变量大小的函数);对于成员变量为数组类型变量,跳转到步骤c计算该数组类型的成员变量,即size(c[])=数组c的元素个数×基础类型变量float的大小;对于成员变量为对象类型变量,根据步骤b计算对象类型变量dataOther的大小即size(dataOther),其中,dataOther的大小由结构体中包括的变量个数以及各变量的类型决定,此处不再详细说明dataOther的计算,故对象类型变量data的大小=sizeof(a)+sizeof(b)+size(c[])+size(dataOther)。
需要说明的是,权重计算公式中IS(P(RDDi))即RDD的父RDD的大小计算过程与上述RDD的大小计算相似,此处不再赘述。
2)计算RDD的计算代价CC(RDDi)
RDD的计算由RDD操作类型和闭包两部分组成,故计算RDD的计算代价包括计算RDD操作的复杂程度和闭包操作的复杂程度。需要说明的是,复杂程度的计算可以等价为时间长短的计算,将计算RDD操作和闭包操作的复杂程度转换为计算RDD操作和闭包操作的计算时间。
3)计算RDD的使用次数UT(RDDi)
遍历DAG图,以RDD顶点的出度作为该RDD的使用次数。
4)计算RDD的生命周期LC(RDDi)
RDD的生命周期LC是指RDD在创建至销毁的过程中跨过的Action的个数即DAG中RDD顶点的表示Action操作的边,可以通过遍历DAG图得到。
步骤S05,当输入真正的作业数据执行应用程序时,根据预先执行应用程序后优化的RDD数据计算的访问顺序,依次将RDD缓存至内存,若内存已满,利用Min替换算法决定要从内存中被替换出的RDD。
Min替换算法(MinCacheReplacementAlgorithm)是指当内存已满时,将最长时间之后使用到的数据或页面替换出去,该算法是操作系统的内存替换算法中的一个理论最优算法,要求处理器能够预见程序将来的执行过程中数据的使用情况,因此该算法在操作系统的内存替换作业中无法具体实现。
本较佳实施例中,参见步骤S01-S03,预先执行Spark应用程序,对应用程序进行动态语义分析以构造DAG,通过分析DAG得出需要缓存至内存的RDD,并利用贪心算法调整Action的执行顺序以优化RDD数据计算的访问顺序,通过以上步骤,可以得出应用程序执行过程中RDD数据计算的访问顺序。故,本较佳实施例中使用Min替换算法实现内存中RDD的替换。
本较佳实施例中,利用该Min替换算法决定内存中被替换出的RDD的过程如下:
当内存已满且需要加载(缓存)某个RDD至内存时,倒序遍历RDD数据计算的访问顺序;
若在该访问顺序中遍历到一个缓存至内存的RDD,则停止遍历,将该RDD替换出内存;例如,内存有两个区块,RDD数据计算的访问顺序为A、B、A、C、A、A、B,当需要将RDDD加载至内存时,RDDA、B分别缓存至内存中,倒序遍历该访问顺序,RDDB被缓存,停止遍历,将B替换出内存;
预先确定在访问顺序中当前要缓存的RDD最早被访问的位次,当遍历到该位次之前都未遍历到已缓存至内存的RDD,则停止遍历,任意选取内存中的RDD被替换出。例如:内存有两个区块,RDD数据计算的访问顺序为A、B、A、B、C、C、D、D,则当需要将RDDC加载至内存时,RDDA、B分别缓存至内存中,倒序遍历该访问顺序,当遍历到该访问顺序中排序在倒数第四位次的RDDC时,该位次为访问顺序中RDDC最早被访问的位次,都未遍历到已缓存至内存的RDD(倒序遍历的RDDD、D、C都未缓存)则停止遍历,任意选取内存中的RDDA或B被替换出。
基于本发明所述内存优化方法中预先执行应用程序,通过动态语义分析以及Action执行顺序调整,得出了RDD数据计算的访问顺序,故,利用该Min算法还可以通过以下步骤决定内存中被替换出的RDD:
当内存已满且需要将某个RDD缓存至内存,确认当前已缓存至内存的RDD;
从已缓存的RDD中选取出在当前需缓存的RDD后的访问顺序中最晚被访问的RDD;
替换出该最晚被访问的RDD。
例如:访问顺序A、B、A、C、A、A、B,两个内存区块,按照该访问顺序,当需要访问C时,内存已满且A、B已被缓存,而当前需缓存的RDDC其后的访问顺序为A、A、B,即A随后即将被访问,RDDB最晚被访问,故选取RDDB替换出内存。
需要说明的是,利用Min替换算法进行内存替换也存在一定的缺陷,在内存替换过程中,Min替换算法并不能适用于所有的访问顺序。例如,RDD数据计算的访问顺序为:A、B、A、B、A、B……,即交替访问RDDA、B,假设当前内存仅能缓存一个RDD,则根据Min替换算法,交替替换A、B,则导致最终A、B的命中率都是0%,而若选择将其中一个缓存至内存中且整个访问顺序的期间都不被替换,那么牺牲其中一个RDD,而被选择缓存的RDD除了第一次未命中,其余各次皆命中。鉴于此,本较佳实施例中还利用了寄存器分配的图着色算法进行替换,该图着色算法是解决为变量分配寄存器问题,若以RDD等同为变量,内存的各个区块等同为寄存器,则实现以寄存器分配的图着色算法解决内存中RDD的替换问题,关于利用该图着色算法解决内存中RDD的替换此处不进行详细说明,可通过查阅相关技术文档获取该算法进行内存替换的具体实现过程。
内存中的RDD在替换过程中,无法同时使用Min替换算法和寄存器分配的图着色算法。因此,本较佳实施例中,当内存已满需要进行替换时,根据RDD数据计算的访问顺序以及RDD的权重,计算两种替换算法进行内存替换时内存未命中的总代价即访问顺序中各RDD的未命中次数乘以该RDD权重的累加值(可参考上述步骤S04中,关于LRU替换算法和FIFO替换算法的内存替换过程),选取内存未命中的总代价较小的替换算法对内存中的RDD进行替换。
步骤S06,根据多级缓存算法确定从内存中替换出的RDD是直接丢弃还是将替换出的RDD存储至磁盘。
Spark对于从内存中替换出的RDD有两种处理方式:一是直接丢弃替换出的RDD,下次使用该RDD时根据元数据重新计算;二是将替换出的RDD存储至磁盘中,以便下次读取。目前,Spark系统的实现是通过配置文件中统一设定将替换出的RDD丢弃或是存储至磁盘中,这种做法存在一定便利性,但是无法根据替换出的RDD的信息以及结合RDD的访问顺序,灵活决定该RDD是丢弃或是存储至磁盘。
例如:RDDA计算代价大,但RDDA的大小很小;RDDB计算代价小,但RDDB的大小很大。那么当这两个RDD从内存中被替换出时,应采取不同策略,将RDDA存储在磁盘,将RDDB直接丢弃而在下次使用时再次计算。再考虑一种情况,如果RDDA在后续执行中不会使用,那么直接将RDDA丢弃。
在本较佳实施例中,参考图9所示的该多级缓存算法的伪代码,利用该多级缓存算法灵活决定从内存中被替换出的RDD的处理方式的具体实现如下:
a)获取从内存中替换出的RDD的大小,计算过程具体参见上述RDD权重计算过程中RDD的大小计算,此处不再赘述;
b)根据RDD的大小和磁盘I/O的访问速度,计算将替换出的RDD存储至磁盘的代价iocost,即RDD的大小除以I/O的访问速度;
c)获取RDD的计算代价CC(ComputeCost),具体参见上述RDD权重计算过程中计算代价的计算;
d)判定CC<2×iocost,若满足条件则将替换出的RDD丢弃,否则进入下个步骤e;
e)根据优化的RDD数据计算的访问顺序,查找被替换出的RDD后续是否会使用,若是,将该替换出的RDD存入磁盘,否则直接丢弃。
最后需要说明的是,以上较佳实施例仅用于说明本发明的技术方案而非限制,尽管按照以上较佳实施例对本发明技术方案进行了详细说明,本领域的普通技术人员应当理解,对本发明技术方案的修改或等同替换都不应该脱离本发明要保护的范围和精神。

Claims (10)

1.一种内存计算的缓存优化方法,其特征在于,该方法包括:
构造DAG(DirectedAcyclicGraph,有向无环图)步骤:在Spark的源程序代码中插入监听代码,以样本数据作为输入预先执行应用程序,对应用程序进行动态语义分析,获取所有RDD(ResilientDistributedDataset,弹性分布式数据集)函数操作的输入RDDID、操作类型、输出RDDID,根据获取的信息构造DAG;
筛选RDD步骤:遍历上述DAG,计算各顶点的出度,筛选出出度大于1的顶点对应的RDD并建立RDD集合S,该集合S中的RDD为需要缓存至内存中的RDD;
Action执行顺序调整步骤:调整上述RDD集合S中所有RDD的Action执行顺序,以优化需要缓存至内存的RDD数据计算的访问顺序;
RDD权重计算步骤:计算所述RDD集合S中所有RDD的权重;
RDD替换步骤:当输入真正的作业数据执行应用程序时,根据优化的RDD数据计算的访问顺序,依次将RDD缓存至内存,若内存已满,根据内存替换算法决定从内存中被替换出的RDD;
RDD处理步骤:根据多级缓存算法确定被替换出的RDD是直接丢弃还是存储至磁盘。
2.如权利要求1所述的内存计算的缓存优化方法,其特征在于,在所述构造DAG步骤中,将输入RDDID和输出RDDID作为顶点,输入RDD和输出RDD进行的函数操作的操作类型为边,构造DAG。
3.如权利要求1所述的内存计算的缓存优化方法,其特征在于,在所述Action执行顺序调整步骤中,是根据贪心算法调整集合S中所有RDD的Action执行顺序,包括以下步骤:
a)查找所述RDD集合S中的所有RDD的Action,合并有依赖关系的Action为一个新Action,合并后的多个新Action与无依赖关系的Action共同形成一个Action集合A;
b)创建空集合R和空序列S’;
c)从Action集合A中任意选取一个ActionAi,将Ai加入序列S’的末尾,将Ai对应的RDD加入到集合R;
d)迭代执行步骤c,直至集合A中的元素为空,则序列S’即为调整的Action执行顺序,其中,迭代执行从集合A中选取ActionAi时,选取的依据是所选取的Ai对应的RDD与集合R的交集最大。
4.如权利要求1所述的内存计算的缓存优化方法,其特征在于,在所述权重计算步骤中,RDD权重的计算公式为:
W ( RDD i ) = I S ( P ( RDD i ) ) × C C ( RDD i ) × U T ( RDD i ) × f O S ( RDD i ) × L C ( RDD i )
其中,IS(P(RDDi))为RDDi的父RDD的大小、CC(RDDi)为RDDi的计算代价、UT(RDDi)为RDDi的使用次数、OS(RDDi)为RDDi的大小、LC(RDDi)为RDDi的生命周期,RDDi的计算代价包括RDD操作和闭包操作的复杂程度,RDDi的使用次数为DAG中该RDDi顶点的出度,RDDi的生命周期为RDDi创建至销毁过程中Action的个数,f为用于归一化的校正参数。
5.如权利要求4所述的内存计算的缓存优化方法,其特征在于,所述RDD的大小根据动态采样法进行计算:
采样:取作业数据中的一定大小的数据作为样本数据;
计算对象大小:将样本数据作为输入,执行应用程序,计算执行过程中的对象大小,所述对象包括各类型变量;
汇总:汇总RDD的所有对象的大小即为RDD的大小。
6.如权利要求5所述的内存计算的缓存优化方法,其特征在于,通过以下步骤计算对象大小:
a)定义所有基础类型变量的大小,制作一张记录各基础类型变量大小的查询表;
b)对象类型变量的大小等于其所有成员变量大小的累加值,对象类型变量一般包括三种类型的成员变量:基础类型变量、数组类型变量和对象类型变量,其中:
若成员变量为基础类型变量,则根据步骤a中定义的各种基础类型变量的大小,累加各基础类型变量的大小;
若成员变量为数组类型变量,则根据下述的步骤c进行计算;
若成员变量为对象类型变量,则迭代执行步骤b计算对象类型的成员变量的大小;
c)数组类型变量的大小等于数组长度乘以数组元素的大小,若数组元素为基础类型变量,根据步骤a计算数组元素为基础类型变量的大小,若数组元素为对象类型变量,根据步骤b计算数组元素为对象类型变量的大小;
d)汇总对象包括的所有各类型变量的大小。
7.如权利要求1所述的内存计算的缓存优化方法,其特征在于,所述RDD替换步骤中根据内存替换算法决定内存已满时需要被替换出内存的RDD包括:
根据RDD数据计算的访问顺序以及RDD的权重,分别计算Min替换算法和寄存器分配的图着色算法进行内存替换时内存未命中的总代价即访问顺序中各RDD的未命中次数乘以该RDD权重的累加值;
选取总代价较小的替换算法对内存中的RDD进行替换。
8.如权利要求7所述的内存计算的缓存优化方法,其特征在于,根据Min替换算法决定内存已满时被替换出的RDD包括:
当内存已满且需要缓存某个RDD至内存时,倒序遍历RDD数据计算的访问顺序;
若在该访问顺序中遍历到一个已经缓存至内存的RDD,则停止遍历,将该RDD替换出内存;
预先确定在访问顺序中当前要缓存的RDD最早被访问的位次,当遍历到该位次之前都未遍历到已缓存至内存的RDD,则停止遍历,任意选取内存中的RDD替换出内存。
9.如权利要求7所述的内存计算的缓存优化方法,其特征在于,根据Min替换算法决定内存已满时被替换出的RDD包括:
当内存已满且需要缓存某个RDD至内存时,确认当前已缓存至内存的RDD;
从已缓存的RDD中选取出在当前需缓存的RDD后的访问顺序中最晚被访问的RDD;
替换出该最晚被访问的RDD。
10.如权利要求4所述的内存计算的缓存优化方法,其特征在于,根据多级缓存算法决定被替换出的RDD是直接丢弃还是存储至磁盘包括:
获取从内存中被替换出的RDD的大小;
根据RDD的大小和磁盘I/O的访问速度,计算将替换出的RDD存储至磁盘的代价iocost即RDD的大小除以I/O的访问速度;
获取RDD的计算代价CC;
判定CC<2×iocost,若满足该判定条件则将替换出的RDD丢弃;
若不满足该判定条件,则根据RDD数据计算的访问顺序,查找被替换出的RDD后续是否会使用,若是,则将该替换出的RDD存入磁盘,否则直接丢弃。
CN201310531246.7A 2013-11-01 2013-11-01 内存计算的缓存优化方法 Active CN103631730B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201310531246.7A CN103631730B (zh) 2013-11-01 2013-11-01 内存计算的缓存优化方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201310531246.7A CN103631730B (zh) 2013-11-01 2013-11-01 内存计算的缓存优化方法

Publications (2)

Publication Number Publication Date
CN103631730A CN103631730A (zh) 2014-03-12
CN103631730B true CN103631730B (zh) 2016-04-27

Family

ID=50212812

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201310531246.7A Active CN103631730B (zh) 2013-11-01 2013-11-01 内存计算的缓存优化方法

Country Status (1)

Country Link
CN (1) CN103631730B (zh)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104360903B (zh) * 2014-11-18 2017-10-31 北京赛特斯信息科技股份有限公司 Spark作业调度系统中实现任务数据解耦的方法
CN105468445B (zh) * 2015-11-20 2020-01-14 Tcl集团股份有限公司 一种基于WEB的Spark应用程序调度方法及系统
CN105279286A (zh) * 2015-11-27 2016-01-27 陕西艾特信息化工程咨询有限责任公司 一种交互式大数据分析查询处理方法
CN105426504A (zh) * 2015-11-27 2016-03-23 陕西艾特信息化工程咨询有限责任公司 一种基于内存计算的分布式数据分析处理方法
CN105824737B (zh) * 2016-03-31 2018-08-17 华中科技大学 用于大数据处理系统的内存数据集置换系统与置换方法
CN106484368B (zh) * 2016-09-20 2019-08-16 深圳大学 一种基于Spark语义的数据重用方法及其系统
US10572383B2 (en) 2017-04-12 2020-02-25 International Business Machines Corporation Caching a block of data in a multi-tenant cache storage device based on space usage boundary estimates
CN107066316A (zh) * 2017-04-25 2017-08-18 华中科技大学 分布式数据处理系统中缓解内存压力的调度方法和系统
CN107220188B (zh) * 2017-05-31 2020-10-27 中山大学 一种自适应缓冲块替换方法
CN107256158B (zh) * 2017-06-07 2021-06-18 广州供电局有限公司 电力系统负荷削减量的检测方法和系统
WO2019037093A1 (zh) * 2017-08-25 2019-02-28 深圳大学 一种 Spark 分布式计算数据处理方法及系统
CN107480071B (zh) * 2017-08-25 2020-11-03 深圳大学 缓存数据迁移方法及装置
CN107526546B (zh) * 2017-08-25 2020-09-11 深圳大学 一种Spark分布式计算数据处理方法及系统
CN108073688B (zh) * 2017-11-20 2022-06-07 苏宁易购集团股份有限公司 一种数据迁移的方法及装置
CN108804222B (zh) * 2018-04-13 2021-07-27 南京南瑞继保电气有限公司 一种临时变量的数据区分配方法
US10671436B2 (en) 2018-05-02 2020-06-02 International Business Machines Corporation Lazy data loading for improving memory cache hit ratio in DAG-based computational system
CN109800092A (zh) 2018-12-17 2019-05-24 华为技术有限公司 一种共享数据的处理方法、装置及服务器
CN109951556A (zh) * 2019-03-27 2019-06-28 联想(北京)有限公司 一种Spark任务处理方法及系统
CN110209434B (zh) * 2019-04-23 2022-04-22 努比亚技术有限公司 一种内存管理方法、装置及计算机可读存储介质
CN110109747B (zh) * 2019-05-21 2021-05-14 北京百度网讯科技有限公司 基于Apache Spark的数据交换方法及系统、服务器
CN110162272B (zh) * 2019-05-23 2020-06-12 北京邮电大学 一种内存计算缓存管理方法及装置
CN110232087B (zh) * 2019-05-30 2021-08-17 湖南大学 大数据增量迭代方法、装置、计算机设备和存储介质
CN110245095A (zh) * 2019-06-20 2019-09-17 华中科技大学 一种基于数据块图谱的固态盘缓存优化方法和系统
CN111538681B (zh) * 2020-03-25 2022-11-01 武汉理工大学 Spark平台下基于最大化缓存增益的缓存替换方法
CN112015765B (zh) * 2020-08-19 2023-09-22 重庆邮电大学 基于缓存价值的Spark缓存淘汰方法及系统
CN113064870B (zh) * 2021-03-22 2021-11-30 中国人民大学 一种基于压缩数据直接计算的大数据处理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Log Analysis In Cloud Computing Environment With Hadoop And Spark;Xiuqin LIN, Peng WANG, Bin WU;《2013 5th IEEE International Conference On Broadband Network & Multimedia Technology》;20130917;273-276 *
Resilient distributed datasets:a fault-tolerant abstraction for in-memory cluster computing;Zaharia M, Chowdhury M, Das T,et al;《Proceedings of Proceedings of the 9th USENIX conference on Networked Systems Design and Implementation, Berkeley, CA, USA:USENIX Association》;20121231;2-2 *

Also Published As

Publication number Publication date
CN103631730A (zh) 2014-03-12

Similar Documents

Publication Publication Date Title
CN103631730B (zh) 内存计算的缓存优化方法
CA2963088C (en) Apparatus and method for scheduling distributed workflow tasks
Klonatos et al. Building efficient query engines in a high-level language
Armenatzoglou et al. Amazon Redshift re-invented
US9424282B2 (en) Online reorganization of hybrid in-memory databases
US10049134B2 (en) Method and system for processing queries over datasets stored using hierarchical data structures
Grund et al. Hyrise: a main memory hybrid storage engine
US20140215487A1 (en) Optimizing execution and resource usage in large scale computing
CN106777351A (zh) 基于art树分布式系统图存储计算系统及其方法
CN104778077B (zh) 基于随机和连续磁盘访问的高速核外图处理方法及系统
CN108536692A (zh) 一种执行计划的生成方法、装置及数据库服务器
EP3547166A1 (en) Data placement in hybrid data layouts for tiered htap databases
García-García et al. Efficient large-scale distance-based join queries in spatialhadoop
Shanoda et al. JOMR: Multi-join optimizer technique to enhance map-reduce job
Costa et al. A survey on data-driven performance tuning for big data analytics platforms
Munir et al. A cost-based storage format selector for materialized results in big data frameworks
Xin et al. Enhancing the interactivity of dataframe queries by leveraging think time
Cassales et al. Improving the performance of bagging ensembles for data streams through mini-batching
Lai et al. Accelerating multi-way joins on the GPU
AU2020101071A4 (en) A Parallel Association Mining Algorithm for Analyzing Passenger Travel Characteristics
CN102141988B (zh) 一种数据挖掘系统中数据聚类的方法、系统及装置
CN116827950A (zh) 云资源的处理方法、装置、设备及存储介质
CN106599005A (zh) 一种数据归档方法及装置
Ji et al. Query execution optimization in spark SQL
Hagedorn et al. Cost-based sharing and recycling of (intermediate) results in dataflow programs

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20170821

Address after: Nanshan District Guangdong streets of Shenzhen science and technology of Guangdong Province in 518054 southern Shenzhen Research Institute of Tsinghua University, A304-1

Patentee after: Cleanergy Aike (Shenzhen) Energy Technology Co. Ltd

Address before: 518057 Shenzhen Institute of technology, Nanshan District high tech Industrial Park, Guangdong,, Tsinghua University, A302

Patentee before: Shenzhen Institute of Stinghua University

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20171020

Address after: 518057 Shenzhen Institute of technology, Nanshan District high tech Industrial Park, Guangdong,, Tsinghua University, A302

Patentee after: Shenzhen Institute of Stinghua University

Address before: Nanshan District Guangdong streets of Shenzhen science and technology of Guangdong Province in 518054 southern Shenzhen Research Institute of Tsinghua University, A304-1

Patentee before: Cleanergy Aike (Shenzhen) Energy Technology Co. Ltd

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20180207

Address after: 518000 Guangdong city of Shenzhen province Nanshan District Guangdong streets Technology Park A304-1 District Research Institute of Tsinghua University in Shenzhen room

Patentee after: Cleanergy Aike (Shenzhen) Energy Technology Co. Ltd

Address before: 518057 Shenzhen Institute of technology, Nanshan District high tech Industrial Park, Guangdong,, Tsinghua University, A302

Patentee before: Shenzhen Institute of Stinghua University

TR01 Transfer of patent right