データの読み込みの概要

このページでは、BigQuery へのデータの読み込みの概要を説明します。

概要

BigQuery にデータを取り込む方法はいくつかあります。

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

このセクションでは、それぞれの方法について簡単に説明します。

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

BigQuery のバッチ読み込みのオプションは次のとおりです。

  • 読み込みジョブを作成して、Cloud Storage またはローカル ファイルからデータを読み込みます。レコードは、Avro、CSV、JSON、ORC、または Parquet 形式にすることができます。
  • BigQuery Data Transfer Service を使用すると、SaaS(Software as a Service)アプリまたはサードパーティのアプリケーションやサービスからのデータの読み込みを自動化できます。
  • 他のマネージド サービスを使用して、外部データソースからデータをエクスポートし、BigQuery にインポートします。たとえば、Firestore エクスポートからデータを読み込むことができます。

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

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

ストリーミング。 ストリーミングでは、データを 1 つずつ、または一括して送信します。ストリーミング API を直接呼び出すコードを作成できます。あるいは、Dataflow と Apache Beam SDK を使用してストリーミング パイプラインを設定することもできます。

生成されたデータ。 データ操作言語(DML)ステートメントを使用して、既存のテーブルの一括挿入や、クエリの結果を新しいテーブルに格納できます。

サードパーティ製アプリケーション一部のサードパーティのアプリケーションやサービスでは、データを BigQuery に取り込むためのコネクタを提供しています。取り込みパイプラインを構成および管理する方法の詳細は、アプリケーションによって異なります。

新しいテーブルまたはパーティションへのデータの読み込み、既存のテーブルまたはパーティションへのデータの追加、テーブルまたはパーティションの上書きを行うことができます。パーティションの操作の詳細については、パーティション分割テーブルの管理をご覧ください。BigQuery に読み込まれたデータは Capacitor の列型(BigQuery のストレージ形式)に変換されます。

BigQuery では、データを BigQuery ストレージに読み込むことなく、特定の形式の外部データに対してクエリを実行することもできます。詳しくは、データの読み込みに代わる方法をご覧ください。

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

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

データソースデータのソースまたはデータ形式で、バッチの読み込みまたはストリーミングの実装と保守が容易かどうか判断できます。次の点を考慮してください。

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

  • データが 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 割り当てエラーのトラブルシューティングをご覧ください。
  • サードパーティ ソリューションは構成可能性、信頼性、順序付けの保証などの要因によって異なるため、ソリューションを導入する前にこれらを検討してください。

レイテンシ 読み込むデータの量とデータが利用可能になるまでの希望の時間を検討します。ストリーミングでは、分析に利用できるデータのレイテンシが最小になります。定期的な読み込みジョブでは、各読み込みジョブが終了する後にのみ新しいデータを利用できるため、レイテンシが高くなります。

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

外部データソースに対するクエリのパフォーマンスは、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 エンコードもサポートします。

非正規化されたデータ、ネストされたデータ、繰り返しデータの読み込み

デベロッパーの多くは、リレーショナル データベースと正規化されたデータスキーマでの作業に慣れています。正規化で重複データの保存がなくなり、データが定期的に更新される場合の整合性が保たれます。

非正規化は、以前に正規化されたリレーショナル データセットの読み取りパフォーマンスを向上させるための一般的な手法です。BigQuery でデータを非正規化するために推奨されている方法は、ネストされたフィールドと繰り返しフィールドを使用することです。関係が階層的で、多くの場合、親子関係のように一緒に照会されるため、これが最適な方法です。

最新のシステムでは、正規化データの使用によるストレージ節約はあまり問題とはなりません。ストレージの費用が増加するとしても、データ非正規化によるパフォーマンス向上には価値があります。結合にはデータ調整(通信帯域幅)が必要です。非正規化するとデータがローカライズされて個々のスロットに入れられるため、並行実行が可能です。

データを非正規化すると同時に関係を維持するには、データを完全にフラットにするのではなく、ネスト フィールドと繰り返しフィールドを使用します。リレーショナル データが完全に平坦化されると、ネットワーク通信(シャッフル)がクエリのパフォーマンスを下げる可能性があります。

たとえば、ネスト フィールドや反復フィールドを使用せずにオーダー スキーマを非正規化する際、order_id などのフィールドでデータをグループ化しなければならない場合があります(1 対多の関係がある場合)。シャッフルが必要になると、ネスト フィールドと繰り返しフィールドを使ってデータを非正規化した場合と比較して、データのグループ化はパフォーマンスが低くなります。

場合によっては、データを非正規化し、ネスト フィールドと繰り返しフィールドを使用しても、パフォーマンスは向上しません。以下のような場合は、非正規化を避けてください。

  • 頻繁にディメンションが変化するスタースキーマがある場合。
  • BigQuery が行レベルの変更(ミューテーション)があるオンライン トランザクション処理(OLTP)システムを補完しているが、それに置き換えることはできない場合。

ネストされたフィールドと繰り返しフィールドは、次のデータ形式でサポートされています。

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

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

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

BigQuery Data Transfer Service

BigQuery Data Transfer Service は、次のサービスから自動的に BigQuery にデータを読み込みます。

Google Software as a Service(SaaS)アプリ 外部クラウド ストレージ プロバイダ データ ウェアハウス また、Google Cloud Marketplace では、いくつかのサードパーティ転送を利用できます。

データ転送を構成すると、BigQuery Data Transfer Service がソース アプリケーションから BigQuery への定期的なデータ読み込みを自動的にスケジュールして管理します。

Google アナリティクス 360

Google アナリティクス 360 のレポートビューから BigQuery にセッション データとヒットデータをエクスポートする方法については、アナリティクス ヘルプセンターで BigQuery Export をご覧ください。

BigQuery でアナリティクスのデータをクエリする例は、アナリティクス ヘルプの BigQuery クックブックをご覧ください。

Dataflow

Dataflow から BigQuery に直接データを読み込むことができます。Dataflow を使用した BigQuery の読み取りと書き込みの詳細については、Apache Beam ドキュメントの BigQuery I/O コネクタ をご覧ください。

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

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

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

次のステップ