このリファレンス アーキテクチャでは Hive データを Cloud Storage に格納し、Hive メタストアを Cloud SQL 上の MySQL データベースにホスティングすることで、効率的かつ柔軟な方法で Dataproc 上で Apache Hive を使用する利点について説明します。
このドキュメントは、Dataproc での Apache Hive と Cloud SQL での Hive メタストアのデプロイに関心があるクラウド アーキテクトとデータ エンジニアを対象としています。
アーキテクチャ
次の図は、Hive クエリのライフサイクルを示しています。
この図では、Hive クエリのライフサイクルは次のステップに従います。
- Hive クライアントが、エフェメラル Dataproc クラスタで動作する Hive サーバーにクエリを送信します。
- Hive サーバーがクエリを処理し、メタストア サービスにメタデータをリクエストします。
- メタストア サービスは、Cloud SQL Proxy を介して Cloud SQL から Hive メタデータをフェッチします。
- Hive サーバーが、Cloud Storage のリージョン バケットに存在する Hive ウェアハウスからデータを読み込みます。
- Hive サーバーからクライアントに結果が返されます。
代替案を設計する
次のセクションでは、このアーキテクチャの代替となる設計案を示します。
マルチリージョン アーキテクチャ
ただし、Hive サーバーを異なる地理的地域で実行しなければならない場合は、マルチリージョン アーキテクチャを検討してください。その場合は、Cloud SQL インスタンスと同じリージョンに、メタストア サービスのホスト専用の Dataproc クラスタを別に作成する必要があります。
メタストア サービスから MySQL データベースに送信されるリクエストの量は非常に多くなる可能性があるため、パフォーマンスへの影響を最小限に抑えるために、メタストア サービスを地理的に MySQL データベースに近づけることが重要です。それに比べて、Hive サーバーからメタストア サービスに送信されるリクエストの量は通常、はるかに少数です。したがって、レイテンシが増加しても、Hive サーバーとメタストア サービスは異なるリージョンに配置してかまわない場合があります。
メタストア サービスは Dataproc マスターノードでのみ実行でき、ワーカーノードでは実行できません。Dataproc の標準クラスタおよび高可用性クラスタでは、最低 2 つのワーカーノードが強制的に作成されます。
未使用のワーカーノードでのリソースの浪費を避けるため、代わりにメタストア サービス用の単一ノードクラスタを作成できます。高可用性を実現するため、複数の単一ノードクラスタを作成できます。
Cloud SQL インスタンスに直接接続しなければならないのはメタストア サービス クラスタだけなので、Cloud SQL Proxy はメタストア サービス クラスタにのみインストールする必要があります。Hive サーバーからアクセスするメタストア サービス クラスタを指定するには、hive.metastore.uris プロパティの値として URI のカンマ区切りのリストを設定します。例:
thrift://metastore1:9083,thrift://metastore2:9083
複数のロケーションにある Hive サーバーから Hive データにアクセスする必要がある場合は、デュアルリージョン バケットまたはマルチリージョン バケットを使用することも検討できます。バケット ロケーションのタイプはユースケースによって異なります。レイテンシ、可用性、コストのバランスをとる必要があります。
次の図は、マルチリージョン アーキテクチャの例を示しています。
ご覧のとおり、マルチリージョンのシナリオはやや複雑ではるかに堅牢です。このリファレンス アーキテクチャのデプロイガイドでは、単一リージョンのシナリオを使用しています。
マルチリージョン アーキテクチャの利点
コンピューティング リソースとストレージ リソースを分離すると、次のような利点があります。
- 柔軟性とアジリティ: 特定の Hive ワークロードに合わせてクラスタ構成をカスタマイズし、必要に応じて各クラスタを個別にスケールアップまたはスケールダウンできます。
- 費用の削減: Hive ジョブを実行するときにエフェメラル クラスタをスピンアップし、ジョブが完了したら削除できます。ジョブに必要なリソースは使用されるときにのみアクティブになるため、使用した分に限り課金されます。重要性の低いデータ処理や低コストでの大規模なクラスタ作成に、プリエンプティブル VM も使用できます。
- 復元力: わかりやすくするため、このリファレンス アーキテクチャでは 1 つのマスター インスタンスのみを使用しています。本番環境ワークロードの復元力を強化するには、Dataproc の高可用性モードを使用し、3 つのマスター インスタンスを持つクラスタを作成することを検討してください。
費用の最適化
このリファレンス アーキテクチャとデプロイでは、Google Cloud の次の課金対象コンポーネントを使用します。
- Dataproc
- Cloud Storage
- Cloud SQL
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。
新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。
デプロイ
このアーキテクチャをデプロイするには、Dataproc に Apache Hive をデプロイするをご覧ください。
次のステップ
- Google のサーバーレス、高スケーラビリティ、低コストのエンタープライズ データ ウェアハウスである BigQuery を試す。
- Hadoop ワークロードの Google Cloud への移行に関するガイドを読む。
- 初期化アクションを確認して、Dataproc で Hive HCatalog を使用する方法の詳細を確認する。
- 高可用性対応の Cloud SQL を構成してサービスの信頼性を向上させる方法を学ぶ。
- リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。