数据中心的可抢救工人

时间:2017-12-10 18:24:19

标签: google-cloud-platform google-cloud-dataproc

我在dataproc文档中看到,不应该使用可抢占工人进行存储。这是为什么他们的启动盘保持较小的原因?即我应该保证永久工人在处理过程中有足够的存储空间来存储数据吗?如何最好地使用可抢占工人的任何详细指导将不胜感激。

1 个答案:

答案 0 :(得分:4)

这是一个很好的参考:https://cloud.google.com/dataproc/docs/concepts/compute/preemptible-vms。另请考虑在此处阅读有关可抢占虚拟机的更多信息:https://cloud.google.com/compute/docs/instances/preemptible

1)可抢占的虚拟机用于HDFS存储。可抢占的虚拟机每24小时抢占一次(通常是几个小时),并且不保证会回来。如果HDFS块保留在PVM上,则很可能您的数据不可用。

话虽如此,如果您使用GCS进行存储,您不必担心群集上的HDFS。

2)是的,这就是默认情况下PVM启动盘较小的原因。正如文档所说,您可以覆盖默认值并使其更大。持久性磁盘性能随大小而变化(我承认这会让人感到困惑),因此如果您正在运行随机播放的作业(如SQL类型的查询),您可能需要增加它。如果你正在运行CPU绑定的工作(比如机器学习),那可能不是什么大问题。您只需要使用磁盘大小来查看适合您的内容。

3)是的,您应该保证主要工作人员有足够的空间容纳所有HDFS数据。

4)我将联系我们的PM / docs作者,为PVM添加更好的指导。从我所听到的情况来看,一个好的经验法则是确保你没有超过50%的集群成为PVM。

如果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创建群集时,可以设置这些属性。