抢先的dataproc工作者

Question

我在dataproc文档中看到，不应将可抢占的工作程序用于存储。这就是为什么它们的启动盘尺寸较小的原因？我是否应该保证永久性工作者在处理过程中有足够的存储空间来存储我的数据？任何有关如何最好地使用抢占式工人的详细指导将不胜感激。

Answer 1

这是一个很好的参考：https : //cloud.google.com/dataproc/docs/concepts/compute/preemptible-vms。还可以考虑在此处阅读有关可抢先VM的更多信息：https : //cloud.google.com/compute/docs/instances/preemptible

1）可抢占式VM 不用于HDFS存储。可抢占式VM每24小时（通常同时几个小时）被抢占，并且不保证会回来。如果HDFS块保留在PVM上，则很可能您的数据将不可用。

话虽如此，如果您使用GCS进行存储，则无需担心群集上的HDFS。

2）是的，这就是默认情况下PVM引导盘较小的原因。如文档所述，您可以覆盖默认值并将其增大。永久磁盘的性能随大小而定（我承认这很令人困惑），因此，如果您正在运行大量随机播放的作业（如SQL类型的查询），则可能需要增加它。如果您正在运行CPU密集型作业（例如机器学习），则可能没什么大不了的。您只需要考虑磁盘大小，即可查看适合您的磁盘。

3）是的，您应该保证主要工作者有足够的空间来存储所有HDFS数据。

4）我将与我们的PM / docs作家联系，为PVM添加更好的指导。据我所知，一个很好的经验法则是确保您的群集中的PVM不超过50％。

如果在作业运行时抢占了PVM，则作业进度将被推迟。正在进行的任务不仅会失败，而且完成任务中的混洗数据也会丢失。同样，您将不得不尝试看看哪种方法对您有效。

由于使用抢占式VM时任务可能会失败，因此您可能需要增加任务重试次数和应用程序主重试次数。

纱：

• yarn.resourcemanager.am.max-attempts（默认为2）

Mapreduce：

• mapreduce.map.maxattempts（默认为4）
• mapreduce.reduce.maxattempts（默认为4）

火花：

• spark.task.maxFailures（默认4）
• spark.stage.maxConsecutiveAttempts（默认4）

您可以在使用--properties创建集群时设置以下属性：https ://cloud.google.com/dataproc/docs/concepts/configuring-clusters/cluster-properties 。