CN110740079A - 一种面向分布式调度系统的全链路基准测试系统 - Google Patents

Abstract

一种面向分布式调度系统的全链路基准测试系统，其特征在于，包括数据集模块，负载集模块，测试指标集模块，负载提交策略模块，性能指标监控收集模块，客户端；所述客户端获取配置文件中的各类配置参数，负责各个模块之间的连接与控制、任务提交以及处理分布式调度系统测试后的反馈；所述数据集模块提供负载运行时所需的测试数据；所述负载集模块根据配置的负载类型进行负载集准备；所述测试指标集模块根据配置的测试指标进行测试指标集选择；所述负载提交策略模块根据配置的负载提交方式准备提交脚本，以脚本的方式向系统中按照既定策略提交负载；所述性能指标监控收集模块实时收集各维度指标信息并发送给客户端进行前端显示。

Description

一种面向分布式调度系统的全链路基准测试系统

技术领域

本发明涉及一个测试系统，尤其涉及一种面向分布式调度系统的全链路基准测试的系统。

背景技术

随着社会生产力和科学技术的飞速发展，特别是互联网技术和多媒体技术的快速发展，信息爆炸成为必然趋势。数据增长速度呈现出指数增长的趋势，数据量已经达到EB水平，海量数据中蕴含着丰富的价值信息，挖掘这些隐藏的价值信息对数据存储和计算都带来了很大挑战，计算平台的规模效应愈加凸显。现今的计算任务具有规模大、高并发等特点，传统的单机模式已经无法满足计算需求，而分布式调度系统的出现为大规模计算任务的稳定运行提供了可靠支持。

分布式调度系统是大规模集群中用于进行资源管理和任务分配的管理系统，其一方面管理大规模集群中各个计算节点和各维度计算资源，例如：CPU、内存、磁盘、网络等，另外一方面管理提交至集群中的任务并按照一定分配策略将集群中空闲的计算资源分配给相应任务，保证其稳定运行。分布式调度系统在节省成本、提升可用性、简化运维等方面有重大意义，各大主流公司都在其上投入了大量研究，例如：谷歌、亚马逊、微软、阿里云、腾讯云等。

分布式调度系统也经历了一个快速迭代发展的过程，从一开始的单体式调度系统，由单一的调度器决定将可用资源以恰当的分配策略分配给提交至集群中的任务，所有的调度信息由调度器自身收集，典型的如：MapReduce、Hadoop1.0等。随着集群规模的增加，单一调度器成为性能瓶颈，由此演变出了两层调度系统，将资源分配和任务管理解耦，资源分配模块仅负责集群资源管理和分配，任务管理模块负责进行资源申请和任务运行全周期信息维护，典型的调度系统如：YARN、Mesos。随后又发展出去中心化的分布式调度系统，在分布式调度系统中，存在多个分布式的调度器，它们在进行调度决策前发出探针探测集群中部分机器的使用状态，并从探测的机器中挑选最优的调度计算任务，典型的调度系统如：Sparrow。随机探测导致资源分配不能保证全局最优，因此又发展出状态共享式调度系统，集群中机器的全局信息存储在一个共享的可靠数据结构中，多个调度器共享此数据结构执行调度决策，从而保证调度决策的全局最优，典型系统如：Omega。状态共享式调度系统虽然可以保证资源的最优分配，但是全局资源信息的一致性维护需要较大成本且会降低吞吐量。因此又发展出混合式调度系统，在一个集群中有多个不同类型的调度系统，针对不同的计算任务选择不同的调度系统进行调度，典型系统如：Borg、Mercury。目前又出现了中心化与分布式混合机制，通过将不同异构类型的负载进行混合调度来提高系统资源利用率，中心调度器通过运行节点进程收集可用资源使用情况，协调者将全局状态信息实时同步给分布式调度器。并且随着对分布式调度系统性能的极致追求，很多新的优化方案也不断出现，例如：通过对计算节点物理指标信息进行汇总和排序以解决集群资源异构性问题，通过对任务进行资源建模以更好的进行底层资源隔离，通过超售机制来提高集群的物理资源利用率等。

从上述描述可以看出，针对不同场景和不同性能要求的调度系统蓬勃发展，如何合理评估这些调度系统的性能是一个很大的挑战，基准测试技术应运而生。

基准测试技术是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项或多项性能指标进行定量的、可对比的和可复现的测试。早期时候SPEC(Standard Performance Evaluation Corporation)公司已经开发了针对计算机硬件较为成熟的基准测试，例如针对CPU、存储、功耗等方面的基准测试。TPC(TransactionProcessing Performance Council)也在早期根据不同的应用环境推出了TPC系列的基准程序。随后随着大数据的快速发展，大数据领域的基准测试得到了国内外工业界和学术界的广泛关注和深入研究，出现了一些研究成果。

现有技术中针对大数据领域的基准测试系统主要分为三类：微基准测试系统、端到端基准测试系统、综合性基准测试系统。

微基准测试系统主要通过对应用领域的广泛深入调研，选择了一些能够代表应用领域任务特征的小型负载或核心负载作为基准测试的负载集，被测系统可以从负载集中选择全部或部分负载进行功能或性能测试。其包含的负载计算复杂度和规模都较小，且没有提供负载提交策略的定义，可用于小规模系统测试。典型系统如：Hadoop系统自带的基准测试负载、AMPLab benchmark。

端到端基准测试系统主要通过构建一个真实的应用，并将该应用运行在被测系统中，根据该应用运行时的各维度指标信息来间接评估被测系统的性能。端到端的含义在于测试时只关注应用本身的指标信息，例如：请求延迟、请求吞吐量等。典型系统如：YCSB、TPC-W。

综合性基准测试系统是上述两种基准测试系统的整合和完善，其中不仅包含一些具有代表性的核心负载、真实的应用，也包含一些真实应用场景下的真实负载，例如：各种机器学习算法、数据库操作等，同时其还提供了负载运行的数据集和一些评测指标。典型系统如：CloudSuite、HiBench。

虽然现有基准测试技术有了一定发展，但是还存在一些问题。从整体上来看主要有两方面问题，一方面现有的基准测试系统主要针对大数据系统，而分布式调度系统只是大数据系统中的一个重要可插拔模块，所以现有的基准测试系统并不能完全适配分布式调度系统的测评。另一方面现有基准测试系统主要关注负载集的构建，而没有关注评测其他环节，并没有提供一个全链路的基准测试系统。目前基准测试技术存在的详细问题包括以下几个方面：

(1)现有基准测试系统所包含的负载集和测试指标集主要针对大数据系统，而分布式调度系统是大数据系统中一个重要可插拔模块，因此其最终评测的结果是系统所有模块相互协作后体现的整体性能而并不能代表分布式调度系统的性能。目前面向分布式调度系统的基准测试技术研究存在短板，亟待一个基准测试系统对分布式调度系统进行公平合理的量化评估；

(2)缺乏对数据集的构建。数据是负载运行的基础，数据规模和特征对负载的运行有直接影响，在目前的大数据时代，数据具有规模大、多样化、价值密度低、生产速度快和准确性高等特征，因此测试时的数据应该尽可能满足上面特征。但是目前的基准测试系统中所采用的测试数据大多通过随机生成的方式或爬取网上现有数据的方式进行构建，随机生成的数据中并没有体现上述数据特征，通过爬取获得的数据有较大的时间成本不能快速进行评测；

(3)负载集软件栈实现较为单一。随着大数据技术的发展，不同的软件栈在特定的应用需求下被提出，例如：Spark、Stream、MPI等，这些软件栈在真实生产环境中有广泛应用。而目前基准测试系统的负载集中的负载大多为Hadoop类型的任务，不同软件栈实现的负载在计算逻辑、数据处理等方面都有较大差异，只通过Hadoop类型的任务进行评测缺少合理性，不能覆盖其他软件栈；

(4)没有针对分布式调度系统的测试指标集。目前基准测试系统中的测试指标主要包括三个维度，第一个维度关注任务的运行质量，例如：任务运行时间、吞吐量、延迟；第二个维度关注系统资源使用情况，例如：集群各维度资源利用率；第三个维度关注微体系结构层指标，例如：IPC、每秒完成的基本操作数等。这些指标所体现的是大数据系统的整体性能情况，并不能直接客观的评价分布式调度系统；

(5)没有统一可量化的负载提交策略。在很多研究的评测中，负载提交往往基于经验或者对被测系统有利的方式进行，没有一个统一的量化标准。在目前的基准测试系统中也很少有关于负载提交策略的说明，评测时候有较大自由度。而负载提交策略对系统评测有很重要的影响，没有统一可量化的提交方式，就很难公平地进行系统横向对比，也会使得评测失真；

(6)缺乏指标收集和监控模块。评测最终需要落在具体的评测指标上，这就需要在评测过程中收集评测指标数据。而目前的基准测试系统并没有包含监指标收集和监控模块，这就给评测带来一定不便，在评测时候还需要自己选择指标收集和监控工具。

(7)缺乏全链路的测试系统。目前的基准测试系统主要侧重负载集构建，而对于数据集、测试指标集、负载提交策略设计、负载提交、指标收集和监控方面相对较少，在进行评测时还需要再去寻找相关的工具来进行测试，测试流程比较复杂。

(8)原生集群管理系统的模拟器中存在一些问题：(1)调度器和任务节点模拟器运行在同一个计算节点上，通过线程来模拟任务申请资源和节点汇报心跳信息，启动大量线程会直接影响到调度器的评估；(2)在调度层对可插拔的调度器做了一层封装，然而该层封装的实现存在一些和不合理的逻辑；(3)出于通用性的设计，只能从外围获取到一些指标数据，不能获取调度器内部指标；(4)该模拟器侧重于测试调度器的性能，实际对资源管理器的优化涉及到很多方面，其评估不够全面。鉴于上面的问题对其进行了优化扩展。

发明内容

针对上述问题，本发明提供了一种面向分布式调度系统的全链路基准测试系统，包括数据集模块，负载集模块，测试指标集模块，负载提交策略模块，性能指标监控收集模块，客户端；所述客户端获取配置文件中的各类配置参数，负责各个模块之间的连接与控制、任务提交以及处理分布式调度系统测试后的反馈；所述数据集模块提供负载运行时所需的测试数据，所述测试数据包括从网上爬取的的真实数据和基于数据生成工具快速生成的数据，所述测试数据生成好后加载至集群的文件系统中；所述负载集模块根据配置的负载类型进行负载集准备，负载选择完成后将相关执行包加载至集群中以备负载运行；所述测试指标集模块根据配置的测试指标进行测试指标集选择，选择好的测试指标将发送至性能指标监控收集模块；所述负载提交策略模块根据配置的负载提交方式准备提交脚本，以脚本的方式向系统中按照既定策略提交负载；所述性能指标监控收集模块实时收集各维度指标信息并发送给客户端进行前端显示。

本发明现对于目前的基准测试系统有以下特点和优势：

(1)面向分布式调度系统的基准测试系统。本基准测试系统立足于评测分布式调度系统，因此从系统的整体框架设计和每个模块的设计实现都针对分布式调度系统进行，保证评测的有效性。

(2)完善的数据集和数据生成工具构建。在本基准测试系统中数据集主要包含两个部分，第一部分是从网上爬取的一些具有代表性的数据，例如：维基百科词条、影评等，考虑到网络传输开销，此部分数据集较小，对于小规模系统评测可以直接采用这些真实数据集进行；第二部分基于一些研究实现了数据生成工具，从真实数据集中提取数据特征并进行规模化扩展，数据生成过程进行了并行化实现，能够快速生成测试数据，既保证数据生成速度同时尽最大可能保留真实数据特征。

(3)负载集的不同软件栈实现。基于一些研究中对负载的分类，对选取的有代表性的负载进行其他软件栈实现，目前主要进行Spark和MPI两种软件栈扩展实现，因为这两种软件栈在实际应用中占有较大比重。

(4)面向分布式调度系统的评测指标设计。除了保留现有基准测试系统中的评测指标外，还设计了针对分布式调度系统的评测指标，主要包括每秒钟容器分配个数和任务资源分配延迟，这两个指标直接与分布式调度系统相关，能够更好的体现分布式调度系统的性能。

(5)基于真实trace数据的负载提交策略设计。基于阿里云公布的生产集群的trace数据，对trace数据进行多维度的分析和建模，特别对负载提交策略进行建模，包括并发度和负载提交时间。在实际负载加载时通过建好的模型进行负载提交，以最大程度还原真实生产集群任务提交情况，提供一种可横向对比的、公平的提交方式。

(6)完善的指标收集和监控模块。基于ELK系统栈，实现了指标收集和监控模块，对于系统的性能指标直接监控计算节点得到，对于一些任务层指标通过解析日志文件数据得到，相关指标可以实时的以图像化的方式进行展示。

(7)全链路的基准测试系统。本发明奖基准测试过程中的所有模块汇集在一起，在进行测试时只需要配置一些必要参数，系统就可以进行自动化测试，并自动化收集指标信息，大大简化了测试流程和复杂度。

附图说明

图1为全链路基准测试系统架构图；

图2为全链路基准测试流程图；

图3为数据集模块的数据生成架构；

图4为负载提交策略模块基于trace数据提交的并发度；

图5为负载提交策略模块采用LSTM模型的实验图；

图6为指标监控收集模块架构图；

图7为YARN模拟器优化后架构对比图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

本发明提供了一种面向分布式调度系统的全链路基准测试系统，包括数据集模块，负载集模块，测试指标集模块，负载提交策略模块，性能指标监控收集模块，客户端；所述客户端获取配置文件中的各类配置参数，负责各个模块之间的连接与控制、任务提交以及处理分布式调度系统测试后的反馈；所述数据集模块提供负载运行时所需的测试数据，所述测试数据包括从网上爬取的的真实数据和基于数据生成工具快速生成的数据，所述测试数据生成好后加载至集群的文件系统中；所述负载集模块根据配置的负载类型进行负载集准备，负载选择完成后将相关执行包加载至集群中以备负载运行；所述测试指标集模块根据配置的测试指标进行测试指标集选择，选择好的测试指标将发送至性能指标监控收集模块；所述负载提交策略模块根据配置的负载提交方式准备提交脚本，以脚本的方式向系统中按照既定策略提交负载；所述性能指标监控收集模块实时收集各维度指标信息并发送给客户端进行前端显示。，系统整体架构如图1所示：

数据集模块主要用于提供负载运行时所需的测试数据。在本发明中，数据集包括两部分，第一部分是从网上爬取的一些具有代表性的真实数据，此部分数据集较小，对于小规模系统评测可以直接采用这些真实数据集进行；第二部分基于一些研究实现了数据生成工具，能够快速生成测试数据。

负载集模块主要提供测试时的任务。在本发明中，继承了现有基准测试系统中的负载，并针对这些负载进行Spark和MPI两种软件栈的扩展实现，以能够体现真实的应用类别。

测试指标集模块主要提供能够表征被测系统各维度性能的一些性能指标。本发明中针对分布式调度系统的测试指标主要包括两部分，一部分是间接指标，这些指标能从一定程度和角度反映分布式调度系统的性能。另一部分是直接指标，这些指标直接与分布式调度系统相关，能够直接反应分布式调度系统的性能情况，本发明中主要包括每秒分配容器数量和任务资源分配延迟两个指标。

负载提交策略模块主要决定评测时负载的加载方式。现有测试中负载提交的随意性和自由度很大，而负载提交方式对评测结果有很大影响，为了能够定义一种通用公平的提交策略。本发明基于阿里云2019年公布的最新生产集群trace数据，对trace数据中的负载提交行为进行建模分析，使用建好的模型进行负载提交。

性能指标监控收集模块主要进行相关性能指标的收集和实时监控，在评测过程中不仅要关注最终的结果还应该实时关注评测过程中评测指标的变动情况。本发明基于ELK软件栈搭建了一套性能指标监控收集模块，能够准实时的展示评测过程中各维度指标的变动情况，并对关键指标进行收集。

数据集模块输入为数据集类型、数据生成模型和规模三个参数，输出为符合要求的模拟数据集，输出数据直接加载至集群中；负载集模块输入为负载名称，输出为各个负载的执行包，输出的负载将直接加载至集群中；测试指标集模块输入为测试指标名称，输出为所需要监控的测试指标，输出的测试指标将发送给指标监控收集模块进行监控和收集；负载提交策略模块输入为负载提交策略类型参数，输出为封装好的提交脚本，输出脚本直接在集群上运行进行测试；指标监控收集模块输入为测试指标集传输过来的指标和集群中实时的物理资源指标和其他系统指标，输出为格式化之后的各维度测试指标信息。

大规模仿真测试模块主要进行大规模仿真测试。通常情况下优化后的调度系统无法在线上大规模集群中进行测试，而用于测试的小集群又不能复现线上的大规模场景，因此就需要进行大规模仿真测试。本发明主要基于Hadoop SLS仿真模块进行优化改进，以能够更加真实的反映调度系统的性能。

所有上面模块之间并不是独立运行，各个模块之间需要进行一定的交互和信息传输，因此本发明各个模块集成在一起构建了该基准测试系统，能够方便的进行自动化评测。

如图2，基准测试系统进行分布式调度系统测试流程主要包括以下步骤：

步骤1，确定测试需求。首先需要根据实际的业务场景和评测规范制定测试需求，测试需求中需要阐明评测过程中所使用的数据集、负载集、测试指标集、负载的提交策略、评测规模等信息。在本发明中评测需求可以通过配置参数的方式进行，一旦相关配置参数确定，系统就可以自动按照评测需求进行数据生成、负载加载提交、性能指标监控收集等步骤。

步骤2，生成测试数据。系统会根据配置文件中数据集部分的配置参数选择相应的数据集，如果配置参数中指明使用真实数据集，则将真实数据集加载至系统文件目录下。如果配置参数中指明使用模拟生成数据，则根据配置参数来进行相应类型和规模的数据生成。

步骤3，准备测试负载。获取测试负载部分的配置参数，包括负载名称、负载输入数据规模等。按照配置参数将负载加载至系统中，准备进行负载提交。

步骤4，确定需要监控的测试指标。不同的测试需求对监控指标的要求也不同，在评测需求中可以配置必要的监控指标，如果未配置则默认收集所有预定义的测试指标。

步骤5，根据负载提交策略提交负载。获取配置文件中负载提交策略部分的参数，根据参数选择相应的负载提交脚本进行负载提交测试。

步骤6，监控并收集性能指标。在测试过程中，实时监控各维度指标的执行情况，并收集相关性能指标，以供后续分析。

步骤7，汇总指标信息并分析。将收集到的指标进行分类整理汇总，按照评测目的进行分析，从中得出相关评测结论。

所述数据集模块进行数据采样和格式转换。数据集是评测过程的基础，任何负载都需要输入数据。在本发明中，数据集包括两部分，第一部分是从网上爬取的一些具有代表性的真实数据，选取标准上包括：数据来源真实、可靠、权威，数据本身具有真实的作用和影响，数据在一些评测中得到应用，数据规模大小适中。这些数据涵盖了结构化数据、半结构化数据和非结构化数据，其中包含约4000000篇英文维基百科词条、7000000条亚马逊电影评论影评等，数据集详细情况参见下表，考虑到网络传输开销，此部分数据集较小，对于小规模系统评测可以直接采用这些真实数据集进行。

表1真实数据集信息

第二部分基于一些研究实现了数据生成工具，能够快速生成文本类型数据、图类型数据和表类型数据，数据生成架构如下图3所示。首先从收集到的真实数据集中进行数据采样，将得到的采样数据使用基于统计学方法的LAD-C模型进行多维度建模，抽取出采样数据中的特征信息，然后基于建立好的模型进行大规模数据生成，在数据生成时为了能够最大限度提高数据生成速度，对生成过程进行了并行化实现，数据生成完成后按照负载要求进行格式转化即可供负载使用。实验表明在单机上进行数据生成时，文本数据并行化生成速度平均为50MB/S，图数据并行化生成速度平均为700000edge/S，表数据并行化生成速度平均为20MB/S。由此可见，数据可以在测试前被快速生成。此外针对某些特定领域如NLP领域，其对文本数据的要求更高，LAD-C模型能够保留一些统计特征，但是无法保证语义特征，因此采用了深度学习模型GPT-2和VAE模型对文本生成工具进行扩展，能够根据样本数据生成更加“相似”的数据。通过这种方式既保证了数据生成速度避免了庞大的爬取和网络传输开销又尽最大可能保留了真实数据集的特征保证测试的准确度。

所述负载集模块是评测过程的核心，包含批处理任务、机器学习任务、数据库操作和基于微服务的在线负载集。最终的评测指标都是通过具体的任务运行来体现的。本发明对目前大数据系统和数据中心中运行的应用进行调研，通过分析应用的具体实现技术来选取占比高、流行度广的技术来选择负载，并集成目前已有的较为成熟的基准测试系统中的负载。详细负载集信息如表2所示：

表2负载集

其中批处理任务和数据库操作类负载直接继承自现有基准测试系统，但是对其进行了Spark和MPI软件栈改写，Spark作为一种大数据处理引擎，计算过程的中间结果保存在内存中而非文件系统下，可大大提高运算速度。MPI作为一种并行编程模型，在实际应用场景下有广泛应用。随着对计算速度的更高要求，这两种软件栈在生产环境中占据越来越大的比重也发挥越来越重要的作用。对于机器学习类负载则通过调用mahout库实现，基于微服务的在线负载PiggyMetrics是一个包含13个微服务组件的在线记账类应用，可以通过docker镜像快速部署。

所述测试指标集模块是评测过程的最终展现，其中测试指标主要包括两部分，一部分是间接指标，这些指标能从一定程度和角度反映分布式调度系统的性能，例如：集群资源利用率、在线请求响应时间、离线任务完成时间、任务执行吞吐量、IPS(每秒完成指令周期数)等。另一部分是直接指标，这些指标直接与分布式调度系统相关，能够直接反应分布式调度系统的性能情况，本发明中主要有两个该类指标，其一是每秒钟分配容器个数，指每秒钟分布式调度系统能够分配的容器个数，该指标能够直接反应分布式调度系统的并发处理能力。其二是任务资源分配延迟，指任务从提交到运行过程中所等待的时间，该段时间的长短直接由分布式调度系统控制，其能够直接反应调度过程的逻辑复杂度和并发处理能力。这两个部分的指标相互补充，间接指标可以从侧面反映出分布式调度的资源分配和任务调度质量，直接指标可以反映出分布式调度系统的并发处理能力。

所述负载提交策略是评测过程的关键环节，负载提交模式对评测具有较大影响，不同的负载提交模式可能会导致不同的结果。在本基准测试系统设计和实现中涵盖了不同类型的负载提交模式，本发明包含以下多种提交模式。

(1)固定时间间隔提交方式，用户设置每次提交任务的并发量和提交时间间隔，在一段时间内任务按照预先配置的参数进行任务提交。在任务提交脚本中会根据配置的并发量和提交时间间隔来设计任务提交逻辑，每间隔固定时间就提交一批任务。该种提交方式是最基础的提交方式，其中任务的并发量和提交时间间隔由用户确定。

(2)累次提交模式，用户选定好负载后设置提交时间间隔，每间隔一定时间就提交相应任务，待任务失败率达到一定阈值后停止提交任务并观测这个时间段内系统各项指标。该种提交方式主要解决不同规模集群如何确定负载提交量的问题，为了评测分布式调度系统，不同规模集群在进行具体评测时所提交的任务量应不同。通过这种方式只需要确定好统一的任务失败率阈值，而无需关注集群规模大小。

(3)基于trace数据提交。前两种提交方式中都需要人为确定一些参数如：负载提交时间间隔、并发量、任务失败阈值等，这些参数往往是经验数据，在进行横向对比时无法保证公平性。在提交模式中有两个关键点，一是在什么时间提交，二是每次提交时的并发度为多少。本发明中主要通过对阿里巴巴2017年和2018年公开的生产集群trace数据进行这两个参数的建模构建。对于任务提交时间，任务提交过程本身是一个随机过程，通过对阿里巴巴2017年trace数据中任务提交时间的过滤和方差分析后得出任务提交时间服从λ＝1420(平均每分钟任务提交数量)的泊松分布，在进行具体测试可以按照λ＝(1420*集群计算节点规模)/3170(注：3170为trace数据中集群计算节点规模)的泊松分布来确定任务提交时间。对于任务提交并发度，图4所示为每次提交的并发度，可以明显的看出并发度在以天为周期的时间序列上具有很强的周期性特征。因此采用多种时序预测方法以2018年trace数据中6天数据作为训练集，1天数据作为验证集进行时序数据预测，并以均方根误差(MSE)的大小作为方法选择标准。其中选择的方法包括：移动平均数法、指数平滑法、Holt线性趋势法、综合自回归移动平均法(ARIMA)、RNN和LSTM。通过多轮实验测试和验证，上面各种方法所对应的均方根误差分别为：移动平均法(0.1157)、指数平滑法(0.1043)、Holt线性趋势法(0.0876)、综合自回归移动平均法(0.0341)、RNN(0.0102)、LSTM(0.0086)，从上面结果可以看出使用LSTM模型生成的数据与验证集差别很小。因为LSTM模型中不仅仅保留了原始数据的统计特征，同时还考虑到数据的时序特征，因此可以使用此训练好的模型来生成并发序列进行任务提交，图5所示为并发度LSTM模型预测结果图。从图中可以看出，训练好的模型采集了并发度的时序特征，能够很好的进行数据预测生成，具有较高的准确率。在进行具体任务提交时，先用此建好的LSTM模型进行并发度数据生成，然后结合实际的集群规模来确定最终的并发度序列，在测试时综合负载提交时间和并发度两个维度指标进行负载提交。

所述性能指标监控收集模块基于ELK软件栈进行指标监控收集模块的构建，指标监控收集模块架构图的架构图如图6所示，一共包含5个组件，其中Kibana是一个前端展示组件，其能够通过检索数据库中的数据以准实时的方式将检索到的数据以图形化的方式展示出来；Elasticsearch是一个高效的文件类型数据库，其能够提供文件类型数据的存储和高效检索；Logstash是一个轻量级的文件过滤和缓存组件，其能够按照一定规则对文件进行过滤和格式转换；metricbeat是一个用于收集计算节点上各维度物理资源信息的监控组件；filebeat是一个用于收集计算节点上文件的文件收集组件。监控的指标主要分为两类，一类是物理资源使用指标，该类指标可以直接通过metricbeat进行监控收集，另外一类是性能指标，该类指标往往通过解析日志文件的方式获取。在本发明中在每个计算节点都部署metricbeat和filebeat组件，使用metricbeat组件进行物理资源使用指标监控收集，使用filebeat进行日志文件收集。

监控收集过程主要包含下面几个步骤：

步骤1，在计算节点上部署并启动metricbeat和filebeat组件；

步骤2，上面两个组件会定时收集相关指标，metricbeat收集到的物理资源使用指标直接发送给Elasticsearch进行存储，filebeat收集到的日志文件则发送至logstash组件进行过滤处理，处理后发送至Elasticsearch进行存储；

步骤3，Kibana从Elasticsearch中检索所需要的数据进行前端展示，检索到的数据可以导出以供更深度分析。

YARN作为资源管理与任务调度系统的典范，在学术界被深入的研究并在工业界得到了广泛应用，很多大型互联网公司都使用YARN作为其公司内部的集群管理系统。为了适应不同的业务场景与性能要求，常常需要对原生YARN系统中的某些模块进行性能优化，通常这些优化不能直接应用到线上环境进行测试，需要先在线下环境进行测试，但是很多公司并没有线上规模的线下测试设备，这就需要通过一些方法来进行模拟测试以验证性能优化的可行性。Apache社区在YARN出现的同时就提供了一个开源模拟工具Scheduler LoadSimulater(SLS)以便进行模拟测试，同时也能够解决测试不能规模化扩展的问题。

主要做的改进包括：(1)将调度层单独抽离出来以避免调度层和模拟线程之间的干扰；(2)用真实的ResourceManager来替换原有对调度的封装部分，这样对于一些内部的细粒度指标可以通过log的方式进行输出并分析；(3)任务和节点仍然通过线程方式进行模拟，通过RPC调用与ResourceManager建立联系；

当对ResourceManager中的模块进行性能优化后可以直接使用模拟器进行性能测试，同时在测试阶段也可以在ResourceManager中加入一些细粒度指标监控代码以对调度器性能进行全面评估。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (8)

1.一种面向分布式调度系统的全链路基准测试系统，其特征在于，包括数据集模块，负载集模块，测试指标集模块，负载提交策略模块，性能指标监控收集模块，客户端；所述客户端获取配置文件中的各类配置参数，负责各个模块之间的连接与控制、任务提交以及处理分布式调度系统测试后的反馈；所述数据集模块提供负载运行时所需的测试数据，所述测试数据包括从网上爬取的的真实数据和基于数据生成工具快速生成的数据，所述测试数据生成好后加载至集群的文件系统中；所述负载集模块根据配置的负载类型进行负载集准备，负载选择完成后将相关执行包加载至集群中以备负载运行；所述测试指标集模块根据配置的测试指标进行测试指标集选择，选择好的测试指标将发送至性能指标监控收集模块；所述负载提交策略模块根据配置的负载提交方式准备提交脚本，以脚本的方式向系统中按照既定策略提交负载；所述性能指标监控收集模块实时收集各维度指标信息并发送给客户端进行前端显示。

2.如权利要求1所述的系统，其特征在于，所述数据集模块基于数据生成工具快速生成的测试数据的方式为首先从收集到的真实数据集中进行数据采样，将得到的采样数据使用基于统计学方法的LAD-C模型进行多维度建模，抽取出采样数据中的特征信息，然后基于建立好的模型进行大规模数据生成，对生成过程进行并行化实现，数据生成完成后按照负载要求进行格式转化。

3.如权利要求2所述的系统，其特征在于，所述测试指标集模块提供表征被测系统各维度性能的性能指标包括间接指标和直接指标，所述间接指标包括集群资源利用率、在线请求响应时间、离线任务完成时间、任务执行吞吐量、IPS；所述直接指标包括每秒钟分配容器个数，任务资源分配延迟。

4.如权利要求3所述的系统，其特征在于，所述负载提交策略模块主要决定评测时负载的加载方式为基于trace数据提交，所述基于trace数据提交的具体方式为通过对trace数据中任务提交时间的过滤分析后得出任务提交时间服从泊松分布，然后按照所述泊松分布提交任务。

5.如权利要求4所述的系统，其特征在于，所述性能指标监控收集模块对指标的监控包括是物理资源使用指标和性能指标的监控，对所述物理资源使用指标的监控直接通过用于收集计算节点上各维度物理资源信息的监控组件进行收集，对所述性能指标的监控通过解析日志文件的方式获取。

6.如权利要求5所述的系统，其特征在于，性能指标监控收集过程主要包含下面几个步骤：

步骤1，在计算节点上部署并启动用于收集计算节点上各维度物理资源信息的监控组件和用于收集计算节点上文件的文件收集组件；

步骤2，上面两个组件会定时收集相关指标，所述用于收集计算节点上各维度物理资源信息的监控组件收集到的物理资源使用指标直接发送给文件类型数据库进行存储，所述收集计算节点上文件的文件收集组件收集到的日志文件则发送至轻量级的文件过滤和缓存组件进行过滤处理，处理后发送至文件类型数据库进行存储。

步骤3，前端展示组件从文件类型数据库中检索所需要的数据进行前端展示，检索到的数据可以导出以供更深度分析。

7.如权利要求6所述的系统，其特征在于，对面向分布式调度系统的全链路基准测试系统进行测试的模拟器中将调度层单独抽离出来以避免调度层和模拟线程之间的干扰，并且用真实的资源来替换原有对调度的封装部分，任务和节点仍然通过线程方式进行模拟，通过RPC调用与资源管理器建立联系。

8.一种面向分布式调度系统的全链路基准测试方法，其特征在于，包括以下步骤：步骤1，客户端确定测试需求，所述测试需求包括数据集、负载集、测试指标集、负载的提交策略、评测规模；步骤2，生成测试数据，根据配置文件中数据集部分的配置参数选择相应的数据集，如果配置参数中指明使用真实数据集，则将真实数据集加载至系统文件目录下。如果配置参数中指明使用模拟生成数据，则根据配置参数来进行相应类型和规模的数据生成；步骤3，获取测试负载部分的配置参数，包括负载名称、负载输入数据规模等，按照配置参数将负载加载至系统中，准备进行负载提交；步骤4，确定需要监控的测试指标，在评测需求中配置必要的监控指标，如果未配置则默认收集所有预定义的测试指标；步骤5，获取配置文件中负载提交策略部分的参数，根据参数选择相应的负载提交脚本进行负载提交测试；步骤6，实时监控各维度指标的执行情况，并收集相关性能指标；步骤7，将收集到的指标进行分类整理汇总，按照评测目的进行分析，从中得出相关评测结论。

Images