データの読み込みの概要

このドキュメントでは、BigQuery へのデータの読み込みの概要を説明します。

データの読み込み方法

BigQuery にデータを読み込む（取り込む）には、いくつかの方法があります。

  • データレコードのセットを一括で読み込む。
  • 個別のレコードまたはレコードのバッチをストリーミングする。
  • クエリを使用して新しいデータを生成し、結果をテーブルに追加または上書きする。
  • サードパーティのアプリケーションやサービスを使用する。

バッチ読み込み

バッチ読み込みでは、単一のバッチ オペレーションでソースデータを BigQuery テーブルに読み込みます。たとえば、データソースとして CSV ファイル、外部データベース、ログファイルのセットなどを使用できます。従来の抽出、変換、読み込み（ETL）ジョブはこのカテゴリに分類されます。

BigQuery の一括読み込みのオプションは次のとおりです。

  • 読み込みジョブ。読み込みジョブを作成して、Cloud Storage またはローカル ファイルからデータを読み込みます。レコードは、Avro、CSV、JSON、ORC、Parquet 形式のいずれかになります。
  • SQL。LOAD DATA SQL ステートメントは、1 つ以上のファイルからデータを新規または既存のテーブルに読み込みます。LOAD DATA ステートメントを使用して、Avro、CSV、JSON、ORC、Parquet のファイルを読み込むことができます。
  • BigQuery Data Transfer Service。BigQuery Data Transfer Service を使用して、Google の Software as a Service（SaaS）アプリまたはサードパーティのアプリケーションやサービスからのデータの読み込みを自動化します。
  • BigQuery Storage Write API。Storage Write API を使用すると、多数のレコードをバッチ処理して、1 回のアトミック操作で commit できます。commit オペレーションが失敗した場合、オペレーションを安全に再試行できます。BigQuery の読み込みジョブとは異なり、Storage Write API では、Cloud Storage などの中間ストレージにデータをステージングする必要はありません。
  • その他のマネージド サービス。他のマネージド サービスを使用して、外部データストアからデータをエクスポートし、BigQuery にインポートします。たとえば、Firestore エクスポートなどからデータを読み込めます。

バッチ読み込み方法を選択する場合、ほとんどのファイルベースのパターンでは、読み込みジョブまたは LOAD DATA SQL ステートメントを使用してデータをバッチ読み込みする必要があります。他のサービスでは、通常、BigQuery Data Transfer Service を使用するか、Google サービスからデータをエクスポートする必要があります。

一括読み込みは、一回限りまたは定期的なスケジュールで行えます。たとえば、次の操作が可能です。

  • BigQuery Data Transfer Service の転送はスケジュールに基づいて実行できます。
  • Cloud Composer などのオーケストレーション サービスを使用して、読み込みジョブをスケジュールできます。
  • cron ジョブを使用して、スケジュールに従ってデータを読み込めます。

ストリーミング

ストリーミングでは、より小さいバッチデータがリアルタイムで継続的に送信されるため、データの到着時にそのデータに対するクエリを実行できます。BigQuery のストリーミングには次のオプションがあります。

  • Storage Write API。Storage Write API では、1 回限りの配信セマンティクスを持つ、高スループットのストリーミング取り込みがサポートされています。
  • Dataflow。Dataflow を Apache Beam SDK で使用して、BigQuery に書き込むストリーミング パイプラインを設定します。詳細については、Apache Beam ドキュメントの BigQuery I/O コネクタと Pub/Sub から BigQuery へのストリーミングのチュートリアルをご覧ください。
  • Datastream。Datastream は、BigQuery の変更データ キャプチャ機能と Storage Write API を使用して、オペレーショナル データベースからデータとスキーマの更新を BigQuery に直接複製します。このクイックスタートでは、Cloud SQL for PostgreSQL データベースから BigQuery に複製する例をご覧ください。
  • BigQuery Connector for SAP。BigQuery Connector for SAP を使用すると、SAP データを BigQuery にほぼリアルタイムで直接複製できます。詳しくは、BigQuery Connector for SAP のプランニング ガイドをご覧ください。
  • Pub/Sub。Pub/Sub は、ストリーミング分析とデータ統合パイプラインを調整するために使用できるメッセージング サービスです。BigQuery サブスクリプションを使用すると、既存の BigQuery テーブルに直接メッセージを書き込むことができます。

生成されたデータ

SQL を使用してデータを生成し、結果を BigQuery に保存できます。データの生成には次のオプションがあります。

  • データ操作言語（DML）ステートメントを使用する。既存のテーブルへの一括挿入や、新しいテーブルへのクエリ結果の保存を行うことができます。

  • CREATE TABLE ... AS ステートメントを使用して、クエリ結果から新しいテーブルを作成する。

  • クエリを実行し、結果をテーブルに保存する。既存のテーブルへの結果の追加や、新しいテーブルへの書き込みを行うことができます。詳細については、クエリ結果の書き込みをご覧ください。

サードパーティ アプリケーション

一部のサードパーティ アプリケーションやサービスでは、データを BigQuery に取り込むためのコネクタが提供されています。取り込みパイプラインを構成および管理する方法の詳細は、アプリケーションによって異なります。たとえば、外部ソースから BigQuery のストレージにデータを読み込むには、Informatica Data Loader または Fivetran Data Pipelines を使用します。詳細については、サードパーティ アプリケーションを使用してデータを読み込むをご覧ください。

データの取り込み方法の選択

データの取り込み方法を選択する際は、次の点を考慮してください。

データソース。データのソースやデータ形式から、一括読み込みとストリーミングのどちらが簡単に実装、維持できるかを判断できます。以下の点について検討してください。

  • BigQuery Data Transfer Service がデータソースをサポートしている場合は、BigQuery に直接データを転送することが最も簡単に実装できるソリューションである場合があります。

  • BigQuery Data Transfer Service でサポートされていないサードパーティのソースからのデータの場合、バッチ読み込みでサポートされている形式にデータを変換して、代わりにその方法を使用します。

  • データが Spark または Hadoop にある場合は、BigQuery コネクタを使用してデータの取り込みを簡易化することを検討してください。

  • ローカル ファイルの場合、特に BigQuery が変換やデータ クレンジングを必要としないファイル形式をサポートしている場合は、一括読み込みを検討してください。

  • アプリケーション イベントやログストリームなどのアプリケーション データの場合、一括読み込みを実装するよりも、データをリアルタイムでストリーミングする方が簡単な場合があります。

変化の少ないデータか、多いデータか。ほぼリアルタイムでデータを取り込んで分析する必要がある場合は、データのストリーミングを検討してください。ストリーミングでは、レコードが受信された後すぐにデータをクエリできます。個別の行の更新や挿入を大量に送信するために DML ステートメントを使用しないでください。頻繁に更新されるデータの場合は、変更ログをストリーミングして、ビューを使用して最新の結果を取得するほうが良い場合があります。また、オンライン トランザクション処理（OLTP）データベースとして Cloud SQL を使用し、連携クエリを使用して BigQuery のデータを結合することもできます。

ソースデータの変更が少ない場合や、継続的に更新される結果を必要としない場合は、読み込みジョブの使用を検討してください。たとえば、データを使用して日単位または時間単位のレポートを実行する場合、読み込みジョブを使用することで、費用や消費されるシステム リソースを抑えることができる可能性があります。

また、受信頻度が低いデータやイベントに応じたデータもあります。その場合、Dataflow を使用してデータをストリーミングするか、Cloud Functions を使用してトリガーに応じてストリーミング API を呼び出すことを検討してください。

ソリューションの信頼性。BigQuery にはサービスレベル契約（SLA）がありますが、実装する特定のソリューションの信頼性も考慮する必要があります。以下の点について検討してください。

  • JSON や CSV などの大まかな型のフォーマットを使用すると、不良なデータによって読み込みジョブ全体が失敗する可能性があります。読み込み前にデータのクレンジングが必要かどうかを検討し、エラーの応答方法を検討します。また、Avro、ORC、Parquet などの厳密な型のフォーマットの使用を検討してください。
  • 定期的な読み込みジョブを行うには、Cloud Composer や cron など、別のツールを使用してスケジュールを設定する必要があります。スケジューリング コンポーネントは、ソリューションにおける失敗点になる可能性があります。
  • ストリーミングの場合、各レコードの成功を確認し、エラーをすばやく報告できます。後で分析と処理を行うために、処理されなかったメッセージを未処理のメッセージ キューに書き込むことを検討してください。BigQuery ストリーミング エラーの詳細については、ストリーミング挿入に関するトラブルシューティングをご覧ください。
  • ストリーミング ジョブと読み込みジョブは割り当ての対象です。割り当てエラーを処理する方法については、BigQuery 割り当てエラーのトラブルシューティングをご覧ください。
  • サードパーティ ソリューションは構成の柔軟性、信頼性、順序付けの保証などの要因によって異なる場合があるため、ソリューションを採用する前に以下を検討してください。

レイテンシ。読み込むデータの量と、データが利用可能になるまでの時間について検討してください。ストリーミングの場合、データを分析に利用できるようになるまでのレイテンシを最も低く抑えられます。定期的な読み込みジョブの場合、それぞれの読み込みジョブが完了してから新しいデータを利用できるようになるため、レイテンシが高くなります。

読み込みジョブではデフォルトでスロットの共有プールが使用されます。読み込みジョブでは、スロットが利用可能な状態になるまで保留状態で待機することがあります。特に大量のデータを読み込む場合は、保留状態になる可能性があります。この保留時間が許容できない場合は、共有スロットプールではなく専用のスロットを購入してください。詳細については、予約の概要をご覧ください。

外部データソースに対するクエリ パフォーマンスは、BigQuery に格納されているデータに対するクエリ パフォーマンスよりも低くなる場合があります。クエリのレイテンシを最小限に抑えることが重要な場合は、データを BigQuery に読み込むことをおすすめします。

データの取り込み形式。データの取り込み形式を以下の要素に基づいて選択します。

  • スキーマのサポート。Avro、ORC、Parquet、Firestore エクスポートは自己記述型です。BigQuery は、ソースデータに基づいてテーブル スキーマを自動的に作成します。JSON データと CSV データには、明示的なスキーマを指定するか、スキーマ自動検出を使用できます。

  • フラットデータ、またはネストされた繰り返しフィールド。 Avro、CSV、JSON、ORC、Parquet ではフラットデータがサポートされています。Avro、JSON、ORC、Parquet、Firestore エクスポートでは、ネストされたフィールドや繰り返しフィールドを使用したデータもサポートされます。ネストされたデータや繰り返しデータは、階層データの表現に役立ちます。ネストされたフィールドと繰り返しフィールドを使用すると、データの読み込み時のデータの重複も削減されます。

  • 埋め込みの改行。JSON ファイルからデータを読み込むときは、行を改行で区切る必要があります。BigQuery は、改行で区切られた JSON ファイルには 1 行に 1 つのレコードが含まれているものと想定します。

  • エンコード。BigQuery は、ネストされたデータまたは繰り返しデータとフラットデータの両方について UTF-8 エンコードをサポートします。CSV ファイルの場合のみ、フラットデータについて ISO-8859-1 エンコードもサポートします。

ネストされたデータと繰り返しデータを読み込む

次のデータ形式で、ネストされたフィールドと繰り返しフィールドにデータを読み込むことができます。

  • Avro
  • JSON（改行区切り）
  • ORC
  • Parquet
  • Datastore エクスポート
  • Firestore エクスポート

データを読み込むとき、ネストされたフィールドと繰り返しフィールドをスキーマに指定する方法については、ネストされたフィールドと繰り返しフィールドの指定をご覧ください。

他の Google サービスからデータを読み込む

一部の Google サービスは、スケジュールされたクエリ、エクスポート、転送を使用してデータを BigQuery にエクスポートします。BigQuery へのエクスポートをサポートするサービスの詳細については、Google サービスからデータを読み込むをご覧ください。

他の Google サービスでは、BigQuery Data Transfer Service から開始されたデータ エクスポートがサポートされています。BigQuery Data Transfer Service によって開始されたエクスポートをサポートするサービスの詳細については、BigQuery Data Transfer Service をご覧ください。

割り当て

割り当ての詳細については、次のセクションをご覧ください。

データ読み込みに代わる方法

次のような状況でクエリを実行する場合は、データを読み込む必要はありません。

公開データセット
一般公開データセットとは、BigQuery に保存されて、一般公開されるデータセットです。詳細については、BigQuery 一般公開データセットをご覧ください。
共有データセット
BigQuery に格納したデータセットは共有できます。別のユーザーのデータセットを共有している場合は、そのデータを読み込まなくても、データセットに対してクエリを実行できます。
外部データソース
BigQuery では、データを BigQuery ストレージに読み込むことなく、特定の形式の外部データに対してクエリを実行できます。このアプローチでは、別の場所に保存されているデータを移動することなく、BigQuery の分析機能を活用できます。この方式の利点と制限については、外部データソースをご覧ください。
ファイルのロギング
Cloud Logging には、ログファイルを BigQuery にエクスポートするオプションがあります。詳しくは、シンクを構成、管理するをご覧ください。

読み込みジョブの使用状況をモニタリングする

読み込みジョブの使用状況は、次の 2 つの方法でモニタリングできます。

  • Cloud Monitoring を使用する。詳細については、BigQuery の指標をご覧ください。具体的には、特定のテーブルにアップロードされたデータ量と行数をモニタリングできます。読み込みジョブが特定のテーブルにデータをアップロードする場合、読み込みジョブのアップロード データ使用量をモニタリングするためのプロキシとして使用できます。

  • INFORMATION_SCHEMA.JOBS_BY_PROJECT を使用します。INFORMATION_SCHEMA.JOBS_BY_PROJECT ビューを使用すると、テーブルごとの 1 日あたりの読み込みジョブ数を取得できます。

使用例

次の例では、ユースケースに基づいた使用方法と、他のデータ分析ソリューションでの使用方法について説明します。

Storage Write API を使用したデータのストリーミング

エンドポイント ログのイベントデータを処理するパイプラインがあるとします。イベントは継続的に生成され、できるだけ早く BigQuery でのクエリで使用できるようにする必要があります。このユースケースではデータの更新頻度が最重要であるため、BigQuery にデータを取り込むには Storage Write API が最適です。エンドポイントを無駄のないものにするための推奨アーキテクチャは、BigQuery に直接ストリーミングする Dataflow ストリーミング パイプラインで消費されるイベントから Pub/Sub にイベントを送信することです。

このアーキテクチャの信頼性に関する主な懸念事項は、BigQuery にレコードを挿入できない場合の対処方法です。各レコードが重要であり、失われることができない場合は、挿入する前にデータをバッファする必要があります。上記の推奨アーキテクチャでは、Pub/Sub がメッセージ保持機能を備えたバッファの役割を果たすことができます。Dataflow パイプラインは、切り捨て型指数バックオフを使用して BigQuery ストリーミング挿入を再試行するように構成する必要があります。バッファとしての Pub/Sub の容量を使い切ると（BigQuery が長期間使用できない場合やネットワーク障害が発生した場合など）、データをクライアントで維持する必要があり、クライアントでは可用性の復元後に永続レコードの挿入を再開するためのメカニズムが必要です。この状況に対処する方法の詳細については、Google Pub/Sub 信頼性ガイドのブログ投稿をご覧ください。

もう 1 つの処理の失敗ケースとして、ポイズン レコードがあります。ポイズン レコードは、再試行不可能なエラーでレコードの挿入に失敗したために BigQuery によって拒否されたレコードか、最大再試行回数後に正常に挿入されなかったレコードです。両方のタイプのレコードを、さらに調査するために Dataflow パイプラインによって「デッドレター キュー」に保存する必要があります。

exactly-once セマンティクスが必要な場合は、クライアントによって提供されるレコード オフセットを使用して、コミット型で書き込みストリームを作成します。これによって重複が回避され、オフセット値が次に追加されたオフセットに一致する場合にのみ、書き込みオペレーションが実行されます。オフセットを指定しないと、レコードがストリームの現在の末尾に追加され、失敗した追加を再試行すると、レコードがストリーム内に複数回表示される可能性があります。

exactly-once 保証が不要な場合は、デフォルト ストリームへの書き込みによりスループットが向上し、書き込みストリームの作成の割り当て上限にもカウントされません。

ネットワークのスループットを見積もり、スループットを提供するための十分な割り当てがあることを前もって確認します。

ワークロードによって非常に不均一にデータが生成または処理されている場合、クライアントでの負荷の急増を抑制し、一定のスループットで BigQuery にストリーミングしてみてください。これにより、キャパシティ プランニングを簡素化できます。それができない場合は、短時間の急増中にスループットが割り当てを超過した場合に 429（リソース不足）エラーを処理できるように準備してください。

バッチデータ処理

決められた期限までに完了する必要がある夜間のバッチ処理パイプラインがあるとします。規制当局に送信するレポートを生成するには、別のバッチ処理でさらに処理を行ってこの期限までにデータを使用可能にする必要があります。このユースケースは金融などの規制が多い業界では一般的です。

期限が満たされていれば、レイテンシは問題にならないため、このユースケースに適したアプローチは、読み込みジョブを使用したデータの一括読み込みとなります。Cloud Storage バケットが BigQuery データセットにデータを読み込むためのロケーションの要件を満たしていることを確認します。

BigQuery の読み込みジョブの結果はアトミックです。すべてのレコードが挿入されるか、どれも挿入されません。ベスト プラクティスとして、単一の読み込みジョブにすべてのデータを挿入する場合は、JobConfigurationLoad リソースの WRITE_TRUNCATE 処理を使用して新しいテーブルを作成します。たとえば、成功状態をクライアントに返す際など、クライアントが失敗したジョブと引き起こされた失敗を区別できない可能性があるため、これは失敗した読み込みジョブを再試行する場合に重要です。

取り込まれるデータがすでに Cloud Storage に正常にコピーされていると仮定すれば、指数バックオフを使用して再試行するだけで取り込みの失敗に対処できます。

再試行を含めても、夜間のバッチジョブでテーブルごとに 1 日あたり 1,500 回の読み込みというデフォルトの割り当てに達しないようにすることをおすすめします。データを段階的に読み込む場合は、デフォルトの割り当てで 5 分ごとに読み込みジョブを実行できますが、ジョブごとに少なくとも 1 回の再試行の未消化の割り当てが必要です。

次のステップ