Cloud Storage の転送の概要

BigQuery Data Transfer Service for Cloud Storage では、Cloud Storage バケットから BigQuery への定期的なデータ読み込みをスケジュールできます。Cloud Storage に保存されているデータへのパスと宛先テーブルの両方をパラメータ化して、日付で整理された Cloud Storage バケットからデータを読み込むことができます。

サポートされているファイル形式

現在 BigQuery Data Transfer Service では、次のいずれかの形式で Cloud Storage からのデータの読み込みをサポートしています。

  • カンマ区切り値（CSV）
  • JSON（改行区切り）
  • Avro
  • Parquet
  • ORC

サポートされている圧縮タイプ

BigQuery Data Transfer Service for Cloud Storage は、圧縮データの読み込みをサポートしています。BigQuery Data Transfer Service でサポートされている圧縮タイプは、BigQuery の読み込みジョブでサポートされているものと同じです。詳細については、圧縮データと非圧縮データを読み込むをご覧ください。

Cloud Storage 転送のデータの取り込み

Cloud Storage の転送を設定するときに転送構成で [書き込み設定] を選択することで、BigQuery へのデータの読み込み方法を指定できます。

書き込み設定には、増分転送と切り捨て転送の 2 種類があります。

増分転送

APPEND または WRITE_APPEND の書き込み設定がある転送構成（増分転送とも呼ばれる）では、前回成功した BigQuery の宛先テーブルへの転送以降の新しいデータの増分が追加されます。転送構成が APPEND の書き込み設定で実行されると、BigQuery Data Transfer Service は、前回の転送実行後に変更されたファイルを絞り込みます。ファイルが変更されたタイミングを判断するため、BigQuery Data Transfer Service は、ファイルのメタデータで「最終更新日時」プロパティを確認します。たとえば、BigQuery Data Transfer Service は、Cloud Storage ファイルの updated タイムスタンプ プロパティを参照します。BigQuery Data Transfer Service では、「最終更新日時」が最後に成功した転送のタイムスタンプより後のファイルが見つかると、BigQuery Data Transfer Service によってそれらのファイルが増分転送で転送されます。

増分転送の仕組みを示すために、次の Cloud Storage 転送の例を考えます。時刻 2023-07-01T00:00Z に、あるユーザーが Cloud Storage バケットに file_1 というファイルを作成します。file_1 の updated タイムスタンプは、ファイルが作成された時刻です。次にユーザーは、Cloud Storage バケットからの増分転送を作成し、2023-07-01T03:00Z から、毎日 1 回、時刻 03:00Z に実行されるようにスケジュール設定します。

  • 2023-07-01T03:00Z に、最初の転送実行が開始されます。これがこの構成での最初の転送実行であるため、BigQuery Data Transfer Service は、転送元 URI に一致するすべてのファイルを宛先 BigQuery テーブルに読み込むことを試みます。転送実行は成功し、BigQuery Data Transfer Service が宛先 BigQuery テーブルに file_1 を正常に読み込みます。
  • 次の転送実行（2023-07-02T03:00Z）では、最後に成功した転送実行（2023-07-01T03:00Z）より updated タイムスタンプ プロパティが大きいファイルは検出されません。転送実行は、転送先の BigQuery テーブルに追加のデータを読み込むことなく成功します。

前述の例は、BigQuery Data Transfer Service がソースファイルの updated タイムスタンプ プロパティを確認し、ソースファイルに変更が加えられているかどうかを判断して、変更が検出された場合はその変更を転送する方法を示しています。

同じ例に沿って、ユーザーが Cloud Storage バケットに、別のファイルを file_2 という名前で時刻 2023-07-03T00:00Z に作成したとします。file_2 の updated タイムスタンプは、ファイルが作成された時刻です。

  • 次の転送実行（2023-07-03T03:00Z）で、file_2 の updated タイムスタンプが最後に成功した転送実行（2023-07-01T03:00Z）より大きいことが検出されます。転送実行の開始時に、一時的なエラーで失敗したとします。このシナリオでは、file_2 は宛先 BigQuery テーブルに読み込まれません。最後に成功した転送実行のタイムスタンプは 2023-07-01T03:00Z のままです。
  • 次の転送実行（2023-07-04T03:00Z）で、file_2 の updated タイムスタンプが最後に成功した転送実行（2023-07-01T03:00Z）より大きいことが検出されます。今回は、転送実行が問題なく完了するため、転送先 BigQuery テーブルに file_2 が正常に読み込まれます。
  • 次の転送実行（2023-07-05T03:00Z）では、最後に成功した転送実行（2023-07-04T03:00Z）より updated タイムスタンプが大きいファイルは検出されません。転送実行は、転送先の BigQuery テーブルに追加のデータを読み込むことなく成功します。

前述の例では、転送が失敗した場合、BigQuery の宛先テーブルに転送されるファイルがありません。ファイルの変更は、次に転送の実行が成功したときに転送されます。失敗した転送に続いて成功した転送で重複データは発生しません。転送が失敗した場合は、定期的に予定されている時間外に転送を手動でトリガーすることもできます。

切り捨て転送

MIRROR または WRITE_TRUNCATE の書き込み設定がある転送構成（切り捨て転送とも呼ばれる）は、各転送の実行時に、BigQuery 宛先テーブルのデータを、ソース URI に一致するすべてのファイルのデータで上書きします。MIRROR は、宛先テーブル内のデータの新しいコピーを上書きします。宛先テーブルがパーティション デコレータを使用している場合、転送実行では指定されたパーティションのデータのみが上書きされます。パーティション デコレータがある宛先テーブルの形式は、my_table${run_date} になります（例: my_table$20230809）。

同じ増分転送や切り捨て転送を 1 日で繰り返しても、データの重複は発生しません。ただし、同じ BigQuery 宛先テーブルに影響する複数の転送構成を実行すると、BigQuery Data Transfer Service がデータを重複させる可能性があります。

Cloud Storage リソースパス

Cloud Storage データソースからデータを読み込むには、データへのパスを指定する必要があります。

Cloud Storage のリソースパスには、バケット名とオブジェクト（ファイル名）が含まれます。たとえば、Cloud Storage バケットの名前が mybucket でデータファイルの名前が myfile.csv の場合、リソースパスは gs://mybucket/myfile.csv になります。

BigQuery では、最初のダブル スラッシュの後に複数の連続スラッシュが含まれる Cloud Storage リソースパスはサポートされていません。Cloud Storage オブジェクトの名前には複数の連続スラッシュ（"/"）文字を含めることができます。一方、BigQuery では、複数の連続スラッシュは単一のスラッシュに変換されます。たとえば、リソースパス gs://bucket/my//object//name は Cloud Storage では有効ですが、BigQuery では機能しません。

Cloud Storage のリソースパスを取得するには:

  1. Cloud Storage コンソールを開きます。

    Cloud Storage コンソール

  2. ソースデータを含むオブジェクト（ファイル）の場所に移動します。

  3. オブジェクトの名前をクリックします。

    [オブジェクトの詳細] ページが開きます。

  4. [gsutil URI] フィールドに表示されている値（gs:// で始まる）をコピーします。

Cloud Storage のリソースパスのワイルドカード サポート

Cloud Storage データを共通のベース名を持つ複数のファイルに分割した場合は、データを読み込むときにリソースパスでワイルドカードを使用できます。

Cloud Storage リソースパスにワイルドカードを追加するには、ベース名にアスタリスク（*）を加えます。たとえば、fed-sample000001.csv と fed-sample000002.csv という 2 つのファイルがある場合、リソースパスは gs://mybucket/fed-sample* になります。このワイルドカードは、Google Cloud コンソールまたは Google Cloud CLI で使用できます。

バケット内のオブジェクト（ファイル名）には複数のワイルドカードを使用できます。ワイルドカードは、オブジェクト名の任意の場所で使用できます。

ワイルドカードが gs://bucket/ 内のディレクトリを展開することはありません。たとえば、gs://bucket/dir/* で dir ディレクトリ内のファイルを見つけることはできますが、gs://bucket/dir/subdir/ サブディレクトリ内のファイルを見つけることはできません。

ワイルドカードを使用せずに接頭辞に一致させることもできません。たとえば、gs://bucket/dir は gs://bucket/dir/file.csv とも gs://bucket/file.csv とも一致しません。

ただし、バケット内のファイル名には複数のワイルドカードを使用できます。たとえば、gs://bucket/dir/*/*.csv は gs://bucket/dir/subdir/file.csv と一致します。

パラメータ化されたテーブル名と組み合わせたワイルドカードの使用例については、転送でのランタイム パラメータをご覧ください。

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

Cloud Storage バケットは、BigQuery の宛先データセットのリージョンまたはマルチリージョンと互換性のあるリージョンまたはマルチリージョンに存在する必要があります。

  • BigQuery データセットがマルチリージョンにある場合、転送するデータが含まれている Cloud Storage バケットは、同じマルチリージョンまたはマルチリージョンに含まれるロケーションに存在する必要があります。たとえば、BigQuery データセットが「EU」マルチリージョンにある場合、Cloud Storage バケットは EU 内の「europe-west1」ベルギー リージョンに配置できます。
  • データセットがリージョンにある場合、Cloud Storage バケットは同じリージョンに存在する必要があります。たとえば、データセットが「asia-northeast1」東京リージョンにある場合、Cloud Storage バケットを「ASIA」マルチリージョンに配置することはできません。

転送とリージョンについて詳しくは、データセットのロケーションと転送をご覧ください。

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

料金

  • 読み込みジョブに対する標準の BigQuery の割り当てと上限が適用されます。

  • データが BigQuery に転送されると、BigQuery のストレージとクエリの標準料金が適用されます。

  • 転送を設定する際にアップロード済みのデータの削除を指定しない限り、データが BigQuery にアップロードされたあと、Cloud Storage バケットから自動で削除されることはありません。Cloud Storage の転送の設定をご覧ください。

  • 詳細については、転送の料金ページをご覧ください。

割り当てと上限

BigQuery Data Transfer Service は読み込みジョブを使用して、Cloud Storage データを BigQuery に読み込みます。

定期的な Cloud Storage 読み込みジョブには、BigQuery の読み込みジョブに対するすべての割り当てと上限が適用されます。また、次の点に注意してください。

値 上限
読み込みジョブの転送実行ごとの最大サイズ 15 TB
転送実行ごとの最大ファイル数 10,000 ファイル

次のステップ