コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

外部テーブルの概要

このページでは、外部テーブルを紹介し、BigQuery の外部に保存されたデータに対してクエリを実行することについてのガイダンスを示します。

BigLake 以外の外部テーブルを使用すると、外部データストアの構造化データをクエリできます。BigLake 以外の外部テーブルをクエリするには、外部テーブルと外部データソースの両方に対する権限が必要です。たとえば、Cloud Storage のデータソースを使用する BigLake 以外の外部テーブルをクエリするには、次の権限が必要です。

  • bigquery.tables.getData
  • bigquery.jobs.create
  • storage.buckets.get
  • storage.objects.get

サポートされているデータストア

BigLake 以外の外部テーブルは、次のデータストアで使用できます。

一時テーブルのサポート

永続テーブルまたは一時テーブルを使用すると、BigQuery で外部のデータソースに対してクエリを行うことができます。永続テーブルは、データセット内に作成され、外部データソースにリンクされるテーブルです。テーブルは永続的であるため、アクセス制御を行い、基礎となる外部データソースにアクセスできる他のユーザーとテーブルを共有できます。テーブルに対するクエリはいつでも実行できます。

一時テーブルを使用して外部データソースに対してクエリを実行する場合には、クエリを含むコマンドを送信し、外部データソースにリンクする一時テーブルを作成します。一時テーブルを使用する場合、BigQuery データセット内にはテーブルを作成しません。テーブルはデータセットに永続的に保存されないため、このテーブルを他のユーザーと共有することはできません。一時テーブルを使用して外部データソースにクエリを実行する方法は、外部データに 1 回限りのアドホック クエリを実行する場合、あるいは抽出、変換、読み込み(ETL)プロセスを行う場合に便利です。

複数のソースファイル

Cloud Storage に基づいて BigLake 以外の外部テーブルを作成する場合は、データソースが同じスキーマを持つ複数の外部データソースを使用できます。これは、Bigtable や Google ドライブに基づく BigLake 外部テーブルではサポートされていません。

制限事項

外部テーブルには、以下の制限が適用されます。

  • BigQuery では外部データテーブルに対してデータの整合性が保証されません。クエリの実行中に基になるデータを変更すると、予期しない動作が発生する可能性があります。
  • 外部テーブルに対するクエリのパフォーマンスは、標準 BigQuery テーブルのデータに対するクエリよりも低くなる可能性があります。クエリ速度を優先する場合は、外部データソースを設定するのではなく、データを BigQuery に読み込みます。外部テーブルを含むクエリのパフォーマンスは、外部ストレージのタイプに依存します。たとえば、Cloud Storage に格納されたデータのクエリは、Google ドライブに格納されたデータのクエリよりも高速です。一般的に、外部テーブルのクエリ パフォーマンスは、データソースからデータを直接読み取る処理と同等になります。
  • DML やその他の方法を使用して外部データテーブルを変更することはできません。BigQuery 用の外部テーブルは読み取り専用です。
  • TableDataList JSON API メソッドを使用して外部テーブルからデータを取得することはできません。詳細については、tabledata.list をご覧ください。

    この制限を回避するには、宛先テーブルにクエリ結果を保存します。その後、結果テーブルで TableDataList メソッドを使用できます。

  • 外部テーブルからデータをエクスポートする BigQuery ジョブは実行できません。

    この制限を回避するには、宛先テーブルにクエリ結果を保存します。次に、結果テーブルに対してエクスポート ジョブを実行します。

  • ワイルドカード テーブルのクエリで外部テーブルを参照することはできません。

  • 外部テーブルはクラスタリングをサポートしていません。パーティショニングは制限付きでサポートされています。詳細については、外部でパーティションに分割されたデータのクエリをご覧ください。

  • Cloud Storage 以外の外部データソースにクエリを実行する場合、結果はキャッシュに保存されません(Cloud Storage の Google SQL クエリはサポートされています)。同じクエリを複数回発行する場合でも、外部テーブルに対するクエリごとに課金されます。頻繁には変更されない外部テーブルに対してクエリを繰り返し発行する必要がある場合は、クエリ結果を永続的なテーブルに書き込み、永続的なテーブルに対してクエリを実行することを検討してください。

  • Cloud Bigtable 外部データソースに対する最大同時クエリ数は 4 です。

  • 外部テーブルを使用する連携クエリのドライランで、行が返されても 0 バイトの下限が報告される場合があります。これは、実際のクエリが完了するまで、外部テーブルで処理されるデータの量が確定できないためです。連携クエリを実行すると、このデータの処理に引き続き費用がかかります。

  • 外部テーブルでは、列名として _object_metadata を使用できません。これは内部用に予約されています。

ロケーションに関する留意事項

データのロケーションを選択するときは、次の点を考慮してください。

Cloud Storage

BigQuery を使用して Cloud Storage のデータを操作する方法は次のとおりです。

Cloud Storage データのクエリ

BigLake または BigLake 以外の外部テーブルを使用して Cloud Storage のデータにクエリを実行する場合、クエリするデータは BigQuery データセットと同じロケーションに配置する必要があります。 例:

  • シングル リージョンのバケット: BigQuery データセットがワルシャワ(europe-central2)リージョンにある場合、対応する Cloud Storage バケットもワルシャワ リージョンにある必要があります。これは現在、ワルシャワを含む Cloud Storage のデュアルリージョンがないためです。

    BigQuery データセットがマルチリージョンのいずれかにある場合、BigLake テーブルに対してクエリを実行すると、単一リージョンの Cloud Storage バケットの使用がサポートされます。

    BigQuery データセットがマルチリージョンのいずれかにある場合、BigLake 以外の外部テーブルに対してクエリを実行すると、単一リージョンの Cloud Storage バケットの使用はサポートされません。単一リージョンの Cloud Storage バケットの使用は、バケットがデータセットのマルチリージョン内に含まれるロケーションにある場合であってもサポートされません。たとえば、外部テーブルが EU マルチリージョンにあり、Cloud Storage バケットが europe-central2 にある場合、ジョブは失敗します。

  • デュアルリージョン バケット: BigQuery データセットが東京(asia-northeast1)リージョンにある場合、対応する Cloud Storage バケットは東京リージョンまたは ASIA1 デュアルリージョン(東京を含む)内のバケットである必要があります。

  • マルチリージョン バケット: 外部クエリのパフォーマンスは最小のレイテンシと最適なネットワーク帯域幅によって決まるため、外部データに対して、マルチリージョンの Cloud Storage バケットを持つマルチリージョン データセットのロケーションを使用することはおすすめしません

サポートされているCloud Storage のロケーションについて詳しくは、Cloud Storage ドキュメントのバケットのロケーションをご覧ください。

Cloud Storage からデータを読み込む

データを読み込むCloud Storage バケットを同じリージョンに配置する:
  • BigQuery データセットが EU マルチリージョンにある場合、読み込むデータが含まれている Cloud Storage バケットは、同じマルチリージョンまたはマルチリージョンに含まれるロケーションに存在する必要があります。たとえば、BigQuery データセットが EU マルチリージョンにある場合、Cloud Storage バケットは EU 内の europe-west1 ベルギー リージョンに配置できます。

    データセットが US マルチリージョンにある場合は、任意のロケーションにある Cloud Storage バケットからデータを読み込めます。

  • データセットがリージョンにある場合、Cloud Storage バケットは同じリージョンに存在する必要があります。たとえば、データセットが asia-northeast1 の東京リージョンにある場合、Cloud Storage バケットを ASIA マルチリージョンに配置することはできません。

詳細については、データ読み込みバッチをご覧ください。

Cloud Storage にデータをエクスポートする

データをエクスポートするには Cloud Storage バケットを同じリージョンに配置する:
  • BigQuery データセットが EU マルチリージョンにある場合、エクスポート対象のデータが含まれている Cloud Storage バケットは、同じマルチリージョンか、マルチリージョンに含まれているロケーションに存在する必要があります。たとえば、BigQuery データセットが EU マルチリージョンにある場合、Cloud Storage バケットは EU 内の europe-west1 ベルギー リージョンに配置できます。

    データセットが US マルチリージョンにある場合は、任意のロケーションにある Cloud Storage バケットにデータをエクスポートできます。

  • データセットがリージョンにある場合、Cloud Storage バケットは同じリージョンに存在する必要があります。たとえば、データセットが asia-northeast1 の東京リージョンにある場合、Cloud Storage バケットを ASIA マルチリージョンに配置することはできません。

詳細については、テーブルデータのエクスポートをご覧ください。

Cloud Bigtable

BigQuery 外部テーブルを介して Bigtable のデータにクエリを実行する場合は、Bigtable インスタンスが BigQuery データセットと同じロケーションに存在しなければなりません。

  • 単一リージョン: BigQuery データセットがベルギー(europe-west1)のリージョン ロケーションにある場合は、対応する Bigtable インスタンスがベルギー リージョンに存在しなければなりません。
  • マルチリージョン: 外部クエリのパフォーマンスは最小のレイテンシと最適なネットワーク帯域幅によって決定されるため、Bigtable の外部テーブルにマルチリージョン データセットのロケーションを使用することはおすすめしません

サポートされている Bigtable のロケーションについて詳しくは、Bigtable のロケーションをご覧ください。

Google ドライブ

ロケーションに関する考慮事項は、Google ドライブの外部データソースには適用されません。

Cloud SQL

BigQuery の連携クエリを使用して Cloud SQL のデータに対してクエリを実行する場合、Cloud SQL インスタンスは BigQuery データセットと同じロケーションに存在する必要があります。

  • 単一リージョン: BigQuery データセットがベルギー(europe-west1)のリージョン ロケーションにある場合は、対応する Cloud SQL インスタンスがベルギー リージョンに存在する必要があります。
  • マルチリージョン: BigQuery データセットが US マルチリージョンにある場合、対応する Cloud SQL インスタンスは米国の地理的エリアの単一リージョンに存在する必要があります。

サポートされている Cloud SQL のロケーションについて詳しくは、Cloud SQL のロケーションをご覧ください。

Cloud Spanner

BigQuery の連携クエリを使用して Spanner のデータに対してクエリを実行する場合、Cloud Spanner インスタンスは BigQuery データセットと同じロケーションに存在する必要があります。

  • 単一リージョン: BigQuery データセットがベルギー(europe-west1)のリージョン ロケーションにある場合は、対応する Spanner インスタンスがベルギー リージョンに存在する必要があります。
  • マルチリージョン: BigQuery データセットが US マルチリージョンにある場合、対応する Spanner インスタンスは米国の地理的エリアの単一リージョンに存在する必要があります。

サポートされている Spanner のロケーションについて詳しくは、Spanner のロケーションをご覧ください。

データ マネジメント

    データ管理計画を作成する:
    • BigQuery データセットや Cloud Storage バケットなどのリージョン ストレージ リソースを選択する場合は、データの地理的管理を行うための計画を作成します。

ロケーション間でのデータの移動

データセットをあるロケーションから別のロケーションに手動で移動するには、次の手順を行います。

  1. データセットと同じロケーションか、データセットのロケーションに含まれるロケーションの Cloud Storage バケットに、BigQuery テーブルからデータをエクスポートします。たとえば、データセットが「EU」マルチリージョン ロケーションにある場合は、EU の一部である「europe-west1」ベルギーのロケーションにデータをエクスポートできます。

    BigQuery からのデータのエクスポートに対しては課金されませんが、エクスポートしたデータを Cloud Storage に保存する場合は課金の対象になります。BigQuery からのエクスポートには、エクスポート ジョブの上限が適用されます。

  2. データを、Cloud Storage のエクスポート バケットから転送先の場所に作成した新しいバケットに、コピーまたは移動します。たとえば、「US」(マルチリージョン)から「asia-northeast1」(東京リージョン)にデータを移動すると、東京で作成したバケットにデータが転送されます。Cloud Storage オブジェクトの転送について詳しくは、Cloud Storage ドキュメントのオブジェクトのコピー、名前変更、移動をご覧ください。

    リージョン間でデータを転送すると、Cloud Storage でネットワークの下り(外向き)料金が発生することに注意してください。

  3. 新しいロケーションの Cloud Storage バケットにデータを転送した後、新しい BigQuery データセットを(新しいロケーションに)作成します。次に、Cloud Storage バケットから BigQuery にデータを読み込みます。

    BigQuery へのデータの読み込みに対しては課金されませんが、Cloud Storage にデータを保存した場合は課金の対象となり、データまたはバケットを削除するまで料金が請求されます。読み込まれたデータを BigQuery に保存することについても、請求の対象になります。BigQuery へのデータの読み込みには、読み込みジョブの上限が適用されます。

また、Cloud Composer を使用して、大規模なデータセットをプログラムで移動し、コピーすることもできます。

Cloud Storage を使用した大量のデータセットの保存や移動に関する詳細は、Cloud Storage とビッグデータの使用をご覧ください。

料金

BigQuery から外部テーブルに対してクエリを実行する場合、クエリの実行に対して課金されます。

データが Cloud Storage の ORC または Parquet に格納されている場合は、データサイズの計算をご覧ください。

また、アプリケーションの料金設定のガイドラインに従い、ソース アプリケーションで使用されるデータやリソースの保存に対しても請求されます。

  • Cloud Storage の料金については、Cloud Storage の料金をご覧ください。
  • Cloud Bigtable の料金については、料金をご覧ください。
  • ドライブの料金については、料金をご覧ください。

次のステップ