Amazon S3 転送の概要

BigQuery Data Transfer Service for Amazon S3 を使用すると、Amazon S3 から BigQuery への定期的な読み込みジョブを自動的にスケジュールし、管理できます。

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

BigQuery Data Transfer Service では、次のいずれかの形式で Amazon S3 からデータを読み込むことができます。

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

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

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

Amazon S3 の前提条件

Amazon S3 のデータソースからデータを読み込むには、以下を行う必要があります。

  • ソースデータの Amazon S3 URI を指定する
  • アクセスキー ID を用意する
  • シークレット アクセスキーを用意する
  • Amazon S3 ソースデータに対して少なくとも AWS 管理ポリシー AmazonS3ReadOnlyAccess を設定する

Amazon S3 の URI

Amazon S3 URI を指定する際は、パスに s3://bucket/folder1/folder2/... の形式を使用する必要があります。最上位のバケット名のみが必要です。フォルダ名は省略可能です。URI にバケット名のみを指定した場合、そのバケット内のすべてのファイルが BigQuery に転送され、読み込まれます。

Amazon S3 転送のランタイムのパラメータ化

Amazon S3 の URI と宛先テーブルはどちらもパラメータ化が可能で、日付順に整理された Amazon S3 バケットからデータを読み込めます。ただし、URI のバケット部分はパラメータ化できません。Amazon S3 の転送で使用されるパラメータは、Cloud Storage の転送で使用されるものと同じです。

詳細については、転送のランタイム パラメータをご覧ください。

Amazon S3 転送のデータ取り込み

Amazon S3 転送を設定するとき、転送構成で書き込み設定を選択することにより、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 がデータを重複させる可能性があります。

Amazon S3 の URI でのワイルドカードの使用

ソースデータが、共通のベース名を持つ複数のファイルに分割されている場合は、データを読み込むときに URI でワイルドカードを使用できます。ワイルドカードはアスタリスク（*）からなり、Amazon S3 URI の任意の場所で使用できます。ただし、URI のバケット名では使用できません。

Amazon S3 URI では複数のワイルドカードを使用できますが、Amazon S3 URI でワイルドカードを 1 つだけ指定すると、最適化が可能になります。

  • 転送実行ごとの最大ファイル数には上限があります。

  • ワイルドカードはディレクトリの境界をまたがって適用されます。たとえば、Amazon S3 の URI s3://my-bucket/*.csv はファイル s3://my-bucket/my-folder/my-subfolder/my-file.csv と一致します。

Amazon S3 URI の例

例 1

Amazon S3 からファイル 1 つを BigQuery に読み込むには、ファイルの Amazon S3 URI を指定します。

s3://my-bucket/my-folder/my-file.csv

例 2

Amazon S3 バケットからすべてのファイルを BigQuery に読み込むには、バケット名のみを指定します。ワイルドカードの使用は任意です。

s3://my-bucket/

または

s3://my-bucket/*

バケット名にはワイルドカードを使用できないため、s3://my-bucket* は Amazon S3 URI として許容されません。

例 3

Amazon S3 から共通のプレフィックスを共有するすべてのファイルを読み込むには、共通のプレフィックスの後に続けてワイルドカードを指定します。

s3://my-bucket/my-folder/*

最上位の Amazon S3 バケットからすべてのファイルを読み込む場合とは異なり、読み込むファイルの Amazon S3 URI の末尾にワイルドカードを指定する必要があります。

例 4

Amazon S3 からパスが同様のすべてのファイルを読み込むには、共通のプレフィックスの後に続けてワイルドカードを指定します。

s3://my-bucket/my-folder/*.csv

例 5

注意する点として、ワイルドカードはディレクトリをまたいで適用されます。したがって、my-folder 内だけでなく、my-folder のサブフォルダ内の csv ファイルも BigQuery に読み込まれます。

logs フォルダ内に次のソースファイルがあるとします。

s3://my-bucket/logs/logs.csv
s3://my-bucket/logs/system/logs.csv
s3://my-bucket/logs/some-application/system_logs.log
s3://my-bucket/logs/logs_2019_12_12.csv

これらのファイルは次の値と一致することになります。

s3://my-bucket/logs/*

例 6

次のソースファイルの中から、名前に logs.csv が含まれるファイルだけを転送するとします。

s3://my-bucket/logs.csv
s3://my-bucket/metadata.csv
s3://my-bucket/system/logs.csv
s3://my-bucket/system/users.csv
s3://my-bucket/some-application/logs.csv
s3://my-bucket/some-application/output.csv

名前に logs.csv が含まれるファイルは次の値によって確認できます。

s3://my-bucket/*logs.csv

例 7

複数のワイルドカードを使用すると、転送するファイルをよりきめ細かく制御できますが、転送できるファイル数の上限が低くなります。複数のワイルドカードを使用すると、それぞれのワイルドカードがサブディレクトリ内のパスの末尾にのみ一致することになります。たとえば、Amazon S3 内に次のソースファイルがあるとします。

s3://my-bucket/my-folder1/my-file1.csv
s3://my-bucket/my-other-folder2/my-file2.csv
s3://my-bucket/my-folder1/my-subfolder/my-file3.csv
s3://my-bucket/my-other-folder2/my-subfolder/my-file4.csv

my-file1.csv と my-file2.csv のみを転送しようとする場合、Amazon S3 URI として次の値を使用します。

s3://my-bucket/*/*.csv

この例の場合、いずれのワイルドカードもディレクトリをまたいで適用されることはないため、この URI では、my-folder1 フォルダと my-other-folder2 フォルダ内にある CSV ファイルだけが転送されます。サブフォルダは転送の対象になりません。

AWS のアクセスキー

アクセスキー ID とシークレット アクセスキーは、ユーザーに代わって Amazon S3 のデータにアクセスするために使用されます。BigQuery Data Transfer Service へのアクセスを最小限に抑えるために、Amazon S3 転送専用の固有のアクセスキー ID とシークレット アクセスキーを作成することをおすすめします。アクセスキーの管理については、AWS 全般のリファレンスをご覧ください。

整合性に関する留意事項

Amazon S3 からデータを転送する際、バケットにファイルが追加されて間もない場合は特に、一部のデータが BigQuery に転送されない可能性があります。ファイルがバケットに追加されてから BigQuery Data Transfer Service で使用できるようになるまでに約 10 分かかります。ただし、場合によっては 10 分以上かかることがあります。

Amazon S3 整合性モデルの詳細については、Amazon S3 ドキュメントの Amazon S3 のデータ整合性モデルをご覧ください。

アウトバウンド データ転送の費用に関するベスト プラクティス

宛先テーブルが正しく構成されていないと、Amazon S3 からの転送が失敗する可能性があります。不適切な構成になる原因としては、次が挙げられます。

  • 宛先テーブルが存在しない。
  • テーブル スキーマが定義されていない。
  • テーブル スキーマと転送されるデータとの互換性がない。

Amazon S3 のアウトバウンド データ転送の費用が発生しないようにするには、まず、サイズが小さく、代表的なファイルのサブセットで転送をテストする必要があります。ここで言う「小さい」とは、データサイズが小さく、少数のファイルでテストを行うことを意味します。

料金

BigQuery Data Transfer Service の料金については、料金をご覧ください。

このサービスを使用すると、Google 以外で費用が発生する可能性があります。詳しくは、Amazon S3 の料金をご覧ください。

割り当てと上限

BigQuery Data Transfer Service は、読み込みジョブを使用して Amazon S3 データを BigQuery に読み込みます。定期的な Amazon S3 転送には、BigQuery の読み込みジョブに関するすべての割り当てと上限に加え、次の考慮事項も適用されます。

値 上限
読み込みジョブの転送実行ごとの最大サイズ 15 TB
Amazon S3 URI に 0～1 個のワイルドカードを使用する場合の転送実行ごとの最大ファイル数 10,000,000 ファイル
Amazon S3 URI に複数のワイルドカードを使用する場合の転送実行ごとの最大ファイル数 10,000 ファイル

次のステップ