创建许多小型Spark集群或少量非常大的集群是否更好

Question

我目前正在开发一个使用Spark来处理大量数据的应用程序。这些数据是Apache（和其他）日志文件以及csv和json文件的混合体。我的Google存储桶的目录结构如下所示：

ROOT_DIR

• web_logs
• \ input（子目录）
• \ output（子目录）
• network_logs（与web_logs相同的子目录）
• system_logs（与web_logs相同的子目录）

\ input目录下的目录结构是任意的。 Spark作业从\ input目录中获取所有数据并将其放在\ output目录中。有任意数量的* _logs目录。

我目前的计划是将整个争吵任务分成大约2000个作业，并使用云数据空间api来启动集群，完成工作并关闭。另一个选择是创建较少数量的非常大的集群，而只是将作业发送到更大的集群。

正在考虑第一种方法，因为每项工作大约需要一个小时才能完成。只需等待一份工作完成另一份工作就会花费太多时间。

我的问题是：1）除了集群启动成本之外，采取第一种方法还有什么不利之处吗？ 2）有更好的选择吗？

提前非常感谢！

Answer 1

除了启动开销之外，每个作业使用一次性群集时的另一个主要考虑因素是某些作业可能更容易出现＆＃34; stragglers＆＃34;数据偏差导致少量任务比其他任务花费更长的时间，因此在作业结束时不能有效地利用群集。在某些情况下，这可以通过明确缩减，并结合graceful decommissioning的帮助来减轻，但如果一个工作的形状使得许多＆＃34;映射＆＃34;分区在所有节点上产生shuffle输出，但有＆＃34; reduce＆＃34;落后者，那么你就无法安全地缩减仍负责提供随机数据的节点。

也就是说，在许多情况下，只需调整分区的大小/数量即可在几个波浪中进行调整＆＃34; （即如果你有100个内核正在工作，将工作分成1000到10,000个分区）有助于缓解即使存在数据偏差时的拖延问题，并且缺点与启动开销相当。

尽管启动和落后者的开销很大，但通常使用新的短暂集群每个工作的优点远远超过缺点;保持对大型共享集群的完美利用并不容易，使用短暂集群的好处包括极大地提高了灵活性和可扩展性，让您可以选择采用新的软件版本，交换机区域，交换机类型，整合全新的硬件功能（如GPU），如果他们需要，等等。这里＆＃39; sa blog post by Thumbtack discussing the benefits of such "job-scoped clusters" on Dataproc。

如果您的作业非常短（即如果每个只运行几分钟，从而放大启动开销的缺点）或者落后者问题不可解决，那么架构会略有不同，就是使用＆ ＃34;池＆＃34;集群这个blog post touches on using "labels" to easily maintain pools of larger clusters您还会定期拆除/创建群集，以确保版本更新的灵活性，采用新硬件等。

Answer 2

您可能想要探索我的Autoscaling Google Dataproc Clusters解决方案 源代码可以找到here