google-cloud-dataproc - 为什么不推荐持久性 Dataproc 集群？

Question

我正在考虑运行一个托管 Hive 服务器的持久性 GCP Dataproc 集群，该集群将提供 HiveQL 接口(interface)，用于查询和更新存储在 Google Cloud Storage 中的长期数据，可通过 Cloud Storage connector 访问。 .

我正在阅读以下文档:https://cloud.google.com/architecture/hadoop/hadoop-gcp-migration-overview#moving_to_an_ephemeral_model

列出了临时集群的优点，但也提出了以下警告:

If you can't accomplish your work without a persistent cluster, youcan create one. This option may be costly and isn't recommended ifthere is a way to get your job done on ephemeral clusters.

除了无法享受临时 Dataproc 集群所列出的优点之外，运行持久性 Dataproc 集群是否还有其他缺点/陷阱？

我维护持久集群的主要动机是避免重新创建集群的任何管理开销。集群需要能够无限期地为 Hive 客户端提供服务；没有自然的集群结束日期。

编辑:需要明确的是，我担心长时间运行的持久集群可能会随着时间的推移积累故障，类似于内存泄漏。

Answer 1

当您拥有持久集群时，会发生两件事:

• 首先，您将尝试在其上运行尽可能多的进程以优化使用。

  如果您位于物理 hadoop/spark 集群上，这是一个好主意，因为硬件成本高昂，但您将结束解析日志以找出哪个部门或用例实际上正在使用您的所有资源集群容量。

• 其次，您的集群将闲置一段时间，并且您将为在需要运行作业之前不执行任何操作的机器付费。

  由于您位于云中，因此您可以仅为需要运行的作业创建一个 dataproc 集群，并在作业完成时废弃它(仅将结果存储在云存储中)。

如果您在自己的项目中运行该集群(和作业)，您将能够轻松识别每个中心/部门等的成本，而无需解析日志文件。

当然，当没有计算可做时，您只需关闭机器即可节省资金。

在不需要的时候关闭东西使得云具有成本效益。

如果您只需要进行临时(一次性)查询，则可以让 BigQuery 直接从云存储中检索数据。请记住，BQ 不会缓存针对存储的查询 -> 不要使用该查询来提供仪表板应用程序。

通常，使用 bigquery 进行数据访问/报告比使用 24x7 运行的 dataproc 集群更便宜(也更快)...除非您整天有很多工作，并且它们之间的“空闲”时间非常少...或者您无法修改查询 Hive 的应用程序。