CN108255689A - 一种基于历史任务分析的Apache Spark应用自动化调优方法 - Google Patents

Abstract

本发明提出了一种基于历史任务分析的Apache Spark应用自动化调优方法，包括对Spark应用的任务提交接口进行封装，判断是否已有该Spark应用的分层灰盒时间预测模型，访问数据库，读取并更新所述分层灰盒时间预测模型，用户选择是否进行优化；如果进行优化则生成优化参数，如果不进行优化则按原参数执行，调用shell命令运行任务。本发明充分地利用了已知的集群硬件资源信息，选择并实现一了个能够在高维参数空间上对最优参数进行高效搜索方案，从而筛选出在建立的分层灰盒时间预测模型下，性能表现较优的配置参数，达到实现自动化Spark参数调优的目的。

Description

一种基于历史任务分析的Apache Spark应用自动化调优方法

技术领域

本发明属于计算机软件技术领域，特别是涉及一种基于历史任务分析的ApacheSpark应用自动化调优方法。

背景技术

Apache Spark是一款被广泛使用的开源大数据通用处理平台，具有编程简单，计算速度快等优点，因而在工业界被广泛使用。然而，由于Apache Spark系统有150个左右的配置参数，这些参数的取值会影响系统的表现和性能，所以对他们的配置需要慎重。考虑到Spark系统本身的复杂性和Spark系统参数之间潜在的相互作用，仅仅依靠人工进行参数调优并不十分现实。而且手动调参无法为每个任务根据其特点进行个性化的调整，这使得自动调参技术具有相当大的重要性。

现有针对Spark的自动调优技术研究十分稀少，清华大学陈侨安等发表的论文提出了根据任务相似性，寻找已优化的相似任务并迁移参数配置的思路，然而该技术仅能在具有足够数量经过手动优化的任务记录的情况下工作良好，且这些工作记录需要和被调优的参数具有高度的相似性，而这种相似相性度量在复杂条件下难以应用。中国科学院大学G.Wang等发表的论文中提出使用机器学习分类问题建立应用性能模型的思路，通过将历史配置参数和性能表现作为样本集输入，建立一个黑盒模型的方法，作者在不关心Spark底层实现的情况下通过优化参数配置得到了一定的性能提高。然而他们提出的机器学习框架相对比较简单，并且完全将系统的表现当做黑盒模型进行处理，对于参数的选取进行实验的效率和模型精度都有改进的空间，没有充分利用Spark资源管理器的资源分配模式和一些已知的集群硬件信息。

发明内容

本发明为了解决现有的技术问题，提出一种基于历史任务分析的Apache Spark应用自动化调优方法。

本发明的目的通过以下技术方案实现：一种基于历史任务分析的Apache Spark应用自动化调优方法，包括以下步骤：

步骤1、对Spark应用的任务提交接口进行封装，用户直接将要运行的Spark应用和默认的相关选项提交到用户提交接口上；

步骤2、判断是否已有该Spark应用的分层灰盒时间预测模型；如有则执行步骤3；如无则按原参数执行，执行步骤5；

步骤3、访问数据库，读取并更新所述分层灰盒时间预测模型；

步骤4、用户选择是否进行优化；如果进行优化则生成优化参数，执行步骤5；如果不进行优化则按原参数执行，执行步骤5；

步骤5、调用shell命令运行任务。

进一步地，所述数据库中数据是通过定时历史数据采集器从Hadoop、Sparkhistoryserver中获取得到或通过日志文件采集和解析工具从HDFS中获取得到。

进一步地，所述数据库中数据为应用时配置参数和任务执行时调度信息。

进一步地，所述分层灰盒时间预测模型共两层，通过选择不同的机器学习算法对Stage运行时间进行预测的模块构成了分层灰盒时间预测模型的第一层，将每个Stage的执行时间和整个应用的总执行时间之间的关系作为分层灰盒时间预测模型的第二层。

附图说明

图1为基于历史任务分析的Apache Spark应用自动化调优方法流程图；

图2为分层灰盒时间预测模型与其他预测模型误差比较图。

具体实施方式

下面将结合本发明实施例中的附图对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明充分地利用了已知的集群硬件资源信息，选择并实现一了个能够在高维参数空间上对最优参数进行高效搜索方案，从而筛选出在建立的分层灰盒时间预测模型下，性能表现较优的配置参数，达到实现自动化Spark参数调优的目的。

结合图1，本发明提出一种基于历史任务分析的Apache Spark应用自动化调优方法，包括以下步骤：

步骤1、对Spark应用的任务提交接口进行封装，用户直接将要运行的Spark应用和默认的相关选项提交到用户提交接口上；

步骤2、判断是否已有该Spark应用的分层灰盒时间预测模型；如有则执行步骤3；如无则按原参数执行，执行步骤5；

步骤3、访问数据库，读取并更新所述分层灰盒时间预测模型；

步骤4、用户选择是否进行优化；如果进行优化则生成优化参数，执行步骤5；如果不进行优化则按原参数执行，执行步骤5；

步骤5、调用shell命令运行任务。

所述数据库中数据是通过定时历史数据采集器从Hadoop、Spark history server中获取得到或通过日志文件采集和解析工具从HDFS中获取得到。日志文件中的每个JSON对象对应着Spark系统的一个事件(Event)，由于应用执行过程和执行环境的差异，每个日志文件中所含有的JSON对象个数和类型也不尽相同。本发明使用一个定时自动启动的装置自动从历史数据服务器上增量式地采集有关的历史数据，并进行解析分析每一个任务执行过程中每个Stage和Task的相关任务信息。同时还结合Spark History Server上的一些相关API，综合利用相关的有效资源。并不是每一个日志文件都对应着一个成功运行的Spark任务，所以必须能够区分一个任务是否成功的执行，一个未能成功的应用可以有各种各样的原因，比如应用的参数设置内存不足，导致内存溢出等，因此在读取日志文件是需要检查每一个Stage是否成功执行，以判断整体任务是否执行成功。为了实现这一目的，需要逐一检查Spark中每个Stage的执行状态，只有所有的Stage都成功结束，整个应用才算执行成功。

在日志文件中比较重要的事件(Event)有：

a)SparkListenerLogStart：

Spark应用的启动history server上进行注册的信息，包含Spark版本号信息。

b)SparkListenerEnvironmentUpdate：

这一JSON对象对应了history server Web UI上environment子页面上全部信息。在其中包含Spark.driver所在的主机，占用的端口，应用提交的Jar包(如果使用Sparkjava编程)，应用名称，任务部署模式等任务基本信息。

根据Spark2.1.0官方文档的解释，Spark历史服务器中WEB UI页面上只显示用户手动配置的应用参数(包括在配置文件中配置的参数，动态提交任务时配置的参数，或在应用源代码中显示写出的参数)，而用户没有设置的应用参数则不予显示。通过比较日志文件，发现日志文件中也的确仅有用户手动配置的参数。而其他没有显示的配置参数，如果用户没有手动配置，即为默认值。每一个可配置参数的默认取值都可以在Spark官网上找到，其参数值与具体的版本有关。

c)SparkListenerApplicationStart：

应用正式开始执行，包含任务的唯一ID,任务启动的时间戳。

d)SparkListenerJobStart：

对于应用中的每一个Job，都有一个这样的JSON对象与之对应。记录有这个job中Stage的信息，Job ID等。

e)SparkListenerStageSubmitted：

对应于一个Stage的提交过程，含有Stage ID，Stage中包含的任务数量，使用RDD的信息，以及该Stage依赖的Stages编号，通过这新信息可以从任务日志中重构Job在执行时生成的Stage DAG图。

f)SparkListenerTaskStart：

对应于一个Task的启动，记录有该Task的ID和所属Stage。

g)SparkListenerTaskEnd：

对应于一个Task执行完成，记录有该Task的ID，任务类型，结束原因，执行的起止时间等。

h)SparkListenerStageCompleted；

对应于一个Stage执行结束，包含Stage的ID，依赖关系，以及起止时间信息。

i)SparkListenerJobEnd:

对应于Job的结束信息，包含Job，ID，结束时间，执行结果等。

j)SparkListenerApplicationEnd:

Spark应用执行结束，包含任务的唯一ID,任务结束的时间戳。

通过从日志文件中读取上述事件记录并分析，能够获得每个应用在运行时的任务调度情况以及每个Stage和task的执行时间等数据。据此，可以重构任务执行时的Stage依赖关系，以及每个执行Stage中提交的Task数目等。

通过对Spark的任务提交接口进行封装，用户直接将要运行的Spark应用和自己默认的相关选项提交到应用提交接口上，系统将在历史数据库中进行搜索，如果没有检索到可以匹配的任务历史数据，则系统会使用用户提交的参数，或者是Spark自带的默认配置参数；如果搜索到可以使用历史任务信息，则询问用户是否要对任务进行优化。如果优化选项被选中，则系统将自动调用相应的分层灰盒时间预测模型(在后台采集历史任务数据时已经预先训练好)。然后经过优化的参数会通过实现的接口调用spark系统直接执行。

Spark任务的运行日志文件中存储了应用在运行时的信息，其包含的信息中的一部分通过Spark History Server显示在所提供的web UI上。另一部分通过读取日志文件的方式来获取应用时配置参数、任务执行时调度信息等用于建立分层灰盒时间预测模型的数据。

调优参数的选取，调优参数如表1所示：

表1调优参数

所述分层灰盒时间预测模型共两层，通过选择不同的机器学习算法对Stage运行时间进行预测的模块构成了分层灰盒时间预测模型的第一层，将每个Stage的执行时间和整个应用的总执行时间之间的关系作为分层灰盒时间预测模型的第二层。Spark系统执行一个应用的过程可以视为是执行这一应用中所有Stage的过程。因为Spark划分Stage的标准是数据之间的宽依赖关系，所以同一应用的不同的Stage执行运算的特点可能几乎没有相似性。通过分别选择不同的机器学习算法来预测其执行时间，这些对Stage运行时间进行预测的模块构成了整个应用分层灰盒时间预测模型的第一层。通过将每个Stage的运行时间预测视为一个子问题，可以从一个给定的机器学习回归模型列表中选出在某一个子问题上表现更好的算法。整个应用的运行时间并不是各个Stage之间运行时间之和，考虑到Stage之间复杂的数据依赖关系以及整个系统的并行性，将每个Stage的执行时间和整个应用的总执行时间之间的关系当成一个黑盒进行处理，这一个黑盒模型也可以被描述为一个机器学习回归问题，是应用分层灰盒时间预测模型的第二层。

分层灰盒时间预测模型相对于传统黑盒模型的优点是具有更高的性能预测精度：如图2所示，该模型相对于传统灰盒模型，均方误差减小了90％左右。

使用SHELL在linux下输入：

Java-jar Spark-tune-submit.jar[options]<app jar|python file>[apparguments]

其中“[options]<app jar|python file>[app arguments]”作为参数其含义与Spark-submit命令中的参数含义和格式相同，如表2所示：

表2各参数含义和格式

以上对本发明所提供的一种基于历史任务分析的Apache Spark应用自动化调优方法，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (4)

1.一种基于历史任务分析的Apache Spark应用自动化调优方法，其特征在于：包括以下步骤：

步骤1、对Spark应用的任务提交接口进行封装，用户直接将要运行的Spark应用和默认的相关选项提交到用户提交接口上；

步骤2、判断是否已有该Spark应用的分层灰盒时间预测模型；如有则执行步骤3；如无则按原参数执行，执行步骤5；

步骤3、访问数据库，读取并更新所述分层灰盒时间预测模型；

步骤4、用户选择是否进行优化；如果进行优化则生成优化参数，执行步骤5；如果不进行优化则按原参数执行，执行步骤5；

步骤5、调用shell命令运行任务。

2.根据权利要求1所述的方法，其特征在于：所述数据库中数据是通过定时历史数据采集器从Hadoop、Spark history server中获取得到或通过日志文件采集和解析工具从HDFS中获取得到。

3.根据权利要求2所述的方法，其特征在于：所述数据库中数据为应用时配置参数和任务执行时调度信息。

4.根据权利要求3所述的方法，其特征在于：所述分层灰盒时间预测模型共两层，通过选择不同的机器学习算法对Stage运行时间进行预测的模块构成了分层灰盒时间预测模型的第一层，将每个Stage的执行时间和整个应用的总执行时间之间的关系作为分层灰盒时间预测模型的第二层。