スキーマとデータ転送の概要
このドキュメントでは、スキーマとデータを既存のデータ ウェアハウスから BigQuery に転送するためのコンセプトとタスクについて説明します。
データ ウェアハウスからクラウドへの移行は単純なプロセスではありません。慎重に計画を立て、十分なリソースと時間を用意する必要があります。移行を成功させるには、段階的かつ反復的な方法でデータ ウェアハウスを移行する必要があります。スキーマとデータの移行を数回繰り返すと、結果が改善されます。
スキーマとデータの移行プロセス
実際の移行作業を始める前に、データ ウェアハウスにデータを供給するアップストリーム システムと、そのデータをレポートやダッシュボードで使用したり、その他のプロセスに供給したりするダウンストリーム システムがあることを確認しておきましょう。
一般的なデータの流れ（フロー）は次の図のようになります。ここには、多くの分析ユースケースが存在します。
このユースケースをできる限り多く BigQuery 上で実現することが移行の最終的な目的です。この目的を達成できれば、データ ウェアハウスの使用を最小限に抑え、最終的には廃止できます。移行の準備と検出フェーズで、どのユースケースをいつ移行するかを判断します。
スキーマとデータを BigQuery に転送する
移行の計画フェーズで、移行するユースケースを特定します。 次の実行フェーズで移行作業を始めます。中断を最小限に抑え、分析環境を稼働させながら移行作業を繰り返すため、次のプロセスを行います。
テーブルを転送し、ダウンストリーム プロセスの構成とテストを行います。
- BigQuery Data Transfer Service または別の ETL ツールを使用して、各ユースケースのテーブル グループをそのまま BigQuery に転送します。ツールの詳細については、初期のデータ転送をご覧ください。
- ダウンストリーム プロセスのテスト バージョンを構成し、BigQuery テーブルから読み取ります。
この最初のステップでデータの流れ（フロー）がわかれます。次の図は、最終的なフローを示します。一部のダウンストリーム システムは、B フローが示すように BigQuery からデータを読み取ります。その他のダウンストリーム システムは、A フローが示すようにこれまで通りデータ ウェアハウスからデータを読み取ります。
既存のデータ ウェアハウスの代わりに（あるいはこれに追加して）、BigQuery テーブルにデータを書き込むようにテスト用のアップストリーム プロセスを構成します。
テストで問題なければ、BigQuery テーブルに対して書き込みと読み取りを行うように、本番環境のアップストリーム プロセスとダウンストリーム プロセスを構成します。これらのプロセスは、BigQuery API を使用して BigQuery に接続できます。また、Looker Studio や Dataflow などの新しいクラウド プロダクトに組み込むこともできます。
この時点で、データの流れ（フロー）が 3 つにわかれます。
移行に追加するユースケースを選択し、ステップ 1 に進み、実行のイテレーションを新たに開始します。すべてのユースケースが BigQuery に完全に移行されるまで、この手順を繰り返します。ユースケースを選択するときに、オフロード状態のままになっているユースケースを見直し、完全移行のユースケースに移行します。完全に移行されたユースケースでは、BigQuery でスキーマを進化させるのガイドラインに沿って、進化プロセスを続行することを検討してください。
BigQuery でスキーマを進化させる
データ ウェアハウスのスキーマは、データの構造化方法とデータ エンティティ間の関係を定義します。スキーマはデータ設計の中核であり、アップストリームとダウンストリームの両方で多くのプロセスに影響を及ぼします。
データ ウェアハウス移行時は、BigQuery への移行後にスキーマを進化させる絶好の機会です。このセクションでは、一連の手順に従ってスキーマを進化させるためのガイドラインを示します。このガイドラインは、アップストリームとダウンストリームのプロセスの中断を最小限に抑えながら、スキーマの変更中にデータ ウェアハウス環境を稼働し続ける場合に役立ちます。
このセクションでは、単一ユースケースのスキーマ変換を中心に説明します。
どこまで進化させるかに応じて、途中のステップで止めることもできます。また、システムの進化が完了するまで続行することも可能です。
ユースケースをそのまま BigQuery に転送します。
以下の手順に進む前に、ユースケースのアップストリームとダウンストリームのプロセスがともに BigQuery に対して読み書きを行っていることを確認してください。ダウンストリーム プロセスが BigQuery から一部のデータを読み込んでいる中間状態から再開することもできます。このシナリオでは、ダウンストリーム部分に対してのみガイドラインを適用します。次の図では、アップストリームとダウンストリームのプロセスが BigQuery のテーブルに対して読み取り / 書き込みを行っています。
簡単な最適化を行います。
ファサード ビューを作成します。
スキーマをさらに進化させるため、テーブルのファサード ビューを作成します。ファサード パターンは、基になるコードや構造をマスキングし、複雑さを隠す設計方法の一つです。この場合、ファサード ビューは基になるテーブルをマスキングして、ダウンストリーム プロセスからのテーブルの変更に伴う複雑さを隠します。
ビューは新しいスキーマを記述できます。技術的な負担を考慮せず、新しい入出力のシナリオを念頭にモデル化できます。
内部的には、テーブルとビュークエリ定義自体が変更されている可能性がありますが、ビューはこれらの変更をデータ ウェアハウスの内部実装の詳細として抽象化し、常に同じ結果を返します。ファサード ビューで構成されたこの抽象化レイヤにより、アップストリームとダウンストリームのシステムを変更から隔離し、必要な変更のみを表示できます。
ダウンストリーム プロセスを変換します。
実際のテーブルではなくファサード ビューからデータを読み取るようにダウンストリーム プロセスの一部を変換します。これらのプロセスは、進化したスキーマの恩恵をすでに受けています。内部的には、次の図のようにファサード ビューが参照元の BigQuery スキーマからデータを取得していますが、これらのプロセスでこの点を意識する必要はありません。
ここでは、ダウンストリーム プロセスの変換を先に説明しました。ダウンロード プロセスの場合、変換の効果をすぐに見える形で提示できます（ダッシュボードやレポートなど）が、アップストリーム プロセスの場合、その効果を技術者でない関係者に説明するのは簡単ではありません。もちろん、アップストリーム プロセスの変換を先に行うことも可能です。どちらを先にするかはビジネス要件で決まります。
アップストリーム プロセスを変換します。
新しいスキーマに書き込むように、アップストリーム プロセスの一部を変換します。ビューは読み取り専用のため、新しいスキーマでテーブルを作成し、ファサード ビューのクエリ定義を変更します。次の図のように、一部のビューは引き続き参照元スキーマにクエリを実行しますが、他のビューは新しく作成されたテーブルにクエリを実行するか、その両方に SQL
UNIONオペレーションを実行します。
この時点で、新しいテーブルを作成するときに、ネストされたフィールドと繰り返しフィールドを利用できます。これにより、モデルをさらに非正規化し、BigQuery の基になるデータの列表現を直接利用できます。
ファサード ビューの利点は、ダウンストリーム プロセスが、基になるスキーマやアップストリーム プロセスの変更から独立して変換を継続できる点にあります。
ユースケースを完全に進化させます。
最後に、残りのアップストリーム プロセスとダウンストリーム プロセスを変換します。これらのプロセスがすべて新しいテーブルに書き込み、新しいファサード ビューから読み取るように変更されたら、参照元スキーマから読み取らないようにファサード ビューのクエリ定義を変更します。さらに、データフローから参照元モデルのテーブルを削除します。次の図は、参照元テーブルが使用されなくなった状態を示しています。
ファサード ビューでフィールドの集計や列のフィルタリングを行わない場合は、次の図のように、新しいテーブルからデータを読み取るようにダウンストリーム プロセスを構成し、ファサード ビューを廃止して複雑さを解消します。
スキーマとデータの初期転送を実行する
このセクションでは、スキーマとデータを既存のデータ ウェアハウスから BigQuery に移行する際の実践的な考慮事項について説明します。
移行の初期の繰り返しで、変更せずにスキーマを転送することをおすすめします。これには次のような利点があります。
- データ ウェアハウスに対するデータのパイプラインを新しいスキーマに合わせて調整する必要がない。
- スタッフのトレーニング リストに新しいスキーマを追加する必要がない。
- 自動化ツールを利用してスキーマとデータ転送を実行できる。
また、移行を並行して行う場合でも、クラウド機能を利用する概念実証（PoC）や他のデータ探索アクティビティが妨げられることなく継続できます。
転送方法を選択する
初期転送を行うには、いくつかの方法があります。
- Amazon Redshift と Teradata のデータ ウェアハウスでは、BigQuery Data Transfer Service を使用して、既存のシステムから BigQuery に直接スキーマとデータを読み込むことができます。Cloud Storage は、移行プロセスの一環としてデータをステージングするために引き続き使用されます。
- どのデータ ウェアハウスでも、スキーマとデータを含むファイルを抽出し、それらのファイルを Cloud Storage にアップロードしてから、次のいずれかのオプションを使用して、それらのファイルからスキーマとデータを BigQuery に読み込むことができます。
データ転送方法を選択する際のその他の考慮事項については、データの取り込み方法の選択をご覧ください。
データ変換を検討する
データ抽出の形式と、BigQuery に読み込む前にデータをカットまたは拡充するかどうかに応じて、データを変換するステップが必要になる場合があります。既存の環境または Google Cloud でデータを変換できます。
- 現在の環境でデータを変換する場合は、利用可能なコンピューティング能力とツールによりスループットが制限される可能性があります。 また、変換プロセス中にデータを拡充する場合は、追加の転送時間やネットワーク帯域幅が必要かどうかも考慮してください。
- Google Cloud でデータを変換する場合のオプションの詳細については、ETL ツールを使用したデータの読み込みをご覧ください。
既存のスキーマとデータをファイルに抽出する
既存のプラットフォームには、Apache AVRO や CSV などのベンダーに依存しない形式にデータをエクスポートするツールが用意されている可能性があります。転送の複雑さを軽減するために、AVRO、ORC、または Parquet の使用をおすすめします。この場合、スキーマ情報がデータに埋め込まれます。CSV や類似の単純な区切りデータを選択した場合は、スキーマを個別に指定する必要があります。この方法は、選択したデータ転送方法によって異なります。 たとえば一括アップロードでは、読み込み時にスキーマを指定するか、CSV ファイルの内容に基づくスキーマの自動検出を有効にできます。
既存のプラットフォームからこれらのファイルを抽出すると、既存の環境のステージング ストレージにコピーされます。
Cloud Storage にファイルをアップロードする
BigQuery Data Transfer Service を使用して既存の Amazon Redshift または Teradata データ ウェアハウスからデータを直接読み込む場合を除き、抽出したファイルを Cloud Storage のバケットにアップロードする必要があります。転送するデータの量と利用可能なネットワーク帯域幅に応じて、次の転送オプションを選択できます。
- 抽出したデータが別のクラウド プロバイダにある場合は、Storage Transfer Service を使用します。
データがオンプレミス環境または良好なネットワーク帯域幅を持つコロケーション施設にある場合は、
gsutilツールを使用します。gsutilツールはマルチスレッドの並列アップロードに対応し、エラー発生後に再開します。また、セキュリティのため、トラフィックを暗号化してから転送します。十分なネットワーク帯域幅を確保できない場合は、Transfer Appliance を使用してオフライン転送を行います。
Cloud Storage バケットを作成し、ネットワーク経由でデータを転送する場合、データセンターに最も近いロケーションを選択して、ネットワークのレイテンシを最小限に抑えます。可能であれば、BigQuery データセットの場所と同じになるように、バケットのロケーションを選択します。
コストの見積もりなど、Cloud Storage にデータを移動する際のベスト プラクティスについては、ビッグデータ セットを転送するための戦略をご覧ください。
スキーマとデータを BigQuery に読み込む
転送方法を選択するで説明されているいずれかのオプションを使用して、スキーマとデータを BigQuery に読み込みます。
1 回限りの読み込みの詳細については、BigQuery ドキュメントで Cloud Storage からのデータの読み込みの概要をご覧ください。読み込みを定期的に行うようにスケジュールを設定する方法については、BigQuery Data Transfer Service ドキュメントで Cloud Storage の転送の概要をご覧ください。
ETL ツールを使用してデータを読み込む
BigQuery への読み込み時にデータをさらに変換する必要がある場合は、次のいずれかのオプションを使用します。
- Cloud Data Fusion。このツールを使用すると、事前構成されたコネクタと変換のオープンソース ライブラリを使用して、フルマネージドの ETL / ELT データ パイプラインをグラフィカルに構築できます。
- Dataflow。このツールを使用すると、Apache Beam モデルを基にして複雑なデータ変換を定義し、実行できます。Dataflow はサーバーレスで、Google によって完全に管理されています。実質的に処理能力に制限はありません。
- Dataproc。これにより、フルマネージドのクラウド サービスで Apache Spark と Apache Hadoop クラスタを実行できます。
- サードパーティ製ツール。パートナーにお問い合わせください。データ パイプラインの構築を外部化する場合、最適なツールを選ぶことができます。
次の図は、このセクションで説明するパターンを示しています。ここで、データ転送ツールには gsutil を使用し、Dataflow を利用して BigQuery に直接書き込みを行っています。その際、Apache Beam 組み込みの Google BigQuery I/O コネクタなどを使用します。
データの初期セットを BigQuery に読み込んだら、BigQuery の優れた機能を活用できます。
ただし、スキーマの転送と同様に、データのアップロードは反復プロセスの一つです。BigQuery に転送されるデータのフットプリントを増やすと、同じプロセスが繰り返し行われます。その後、アップストリームのデータフィードを BigQuery に再ルーティングすることで、既存のデータ ウェアハウスを稼働させておく必要がなくなります。これらの詳細については、次のセクションで説明します。
データを検証する
BigQuery にデータが格納されたので、Data Validation Tool（DVT）を使用して、データ転送が成功したことを確認できます。DVT は、さまざまなソースのデータを BigQuery のターゲットと比較できるオープンソースの Python CLI ツールです。実行する集計の種類（カウント、合計、平均など）と、適用する列を指定できます。詳細については、DVT によるデータ検証の自動化をご覧ください。
最初の転送を反復処理する
このセクションでは、BigQuery を最大限に活用するために、初期のデータ転送後に行う操作について説明します。
現在、データのサブセットは BigQuery にあります。BigQuery で使用するデータのフットプリントを増やすことで、既存のデータ ウェアハウスへの依存度を減らしていきます。
以降のイテレーションで選択する方法は、ユースケースで 2 番目に新しいデータに更新することがどの程度重要かによって異なります。データ アナリストが、データ ウェアハウスに存在するデータを定期的に処理できる場合、スケジュール オプションが最適です。転送のスケジュールは、初期転送と同様の方法で設定できます。BigQuery Data Transfer Service や Google の Storage Transfer Service などの ETL ツール、サードパーティのツールを使用できます。
BigQuery Data Transfer Service を使用する場合、移動するテーブルを最初に決めます。次に、テーブルのテーブル名パターンを作成します。最後に、転送の実行タイミングに繰り返しスケジュールを設定します。
一方、ユースケースで新しいデータにほぼリアルタイムでアクセスする必要がある場合は、ストリーミング アプローチが必要です。次の 2 つのオプションがあります。
- Google Cloud プロダクトで読み込みパイプラインを作成します。Google では、このタスクを簡単に実行できるように、Dataflow ストリーミング テンプレートを用意しています。
- Google のパートナーのソリューションを使用する。
短期的には、BigQuery データのフットプリントを増やし、それをダウンストリーム プロセスに使用する場合は、既存のデータ ウェアハウスを移行するという中期的な目標に基づき、最優先のユースケースを満たすことに集中する必要があります。初期の繰り返しをうまく利用し、既存のデータ ウェアハウスから BigQuery への取り込みパイプラインを完成させるために、多くのリソースを費やさなようにします。最終的には、既存のデータ ウェアハウスを使用しないようにパイプラインを調整する必要があります。
スキーマを最適化する
BigQuery にテーブルをそのまま移行するだけで、BigQuery 独自の機能を利用できます。たとえば、インデックスの再構築やデータブロックの再シャッフル（バキューム）を行う必要はありません。また、バージョンのアップグレードによるダウンタイムやパフォーマンスの低下もありません。
ただし、移行の初期の繰り返しでデータ ウェアハウス モデルをそのまま保持すると、次のような欠点があります。
- スキーマに関連する既存の問題と技術的な負担が解決されていない。
- クエリの最適化には限界があり、後のステージでスキーマが更新される場合は再最適化のやり直しが必要になる可能性がある。
- ネストされたフィールドや繰り返しフィールド、パーティショニング、クラスタリングなどの BigQuery 機能を有効に利用できない。
最終的な転送を行う際は、スキーマに作成するテーブルにパーティショニングとクラスタリングを適用して、システム パフォーマンスを改善することをおすすめします。
パーティショニング
BigQuery では、データをパーティションというセグメントに分割できます。これにより、データの管理とクエリをより簡単かつ効率的に行うことができます。たとえば、TIMESTAMP 列または DATE 列に基づいてテーブルを分割できます。BigQuery で疑似列を追加し、取り込み中にデータを自動的にパーティショニングすることもできます。小さいパーティションに対するクエリは、データのサブセットのみをスキャンするため、パフォーマンスが向上します。また、読み取りバイト数が最小限になるため、コストを抑えることができます。
パーティショニングで、テーブルの既存の構造が影響を受けることはありません。したがって、スキーマが変更されていない場合でも、パーティション テーブルの作成を検討する必要があります。
クラスタリング
BigQuery では、データのクエリでインデックスを使用しません。BigQuery のパフォーマンスは、基盤となるモデル、ストレージとクエリ技術、超並列アーキテクチャによって最適化されています。 クエリを実行したときに、処理するデータ量が多いほど、より多くのマシンが追加され、データのスキャンと結果の同時集計が行われます。この手法は、巨大なデータセットに適していますが、インデックスの再構築には適していません。
それでも、クラスタリングなどの手法でクエリを最適化する余地はあります。クラスタリングを使用すると、BigQuery は指定された列の値に基づいてデータを自動的に並べ替え、最適なサイズのブロックにデータを配置します。クラスタリングを使用すると、クラスタリングを使用しない場合と比較してクエリのパフォーマンスが向上します。クラスタリングを使用した場合、BigQuery でのクエリの実行コストをより正確に推定できます。クラスタリングされた列を使用すると、ブロックに類似した値を持つレコードが格納されるため、クエリで不要なデータがスキャンされません。これにより、集計値の計算が速くなります。
フィルタリングに頻繁に使用される列のクエリを調べ、その列でクラスタリングを設定してテーブルを作成します。クラスタリングにはパーティション分割テーブルが必要です。これは、テーブルの作成時に定義します。
非正規化
データの移行は反復的なプロセスです。 最初のスキーマをクラウドに移行して簡単な最適化を行い、主要なユースケースをテストした後に、BigQuery のメリットを利用する追加機能の検討が必要になることもあります。たとえば、ネストされたフィールドや繰り返しフィールドなどの機能が必要になるかもしれません。
データ ウェアハウスのスキーマは、これまで次のモデルを使用してきました。
- スタースキーマ。これは非正規化モデルで、ファクト テーブルで注文金額、割引、数量などのメトリックスとキーのグループを収集します。これらのキーは、顧客、サプライヤー、リージョンなどのディメンション テーブルに属します。このモデルをビジュアルに表現すると星型になり、ファクト テーブルが中央にあり、その周りにディメンション テーブルが存在します。
- スノーフレーク スキーマ。スタースキーマに似ていますが、ディメンション テーブルが正規化されているため、スキーマがスノーフレークのように見えます。
BigQuery はスタースキーマとスノーフレーク スキーマの両方に対応していますが、ネイティブ スキーマ表現はこの 2 つのいずれでもありません。データをより自然に表現するため、ネストされたフィールドと繰り返しフィールドを使用しています。詳細については、BigQuery のドキュメントのサンプル スキーマをご覧ください。
ネストされたフィールドと繰り返しフィールドの使用は、スキーマを進化させる非常に優れた方法です。これにより、クエリに必要な結合数が少なくなり、スキーマを BigQuery 内部のデータ表現に合わせることができます。内部的に、BigQuery は Dremel モデルでデータを整理し、Capacitor というカラム型ストレージ形式で格納します。
ケースに最適な非正規化アプローチを決定する際に、BigQuery の非正規化のベスト プラクティスとスキーマの変更の処理のための手法を考慮してください。
次のステップ
データ ウェアハウス移行の次のステップの詳細を確認する。
特定のデータ ウェアハウス テクノロジーから BigQuery に移行する方法についても説明します。