Parallel processing 改进多节点群集上的h2o DRF运行时

我目前正在运行

h2o

的DRF算法，它是一个3节点EC2集群（h2o服务器跨越所有3个节点）。 我的数据集有1m行和41列（40个预测值和1个响应）

我使用

R

绑定来控制集群，RF调用如下

model=h2o.randomForest(x=x,
                       y=y,
                       ignore_const_cols=TRUE,
                       training_frame=train_data,
                       seed=1234,
                       mtries=7,
                       ntrees=2000,
                       max_depth=15,
                       min_rows=50,
                       stopping_rounds=3,
                       stopping_metric="MSE",
                       stopping_tolerance=2e-5)

对于3节点群集（c4.8XL，增强型网络已打开），这大约需要240秒；CPU利用率在10-20%之间；RAM利用率在20-30%之间；网络传输速度在10-50字节/秒之间（输入和输出）。300棵树一直建到提前停车

在单节点集群上，我可以在大约80秒内得到相同的结果。因此，我得到的不是预期的3倍速度，而是3节点集群的3倍速度

我做了一些研究，发现一些资源报告了相同的问题（虽然没有我的极端）。例如，见：

具体而言，本书作者指出

虽然不是本研究的重点，但有迹象表明 多个服务器上的分布式随机林实现（如H2O） 节点不能提供人们希望的速度优势（因为 在过去一年中，每次拆分时运输直方图的成本很高 网络）

还指出了两种不同的DRF实现，其中一种具有更大的网络开销

我想我遇到了与上面链接中描述的相同的问题。 如何在多节点群集上提高

h2o

的DRF性能？ 是否有任何设置可以提高运行时间？

---

非常感谢您的帮助

如果您的随机林在多节点H2O集群上速度较慢，这只意味着您的数据集不够大，无法利用分布式计算。集群节点之间的通信存在开销，因此如果您能够在单个节点上成功地训练您的模型，那么使用单个节点将总是更快

多节点是为数据太大而无法在单个节点上训练而设计的。只有这样，才值得使用多个节点。否则，您只是无缘无故地增加了通信开销，并将看到您观察到的减速类型

---

如果您的数据适合在一台机器上存储（并且您可以成功地训练一台内存不足的w/o型号），加快训练速度的方法是切换到具有更多内核的机器。您还可以使用影响训练速度的某些参数值来查看是否可以提高速度，但这通常会以模型性能为代价。

正如Erin所说，通常添加更多节点只会增加更大数据集的能力，而不是更快的学习。随机森林可能是最糟糕的；我通过深度学习获得了相当好的效果（例如，4个节点快3倍，8个节点快5-6倍）

---

在你对Erin回答的评论中，你提到了真正的问题是你想加速超参数优化？令人沮丧的是，

h2o.grid（）

不支持并行构建模型，在每个节点上构建一个模型，而此时数据将适合每个节点上的内存。但你可以自己做，只需编写一点脚本：在每个节点上设置一个h2o集群，在每个节点上使用超参数子集进行网格搜索，让他们将结果和模型保存到S3，然后将结果引入并在最后合并。（如果进行随机网格搜索，您可以在每个集群上运行完全相同的网格，但最好在每个集群上显式使用不同的种子。）

感谢您的帮助。我假设其他机器学习技术（例如GBM，模型大小通常较小）不会遇到这个问题。遗憾的是，DRF无法加速，因为在我的例子中，单节点模型训练可能需要45分钟，这取决于问题的大小和DRF超参数。这使得顺序超参数优化变得棘手。。。无论如何，我将尝试在一台x1.32xlarge机器上运行我的代码，看看它的性能如何。据我所见，内存带宽似乎是DRF的瓶颈，这些实例提供了高内存带宽（据推测）。GBM将需要类似数量的内存——通常在RF中训练的树比GBM少，但在RF中训练的树更深。GBM的性能通常比RF好，因此您可能希望尝试这两种方法，以了解什么最适合您的数据。Erin，还有一个问题：难道不可能独立地种植森林中的各个树木吗？考虑到提前停止会关闭，那么就不应该有中间通信开销。非常像我在问题中链接的Michal Malohlava的RF brighttalk幻灯片中提出的RF训练算法1。我的猜测是，出于“大数据”的原因，h2o选择了另一个实现（这取决于直方图的中间交换）。h2o是否有计划在第2个算法（见幻灯片）的基础上实现第1个算法？是的，这是可能的，但它需要每个独立的过程将整个训练集保存在内存中，所以这是一个很大的缺点。我们过去在H2O-2中有两个版本（“DRF”和“SpeeDRF”），但后者无法扩展到大数据。我们有可能重新推出fast/smalldata版本，但目前还不在路线图上。感谢您的确认。顺便说一句：现在有了大内存云实例（AWS x1.32xlarge为2TB）和贝叶斯超参数优化变得越来越流行，我猜用户对“小数据”版本的需求将会增加。Darren，非常感谢您的输入。您所描述的（每个节点上有一个单独的h2o集群）对于随机搜索和网格搜索非常有效。实际上，我已经在网格/随机搜索中使用了这样的解决方案。然而，如果要进行贝叶斯超参数优化（基本上是按顺序进行的），最好让多个节点在一个参数配置上工作。顺便说一句：我有你的书；）您的多节点网格/随机se