一种基于机器学习的Spark容器集群性能提升方法

Ctinfo security

4〇19年第4期

■ doi ：10.3969/j.issn.1671-1122.2019.04.002

技术研究_

一种基于机器学习的Spark容器集群

性能提升方法

-----------------------------田春岐 ' 李静 ' 王伟1’2,3,张礼庆u-------------------------------(1.同济大学计算机科学与技术系，上海200092; 2.同济大学丧入式系统与服务计算教育部重点实验室，上海200092;

3.湖北省教育信息化工程技术研究中心，湖北武汉430062 )

摘要：目前基于Spark的应用十分广泛，合理的参数配置会使Spark作业具备较

高的执行效率，很多学者对虚拟机集群上的Spark参数调优进行了深入研究。近年来，

容器作为一种新兴的云计算基础设施越来越广泛地被应用于服务集群中，因而对基于 容器集群的Spark参数调优进行研究也具有重要意义。文章研究了 Docker容器集群中

Spark的参数配置问题，提出了一种新型的参数调优方法（ContainerOpt),使用机器学

习方法学习并预测作业在不同参数组合下的性能，同时引入节点自动伸缩机制，使输 入规模较大的作业可以获得更优的性能。文章还提出了由时间和资源共同决定的性能 表示模型，代替传统的基于单一执行时间的性能表示模型，从而在作业执行时间和资 源占用之间达到较好的平衡。实验结果表明，相较于默认配置，该参数调优方法可提 升50%的执行效率。

关键词：云计算；Spark ; Docker ;机器学习；参数调优

中图分类号：TP309文献标识码：A文章编号：1671-1122 (2019) 04-0011-09

中文引用格式：田春岐，李静，王伟，等.一种基于机器学习的Spark容器集群性能提升方法[J].信息网 络安全，2019, 19(4): 11-19.

英文引用格式：TIAN Chunqi, LI Jing, WANG Wei, et al. A Method for Improving the Performance of Spark on Container Cluster Based on Machine Leaming[J]. Netinfo Security, 2019,19⑷：11—19.

A Method for Improving the Performance of Spark on Container

Cluster Based on Machine Learning

TIAN Oninqi1，2, LI Jing1，2, WANG Wei1，2,3, ZHANG Liqing1'2

(1. Department of Computer Science and Engineering, Tongji University9 Shanghai 200092, China; 2. The Key Laboratory of Embedded System and Service Computing of Ministry of Education, Tongji University, Shanghai

200092, China; 3. Hubei Engineering Research Center for Education Information^ Wuhan Hubei 430062, China)

Abstract: At present, Spark-based applications are very extensive. Reasonable configuration will make Spark jobs have higher execution efficiency. A large number of scholars have

收稿日期：2018—11—19

基金项目：国家自然科学基金[61672384, 61772372];中央高校基本科研业务费专项资金[0800219373];湖北省教育信息化工程技术研 究中心开放基金重点项目[201701]

作者简介：田春岐（1975—)，男，陕西，副教授，博士，主要研究方向为云计算、无线宽带网络；李静（ 1993—)，女，四川，硕士研究生， 主要研究方向为云计算、大数据；王伟（ 1979—)，男，湖北，副教授，博士，主要研究方向为云计算、大数据、大规模在线学习系统; 张礼庆（1994一)，男，江苏，硕士研究生，主要研究方向为云计算、大数据。通信作者：田春岐 tianchunqi@tongji.edu.cn

11

2019年第4期、

conducted in-depth research on the parameter tuning of Spark on virtual machine clusters. In recent years, as an emerging cloud computing infrastructure, containers are more and more widely used in service clusters. Therefore, it is also important to study the parameter tuning of Spark on container clusters. This paper studies the parameter configuration problem of Spark on Docker container cluster, and proposes a new parameter tuning method(ContainerOpt), which uses machine learning method to learn and predict the performance of the job under different parameter combinations, and introduces node automatic scaling mechanism that enable higher-input jobs to achieve better performance. In order to achieve a better balance between job execution time and resource occupation, a performance representation model based on time and resource is proposed to replace the traditional performance representation model based on a single execution time. The experimental results show that compared with the default configuration, the parameter tuning method can improve the execution efficiency by 50%.

Key words: cloud computing; Spark; Docker; machine learning; parameter tuning

〇引言

2008年Google公司发表论文提出了 MapReduce 编程模型[1]，近年来基于MapReduce实现的开源大数 据处理框架Hadoop已得到业界的普遍应用[2]。然而， 随着各大企业数据量的极速增长，越来越多的用户 对MapReduce在迭代式和交互式应用方面的低下处 理效率感到不满。MapReduce分为Map和Reduce两 个处理阶段，将两个处理阶段之间的中间数据存储 到磁盘需引入大量的磁盘IO操作，因而其设计思路 并不适用于处理迭代式和交互式应用。为了克服这 类问题，Spark[3]采用了不同的方法，以弹性数据集 RDD的方式将所有中间数据缓存在内存而不是磁盘 中，因此对两个阶段之间的弹性数据集读取不需要 磁盘访问，每个RDD都记得自身如何从其他数据集 构建而成（通过map、join、Group by等操作），并 在需要时重构自身。在多步骤分析中，Spark的性能 甚至高达MapReduce的100倍。尽管如此，Spark 的性能仍然有很大的提升空间，如果没有对作业进 行合理的调优，其执行速度依然会很慢，无法体现 Spark作为一种快速大数据计算引擎的优势。

目前，大数据框架优化可以分为两方面，一是 改写框架代码，使得分系统更契合业务的处理逻辑； 二是调整应用程序、硬件或软件的参数，使之更能 适用于不同的处理要求。然而，想要得到优化的配 置参数是十分困难的，因为系统中往往具有数百个

参数，且这些参数彼此互相关联和影响。同时框架 的执行效率还受到集群底层资源的影响，相同参数 的作业在不同的集群中也可能有不同的表现[4_6]〇

参数配置方法可以分为3类:遵循官方给出的 最佳实践的调节指南[8]、离线方法配置参数6,911]和在 线方法配置参数12，13]。其中，在线方法配置参数通过 动态分配不同配置，试探性地以小部分输人运行任 务来搜索较为优化的配置，优点是对所有的集群和 作业都适用。然而该方法的缺点是试探性的多次运 行需要较多的时间，这会对作业的总执行时间造成 相当大的影响，并且小部分输入的结果往往无法准 确预测实际输人的作业表现。

目前Spark多数都部署在虚拟机（VM )上，学 术界的研究也是基于VM集群。然而，另一种虚拟 化方式Docker目前也得到了非常广泛的研究和应用， 对云计算的各种服务模式均有非常大的影响。文献[14] 研究表明，使用轻量级虚拟化框架Docker集群部署 的Spark相较于VM集群中的Spark，在同样的配置 下可以获得更优的性能表现，然而如何对Docker集 群中的Spark进行参数配置优化的研究至今仍是空白。

本文研究Docker集群中Spark的参数配置调优， 利用Docker快速启动和低资源能耗的特点，提出了一个基于机器学习的参数调优方法---ContainerOpt〇首先收集作业在不同配置和不同节点数下的性能 表现，然后利用 GBDT (Gradient Boosting Decision

12

Tree)算法训练数据得到性能预测模型。针对小规模 输入的作业，直接利用性能预测模型推荐的参数提 交运行，针对大规模输人的作业，则伸缩节点个数 并配以合适的参数提交运行。

1相关工作

文献[15]研究了 Docker运行参数对Spark作业 执行的影响，通过比较资源限制和资源干扰情况下 的作业完成时间，得出了 Docker配置参数能够极大 地影响Spark性能的结论，尤其对于不同类型的作 业，如WordCount和Sort,影响更加明显。文献[16] 研究了 Docker环境中Hadoop的内存配置，并在改 变Hadoop的内存配置的同时分析了 Hadoop的性 能。测试结果表明，与默认的内存参数设置相比, 适当的内存配置改进了性能。文献[17]提出了分析 模型来分析多个并发Spark程序之间的资源干扰。 文献[18]提出一种基于机器学习的方法为Spark的 任务并行化推荐最佳参数，通过监控一些性能指标 找到参数和性能的统计学相关性，建立表征模型并 推荐配置给用户。该方法的优点是Spark作业运行 的每个阶段有独立的配置，缺点是工作量太大，数 据量也大。文献[19]提出一种混合专家模型来描述 Spark应用的内存行为，使用多个线性或非线性函 数对应用的内存需求进行建模，通过建立机器学习 分类器为当前应用选择合适的内存函数，然后综合 考虑所有任务所需的资源用量来提髙系统的吞吐量。 混合专家模型可以在需要时添加更多的内存函数， 使得框架更加通用。

同时，也有很多文献对MapReduce进行改进，提 升算法性能，或者针对MapReduce作业的参数进行 调优。文献[20]提出基于YARN云计算平台与非负 矩阵傭的大数据聚类算法，讨论了高维数据相似性 聚类与非负矩阵分解的结合，及其面向MapReduce 的数据聚类的任务划分方式。实验表明，该方法比 传统用于数据聚类的非负矩阵方法具有更好的运行 时间与加速比。文献[9]提出了一个两阶段机器学习

nCtinfo security

4〇19年第4期

技术研究

和优化框架^AROMA。第一个阶段是离线工作， 首先收集过去作业的信息并通过*-medoid聚类技术 将其分到几个类别中，每个类别有相似的CPU、内 存和磁盘利用率；然后对于每个类别，使用支持向 量机训练数据得到性能预测模型，用于预测作业在 不同配置参数和输入大小的不同组合下的性能。第 二个阶段是在线工作，首先用默认配置和小部分输 入运行作业得到资源利用特征，选择具有最相似资 源利用特征的类别；然后利用该类别对应性能预测 模型的搜索优化技术，找到使运行时间内资源开销 最小的近似最优参数配置。

文献[21]提出了一^基于机器学习的性能模型用 于自动调节参数。使用不同的MapReduce应用和不 同的集群配置评估了几种机器学习模型，发现支持向 量回归具有最高的准确度。该模型和StarfishPi自动调 节器相比有更优的性能。最后结合智能搜索算法实现 了一个完整的端到端的自动调整流，对参数空间进行 有效的搜索，并且对模型进行了有效训练。

Spark是当前最流行的开源大数据计算框架之 一，引入了弹性分布式数据集RDD。RDD是一个 不可变的、可分区的分布式数据集，该数据集的全 部或部分数据可以缓存在内存中，在多次计算间重 复利用。同时RDD具有懒加载的特性，只有一个动 作被调用时才会生成数据集，避免了不必要的计算， 从而提升了性能。

Docker集群和VM集群的Spark架构如图1所 示。当客户端提交一个Spark作业后，首先该作业 启动一个对应的Driver进程。在YARN-client模式 中，Driver进程被安排在集群中某个工作节点上启 动，负责切始化SparkContext。SparkContext向集群 管理器YARN申请运行Spark作业需要使用的资源。 然后YARN集群管理器依据用户为Spark作业设 置的资源参数，在各个工作节点上启动一定数量的 Executor (执行器）进程，每个Executor进程都占有

13

N©TINF〇 SECURITY

技术研究

2019年第4期

一定数量的资源。

主节点

从节点从节点

执行器||执行器

执行器

执行器

二进制文件二进制文件

Docker引擎

a ) Spark on Docker 架构

Driver

集群管理器

二进制文件

客户机系统

b) Spark on VM 架构

图 1 Spark on YARN 架构

申请到作业执行所需的资源后，Driver进程开始 调度和执行作业。Driver进程将Spark作业代码分拆 为多个Stage(阶段)，每个Stage执行一部分代码片段， 并为每个Stage创建一批Task,然后将这些Task分 配到各个Executor进程中执行。Task是最小的计算 单元，负责执行相同的计算逻辑，只是每个Task处 理的数据不同而已。一个Stage的所有Task都执行 完毕后，在各个节点的内存或本地的磁盘文件写入 中间数据，这些数据就是下一个Stage的Task的输人。 Driver进程调度运行下一个Satge,并按照同样的方 式计算所有数据，将得到的结果写人存储系统。

本文比较了 Docker集群和VM集群中Spark的 性能，如图2所示。选择灸-means、逻辑回归（LR)、 PageRank、SQL、WordCount、Sort 六种作业在集群 资源相同、作业参数相同、输入数据相同的情况下， 分别在Docker集群和VM集群中执行。图2 a)为 不同作业在两个集群中的执行时间；图2 b )为设置 50-1000次的迭代次数，PageRank作业在两个集群

14

中的执行时间。

—

0 Docker SVM

I

ffe系

c

關國

a)不同作业在两个集群中的执行时间

-^—Docker

• VM

112

8

0— o6o /4o雲

o2

o装

o

b> PageRank在两个集群中不同迭代次数的执行时间

图2 Docker集群与VM集群中Spark的性能

由图2可以看出，Spark在Docker集群比在VM 集群有更优的性能。对于PageRank这类迭代式作 业，Spark在Docker集群的性能更是远高于VM集 群，这是因为每次迭代中，Spark中的PageRankX才 于两个特定的RDD都会髙度重用，而这些RDD被 Docker持久化在存储引擎，因此Spark可以快速从 主存中读取。

Spark执行过程中的资源分配对其性能有决定 性影响，资源分配可以由参数决定，同时实验表明, 针对Docker集群的研究非常有必要。因此本文的目 的是找到这些参数的最佳组合以提升Docker集群中 Spark的性能。

3 ContainerOpt3.1 ContainerOpt 概述

本文的ContainerOpt致力于在使用资源和作业 执行时间上达到最高的性价比，以此提高系统的吞 吐量和Spark作业性能。图3展示了该方法的总体

架构，其基于第二代Hadoop-YARN实现。首先，分 析作业的整体执行流程，并结合前人的研究选择对 作业性能影响较大的参数，收集不同参数组合下作 业的性能数据；然后使用梯度提升决策树（GBDT) 训练数据，得到性能预测模型，并集成在Hadoop中。 当有新的作业进入集群时，搜索参数空间，利用性 能预测模型得到适合新作业的配置。在此过程中， 如果作业的输入数据较大（超过GB级)，则启动节 点自动伸缩机制。将节点个数和模型给出的配置作 为作业的新配置参数，在集群中运行作业，记录结 果，并决定是否要将此次结果放人数据集中。因此， ContainerOpt从3个角度改善了性能：1 )节点的自 动伸缩机制使输人规模较大的应用在总资源一致的 情况下能够获得更优的性能；2)作业用性能预测模 型推荐的参数提交运行，将运行结果进行收集并加 入训练，使模型更加完善；3)针对性能改变较大的 作业，考虑到集群已经改变，则重新训练数据，从 而克服针对特定集群的缺点。

图3 ContainerOpt总体架构

3.2性能模型

目前，大部分研究都以作业执行时间作为Spark 性能的唯一评价标准，这其实是不合理的。因为很 多情况下，执行时间的小幅提升需要以大量的资源 增加为代价，通常集群中的作业并不唯一，提交的 新作业如果占用大量的资源反而拖累了其他作业的 执行，降低了系统的整体吞吐量。

本文的性倉I表7K模型[6]为：Pe你r=F(a/!p/jcarion, resource,input,duration),其中，application .

resource表示作业使用的资源，

表示作业的输

nCtinfo security

4〇19年第4期

技术研究_

人数据规模，表示作业的执行时间，F是一

个关于四者输出的函数。在本文的研究场景中，资 源包含CPU和内存，因为二者对性能有非常明显的影响。

在相同的集群中，具有相同分配资源和输人规 模的作业的执行时间基本相同；不同的集群中，相 同分配资源和输入规模的作业的执行时间可能不相 同。另外，预测准确的作业执行时间是非常困难的， 也完全没有必要。因此，本文采用作业执行时间的 提升量，即作业执行时间相较于在最少所需资源量 的配置参数下运行时间的减小比例（如公式（1)所 示，此处最少所需资源量指作业运行成功所需的最 少资源量），来代替作业的执行时间。通常情况下， 非机器学习作业仅默认配置即可成功运行，而机器 学习作业则需要更多的内存资源。

TI = Tmin~TmB xi〇〇%

(1)

Tmm

在作业输入规模较小时，增大CPU和内存的分 配，X^i•该作业而言，77只有非常小的提升，而且这 种方式会占用更多的的资源，对其他作业造成影响。 因此，本文采用公式（2)表示性能。

其中,表示配置的资源数量。由公式（2)可知，77 越大、及越小，性能越好。a和々用于调整执行时间和

资源消耗量在性能表示模型中的权重，实验表明々取 值范围在0.1~0.5之间较为合理。

3.3参数选择

Spark共有180多个配置参数，但对Spark作业 性能影响较大的只有少量。本文选取了6个对作业 性能影响较大的参数，如表1所示。表1中，前6 个参数是Spark的配置参数，此e表示作业的输

人数据大小，

表示集群节点数。“默认”列表

示参数的默认值，“参数范围”列是推荐范围。

3.4数据收集

本文选择了大数据基准框架HiBench的16种负

15

2019年第4期

表1 Spark作业参数

参数

描述

默认

参数范围

Spark.num.instancesExecutor 个数22~nodes x 4

Spark.driver.coresDriver的CPU个数1

1-4Spark.driver.memoryDriver内存11-4Spark, executor, coresExecutor 的 CPU 个数12~16Spark.executor.memoryExecutor内存数1GB2-64GBSpark.default.parallelismExecutor的并行度nodes x executor.cores x 3

inputsize输入数据nodes节点个数

载，分为典型负载（如Wordcount、Sort),迭代式作 业（如PageRank )和机器学习作业（如灸-means) 3类。

数据收集分为离线阶段和在线阶段。离线阶段， 通过稀疏采样的方法在所有的配置参数组合形成的 参数空间中找到合适数量的参数组合。首先随机取 样，取样范围在参数空间中尽可能均匀，以免取样 数据和真实数据间的偏差过大；然后在表现较好的 参数范围内进行间隔更小的搜索，为新作业的参数 搜索提供最优的结果。在此过程中，如果有运行失 败或者超出默认参数配置下运行时间几倍的作业， 则将这些作业的运行时间提升量设为-100%，表示 该配置参数不适合该作业。通过上述方法，可生成 约400种参数组合，并且每个工作负载的参数并不 完全相同。为了排除其他因素和随机性的影响，每 个工作负载在每种参数组合下运行3次，取平均值， 最终得到约64〇〇条数据。

在线阶段，针对一个新提交的作业，首先利用 性能预测模型搜索出合适的参数配置，记录此时模 型预测出的执行时间的提升量。然后用该参数配置 运行作业并记录运行时间，如果时间相差不大，则 将此次运行的数据加入模型的训练数据中，以求下 次作业的预测得到更精确的结果；如果时间相差很 大，考虑是否为集群抖动或者作业太多所致，暂时 不将数据加人模型的训练数据中，等待下次作业运 行结果。如果偏差持续存在，则需要考虑是否集群 已经更换，如果集群更换，则使用新数据代替模型 中的旧数据参与调节。

3.5模型训练

本文使用GBDT算法训练收集到的数据。GBDT

16

也称 MART (Multiple Additive Regression Tree),是一 种迭代的决策_法，该算法由多棵决策树组成，将 所有树的结论进行累加作为最终答案。

为了防止过拟合，本文采用交叉验证方法来提高 性能预测模型的性能。收集到原始的性能数据后，将 数据分为80%的训练集和20%的测试集，训练集用 于训练模型，测试集用于测试模型的准确性。为了得 到更准确的结果，本文随机分割数据并进行了3次测 试，实验结果证明GBDT算法有90%以上的准确度。

3.6模型应用

获得最终模型后，用其预测Spark作业在给定 的参数组合下的性能。但对于一个新作业，其参数 空间十分庞大，不可能也没有必要尝试搜索所有的 参数组合，但还希望尽快得到一个优化的结果，因 此本文采用随机递归搜索的方法来搜索参数空间。

随机递归搜雜法首先通过对参数空间进行随机 抽样，确定可能包含最优结果的组合区域，然后对落 在该区域的参数进行递归随机抽样。与传统算法（如 爬山算法）不同，该算法不能随便选择一个新点重新 开始抽样，而是在抽样效率下降前不麵整参数空间 大小来进行递归随机抽样，从而维持随机抽样的初始 高效性，通过不断比较得到最优的结果。

得到模型最优参数组合后，如果节点个数发生变 化，则使用脚本快速启动新的Docker,更改Hadoop 的slaves文件并下发到各个从节点，然后使用脚本设 置参数提交作业运行。

4实验及分析

实验采用的服务器配置是Intel i7, 32核，128 GB 内存。初始时，启动4个容器，1个作为Master节点， 3个作为Slaves节点。Docker版本是17.0.6, Spark版 本是 1.6.2, Hadoop 版本是 2.6.5。

1)节点个数对作业性能的影响

图 4 为参数相同(executor 为 6，executor.cores 为 4, executor.memory 为 4 GB，paralleliam 为 24,输入为

3 GB),节点个数分别为3和6时，6种作业所取得 的执行时间提升量。可以看出，除SVM外，其余作 业在6个节点上执行获得的执行时间提升量比在3 个节点上执行获得的执行时间提升量更明显。这是 因为虽然executor的个数相同，每个executor的资 源也相同，即作业可使用的资源相同，但6个节点 时拥有更大的HDFS读写吞吐量。因此，在作业的 输入数据量较大且读写HDFS较多时，动态增加节 点个数可以获得更优的性能。该实验证明，节点伸 缩机制有效提升了作业性能。

2) 不同输入规模下作业的最优表现

为了评估ContainerOpt能获得的最优效果，实验 选取了 3类作业的典型作业（WoidCount、PageRank、 LDA),比较在不同输入规模下（例如，WordCount的 5种输人大小分别是30 KB、300 MB、3 GB、16 GB 和32 GB)，不同参数组合所取得的最优作业执行时间 提升量，结果如图5所示。由图5可知，无论哪种输 入规模的作业，使用ContainerOpt推荐参数运行作 业的执行时间都比默认配置下运行作业的执行时间 少（执行时间提升量值越大，作业在推荐参数下执 行时间减小的幅度越大），且输人数据的规模越大， 参数调整的作用越明显。这是因为输人数据规模越 大，对资源的要求也越高，ContainerOpt通过调整参 数调整了分配的资源，所以作业执行速度加快，这 也证明了 ContainerOpt确实是有效的。

3) 参数变化下作业性能的改变

此处的性能指本文提出的性能表示模型。图6

N©TINFO SECURITY ：

,,i〇19年第4期

技术研究

alWadComt作业

b} PageRank 作业

0o9o

8o7o

6o5o4o3o

21ooo^

7

c) LDA作业

图5不同输入规模下最优作业执行时间提升量

为 TeraSort 作业在 executor.memory 为 4 GB,输入为 3 GB时，执行时间提升量随着executor.cores的变化而变化的情况。

图6 TeraSort执行时间提升量随executor.cores变化情况

17

jN&TINFO SECURITY

技术研究

2019年第4期

图 7 为 TeraSort 作业在 executor.cores 为 4,输入 为3 GB时，执行时间提升量随executor.memory的变化而变化的情况。

图7 TeraSort执行时间提升量随executor.memory

变化情况

由图6、图7可知，资源的增加和作业的执行时 间提升量并不是一直正相关，而是存在一个临界点， 当资源数量超过临界点后，作业的执行时间提升量反 而下降。这是因为，一方面，HDFS的并发性较差， 当executor.cores增大时，线程切换时间增加，作业执 行时间也相应增加；另一方面，executo.memory增大 可能导致严重的GC (Garbage Collection)延迟，甚 至阻塞，这也导致了作业的执行时间增加。

由图6、图7还可以看出，接近最优点时，资源 增加一个单位，作业执行时间的提升量却非常有限， 这也是本文提出执行时间与资源共同决定的性能模 型的原因。

在相同的实验条件下，X^f TeraSort作业性能（按 公式（2)进行计算，参数设为0.3 )随executor, cores、executor.memory变化的情况进行实验，并与 执行时间提升量进行对比，结果如图8、图9所示。

图8 TeraSort性能随executor.cores变化情况

18

图9 TeraSort性能随executor.memory变化情况

由图8、图9可知，执行时间提升量和性能的曲

线走势大致相同，但部分点大小有所不同。例如，在 图9中，当executor.memory为4时，执行时间提升量 为35% ; executonmemory为5 B寸，执行时间提升量为 36%,高于35%。然而，在性能曲线上，当executor, memory 为 4 时,性能为 80% ;executor.memory 为 5 时, 性能为80%。虽然性能相同，但本文推荐参数为4而 不是5,这样可以达到节省资源的目的。

5结束语

本文研究了基于Docker部署的Spark集群，提 出了一种Spark容器集群的性能提升方法。首先，采 用由执行时间与资源使用共同决定的性能表示模型 来代替由单一的执行时间决定的性能表示模型；其 次，收集多种作业的性能数据并使用机器学习算法 GBDT进行训练，得到作业性能预测模型，并预测新 作业在不同配置参数下的性能；同时加入了节点自 动伸缩机制，在输人数据规模较大时增加节点以获 得更大的性能提升，在输人数据规模较小时减少节 点以节省资源。实验证明本文方法最大可获得50% 性能提升。下一步将考虑更多作业，并且探究作业 之间的统计相关性，以便在集群中有新作业时可以 根据以前的作业判断出较适合的配置，增大系统的 扩展性。•（责编潘海洋）

参考文献：

[1] DEAN J, SANJAY G. MapReduce: Simplified Data Processing

on Large Clusters[J]* Communications of the ACM, 2008, 51(1):

107-113.

[2] CHEN Yaobing, LIU Bin, SHI Yantao. A Lot of Log Storage and Retrieval Optimization Based on Hadoop Architecture[J]. Netinfo Security, 2013, 13(6): 40—45.

陈耀兵，刘斌，史延涛.基于Hadoop架构的大数据量日志存储和 检索优化信息网络安全，2013，13(6): 40-45.

[3] Apache. Apache Spark[EB/OL]. http://spark.apache.org/, 2018—7—11.[4] BABU S. Towards Automatic Optimization of MapReduce Programs[C]//ACM. 1st ACM Symposium on Cloud Computing, June 10—11, 2010, Indianapolis, Indiana, USA. New York: ACM, 2010: 137-142.

[5] HERODOTOU H, DONG F, BABU S. No One(Cluster) Size Fits All: Automatic Cluster Sizing for Data—intensive Analytics[C]// ACM. 2nd ACM Symposium on Cloud Computing, October 26— 28, 2011, Cascais, Portugal. New York: ACM, 2011: 1—14.

[6] HERODOTOU H, LIM H, LUO G, et al. Starfish: A Self­tuning System for Big Data AnalyticsQ]. CIDR, 2011, 1(11): 161—272.[7] DING Xiaoan, LIU Yi, QIAN Depei. JellyFish: Online Performance Tuning with Adaptive Configuration and Elastic Container in Hadoop Yarn[C]//IEEE. IEEE International Conference on Parallel & Distributed Systems, December 14-17, 2015, Melbourne, VIC, Australia. New Jersey: IEEE, 2016: 831—836.[8] JIANG Dawei, OOI B C, SHI Lei, et al. The Performance of MapReduce: An in—depth StudyQ]. VLDB Endowment, 2010, 3(1— 2): 472-483.

[9] LAMA P, ZHOU Xiaobo. Aroma: Automated Resource Allocation and Configuration of Mapreduce Environment in the Cloud[C]//ACM. 9th International Conference on Autonomic Computing. September 18—20, 2012, San Jose, California, USA. New York: ACM, 2012: 63-72.

[10] LIAO Guangdegn, DATTA K, WILLKE T L. Gunther: Search—based Auto—tuning of MapReduce[C]//Springer. 19th International Conference on Parallel Processing, August 26—30, 2013, Aachen, Germany. Heidelberg: Springer, 2013: 406—419.[11] WU Dili, GOKHALE A. A Self—tuning System Based on Application Profiling and Performance Analysis for Optimizing Hadoop MapReduce Cluster Configuration[C]//IEEE. 20th International Conference on High Performance Computing(HiPC), December 18—21, 2013, Bangalore, India. New Jersey: IEEE, 2014: 89—98.

[12] LI Min, ZENG Liangzhao, MENG Shicong, et al. MRONLINE: MapReduce Online Performance Tuning[C]// ACM. International Symposium on High-performance Parallel &

4〇19年第4期

Distributed Computing, June 23—27, 2014, Vancouver, BC, Canada. New York: ACM, 2014: 165-176.

[13] CHENG Dazhao, RAO Jia, GUO Yanfei, et al. Improving MapReduce Performance in Heterogeneous Environments with Adaptive Task Tuning[C]//ACM. International Middleware Conference, December 8—12, 2014, Bordeaux, France. New York: ACM, 2014: 97-108.

[14] BHIMANI J, YANG Zhengyu, LEESER. M, et al. Accelerating Big Data Applications Using Lightweight Virtualization Framework on Enterprise Cloud[C]//IEEE. 2017 IEEE High Performance Extreme Computing Conference(HPEC), September 12—14, 2017, Waltham, MA, USA. New Jersey: IEEE, 2017: 1—7.

[15] YE Kejiang, JI Yunjie. Performance Tuning and Modeling for Big Data Applications in Docker Containers[C]//IEEE. 2017 International Conference on Networking, August 7—9，2017, Shenzhen, China. New Jersey: IEEE, 2017: 1—6.

[16] WANG Xueyuan, LEE B, QIAO Yuansong. Experimental Evaluation of Memory Configurations of Hadoop in Docker Environments[C]//IEEE. 27th Irish Signals and Systems Conference(ISSC), June 21—22, 2016, Londonderry, UK. New Jersey: IEEE, 2016: 1-6.

[17] WANG Kewen, KHAN M M H, NGUYEN N , et al. Modeling Interference for Apache Spark Jobs[C]//IEEE. 9th IEEE International Conference on Cloud Computing, June 27—July 2, 2016, San Francisco, CA, USA. New Jersey: IEEE, 2017: 423—431.[18] HERNANDEZ Alvaro Brandon, PEREZ Maria S, GUPTA S, et al. Using Machine Learning to Optimize Parallelism in Big Data Applications[EB/OL]. https://www.sciencedirect.com/science/ article/pii/S0167739X17314668, 2018-6-11.

[19] MARCO V S, TAYLOR B, PORTER B, et al. Improving Spark Application Throughput via Memory Aware Task Co­location: A Mixture of Experts Approach[C]//ACM. 18th ACM/ IFIP/USENIX Middleware Conference, December 11—15, 2017, Las Vegas, Nevada. New York: ACM, 2017: 95—108.

[20] FENG Xinyang, SHEN Jianjing. A Yarn and NMF Based Big Data Clustering AlgorithmQ]. Netinfo Security, 2018, 18(8): 43—49.

冯新扬，沈建京.一种基于YARN云计算平台与NMF的大数据 聚类算法D]-信息网络安全，2018, 18(8): 43-49.

[21] YIGITBASI N, WILLKE T L, LIAO G, et al. Towards Machine Learning—based Auto—tuning of MapReduce[C]//IEEE. 2013 IEEE 21st International Symposium on Modelling, Analysis & Simulation of Computer and Telecommunication Systems, August 14—16, 2013, San Francisco, CA, USA. New Jersey: IEEE, 2013: 11—20.

19