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

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

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

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

エクスポート クエリのための、Google Cloud と AWS または Azure との間のデータ移動。
図 2: エクスポート クエリのための Google Cloud と AWS または Azure との間のデータ移動。
  1. BigQuery コントロール プレーンが、Google Cloud コンソール、bq コマンドライン ツール、API メソッド、またはクライアント ライブラリを介して、エクスポート クエリ ジョブを受信します。クエリには、Amazon S3 バケットまたは Blob Storage 内のクエリ結果の送信先パスが含まれます。
  2. BigQuery コントロール プレーンが、エクスポート クエリ ジョブの処理のために BigQuery データプレーン（AWS または Azure）に送信します。
  3. BigQuery データプレーンが、VPN 接続を介してコントロール プレーンからエクスポート クエリを受信します。
  4. BigQuery データプレーンが、Amazon S3 バケットまたは Blob Storage からテーブルデータを読み取ります。
  5. BigQuery データプレーンが、テーブルデータに対してクエリジョブを実行します。テーブルデータの処理が、指定した AWS または Azure リージョンで行われます。
  6. 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 パーティション分割される場合に特に便利です。

BigLake とオブジェクト テーブルは、Cloud Storage や Amazon Simple Storage Service（Amazon S3）などの外部データソースのファイルに関するメタデータのキャッシュ保存をサポートしています。メタデータには、ファイル名、パーティショニング情報、ファイルの物理的なメタデータ（行数など）が含まれます。テーブルでメタデータのキャッシュ保存を有効にするかどうかを選択できます。多数のファイルと Hive パーティション フィルタを使用したクエリは、メタデータのキャッシュから最大限のメリットを得られます。

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

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

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

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

キャッシュを自動または手動で更新することを選択できます。

  • 自動更新の場合、キャッシュはシステムが定義した間隔（通常は 30～60 分）で更新されます。外部データソース内のファイルがランダムな間隔で追加、削除、変更される場合は、キャッシュの自動更新が適しています。更新のタイミングを制御する必要がある場合（たとえば、抽出、変換、読み込みジョブの最後に更新をトリガーするなど）は、手動更新を使用します。

  • 手動で更新する場合は、BQ.REFRESH_EXTERNAL_METADATA_CACHE システム プロシージャを実行して、決定したスケジュールでメタデータのキャッシュを更新します。パイプラインの出力など、既知の間隔で z 内のファイルが追加、削除、変更される場合、キャッシュを手動で更新することをおすすめします。

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

メタデータ キャッシュは、更新しない場合、7 日後に期限切れになります。

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

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

メタデータ更新ジョブに関する情報を探すには、次の例に示すように 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;

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

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

プレビュー版のサポートについては、bq-omni-customer-support@google.com までメールでお問い合わせください。

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、PARTITIONS の INFORMATION_SCHEMA ビューは、Amazon S3 と Blob Storage のデータに基づく BigLake テーブルでは使用できません。
  • Blob Storage では、マテリアライズド ビューはサポートされていません。
  • JavaScript UDF はサポートされていません。

  • 次の SQL ステートメントはサポートされていません。

  • 宛先の一時テーブル（プレビュー）のクエリと読み取りには、次の制限が適用されます。

    • 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-eu-west-1 europe-west1
Azure
Azure - East US 2 azure-eastus2 us-east4

次のステップ