BigQuery Omni の概要

BigQuery Omni を使用すると、BigLake テーブルを使用して、Amazon Simple Storage Service（Amazon S3）または Azure Blob Storage に保存されたデータに対して BigQuery 分析を実行できます。

多くの組織は、データを複数のパブリッククラウドに保存しています。すべてのデータから分析情報を得るのは困難であるため、このようなデータはサイロ化されてしまうことがよくあります。低コストで高速であり、分散型データガバナンスによる追加のオーバーヘッドを発生させないマルチクラウドデータツールでデータを分析できれば望ましい状況です。BigQuery Omni では統合されたインターフェースを使用できるため、この負担を軽減できます。

外部データに対して BigQuery 分析を実行するには、まず Amazon S3 または Blob Storage に接続する必要があります。外部データに対してクエリを実行するには、Amazon S3 または Blob Storage のデータを参照する BigLake テーブルを作成する必要があります。

クラウド間でデータを移動して、クロスクラウド転送でデータを結合できます。また、クロスクラウド結合を使用して、クラウド間でデータのクエリも実行することができます。BigQuery Omni は、クロスクラウドの分析ソリューションで、データが存在する場所で分析する機能と、必要に応じてデータを複製する柔軟性を備えています。詳細については、クロスクラウド転送でデータを読み込むとクロスクラウド結合をご覧ください。

アーキテクチャ

BigQuery のアーキテクチャではコンピューティングとストレージが分離されているため、必要に応じてスケールアウトが可能で、非常に大量のワークロードを処理できます。BigQuery Omni は、BigQuery のクエリエンジンを他のクラウドで実行できるように、このアーキテクチャを拡大したものです。この結果、データを BigQuery ストレージへ物理的に移動する必要はありません。データがすでに存在する場所で処理が行われます。

BigQuery Omni アーキテクチャ

クエリの結果は安全な接続を経由して Google Cloud に戻し、たとえば Google Cloud コンソールに表示できます。または、結果を Amazon S3 バケットや Blob Storage に直接書き込むこともできます。この場合、クエリの結果がクラウド間で転送されることはありません。

BigQuery Omni は、標準の AWS IAM ロールや Azure Active Directory プリンシパルを使用して、サブスクリプション内のデータにアクセスします。読み取りと書き込みのアクセスを BigQuery Omni に委託でき、そのアクセス権はいつでも無効にできます。

データに対してクエリを実行する際のデータフロー

以下の図は、次のクエリに対する Google Cloud と AWS または Azure との間のデータ移動を示しています。

SELECT ステートメント
CREATE EXTERNAL TABLE ステートメント

**図 1:** クエリのための Google Cloud と AWS または Azure との間のデータ移動。

BigQuery コントロールプレーンが、Google Cloud コンソール、bq コマンドラインツール、API メソッド、またはクライアントライブラリを介してクエリジョブを受信します。
BigQuery コントロールプレーンが、クエリジョブの処理のために BigQuery データプレーン（AWS または Azure）に送信します
BigQuery データプレーンが、VPN 接続を介してコントロールプレーンからクエリを受信します。
BigQuery データプレーンが、Amazon S3 バケットまたは Blob Storage からテーブルデータを読み取ります。
BigQuery データプレーンが、テーブルデータに対してクエリジョブを実行します。テーブルデータの処理は、指定された AWS または Azure リージョンで行われます。
クエリ結果は、VPN 接続を介してデータプレーンからコントロールプレーンに送信されます。
BigQuery コントロールプレーンが、クエリジョブのレスポンスとして表示するクエリジョブの結果を受信します。このデータは最大 24 時間保存されます。
クエリ結果が返されます。

詳細については、Amazon S3 データに対してクエリを実行すると Blob Storage データをご覧ください。

データのエクスポート時のデータフロー

次の図は、EXPORT DATA ステートメントで Google Cloud と AWS または Azure の間でのデータ移動を示しています。

エクスポートクエリのための、Google Cloud と AWS または Azure との間のデータ移動。 — **図 2:** エクスポートクエリのための Google Cloud と AWS または Azure との間のデータ移動。

BigQuery コントロールプレーンが、Google Cloud コンソール、bq コマンドラインツール、API メソッド、またはクライアントライブラリを介して、エクスポートクエリジョブを受信します。クエリには、Amazon S3 バケットまたは Blob Storage 内のクエリ結果の送信先パスが含まれます。
BigQuery コントロールプレーンが、エクスポートクエリジョブの処理のために BigQuery データプレーン（AWS または Azure）に送信します。
BigQuery データプレーンが、VPN 接続を介してコントロールプレーンからエクスポートクエリを受信します。
BigQuery データプレーンが、Amazon S3 バケットまたは Blob Storage からテーブルデータを読み取ります。
BigQuery データプレーンが、テーブルデータに対してクエリジョブを実行します。テーブルデータの処理が、指定した AWS または Azure リージョンで行われます。
BigQuery が、Amazon S3 バケットまたは Blob Storage の指定された送信先パスにクエリ結果を書き込みます。

詳細については、クエリ結果を Amazon S3 にエクスポートすると Blob Storage をご覧ください。

利点

パフォーマンス。クラウド間でデータがコピーされず、データが存在する同じリージョンでクエリが実行されるため、分析情報をより迅速に取得できます。

費用。データは移動されないため、アウトバウンドデータ転送の費用を節約できます。クエリは Google が管理するクラスタで実行されるため、AWS や Azure アカウントで、BigQuery Omni 分析に関連する追加料金は請求されません。クエリの実行にのみ、BigQuery の価格モデルに従って請求が行われます。

セキュリティとデータガバナンス。データは、ユーザー独自の AWS または Azure サブスクリプションで管理します。パブリッククラウドから元データの移動やコピーをする必要はありません。すべての計算は、データと同じリージョン内で実行される BigQuery マルチテナントサービスで行われます。

サーバーレスアーキテクチャ。BigQuery の他の部分と同様、BigQuery Omni はサーバーレスサービスです。Google が、BigQuery Omni を実行するクラスタをデプロイして管理します。リソースのプロビジョニングやクラスタの管理は必要ありません。

管理のしやすさ。BigQuery Omni は、Google Cloud による統合型管理インターフェースを提供します。BigQuery Omni では、既存の Google Cloud アカウントと BigQuery プロジェクトを使用できます。Google Cloud コンソールで GoogleSQL クエリを作成して AWS または Azure でデータにクエリを実行し、Google Cloud コンソールに結果を表示できます。

クロスクラウド転送。S3 バケットと Blob Storage から標準の BigQuery テーブルにデータを読み込むことができます。詳細については、Amazon S3 データを転送すると Blob Storage データを BigQuery に転送するをご覧ください。

パフォーマンス向上のためのメタデータキャッシュ

キャッシュに保存されたメタデータを使用すると、Amazon S3 データを参照する BigLake テーブルに対するクエリのパフォーマンスを改善できます。これは、多数のファイルを扱う場合、またはデータが Hive パーティション分割される場合に特に便利です。

メタデータには、ファイル名、パーティショニング情報、ファイルの物理的なメタデータ（行数など）が含まれます。テーブルでメタデータのキャッシュ保存を有効にするかどうかを選択できます。多数のファイルと Hive パーティションフィルタを使用したクエリは、メタデータのキャッシュから最大限のメリットを得られます。

メタデータのキャッシュ保存を有効にしていない場合、テーブルのクエリはオブジェクトメタデータを取得するために外部データソースを読み取る必要があります。このデータを読み取ると、クエリのレイテンシが増加します。外部データソースから数百万のファイルを一覧表示するには、数分かかることがあります。メタデータのキャッシュ保存を有効にすると、クエリで外部データソースのファイルを一覧表示することを回避し、ファイルをより高速にパーティション分割してプルーニングできます。

この機能を制御するプロパティが 2 つあります。

最大の未更新は、キャッシュに保存されたメタデータをクエリで使用するタイミングを指定します。
メタデータキャッシュモードは、メタデータの収集方法を指定します。

メタデータのキャッシュ保存を有効にする場合は、テーブルに対するオペレーションで許容されるメタデータ未更新の最大間隔を指定します。たとえば、1 時間の間隔を指定すると、テーブルに対するオペレーションでは、キャッシュに保存されたメタデータが過去 1 時間以内に更新されている場合、そのメタデータが使用されます。キャッシュに保存されたメタデータがそれより古い場合、オペレーションは代わりに Amazon S3 からメタデータを取得します。未更新の間隔は 30 分～7 日の間で指定できます。

キャッシュを自動更新するか、手動更新するかを選択できます。

自動更新の場合、キャッシュはシステムが定義した間隔（通常は 30～60 分）で更新されます。Amazon S3 内のファイルがランダムな間隔で追加、削除、変更される場合、キャッシュを自動的に更新することをおすすめします。更新のタイミングを制御する必要がある場合（たとえば、抽出、変換、読み込みジョブの最後に更新をトリガーするなど）は、手動更新を使用します。
手動で更新する場合は、BQ.REFRESH_EXTERNAL_METADATA_CACHE システムプロシージャを実行して、要件を満たすスケジュールでメタデータのキャッシュを更新します。パイプラインの出力など、既知の間隔で Amazon S3 内のファイルが追加、削除、変更される場合、キャッシュを手動で更新することをおすすめします。

複数の手動更新を同時に発行しても、成功するのは 1 つだけです。

メタデータキャッシュは、更新されなければ 7 日後に期限切れになります。

手動と自動のキャッシュ更新は、どちらも INTERACTIVE クエリの優先度に従って実行されます。

自動更新を使用する場合は、予約を作成してから、メタデータキャッシュ更新ジョブを実行するプロジェクトの BACKGROUND ジョブタイプの割り当てを作成することをおすすめします。これにより、更新ジョブとユーザーのクエリによるリソースの奪い合いを防ぎ、利用可能なリソースが十分でない場合に失敗する可能性を防ぐことができます。

未更新間隔とメタデータキャッシュモードの値は、設定する前に、どのように相互作用するかを検討する必要があります。以下の例を考えてみましょう。

テーブルのメタデータキャッシュを手動で更新していて、未更新間隔を 2 日に設定した場合、キャッシュに保存されたメタデータを使用するテーブルのオペレーションを行うには 2 日以内の間隔で、BQ.REFRESH_EXTERNAL_METADATA_CACHE システムプロシージャを実行する必要があります。
テーブルのメタデータキャッシュを自動的に更新していて、未更新間隔を 30 分に設定した場合、メタデータキャッシュのリフレッシュが通常の 30～60 分より長くかかると、テーブルに対する操作の一部が Amazon S3 から読み込まれる可能性があります。

メタデータ更新ジョブに関する情報を探すには、次の例に示すように INFORMATION_SCHEMA.JOBS ビューをクエリします。

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

詳細については、メタデータのキャッシュ保存をご覧ください。

キャッシュが有効なテーブルのマテリアライズドビュー

Amazon Simple Storage Service（Amazon S3）メタデータキャッシュが有効になっているテーブルのマテリアライズドビューを使用すると、Amazon S3 に保存されている構造化データをクエリする際のパフォーマンスと効率性を向上させることができます。これらのマテリアライズドビューは、BigQuery マネージドストレージテーブルに対するマテリアライズドビューと同様に、自動更新とスマートチューニングの便益を含めて、機能します。

マテリアライズドビューの Amazon S3 データをサポート対象の BigQuery リージョンで結合に使用できるようにするには、マテリアライズドビューのレプリカを作成します。マテリアライズドビューのレプリカは、承認済みマテリアルビューにのみ作成できます。

制限事項

BigLake テーブルの制限事項に加えて、BigQuery Omni には以下の制限が適用されます。これには、Amazon S3 と Blob Storage のデータに基づく BigLake テーブルが含まれます。

Standard エディションと Enterprise Plus エディションでは、BigQuery Omni リージョンのデータの操作はサポートされていません。エディションの詳細については、BigQuery エディションの概要をご覧ください。
OBJECT_PRIVILEGES、STREAMING_TIMELINE_BY_*、TABLE_SNAPSHOTS、TABLE_STORAGE、TABLE_CONSTRAINTS、KEY_COLUMN_USAGE、CONSTRAINT_COLUMN_USAGE、PARTITIONS の INFORMATION_SCHEMA ビューは、Amazon S3 と Blob Storage のデータに基づく BigLake テーブルでは使用できません。
Blob Storage では、マテリアライズドビューはサポートされていません。
JavaScript UDF はサポートされていません。
次の SQL ステートメントはサポートされていません。
- BigQuery ML ステートメント。
- BigQuery で管理されるデータを必要とするデータ定義言語（DDL）ステートメント。たとえば、CREATE EXTERNAL TABLE、CREATE SCHEMA、CREATE RESERVATION はサポートされていますが、CREATE MATERIALIZED VIEW はサポートされていません。
- データ操作言語（DML）ステートメント。
宛先の一時テーブル（プレビュー）のクエリと読み取りには、次の制限が適用されます。
- SELECT ステートメントを使用した宛先一時テーブルのクエリはサポートされていません。
- BigQuery Storage Read API を使用して宛先の一時テーブルからデータを読み取ることはできません。
- ODBC ドライバの使用の際は、高スループット読み取り（EnableHTAPI オプション）はサポートされていません。
スケジュールされたクエリは、API または CLI メソッドを通じてのみサポートされています。宛先テーブルのオプションはクエリでは無効になっています。EXPORT DATA クエリのみが許可されています。
BigQuery Storage API は、BigQuery Omni リージョンでは使用できません。
クエリで ORDER BY 句を使用しており、結果のサイズが 256 MB を超える場合、クエリは失敗します。この問題を解決するには、結果のサイズを小さくするか、クエリから ORDER BY 句を削除します。BigQuery Omni の割り当ての詳細については、割り当てと上限をご覧ください。
データセットと外部テーブルでは、顧客管理の暗号鍵（CMEK）はサポートされていません。

料金

BigQuery Omni の料金と期間限定特典については、BigQuery Omni の料金をご覧ください。

割り当てと上限

BigQuery Omni の割り当てについては、割り当てと上限をご覧ください。

クエリ結果が 20 GiB より大きい場合は、結果を Amazon S3 または Blob Storage にエクスポートすることを検討してください。BigQuery Connection API の割り当てについては、BigQuery Connection API をご覧ください。

ロケーション

BigQuery Omni は、クエリを実行するテーブルを含むデータセットと同じロケーションでクエリを処理します。データセットを作成した後で、そのロケーションを変更することはできません。データは AWS アカウントまたは Azure アカウント内に存在します。BigQuery Omni リージョンでは、Enterprise エディションの予約とオンデマンドコンピューティング（分析）の料金がサポートされています。エディションの詳細については、BigQuery エディションの概要をご覧ください。

	リージョンの説明	リージョン名	同じロケーションに配置された BigQuery リージョン
AWS
	AWS - US East（北バージニア）	`aws-us-east-1`	`us-east4`
	AWS 米国西部（オレゴン）	`aws-us-west-2`	`us-west1`
	AWS - アジア太平洋（ソウル）	`aws-ap-northeast-2`	`asia-northeast3`
	AWS - アジア太平洋（シドニー）	`aws-ap-southeast-2`	`australia-southeast1`
	AWS - ヨーロッパ（アイルランド）	`aws-eu-west-1`	`europe-west1`
	AWS - ヨーロッパ（フランクフルト）	`aws-eu-central-1`	`europe-west3`
Azure
	Azure - East US 2	`azure-eastus2`	`us-east4`

次のステップ

Amazon S3 への接続と Blob Storage への接続の方法を確認する。
Amazon S3 と Blob Storage の BigLake テーブルの作成方法を学習する。
Amazon S3 と Blob Storage の BigLake テーブルに対してクエリを実行する方法を学習する。
クロスクラウド結合を使用して、Amazon S3 と Blob Storage の BigLake テーブルを Google Cloud テーブルと結合する方法を学習する。
Amazon S3 にクエリ結果をエクスポートする方法と Blob Storage にクエリ結果をエクスポートする方法を確認する。
Amazon S3 からデータを転送する方法と Blob Storage から BigQuery にデータを転送する方法を確認する。
VPC Service Controls の境界を設定する方法を確認する。
ロケーションを指定する方法を確認する。