Dataproc似乎被设计为无状态/不可变。这个假设是否正确？如果我们计划部署Hive / Presto数据仓库，我们现在应该立即退出吗？
我们正在努力寻找一些文档来说明一旦配置了群集应该如何关注群集？
FAQs“我可以运行持久群集吗？”也没有真正解决这个问题。
互联网 建议如果我们遇到问题，我们应该创建一个新的集群。作为开发人员，我对“最小化状态”这个论点非常满意，但我在企业界工作，喜欢Hive（及其元数据存储），Hue和Zeppellin等解决方案，并希望将Tableau等外部工具连接到集群中。 / p>
文档应该真正明确哪些用例数据空间优于（批量，按需和短期工作负载）与其实际未设计的事物（例如OLAP）？
答案 0 :(得分：3)
Dataproc确实为按需用例提供了最大的好处，但这并不一定与用于OLAP的情况不一致。主要思想是有状态组件都可以与“处理”资源分开，以便您可以根据不同时间点的需求更好地调整资源。
Hive元数据的推荐架构是将Hive Metastore后端保留在群集之外，例如：在CloudSQL实例中;许多人能够以这种方式使用Dataproc与短期或半短期集群（例如，保留一组实时集群，但删除/重新创建每天或每周最旧的集群）以及将Hiveserver指向CloudSQL的初始化操作： https://github.com/GoogleCloudPlatform/dataproc-initialization-actions/tree/master/cloud-sql-proxy
在这个世界上，有状态的Metastore片段都在CloudSQL中，而大量存储都在GCS中。出于性能原因，某些群集可能会从GCS同步到本地HDFS（特别是如果在本地SSD上运行HDFS），但即使对于交互式OLAP用例，通常也不需要这样做;直接针对GCS运行查询也可以正常工作。不可否认的是，由于GCS的往返延迟较长，旧格式存在一些性能缺陷，但是一些调整可以使其大部分在线;这是一个（非谷歌拥有的）blog post about Presto on Dataproc超过其中一些。
这也为处理传统集群管理提供了更简单的方法;升级只是交换整个集群，应该在初始化操作中完成其他工具，以便在新集群上轻松再现，并且您可以更轻松地按群集粒度定义安全边界。