估计工作资源需求对于企业集群仍然是一个重要且具有挑战性的问题。工作负载的复杂性不断增加,从传统的批处理作业到交互式查询,再到流式传输,再到最近的机器学习作业,这种情况被放大。这导致作业依赖于多个计算框架(例如Tez,MapReduce,Spark等),并且由于共享群集的性质而使问题进一步复杂化。当前的最新解决方案依靠用户的专业知识来估计作业的资源需求(例如:reduceor的数量或容器内存大小等),这既繁琐又效率低下。
根据对集群工作负载的分析,我们观察到很大一部分工作(超过60%)是循环性工作,这使我们有机会根据工作的历史记录自动估算工作资源需求。值得注意的是,作业通常来自不同的计算框架,并且版本可能会在运行之间发生变化。因此,我们想提出一个与框架无关的黑匣子解决方案,以自动进行重复作业的资源需求估算。
下图说明了资源估计器的实现体系结构。
Hadoop-resourceestimator主要由三个模块组成:转换器,SkylineStore和Estimator。
当前,Hadoop资源估计器为SkylineStore提供内存中的实现。
本节将指导您使用资源估计器服务。
这里让$ HADOOP_ROOT代表Hadoop安装目录。如果您自己构建Hadoop,则$ HADOOP_ROOT是hadoop-dist / target / hadoop- $ VERSION。资源估计器服务$ ResourceEstimatorServiceHome的位置是$ HADOOP_ROOT / share / hadoop / tools / resourceestimator。它包含3个文件夹:bin,conf和data。请注意,用户可以使用默认配置的资源估算器服务。
bin包含资源估计器服务的运行脚本。
conf:包含资源估计器服务的配置文件。
数据包含用于运行资源估计器服务示例的示例日志。
首先,将配置文件(位于$ ResourceEstimatorServiceHome / conf /中)复制到$ HADOOP_ROOT / etc / hadoop。
启动估算器的脚本是start-estimator.sh。
$ cd $ ResourceEstimatorServiceHome $ bin / start-estimator.sh
Web服务器已启动,用户可以通过REST API使用资源估计服务。
资源估计器服务的URI为http://0.0.0.0,默认服务端口为9998(在$ ResourceEstimatorServiceHome / conf / resourceestimator-config.xml中配置)。在$ ResourceEstimatorServiceHome / data中,有一个示例日志文件resourceEstimatorService.txt,其中包含两次运行的tpch_q12查询作业的日志。
发送POST http://0.0.0.0:9998/resourceestimator/translator/data/resourceEstimatorService.txt。基础估算器将从日志文件中提取ResourceSkylines,并将其存储在jobHistory SkylineStore中。
发送GET http://0.0.0.0:9998/resourceestimator/skylinestore/history/*/*,基础的估算器将返回历史SkylineStore中的所有记录。您应该能够看到两次运行tpch_q12的ResourceSkylines:tpch_q12_0和tpch_q12_1。请注意,pipelineId和runId字段均支持通配符操作。
发送http://0.0.0.0:9998/resourceestimator/estimator/tpch_q12,基础估计器将根据其历史资源SkySky预测新运行的作业资源需求,并将预测的资源需求存储到jobEstimation SkylineStore。
发送http://0.0.0.0:9998/resourceestimator/skylinestore/estimation/tpch_q12,基础估计器将返回tpch_q12作业的历史资源需求估计。请注意,对于jobEstimation SkylineStore,它不支持通配符操作。
发送http://0.0.0.0:9998/resourceestimator/skylinestore/history/tpch_q12/tpch_q12_0,基础估算器将删除tpch_q12_0的ResourceSkyline记录。重新发送GET http://0.0.0.0:9998/resourceestimator/skylinestore/history/*/*,基础估算器将仅返回tpch_q12_1的ResourceSkyline。
在这里,我们提供一个使用资源估计器服务的示例。
首先,我们将tpch_q12作业运行9次,并在每次运行中收集作业的资源状况(请注意,在此示例中,我们仅收集“已分配容器的数量”信息)。
然后,我们在Resource Estimator Service中运行日志解析器,以从日志中提取ResourceSkylines,并将其存储在SkylineStore中。下面绘制了作业的ResourceSkylines,以进行演示。
最后,我们在Resource Estimator Service中运行估算器以预测新运行的资源需求,该需求封装在RLESparseResourceAllocation(https://github.com/apache/hadoop/blob/b6e7d1369690eaf50ce9ea7968f91a72ecb74de0/hadoop-yarn-project/hadoop- yarn / hadoop-yarn-server / hadoop-yarn-server-resourcemanager / src / main / java / org / apache / hadoop / yarn / server / resourcemanager / reservation / RLESparseResourceAllocation.java)。预测的资源需求在下面绘制以进行演示。
本节将指导您完成资源估计器服务的配置。配置文件位于$ ResourceEstimatorServiceHome / conf / resourceestimator-config.xml。
资源估算器具有集成的线性规划求解器以进行预测(有关更多详细信息,请参阅https://www.microsoft.com/zh-cn/research/wp-content/uploads/2016/10/osdi16-final107.pdf),并且此参数调整了线性规划模型中资源过度分配和分配不足之间的权衡。此参数从0到1变化,并且较大的alpha值意味着模型可以更好地最小化过度分配。默认值为0.1。
此参数控制线性规划模型的一般化。此参数的范围是0到1。默认值为0.1。
进行预测所需的最少作业数量。预设值为2。
用于将作业执行离散化为间隔的时间长度。注意,估计器针对每个间隔进行资源分配预测。较小的时间间隔可提供更细粒度的预测,但也需要更长的时间和更多的预测空间。默认值为5(秒)。
天际线存储提供程序的类名称。默认值为org.apache.hadoop.resourceestimator.skylinestore.impl.InMemoryStore,它是skylinestore的内存实现。如果用户要使用自己的skylinestore实现,则需要相应地更改此值。
翻译提供者的类名。默认值为org.apache.hadoop.resourceestimator.translator.impl.BaseLogParser,它从日志流中提取资源行。如果用户要使用自己的转换器实现,则需要相应地更改此值。
转换器单行解析器的类名称,它解析日志中的单行。默认值为org.apache.hadoop.resourceestimator.translator.impl.NativeSingleLineParser,它可以解析示例日志中的一行。请注意,如果用户想解析Hadoop资源管理器(https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html)日志,则需要将值设置为org .apache.hadoop.resourceestimator.translator.impl.RmSingleLineParser。如果他们想实现单行解析器来解析其自定义日志文件,则需要相应地更改此值。
求解程序提供程序的类名。默认值为org.apache.hadoop.resourceestimator.solver.impl.LpSolver,该模型结合了线性编程模型来进行预测。如果用户要实现自己的模型,则需要相应地更改此值。
ResourceEstimatorService侦听的端口。默认值为9998。
对于SkylineStore,我们计划提供一个持久存储实现。我们正在考虑使用HBase来证明我们的规模需求。
对于Translator模块,我们希望将Timeline Service v2作为主要来源,因为我们希望依赖稳定的API,并且日志充其量是不稳定的。
由于偏斜,争用,输入数据或代码更改等,作业资源需求在各个运行中可能会有所不同。我们要设计一个Reprovisioner模块,该模块可在运行时动态监视作业进度,并在进度慢于预期时识别性能瓶颈,以及使用ReservationUpdateRequest相应地动态调整作业的资源分配。
当Estimator预测工作的资源需求时,我们要根据估计误差(过度分配和分配不足的组合)等提供与预测相关的置信度。
对于Estimator模块,我们可以集成机器学习工具(例如强化学习)以做出更好的预测。我们还可以与特定领域的求解器(例如PerfOrator)集成,以提高预测质量。
对于Estimator模块,我们要设计增量求解器,它只能基于新日志来增量更新作业的资源需求。