Lakehouse runtime catalogが一般提供を開始、複数のIceberg互換エンジンによる共有データへのアクセスを支援

Lakehouse runtime catalogの背景にある課題

レイクハウスの主要な構成要素はカタログで、Apache Iceberg環境では通常Iceberg REST Catalogを指します。Icebergのカタログは、テーブルのポインターの維持とアトミックコミットの処理を担い、テーブルの所在を示す唯一の信頼できる情報源です。^[1]

エージェントから繰り返される大量の小さなクエリを支えるには、大規模でもアトミック性、整合性、可用性、同時実行性を備えたマネージドカタログが必要です。Google Cloudは現場の声からマネージドカタログの課題を挙げ、その解決のためにLakehouse runtime catalogを構築したとしています。

IcebergはOCCでACIDトランザクションを保証するため、マネージドカタログには現在のメタデータポインターを交換する確実なアトミックCAS操作が必要です。Google Cloudの整理では、高可用性と運用保守の面で、カタログが停止するとクエリはすぐに失敗するため、マネージドカタログはTier-1のサービスです。

図1　マネージドカタログの主な課題

Google Cloudによれば、SQLとACIDを備える従来のスケールアップ型リレーショナルデータベースも、手動シャーディングなしでは同時読み書きの多い負荷で上限に達します。そのシャーディングは運用負担が大きく、一般的なスケールアウト型のデータベースシステムは結果整合性、管理の難しさ、企業利用への未成熟さのいずれか、またはすべてを抱えるとしています。

保守とセキュリティの課題

カタログ単体はデータを最適化しないため、コンパクションやスナップショットの期限切れ処理などには別パイプラインの構築と運用が必要です。ガバナンスとセキュリティでは、カタログがゲートキーパーとして、OAuth2トークン交換などの認証プロトコルや名前空間とテーブル単位のアクセス制御を実装・維持します。

Google Cloudは、マネージドカタログに求められる機能に、ベンディングされたストレージ認証情報を挙げています。例えば有効期間の短いトークンを生成し、クエリエンジンが広範な直接ストレージ認証情報を持たずに済む仕組みです。

図2　カタログに求められる保守とセキュリティ

Lakehouse runtime catalogでできること

登録したテーブルは、標準のRESTインターフェースを通じてすぐに検出・クエリできます。対象のエンジンは、Managed Service for Apache SparkやBigQuery、オープンソースエンジンです。^[1]

Google Cloudが挙げるアーキテクチャ上の利点は、以下の通りです。

クラウド間の双方向カタログフェデレーションでは、Databricks UnityやSnowflake Horizon、AWS Glueのデータにアクセスできます。認証情報ベンディングとOIDCトークン交換に対応し、AWSやAzureのデータでGoogle AIを直接使えます。

図3　Lakehouse runtime catalogの主な利点

テーブルレベルのセキュリティを全コンピュートエンジンで一貫して適用できるのは、Knowledge CatalogとCloud IAMとの統合によるものです。エージェント向けの信頼できるコンテキストを定義でき、カタログ内のIcebergテーブルの検索やリネージ、インサイトは標準で提供されます。

Lakehouse runtime catalogのカタログ作成

推奨の複数バケットカタログは、コンソールの[Lakehouse]ページの[カタログを作成]から作成を始めます。gcloudで作成する場合のコマンドは、gcloud biglake iceberg catalogs createです。^[2]

GAのLakehouse runtime catalogは、Iceberg REST Catalogをサポートしています。Apache Iceberg RESTカタログエンドポイントを使う流れは、タイプの選択から、クライアントでのテーブル作成とクエリまでです。^[1][2]

図4　Apache Iceberg RESTカタログエンドポイントを使う流れ

複数バケットカタログ（推奨）をgcloudで作成するコマンドは、以下の通りです。

gcloud biglake iceberg catalogs create \
    CATALOG_NAME \
    --project PROJECT_ID \
    --catalog-type biglake \
    --default-location DEFAULT_LOCATION \
    --credential-mode CREDENTIAL_MODE \
    [--restricted-locations RESTRICTED_LOCATIONS] \
    [--primary-location LOCATION]

公式資料からの抜粋：Apache Iceberg REST カタログのエンドポイントを設定する（Iceberg REST カタログのエンドポイントを設定する / gcloud）。対象版・範囲：資料記載時点。

上記では、--catalog-type biglakeで複数バケットカタログを作成し、--credential-modeで認証情報の扱いを指定します。値は、エンドユーザー認証情報ならend-user、認証情報ベンディングならvended-credentialsです。

Lakehouse runtime catalogの認可方式

選べる認可方式は、認証情報ベンディングとエンドユーザー認証情報の2つです。認証情報ベンディングでは、Cloud StorageやAWS S3、Azure Blob Storageにある基盤のファイルへ直接アクセスせずにテーブルを扱えます。^[1]

エンドユーザー認証情報では、カタログがアクセスしている利用者のIDをCloud Storageに渡し、認可チェックを行います。認証情報ベンディングモードでは、カタログ利用者がCloud Storageバケットに直接アクセスする必要はありません。^[2]

図5　選べる2つの認可方式

Lakehouse runtime catalogを支えるSpanner

Lakehouse runtime catalogはSpanner上に構築されているため、強い整合性を保証し、高可用で同時実行性とスケーラビリティを備えます。Spannerは、完全なリレーショナルSQLと複数テーブルのACIDトランザクションに、NoSQLのような読み書きの水平スケールアウトを組み合わせたデータベースです。^[1]

Spannerは手動シャーディングなしで、コンピュートとストレージを独立して拡張できます。Google Cloudは、こうしたSpannerの基盤により、Lakehouseの利用者がエージェント規模で運用できるとしました。

Lakehouse runtime catalogはアトミックコミットと同時実行制御を備え、メタデータをデータに合わせて、あらゆる規模のワークロードへ拡張できます。カタログ基盤の管理はサーバーレスで運用作業がなく、TCOが下がるのも利点です。

図6　Lakehouse runtime catalogの可用性とバケット対応

Spannerのリージョン構成でカタログは最大99.99%の可用性を備え、デュアルリージョンとマルチリージョンのCloud Storageバケットはフェイルオーバーに使えます。Lakehouseのトランザクションは直列化可能で、データベース内の順序はクライアントが観測したコミットの順序と同じです。

Knowledge Catalog連携

このカタログはKnowledge Catalogと直接統合され、Icebergテーブルの発見とエージェントへの信頼できるコンテキストの提供を助けます。Knowledge Catalogは、Spannerの全文検索とネイティブベクトル検索でキーワード検索とセマンティック埋め込みを1つのクエリにまとめ、再現率を高めるとされます。

両方のインデックスは同じデータセット上に構築され、ベーステーブルのDML操作とともに厳密なトランザクショナルACID整合性で更新される仕組みです。Google Cloudは、同期パイプラインや外部のベクトル検索、全文検索のシステムを管理する運用負荷がなくなり、エージェント用途の市場投入が速まるとしました。

図7　Knowledge Catalogの検索の仕組み

Google Cloudのレイクハウス例

Google Cloudは、IcebergベースのLakehouseの利用例に、レイクハウスのデータ資産とSpannerのOLTPデータを組み合わせた分析を挙げています。Spannerなどの運用データベースからレイクハウスの資産を使う低遅延の配信アプリや、ファーストパーティとサードパーティのエージェントでの対話型分析も含まれます。

図8　Google Cloudのレイクハウスの利用例

このカタログとSpannerの例は、Icebergのマンハッタンのタクシー走行の分析データと、Spannerのタクシーゾーンの運用データから、最も混雑する経路を求めるものです。同じデータにはConversational Analytics Agentからもアクセスでき、二次的な洞察を得られます。

Google Cloudは、Lakehouseへの移行で、分析エンジンやエージェント間のデータのサイロが減り、複数エンジンのガバナンスも統合されるとしています。SpannerベースのLakehouse runtime catalogを活用すると、最新のクラウド環境をエージェント規模の運用に備えられるとしました。