此参考架构描述了通过将 Hive 数据存储在 Cloud Storage 中以及将 Hive Metastore 托管在 Cloud SQL 上的 MySQL 数据库中，高效灵活地使用 Apache Hive on Dataproc 的优势。
本文档适用于希望部署 Apache Hive on Dataproc 和 Cloud SQL 中的 Hive Metastore 的云架构师和数据工程师。
架构
下图展示了 Hive 查询的生命周期。
在该图中，Hive 查询的生命周期遵循以下步骤：
- Hive 客户端将查询提交到在临时 Dataproc 集群中运行的 Hive 服务器。
- Hive 服务器处理查询并从 Metastore 服务请求元数据。
- Metastore 服务通过 Cloud SQL 代理从 Cloud SQL 提取 Hive 元数据。
- Hive 服务器从位于 Cloud Storage 的区域级存储桶中的 Hive 仓库加载数据。
- Hive 服务器将结果返回给客户端。
设计替代方案
以下部分介绍了此架构可能的设计替代方案。
多区域架构
如果需要在不同地理区域中运行 Hive 服务器，请考虑多区域架构。在这种情况下，您应创建专用于托管 Metastore 服务并且与 Cloud SQL 实例位于同一区域的单独 Dataproc 集群。
Metastore 服务有时会向 MySQL 数据库发送大量请求，因此请务必在地理上靠近 MySQL 数据库的位置保存 Metastore 服务，以便最大限度地降低对性能的影响。 相比之下，Hive 服务器向 Metastore 服务发送的请求通常要少得多。 因此，虽然延迟时间有所增加，但 Hive 服务器和 Metastore 服务位于不同区域可能更易于接受。
Metastore 服务只能在 Dataproc 主节点上运行，不能在工作器节点上运行。Dataproc 会在标准集群和高可用性集群中强制运行至少 2 个工作器节点。
为避免在未使用的工作器节点上浪费资源，您可以为 Metastore 服务创建单节点集群。 要实现高可用性，您可以创建多个单节点集群。
由于只有 Metastore 服务集群才需要直接连接到 Cloud SQL 实例，因此只需在 Metastore 服务集群上安装 Cloud SQL 代理。然后，通过将 hive.metastore.uris 属性设置为 URI 的英文逗号分隔列表，Hive 服务器会指向 Metastore 服务集群。例如：
thrift://metastore1:9083,thrift://metastore2:9083
如果需要从位于多个位置的 Hive 服务器访问 Hive 数据，您还可以考虑使用双区域或多区域存储桶。如何在各种存储桶位置类型之间进行选择取决于您的具体用例。您必须在延迟时间、可用性和费用之间找到平衡。
下图展示了一个多区域架构示例。
您可以看到，多区域场景稍微复杂一些，但更加稳健。此参考架构的部署指南使用单区域场景。
多区域架构的优势
分离计算资源和存储资源具有一些优势：
- 灵活性和敏捷性：您可以为特定 Hive 工作负载定制集群配置，以及根据需要独立扩缩每个集群。
- 节省费用：您可以在需要运行 Hive 作业时启动临时集群，然后在作业完成时将其删除。 作业所需的资源仅在使用时才有效，因此您只需为您使用的资源付费。 您还可以使用抢占式虚拟机进行非关键数据处理，或者以较低的总费用创建大型集群。
- 弹性：为简单起见，此参考架构仅使用一个主实例。如需提高生产工作负载的弹性，应考虑使用 Dataproc 的高可用性模式创建具有三个主实例的集群。
费用优化
此参考架构和部署使用 Google Cloud 的以下收费组件：
- Dataproc
- Cloud Storage
- Cloud SQL
您可使用价格计算器根据您的预计用量来估算费用。
Google Cloud 新用户可能有资格申请免费试用。
部署
如需部署此架构，请参阅部署 Apache Hive on Dataproc。
后续步骤
- 试用 BigQuery，它是 Google 推出的可扩缩性强、费用低廉的无服务器企业数据仓库。
- 查看有关如何将 Hadoop 工作负载迁移到 Google Cloud 的指南。
- 查看此初始化操作，详细了解如何在 Dataproc 上使用 Hive HCatalog。
- 了解如何配置 Cloud SQL 以实现高可用性，从而提高服务可靠性。
- 如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。