ボーダーレスな Lakehouse を加速: クロスクラウド キャッシュのプレビュー版を発表

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

この投稿では、ボーダーレスな Lakehouse の機能強化についてお知らせします。これは、データ エンジニア、データ サイエンティスト、そして急速に導入が進む AI エージェントが、管理されたデータをその保存場所で直接クエリできるようにするためのソリューションです。

正確な推論を行い、複雑なエンタープライズ ワークフローを自動化するには、あらゆるタイプのエージェントとデータ利用者が、組織のデータ資産すべてに迅速かつ統合的にアクセスできる環境が必要です。そうした環境であれば、クラウドをまたいで顧客レコード、トランザクション ログ、運用テレメトリーを結合することが可能になります。しかし、現代の企業データが 1 か所に収まっていることはほとんどありません。データ資産は、Amazon S3、Azure Data Lake Storage（ADLS）、Google Cloud Storage、オペレーショナル データベース、さらには Salesforce、SAP、Workday などの SaaS プラットフォームに分散しているのが一般的です。これまで、こうした分散したデータセットの統合には、不安定な ETL パイプライン、ストレージの重複、極めて高額なクロスクラウド データ転送費用がつきものでした。

組織がクラウドをまたいでデータをクエリして有効活用できるようにするため、今年 Google はボーダーレスな Lakehouse を導入しました。Apache Iceberg REST カタログ仕様を採用することで、Databricks Unity Catalog、AWS Glue、Snowflake Horizon などのカタログとの直接連携が可能になりました。また、他のクラウド プロバイダへの高帯域幅のプライベート リンクを確立する Partner Cross-Cloud Interconnect も導入しました。この接続により、1 ギガバイトあたりの転送費用を公共のインターネットを使用するよりも削減できます。

今回の機能強化では、「そもそもネットワーク経由で転送する必要があるデータの量を最適化する」ことで、マルチクラウドの効率化をさらに一歩進めました。

クロスクラウド データのクエリ費用をさらに削減する、2 つの新機能をご紹介します。1 つは、Lakehouse 向けのクロスクラウド キャッシュのプレビュー版です。頻繁にアクセスされるデータを Google Cloud 内にローカル キャッシュすることで、ユーザーに意識させることなく BigQuery でのクロスクラウド クエリを高速化し、リモート転送の費用も削減することができます。標準的な Iceberg の列圧縮とクロスクラウドでのキャッシュ保存を組み合わせることで、クラウド間で実際に転送するデータの量を処理データの 5% 未満にまで抑えられることも珍しくありません。これにより、総所有コスト（TCO）を削減して、エンタープライズ規模でのクロスクラウド分析と AI 活用を実現できます。もう 1 つは、BigQuery のクロスクラウド接続のプレビュー版（こちらも提供中）です。この機能を使用すれば、他のクラウドにある Iceberg 以外のデータをクエリしてワークロードを高速化できます。

クロスクラウド キャッシュの仕組み

クロスクラウド キャッシュは、パラメータ調整やストレージ管理を一切必要とすることなくクエリを高速化し、企業が求める高度なパフォーマンスとセキュリティ要件を両立させます。それを実現する内部メカニズムの一部をご紹介します。

• サブファイル ブロック単位での処理: Apache Parquet などのカラム型フォーマットでは、クロスクラウド キャッシュはサブファイル ブロック レベルで動作します。そのため、クエリが数列にしかアクセスしない場合、数ギガバイトに及ぶファイル全体をクラウド間で転送する必要がなくなります。BigQuery は、クエリで指定された特定の列チャンクと辞書ページのみをキャッシュ保存します。キャッシュミスが発生すると、BigQuery はクエリに応答するために必要なデータをリモート クラウドから取得し、将来のクエリのためにコピーをローカルにキャッシュ保存します。これにより、繰り返し発生するワークロードのネットワーク転送とレイテンシを大幅に削減できます。

• デフォルトの保存データの暗号化: キャッシュに保存されたデータブロックは、Google が管理する暗号鍵（GMEK）によってデフォルトで暗号化されます。一時的なキャッシュ ストレージであっても、追加のオーバーヘッドなしで、通常の BigQuery ストレージと同様のエンタープライズ グレードのセキュリティ ポスチャーを維持します。

• テナントとリージョンの分離: キャッシュ エントリは、プロジェクトとカタログの境界ごとに厳密に分割され、テナント間でのデータ漏洩を防ぎます。Lakehouse は、ローカル キャッシュとクエリ実行の両方を、指定された Google Cloud リージョン（例: us-east4）に厳密に限定します。これにより、リモート クラウドへのクエリ実行時にも、各リージョンのデータ所在地要件への準拠を支援します。

• 更新頻度チェック: マルチクラウド キャッシュでは、処理速度と鮮度のトレードオフを強いられることがよくあります。ステイル読み取りを防ぐため、BigQuery はキャッシュに保存されたデータを使用する前にリモート オブジェクトのメタデータを取得して、データが変更されておらず、ユーザーが引き続きアクセスできることを確認します。元データのテーブルが変更されると、BigQuery は新しいファイルをフェッチし、参照されなくなったキャッシュ ブロックは自動的に破棄します。これにより、信頼できる唯一の情報源の正確性を維持しながら、ローカルクエリと同等の速度を実現します。

キャッシュの仕組み、統計カウンタ、リージョンに関する留意事項について詳しくは、Lakehouse のインテリジェント キャッシュに関するドキュメントをご確認ください。

クロスクラウド キャッシュの実際の操作

では、日常業務において、この仕組みはどのように動作するのでしょうか。例として、e コマースチームが、Databricks Unity Catalog から Lakehouse に統合された Amazon S3 の 10 TiB の Iceberg 売上テーブル（aws_lakehouse_catalog.sales.web_sales）に対してクエリを実行する場合を考えてみましょう。夕方のタイムセールの時間帯（午後 8 時～9 時）には、アナリストが過去の取引データをクエリし、購入意向の強いユーザー層において、どのオンライン店舗がピーク時の取引量と収益を押し上げているかを特定します。

初回実行: コールド状態でのカラム型データ取得

この最初のコールド実行では、ローカル キャッシュは空の状態です（cacheBytesRead: "0"）。BigQuery は、パーティションのプルーニングと列投影を適用して、必要な Parquet バイト範囲のみを Partner Cross-Cloud Interconnect 経由で Amazon S3 から転送します。

• 処理される論理データ: BigQuery は、10 TiB のデータセット全体のうち 214.5 GiB を処理します。

• 標準的な Iceberg の圧縮効率: Zstandard（zstd）を使用した標準的な Iceberg 列圧縮により、BigQuery が S3 から読み取るのは24.1 GiB のみです。これは8.9:1 の圧縮率に相当します。これらのサブファイル Parquet ブロックが Google Cloud に到着すると、BigQuery はそれらのデータをリージョン キャッシュに保存します。

追加の探索: ディメンションの追加

実際には、アナリストやエージェントがまったく同じクエリを 2 回続けて実行することはほとんどありません。フルフィルメントの詳細をさらに深堀りするため、アナリストは配送方法ディメンション（sm.sm_type）を追加してクエリを修正します。

この後続クエリのジョブ統計は次のようになります。

• 94.8% のキャッシュ ヒット率: BigQuery は、以前にクエリを実行した列の 24.1 GiB をローカル キャッシュから直接返します。

• 最小限のリモート取得: BigQuery は、新しい ws_ship_mode_sk 列と ship_mode テーブルを対象に、S3 から 1.33 GiB だけを転送します。

• サブファイル単位の柔軟性: キャッシュに保存された列チャンクが再利用されるため、クエリを修正しても新たに必要になったバイトのみが転送されます。

エンタープライズ規模で効率性を向上

クロスクラウド クエリの TCO を検討する際に重要となる、上位 2 つの要素は次のとおりです。

• 圧縮率: Iceberg でデフォルトの圧縮アルゴリズム（Zstandard / zstd）を使用すると、カラム型データは高い圧縮効果を発揮します。データの圧縮率が 8:1 であると仮定した場合、処理される論理データ 1 TiB ごとに、ネットワーク経由で移動する必要があるデータは約 128 GiB のみとなります。

• キャッシュ ヒット率: 最近アクセスされたデータをネットワーク経由ではなくキャッシュから取得できれば、ネットワーク転送を回避できます。データの 80% がキャッシュ ヒットになると仮定すると、アクセスされる物理データ 100 GiB ごとに、ネットワーク上を移動するデータは 20 GiB のみとなります。

これらの 2 つの要素と前提条件を掛け合わせると、組織が処理するデータ 1 TiB あたり、ネットワーク経由で転送する必要があるデータ量は約 26 GiB（処理されるデータ全体の 3% 未満）で済みます。この削減効果と Partner Cross-Cloud Interconnect を組み合わせることで、TCO を削減し、ペタバイト規模のクロスクラウド分析や AI 活用を極めて優れた費用対効果で実現できます。

BigQuery クロスクラウド接続のプレビュー版を提供開始

クロスクラウド キャッシュと併せて提供開始となった BigQuery クロスクラウド接続のプレビュー版では、BigQuery を Amazon S3 や Azure Storage のオープン形式データに直接接続することができます。

カタログ連携とクロスクラウド接続のどちらを使うべきかの判断基準はシンプルです。

• BigQuery のクロスクラウド接続（元ファイル用）: Iceberg カタログで管理されていないスタンドアロン ファイル（CSV、JSON、アドホックな Parquet）の場合、クロスクラウド接続を利用することで、リモートのバケットパスを直接参照する BigQuery 外部テーブルを作成できます。

• Lakehouse カタログ連携（Iceberg 向け）: Databricks Unity、AWS Glue、Snowflake Horizon などのカタログで管理されている Iceberg データの場合、Lakehouse がスキーマとテーブル スナップショットを自動的に同期します。これにより、ユーザー エクスペリエンスが簡素化され、ユーザーが常に最新のデータに対してクエリを実行できるようになります。

クロスクラウド接続は、他のクラウドのコンピューティング ワーカーではなく、Google Cloud リージョン内の標準 BigQuery コンピューティング ワーカーを使用する、最先端のアーキテクチャを採用しています。このアプローチにより、世界各地のリージョンでの利用が可能になるほか、リモート ファイルでも BigQuery と同等の機能（BigQuery AI や Gemini を含む）が提供されます。

Lakehouse のクロスクラウド キャッシュ機能は、BigQuery のクロスクラウド接続からクエリされたデータと、Lakehouse カタログ連携のデータの双方に適用されます。接続の作成方法や外部バケットパスへのクエリ実行方法については、BigQuery のクロスクラウド接続の設定に関するドキュメントをご確認ください。

- グループ プロダクト マネージャー、Will Ochandarena

- スタッフ ソフトウェア エンジニア、Jason Ganetsky