Apache Spark Gradient Boosted Tree 训练运行时性能缓慢

Posted 2023-03-23

【中文标题】Apache Spark Gradient Boosted Tree 训练运行时性能缓慢

【英文标题】：Slow Performance with Apache Spark Gradient Boosted Tree training runs

【发布时间】：2015-12-18 14:41:58

【问题描述】：

我正在尝试使用 Spark 1.4 的 ML 库中的 Gradient Boosted Trees 学习算法。我正在解决一个二进制分类问题，其中我的输入是 ~50,000 个样本和 ~500,000 个特征。我的目标是以人类可读的格式输出生成的 GBT 合奏的定义。到目前为止，我的经验是，对于我的问题规模，向集群添加更多资源似乎对运行时间没有影响。 10 次迭代的训练运行似乎大约需要 13 小时。这是不可接受的，因为我希望进行 100-300 次迭代运行，而且执行时间似乎随着迭代次数的增加而爆炸式增长。

我的 Spark 应用程序

这不是确切的代码，但可以简化为：

SparkConf sc = new SparkConf().setAppName("GBT Trainer")
            // unlimited max result size for intermediate Map-Reduce ops.
            // Having no limit is probably bad, but I've not had time to find
            // a tighter upper bound and the default value wasn't sufficient.
            .set("spark.driver.maxResultSize", "0");
JavaSparkContext jsc = new JavaSparkContext(sc)

// The input file is encoded in plain-text LIBSVM format ~59GB in size
<LabeledPoint> data = MLUtils.loadLibSVMFile(jsc.sc(), "s3://somebucket/somekey/plaintext_libsvm_file").toJavaRDD();

BoostingStrategy boostingStrategy = BoostingStrategy.defaultParams("Classification");
boostingStrategy.setNumIterations(10);
boostingStrategy.getTreeStrategy().setNumClasses(2);
boostingStrategy.getTreeStrategy().setMaxDepth(1);
Map<Integer, Integer> categoricalFeaturesInfo = new HashMap<Integer, Integer>();
boostingStrategy.treeStrategy().setCategoricalFeaturesInfo(categoricalFeaturesInfo);

GradientBoostedTreesModel model = GradientBoostedTrees.train(data, boostingStrategy);

// Somewhat-convoluted code below reads in Parquete-formatted output
// of the GBT model and writes it back out as json.
// There might be cleaner ways of achieving the same, but since output
// size is only a few KB I feel little guilt leaving it as is.

// serialize and output the GBT classifier model the only way that the library allows
String outputPath = "s3://somebucket/somekeyprefex";
model.save(jsc.sc(), outputPath + "/parquet");
// read in the parquet-formatted classifier output as a generic DataFrame object
SQLContext sqlContext = new SQLContext(jsc);
DataFrame outputDataFrame = sqlContext.read().parquet(outputPath + "/parquet"));    
// output DataFrame-formatted classifier model as json           
outputDataFrame.write().format("json").save(outputPath + "/json");

问题

我的 Spark 应用程序（或 GBT 学习算法本身）在这种大小的输入上的性能瓶颈是什么？如何实现更高的执行并行度？

我仍然是 Spark 开发新手，如果有任何关于集群配置和执行分析的提示，我将不胜感激。

有关集群设置的更多详细信息

我在 r3.8xlarge 实例（32 个内核，每个 244GB RAM）的 AWS EMR 集群（emr-4.0.0，YARN 集群模式）上运行此应用程序。我使用如此大的实例是为了最大限度地提高资源分配的灵活性。到目前为止，我已经尝试使用 1-3 个 r3.8xlarge 实例以及驱动程序和工作程序之间的各种资源分配方案。例如，对于 1 个 r3.8xlarge 实例的集群，我按如下方式提交应用程序：

aws emr add-steps --cluster-id $1 --steps Name=$2,\
Jar=s3://us-east-1.elasticmapreduce/libs/script-runner/script-runner.jar,\
Args=[/usr/lib/spark/bin/spark-submit,--verbose,\
--deploy-mode,cluster,--master,yarn,\
--driver-memory,60G,\
--executor-memory,30G,\
--executor-cores,5,\
--num-executors,6,\
--class,GbtTrainer,\
"s3://somebucket/somekey/spark.jar"],\
ActionOnFailure=CONTINUE

对于 3 个 r3.8xlarge 实例的集群，我调整了资源分配：

--driver-memory,80G,\
--executor-memory,35G,\
--executor-cores,5,\
--num-executors,18,\

我不清楚给每个执行者多少内存是有用的，但我觉得无论哪种情况我都很慷慨。查看 Spark UI，我没有看到输入大小超过几 GB 的任务。在为驱动程序进程提供这么多内存时，我会谨慎行事，以确保它不会因任何中间结果聚合操作而缺乏内存。

根据Cloudera's How To Tune Your Spark Jobs series 中的建议，我正在尝试将每个执行程序的核心数量保持在 5 个以下（根据他们的说法，超过 5 个核心往往会引入 HDFS IO 瓶颈）。我还要确保主机操作系统和 Hadoop 服务有足够的备用 RAM 和 CPU。

到目前为止我的发现

我唯一的线索是 Spark UI 在执行的尾端显示许多任务的非常长的调度延迟。我还觉得 Spark UI 显示的阶段/任务时间线并没有考虑到完成工作所需的所有时间。我怀疑驱动程序应用程序在每次训练迭代结束时或在整个训练运行结束时都卡在执行某种冗长的操作。

我已经对 Spark 应用程序的调优进行了大量研究。大多数文章都会就使用 RDD 操作提供很好的建议，这些操作可以减少中间输入大小或避免阶段之间的数据混洗。就我而言，我基本上使用的是“开箱即用”算法，它由 ML 专家编写，应该在这方面已经得到很好的调整。我自己的将 GBT 模型输出到 S3 的代码应该需要很短的时间来运行。

【问题讨论】：

您提到向集群添加更多资源（我假设执行程序和节点）不会影响运行时间。您是否看到倾斜的数据处理？并行度是否会随着执行者的增加而增加？

嗨 - 你有没有找到解决 Spark 上 GBT 性能缓慢的解决方案？

问题在 2.3.0 上仍然存在

高效GBT并非易事。这就是 ML 社区开发 LightGBM 和 XGBoost 的原因。此外，对于您的问题，从数据科学的角度来看，拥有比训练样本更多的特征并不正确。

【参考方案1】：

MLLibs GBT 实现我没用过，但是两个都用过

LightGBM 和 XGBoost 成功。我强烈建议您看看这些其他库。

一般而言，GBM 实现需要迭代训练模型，因为它们在构建下一棵树时会考虑整个集成的损失。这使得 GBM 训练固有地成为瓶颈并且不容易并行化（不像随机森林可以简单地并行化）。我希望它在任务更少的情况下表现更好，但这可能不是你的全部问题。由于您有这么多 500K 的特征，因此在训练期间计算直方图和分割点时，您将有非常高的开销。你应该减少你拥有的特征的数量，特别是因为它们比样本数量大得多，这会导致它过拟合。

关于调整集群： 您希望最大限度地减少数据移动，因此更少的执行程序拥有更多的内存。每个 ec2 实例 1 个执行器，核心数设置为实例提供的任何值。

您的数据足够小，可以放入大约 2 个该大小的 EC2。假设您使用的是双精度数（8 字节），则为 8 * 500000 * 50000 = 200 GB 尝试在数据帧上使用 .cache() 将其全部加载到内存中。如果您对所有行执行操作（如 sum），您应该强制它加载，并且您可以测量 IO 需要多长时间。一旦它进入内存并缓存了任何其他操作，它会更快。

【参考方案2】：

对于这样大小的数据集，您最好将整个数据集加载到内存中并直接使用 XGBoost 而不是 Spark 实现。

如果您想坚持使用 Spark 以提供更大的可扩展性，我建议您仔细研究一下您的分区策略。如果您的数据没有被有效地分区，那么添加机器不会改善您的运行时间，正如您上面所描述的，并且超载工作人员的子集将仍然是您的瓶颈。确保您拥有有效的分区键，并在开始训练阶段之前重新分区您的 RDD。