我正在考虑运行一个承载Hive服务器的持久GCP Dataproc集群，该集群将提供一个HiveQL接口，用于查询和更新存储在谷歌云存储中的长期数据，通过云存储连接器访问。
我正在阅读以下文档：https://cloud.google.com/architecture/hadoop/hadoop-gcp-migration-overview#moving_to_an_ephemeral_model
列出了短暂集群的优点，但也列出了以下警告：
如果没有持久集群就无法完成工作，那么可以创建一个。此选项可能成本高昂，如果有一种方法可以在短暂的集群上完成工作。
除了不享受所列的短暂Dataproc集群的优势外，运行持久性Dataproc群集还有其他缺点吗？
我维护持久集群的主要动机是避免必须重新创建集群的任何管理开销。集群需要能够无限期地为配置单元客户端提供服务；集群日期不会自然结束。
编辑：需要明确的是，我担心长时间运行的持久集群可能会随着时间的推移积累故障，类似于内存泄漏。
当您有一个持久集群时，会发生两件事：
-
首先，您将尝试在其上运行尽可能多的进程，以优化使用情况。
如果您在物理hadoop/spark集群上，这是一个好主意，因为硬件成本很高，但您将在分析日志时发现哪个部门或用例实际上使用了所有集群容量。
-
其次，您的集群将闲置一段时间，您将为那些在需要运行作业之前什么都不做的机器付费。
由于您在云中，您可以为需要运行的作业创建一个dataproc集群，并在作业完成时将其废弃(只需将结果存储在云存储中(。
如果您在自己的项目中运行该集群(和作业(，您将能够轻松确定每个中心/部门的成本等，而无需解析日志文件。
当然，当没有计算的时候，你只需关闭机器就可以省钱
在不需要的时候关闭东西是云计算具有成本效益的原因。
如果您只需要进行临时(一次性(查询，可以让BigQuery直接从云存储中检索数据。记住，BQ不会针对存储缓存查询->不要使用该查询为仪表板应用程序提供信息。
通常，使用bigquery进行数据访问/报告比让dataproc集群全天候运行更便宜(更快(……除非你一整天都有很多工作，而且它们之间几乎没有"空闲"时间。。。或者您无法修改查询配置单元的应用程序。
持久/长时间运行的Dataproc集群肯定受到支持，但它们也有自己的缺点(成本、软件升级等(。查看此文档以了解使用长期运行的Dataproc集群的最佳实践。
除了不能优化资源使用外，持久集群的主要缺点是无法更改其配置和更新运行在其上的软件。
您应该有一个自动化，定期重新创建集群，以获取新的软件修复和更新(即Dataproc映像版本(，并应用新的配置。这将允许您降低管理成本，而不是增加管理成本，因为管理一个长期运行的雪花集群比短暂的要困难得多。