Google Cloud の Lakehouse ランタイム カタログを使用して Apache Hive をモダナイズする

※この投稿は米国時間 2026 年 8 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

Apache Hive メタストア（HMS）は、10 年以上にわたり、ビッグデータ分析における事実上のメタデータ管理基盤として機能してきました。Hadoop クラスタ上でも、MySQL や PostgreSQL を基盤とする自己管理型の Compute Engine VM 上でも、HMS は中央スキーマ レジストリとして機能し、Apache Spark、Presto、Hive が未加工の .parquet ファイルや .orc ファイルをクエリできるようにしてきました。

しかし、企業のデータ アーキテクチャがペタバイト規模に拡大し、複数のクエリエンジン（Google Cloud Managed Service for Apache Spark、BigQuery、Trino など）を横断的に利用するようになると、従来の Hive メタストアが運用上の深刻なボトルネックとして顕在化するようになりました。

このブログ記事では、エージェント規模の最新のクラウド環境において、従来のメタストアがなぜ課題を抱えているのかを探り、昨年発表したサーバーレスの Google Cloud Lakehouse ランタイム カタログが、その解決にどのように役立つかを紹介します。このカタログは、オープンな Apache Iceberg REST カタログ仕様に基づいて構築されており、本番環境の Hive テーブルをわずか数分で即座に実行可能な形で移行できる、データコピー不要の移行ソリューションです。

従来の Hive メタストアの課題

本番環境で大規模な分析を実行しているデータ エンジニアやインフラストラクチャ責任者の方々と話をすると、スタンドアロンの Hive メタストアには共通して 3 つの課題があることが分かります。

アーキテクチャとスケーリングのボトルネックスタンドアロンの HMS デプロイでは、テーブル スキーマ、パーティション、保存場所を追跡するために、リレーショナル データベースのバックエンド（MySQL や Postgres など）に依存しています。データレイクが数十万ものパーティション分割テーブルにまで拡大すると、パーティションのプルーニングや大量のリスト処理が発生し、このことがリレーショナル データベースにおける深刻なパフォーマンスのボトルネックを引き起こします。パーティション メタデータを要求する複雑な Spark ジョブが実行されると、メタストアの CPU 使用率が 100% に達し、クラスタ全体のクエリ処理に遅延が生じたり、メモリ不足（OOM）が発生したりする可能性があります。

サイロ化された ID とセキュリティ ガバナンス従来のメタストアは、境界ベースの Hadoop セキュリティ モデルに基づいて設計されています。そのため、Apache Spark のコンピューティング ジョブと BigQuery のようなエンタープライズ SQL エンジンの両方で、テーブルレベルのアクセス制御リスト（ACL）などの最新のきめ細かいデータ ガバナンスを適用するには、2 つの異なるコントロール プレーンに分断された、重複するセキュリティ ポリシーを維持する必要があります。

運用上のオーバーヘッドと総所有コスト（TCO）高可用性 MySQL / Postgres インスタンスの管理、HMS デーモンのパッチ適用、JDBC 接続プールの調整、アイドル状態でも課金されるインスタンス ベースのメタストア サーバーの運用などは、データ プラットフォーム チームに大きな負荷を強いるものであり、本来であればエージェント向けの高価値なデータ プロダクトの開発に充てるべき、データ プラットフォーム チームの貴重な時間を奪っています。

解決策: Lakehouse ランタイム カタログ

既存のペタバイト規模のストレージ ペイロードを書き換えることなく、こうしたアーキテクチャ上のボトルネックを解消するために、Google は Iceberg REST カタログと Hive カタログをサポートする Lakehouse ランタイム カタログを構築しました。

Lakehouse ランタイム カタログは、高可用性を備えた完全にサーバーレスな統合メタデータ レジストリであり、従来の Hive / Parquet テーブルと、Apache Iceberg などの最新のオープン テーブル形式の両方をサポートするようにゼロから設計されています。 Lakehouse ランタイム カタログでは、Apache Iceberg REST カタログ仕様をネイティブに実装することで、メタデータ検出をコンピューティング エンジンから分離しています。カタログとコンピューティング エンジンをこのように分離することで、複数の Iceberg 互換エンジンがデータコピー不要で同じデータにアクセスできるようになり、その結果、顧客側でデータのコピーを複数維持する必要性が軽減され、ワークロードをより早く本番環境に移行できるようになります。

このアプローチには、アーキテクチャ上のメリットが数多くあります。

• マルチエンジンの相互運用性: 登録されたテーブルは、標準の REST インターフェースを介して、Google Cloud Managed Spark、BigQuery、オープンソース エンジンで即座に検出やクエリが可能になります。

• オープン API: Iceberg REST カタログと Hive カタログをサポートしているため、異なるチームがそれぞれ好みの分析ツールを使用しながら、単一の統合データセットを共有できます。

• データコピー不要: テーブル定義は、Google Cloud Storage の既存のデータを直接参照します。基盤となるデータの移動、書き換え、複製を行う必要はありません。

• AI を活用したガバナンス、セキュリティ、信頼できるコンテキスト: Lakehouse ランタイム カタログは、Knowledge Catalog および Cloud IAM と直接統合されているため、エージェント用の信頼できるコンテキストや、すべてのコンピューティング エンジンに一貫して適用されるテーブルレベルのセキュリティを定義できます。さらに、認証情報ベンディングなどの主要な認証メカニズムもサポートしています。これにより、基盤となる Cloud Storage バケット内のファイルに直接アクセスすることなく、テーブルにアクセスできます。

• エンタープライズ対応、スケーリング、TCO 削減: Google の地球規模のインフラストラクチャと Spanner を基盤としたメタデータは、データに合わせてスケールできます。Cloud Storage のデュアルリージョン バケットとマルチリージョン バケットのサポートにより、フェイルオーバーのユースケースが可能になります。また、サーバーレスな NoOps 環境と、あらゆるワークロード サイズに対応可能なスケーラビリティにより TCO を削減します。

従来の Hive メタストアからゼロコピーで移行

実際の運用においてスムーズなカットオーバーが可能であることを示すために、従来の自己管理型 Hive メタストアを Google Cloud Lakehouse にモダナイズできる機能を提供しています。この機能は、従来の Hive メタストアに直接接続し、外部テーブルの定義とパーティション マップを抽出して、サーバーレスの Lakehouse カタログに直接登録します。登録後は、Google Managed Spark、BigQuery、Gemini の会話型分析エージェントでデータを利用できます。

Lakehouse にモダナイズし、主要なエージェント ジャーニーで即座にデータを活用できるようにしましょう。

データ アーキテクチャをモダナイズする準備はできていますか？

従来の Hive メタストアから Google Cloud の Lakehouse にモダナイズすることで、分析エンジンやエージェント間のデータサイロを最小限に抑え、マルチエンジンのガバナンスを統合し、信頼できるコンテキストをエージェントに提供し、運用コストを大幅に削減できます。これにより、最新のクラウド環境をエージェント規模で運用できる基盤が整います。

今すぐ Apache Hive メタストア テーブルを Google Cloud に移行して、エージェントの時代に備えましょう。Google Cloud Lakehouse の詳細については、こちらをご覧ください。

- Lakehouse 担当プロダクト リード、Vinod Ramachandran

- バイス プレジデント、Pratibha Suryadevara