このドキュメントでは、データの変更を BigQuery ベースのデータ ウェアハウス（DWH）に統合するうえで役立つ、再現可能なワークフローを実装するための原則と手法について説明します。これらの変更には、新しいデータセット、新しいデータソース、既存のデータセットの更新と変更などがあります。このドキュメントでは、このタスクのリファレンス アーキテクチャについても説明します。
このドキュメントの対象読者は、BigQuery を DWH として使用するソフトウェアおよびデータ アーキテクトとデータ エンジニアです。このドキュメントは、CI / CD の基本コンセプト、または同様のアプリケーションのライフサイクル管理方法を理解していることを前提としています。
はじめに
継続的インテグレーションと継続的デリバリー（CI / CD）がソフトウェア開発ライフサイクルの重要な手法になっています。CI / CD の原則を採用すると、機能を統合して手動でデプロイするよりも、問題が少ない優れたソフトウェアを提供できます。CI / CD は、データ ウェアハウジングをモダナイズする際のデータ マネジメント戦略にも使用されます。
ただし、BigQuery などの DWH を使用する場合、ソースコードで CI / CD を実装する場合と、CI / CD の実装方法が異なります。こうした違いは、データ ウェアハウジングが、基盤となるデータを管理するためのステートフル システムであるためです。
このドキュメントでは次の情報を提供します。
- BigQuery で継続的インテグレーション（CI）戦略を実装する方法。
- 問題の回避に役立つガイダンスと方法。
- BigQuery での CI に役立つ BigQuery 機能の提案。
このドキュメントは CI に焦点を当てています。インテグレーションは、継続的デリバリー（CD）よりもデータ ウェアハウジング チームにデータ固有の考慮事項があるからです。
BigQuery DWH に CI を使用するタイミング
このドキュメントでは、データ インテグレーションは通常、DWH チームが実行するタスクです。これには、DWH への新しいデータの統合が含まれます。このタスクには、新しいデータソースを DWH に組み込むことや、DWH 内にあるテーブルの構造を変更する作業などが含まれます。
新しいデータを DWH に統合することは、新しい機能を既存のソフトウェアに統合するタスクに似ています。これにより、バグが発生し、エンドユーザー エクスペリエンスに悪影響を及ぼす可能性があります。データを BigQuery に統合すると、データのダウンストリーム コンシューマ（アプリケーション、BI ダッシュボード、個々のユーザーなど）で、スキーマの不一致による問題が発生することがあります。コンシューマが、元のデータソースのデータを反映していない誤ったデータを使用する場合もあります。
DWH の CI は、次のような場合に役立ちます。
- DWH システムの CI の要点を説明する。
- BigQuery 環境の CI 戦略を設計して実装する。
- BigQuery の機能を使用して CI を実装する方法を学ぶ。
このガイドでは、Dataflow や Bigtable などのデータ プロダクトを含む、DWH 以外のプロダクトの CI を管理する方法については説明しません。
実施例
Example Company は、BigQuery で DWH を保守している大企業です。来年は、Example Company が最近買収した会社から、新しいデータソースを DWH に統合する予定です。統合される新しいデータソースは、異なるスキーマを持っています。ただし、DWH は既存のスキーマを保持し、強力なデータ整合性とデータ完全性を提供して、ダウンストリーム コンシューマに悪影響が及ばないようにする必要があります。
現在、Example Company の DWH チームがデータ インテグレーションを行っています。このインテグレーションは、事前定義されたスキーマに既存のデータソースがあることを前提にしています。このワークフローには、従来のデータ インポート プロセス、取得したデータベース、アプリケーション サービスが含まれます。
新しいデータソースに対応するためにデータ インテグレーション プロセスを更新するには、DWH チームは、強力なデータ整合性など、前述の要件に準拠するようにデータ統合のアプローチを再設計する必要があります。チームは、データをダウンストリーム コンシューマに提供する前にデータの変更をテストして測定できるように、変更を分離して実装する必要があります。
DWH チームが新しいワークフローを採用すると、チームには繰り返し可能なプロセスがもたらされます。デベロッパーごとに、本番環境データに基づいて分離された開発環境を作成できます。デベロッパーは、このような隔離された環境を使用して、変更、テスト、レビューを行い、必要な変更を本番環境に実装できます。変更によりバグや予期せぬ問題が生じた場合は、変更を簡単にロールバックできます。
DWH にとっての継続的インテグレーションの意味
継続的インテグレーション（CI）とは、開発チームが開発サイクルを短縮し、手動システムよりも迅速にコードの問題を検出するための一連の手法です。CI アプローチを採用する主なメリットは、迅速な開発が可能で、デベロッパー間の干渉のリスクを軽減できることです。この目標は、各デベロッパーが他のデベロッパーから独立して作業できるようにしながら、プロセスを繰り返すことができるようにすることで実現されます。
この原則は、組織がデータを DWH に統合する必要がある場合にも適用されますが、いくつか違いがあります。一般的なソフトウェア開発のコンテキストでは、CI はソースコードの変更をステートレスで分離します。データ内の CI のコンテキストでは、CI はデータを DWH システムに統合します。ただし、定義上、データはステートフルです。この違いは、このドキュメントで説明するように、DWH シナリオに CI がどのように適用されるかに影響します。
このドキュメントで取り上げていないその他のシナリオ
このドキュメントでは、本番環境からの変更の分離について説明しますが、データ インテグレーションの次の点については説明しません。
- データテスト: 使用しているデータがビジネス要件に準拠していることを確認できるか？信頼できる情報源としてデータは信頼できるか？DWH から提供するデータの信頼度を高めるには、データをテストすることが重要です。テストを実施するには、一連のクエリを実行して、データに値が欠落していないこと、またはデータに「不正な」値が含まれていることをアサートできます。
- データリネージ: コンテキスト内のテーブルを表示できるか？たとえば、データの収集元と、テーブルを生成するために事前計算されたデータセットを確認できます。最新の DWH アーキテクチャでは、データはさまざまな専用データ構造を使用する多くのシステムに分割されています。これには、リレーショナル データベース、NoSQL データベース、外部データソースが含まれます。所有しているデータを完全に把握するには、そのデータを追跡する必要があります。また、データがどのように生成されたか、どこから生成されたかも把握する必要があります。
これらのトピックは、このガイドの対象外です。ただし、チームのワークフローを設計する際は、データ戦略を活用してこれらのトピックを計画することをおすすめします。
DWH としての BigQuery の一般的な設定
次の図は、BigQuery の一般的な DWH の設計を示しています。外部ソースからのデータが DWH に取り込まれる仕組みと、コンシューマが DWH からデータをどのように使用するかが説明されています。
データはデータソースから始まり、OLTP SQL データベースや NoSQL データベースなど、従来のトランザクション データベースまたは低レイテンシ データベースにデータが存在します。スケジュールされたプロセスにより、データがステージング領域にコピーされます。
データはステージング領域に一時的に保存されます。必要に応じて、データは分析システムに合わせて変換されてから、DWH テーブルに読み込まれます（この図で、ステージング領域は Google Cloud 内に存在しますが、必ずしもそうする必要はありません）。変換には、非正規化、特定のデータセットの拡充、不適切な形式のエントリ（値のないエントリなど）の処理などが含まれます。
ステージング領域から、新しいデータが DWH テーブルに読み込まれます。テーブルは、DWH の設計に応じてさまざまな方法で編成できます。通常、コアテーブルと呼ばれます。テーブル設計パラダイムの例には、スタースキーマ パラダイム、非正規化パラダイム、多層集計などがあります。
テーブルの設計に関係なく、これらのテーブルでは時間の経過とともにデータが保存されます。テーブルはスキーマに準拠している必要があり、すべての分析目的で信頼できる情報源を保持していることを前提としています。テーブルに対するこのロールは、これらのテーブル内のデータが完全で整合性があり、事前定義されたスキーマに従っている必要があることを意味します。
これらのテーブルは、コンシューマに直接データを提供しません。代わりに、データはアクセスレイヤを介して提供されます。アクセスレイヤは、基盤となるデータに適用する必要があるビジネス ロジックをカプセル化するように設計されています。このタイプのビジネス ロジックの例としては、レコードごとの指標の計算や、データのフィルタリングとグループ化があります。
データのコンシューマは、DWH アクセスレイヤに接続してデータを読み取ることができます。このようなデータ コンシューマには、次のようなシステムが含まれます。
- ビジネス インテリジェンス（BI）ダッシュボード
- データ サイエンス ノートブック
- DWH で計算されたデータに依存する運用システム
- アドホック クエリを行う人間のユーザー
データ コンシューマは、一貫性のあるスキーマの提供と DWH がカプセル化するビジネス ロジックについて、DWH に大きく依存しています。これらのスキーマとビジネス ロジックは、DWH プラットフォームのサービスレベル契約（SLA）と考えることができます。ビジネス ロジック、スキーマ、データの完全性に対する変更は、ダウンストリームに大きな影響を与える可能性があります。最新のデータ プラットフォームの性質は絶えず変化しているため、DWH チームは SLA を厳密に遵守しながら、このような変更を行う必要が生じる場合があります。チームが SLA を満たし、DWH を最新の状態に保つためには、これらの変更によって生じる障害を最小限に抑えながら、データ インテグレーションを可能にするワークフローが必要です。
DWH での継続的インテグレーションのためのアセット
他の開発チームや IT チームと同様に、DWH チームも業務に不可欠なアセットを維持する必要があります。通常、これらのアセットは次のカテゴリに分類できます。
データ パイプラインのコードベース: これらのアセットは通常、高水準プログラミング言語（Python や Java など）のソースコードで構成されます。これらのタイプのアセットの場合、CI / CD プロセスは、Git や Jenkins などのツール、または Cloud Source Repositories や Cloud Build などの Google Cloud ソリューションを使用してビルドされます。
SQL スクリプト: これらのアセットは、DWH 内にカプセル化される構造とビジネス ロジックを示します。このカテゴリでは、アセットをさらに次のサブカテゴリに分類できます。
- データ定義言語（DDL）: これらのアセットは、テーブルとビューのスキーマの定義に使用されます。
- データ操作言語（DML）: これらのアセットは、テーブル内のデータ操作に使用されます。DML コマンドは、既存のテーブルに基づいて新しいテーブルを作成する場合にも使用されます。
- データ制御言語（DCL）: これらのアセットは、テーブルに対する権限とアクセスの制御に使用されます。BigQuery 内では、SQL と
bqコマンドライン ツール、または BigQuery REST API を使用してアクセスを制御できます。ただし、IAM を使用することをおすすめします。
これらのアセットや、コンポーネントをビルドするために使用される Terraform スクリプトなどの他のアセットは、コード リポジトリ内で管理されます。Dataform などのツールを使用すると、SQL スクリプトを検証し、DDL スクリプトによって作成されるテーブルに対して事前定義された検証ルールをチェックする CI / CD パイプラインを構築できます。これらのツールを使用すると、SQL のコンパイルとテストのプロセスを適用できます。ほとんどのコンテキストでは、自然なテスト環境がありません。
ツールとプロセスに関連するアセットに加えて、DWH チームの主なアセットはデータです。ソースコードを追跡するように設計された Git などのアセット トラッキング システムを使用してデータを追跡できません。このドキュメントでは、トラッキング データに関連する問題に対処します。
データの統合に関する問題
DWH 内のテーブルの関係は複雑になる可能性があるため（前述のテーブル設計パラダイムの 1 つなど）、本番環境データの状態をテスト環境から分離しておくことは困難です。ソフトウェア開発の標準的な手法は、データ インテグレーションのシナリオには適用できません。
次の表は、コードの統合方法とデータの統合方法の違いをまとめたものです。
| コードの統合 | データの統合 | |
|---|---|---|
| ローカルでの開発 | ソースコードはサイズが比較的小さいため、簡単にクローンを作成できます。一般的に、このコードはほとんどのエンドユーザー マシンに適しています（他のソリューションがある monorepos のケースは除きます）。 | DWH のほとんどのテーブルは、そのサイズが原因となって開発マシンに適しません。 |
| 中央テスト | 自動テストを行うために、さまざまな状態のソースコードのクローンが中央システム（CI サーバー）に作成されます。コードの状態をさまざまに変えることで、安定版と開発版で結果を比較できます。 | 分離された環境でさまざまな状態のデータを作成することは簡単ではありません。DWH の外部にデータを移動するには、リソースを大量に消費し、時間がかかります。テストに必要な頻度で実施することは実用的ではありません。 |
| 過去のバージョン | ソフトウェアの新しいバージョンのリリース中に、過去のバージョンを追跡できます。新しいリリースで問題が検出された場合は、安全なバージョンにロールバックできます。 | ロールバックが必要になった場合に備えて、DWH 内でテーブルのバックアップを取ることが標準的な方法です。ただし、影響を受けるすべてのテーブルが同じ時点にロールバックされるようにする必要があります。これにより、関連するテーブルの整合性が相互に確保されます。 |
BigQuery テーブルにデータを統合する
BigQuery には、テーブル スナップショットとテーブル クローンという、データ インテグレーションのワークフローの設計に役立つ 2 つの機能があります。これらの機能を組み合わせると、費用対効果に優れた開発環境を提供するワークフローを実現できます。デベロッパーは、本番環境から切り離してデータとその構造を操作でき、必要に応じて変更をロールバックできます。
BigQuery テーブル スナップショットは、特定の時点のテーブル（ベーステーブルと呼ばれます）の読み取り専用表現です。同様に、BigQuery テーブル クローンは、特定の時点におけるテーブルの読み書き表現です。どちらの場合も、ベーステーブルとの差分のみが保存されるため、ストレージの費用は最小限に抑えられます。ベーステーブルが変更されたとき、またはテーブル クローンが変更されたときに、テーブル クローンの費用が発生します。テーブル スナップショットは読み取り専用であるため、ベーステーブルが変更された場合にのみ費用が発生します。
テーブル スナップショットとテーブル クローンの料金の詳細については、テーブル スナップショットの概要とテーブル クローンの概要をご覧ください。
BigQuery のタイムトラベル機能（過去 7 日以内）を使用して、テーブル スナップショットとテーブル クローンを作成できます。この機能を使用すると、複数のテーブルのスナップショットとクローンを同時にキャプチャできます。これにより、作業環境とスナップショットの整合性を保つことができます。この機能は、頻繁に更新されるテーブルで役立ちます。
テーブル クローンとテーブル スナップショットを使用して分離を可能にする方法
DWH における CI のインテグレーション ワークフローを説明するために、次のシナリオを考えてみます。新しいデータセットを DWH に統合するタスクが与えられます。新しい DWH テーブルの作成、既存のテーブルの更新、テーブル構造の変更、またはこれらのタスクの任意の組み合わせなどのタスクがあります。ワークフローは次のようになります。
- 変更の影響を受ける可能性があるテーブルと、確認する必要がある追加のテーブルを特定します。
- この変更のアセットを含む新しい BigQuery データセットを作成します。このデータセットにより、変更を分離し、このタスクを他のチームメンバーが取り組んでいる他のタスクから分離できます。データセットは、ソース データセットと同じリージョンに存在する必要があります。ただし、組織のセキュリティと課金の要件に対応するため、プロジェクトを本番環境プロジェクトから分離することもできます。
テーブルごとに、新しいデータセットにクローンとスナップショットの両方を作成します（同じポイントを作成できます）。この方法には次のようなメリットがあります。
- テーブル クローンは作業コピーとして機能し、本番環境のテーブルに影響を与えることなく自由に変更を行うことができます。同じベーステーブルの複数のテーブル クローンを作成して、オーバーヘッドを最小限に抑えながら、異なるインテグレーション パスを同時にテストできます。
- スナップショットは、復元および参照ポイントとして機能できます。これは、変更が行われる前にデータが正常に機能していたことがわかっているポイントです。このスナップショットを取得しておくと、プロセスの後半で問題が検出された場合にロールバックを実行できます。
テーブル クローンを使用して、テーブルに必要な変更を実装します。このアクションにより、テーブル クローンの更新バージョンが作成され、分離されたデータセットでテストできます。
必要に応じて、実装フェーズの最後に、次のタスクに使用できるデータセットを提示できます。
- Dataform などの検証ツールを使用した単体テスト。単体テストは自己完結型です。アセットは個別にテストされます。この場合、アセットは BigQuery のテーブルです。単体テストでは、null 値をチェックして、すべての文字列が長さの要件を満たしていること、特定の集計が有用な結果をもたらすことを確認できます。単体テストには、そのテーブルのビジネスルールを確実に維持する信頼性テストを含めることができます。
- ダウンストリーム コンシューマとのインテグレーション テスト。
- ピアレビュー。
このワークフローを使用すると、ダウンストリーム コンシューマに影響を与えることなく、本番環境データでテストできます。
新しいデータを BigQuery に統合する前に、別のスナップショットを作成できます。このスナップショットは、ベーステーブルのデータが変更された場合の別のロールバック オプションとして使用できます。
変更を統合するプロセスは、組織が採用するプロセスと必要な変更によって異なります。たとえば、SQL スクリプトの変更により、新しいデータセットに対して標準コードベースに対する pull リクエストが送信されることがあります。変更が特定のテーブル内のデータの変更に限定されている場合は、BigQuery の標準方法でデータをコピーするだけで済みます。
ストアド プロシージャのスクリプトを使用すると、データセットの作成、クローンとスナップショットの作成の手順をカプセル化して自動化できます。これらのタスクを自動化することで、ヒューマン エラーのリスクが軽減されます。プロセスの自動化に役立つスクリプトの例については、CI for Data in BigQuery CLI utility の GitHub リポジトリをご覧ください。
テーブル クローンとテーブル スナップショットを使用するメリット
前のセクションで説明したワークフローを使用すると、デベロッパーは同僚に干渉することなく、独立して並行に作業できます。デベロッパーは変更のテストとレビューを行い、問題がある場合は変更をロールバックできます。完全なテーブルではなく、テーブル スナップショットを操作するため、完全なテーブルを操作する場合と比べて費用とストレージを最小限に抑えることができます。
このセクションでは、テーブル スナップショットとテーブル クローンを使用して、デベロッパーがこのワークフローを実現する方法について説明します。次の図は、テーブル スナップショットとテーブル クローンが本番環境データセット内のデータとどのように関連しているかを示しています。
この図の本番環境データセットには、本番環境で使用されているすべてのテーブルが含まれています。すべてのデベロッパーが独自の開発環境用のデータセットを作成できます。この図には、Dev Dataset 1 と Dev Dataset 2 というラベルの付いた 2 つのデベロッパー データセットが示されています。これらのデベロッパー データセットを使用すると、デベロッパーは互いに干渉することなく、同じテーブルを同時に操作できます。
データセットを作成したら、作業しているテーブルのクローンとスナップショットを作成できます。クローンとスナップショットは、特定の時点のデータを表します。この時点では、ベーステーブルに変更が反映されないため、デベロッパーはテーブル クローンを自由に変更できます。
デベロッパーは、テーブル クローンを確認してスナップショットと比較し、ダウンストリーム コンシューマとの互換性をテストできます。他のデベロッパーは、リソース消費量の多いベーステーブルのコピーを過剰に作成することなく、他のクローンやスナップショットを干渉なしで操作できます。
デベロッパーは、必要に応じて、ロールバック オプションとしてスナップショットを安全に保ちながら、変更をベーステーブルに統合できます。このプロセスは、開発環境、テスト環境、本番環境など、異なる環境で繰り返すこともできます。
テーブル クローンとテーブル スナップショットに代わる方法
テーブル クローンとテーブル スナップショットを使用して、同様の結果を得ることもできます。通常、これらの代替方法はクローンやスナップショットとは異なる方法で使用されます。これらの方法の違いと、どの方法が最も適しているかを理解することが重要です。
テーブル全体を別のデータセットにコピーする
別のデータセットを使用して、そのデータセットにテーブルをコピーすることもできます。この方法は、テーブル クローンやスナップショットを使用する場合と似ていますが、テーブルのセット全体をコピーします。コピーするデータのサイズによっては、ストレージ費用が高くなる場合があります。BigQuery でテーブル クローンが利用可能になるまで、この方法を使用していた組織もあります。ただし、この方法には、クローンやスナップショットを使用する場合と比べてメリットはありません。
Cloud Storage へのテーブルのエクスポートとインポート
Cloud Storage を介してデータを移動することもできます。この方法は、テーブル クローンやテーブル スナップショットを使用する場合にも類似しています。ただし、Cloud Storage バケットにデータをエクスポートするための追加の手順が含まれます。この方法のメリットの 1 つは、データを追加でバックアップできることです。障害復旧またはハイブリッド ソリューションのバックアップが必要な場合に、この方法を選択できます。
Analytics Hub の使用
Analytics Hub を使用すると、組織内外のデータセットを安全な方法で共有できます。データセットを公開して、それらのデータセットに対する制御された読み取り専用アクセス権をサブスクライバーに提供できるようにする、多くの機能を備えています。ただし、Analytics Hub を使用してデータセットを公開し、変更を実装できる場合でも、デベロッパーはテーブルを操作するためにテーブル クローンを作成する必要があります。
DWH の継続的インテグレーション オプションの概要
次の表は、DWH の継続的インテグレーションのオプションの違い、メリット、デメリットをまとめたものです（Analytics Hub は異なる機能セットを提供しているため、表に記載されているパラメータを使用した測定はできません）。
| 費用 | ロールバック | リスク | |
|---|---|---|---|
| テーブル スナップショットとテーブル クローン | 最小。スナップショットまたはクローンとベーステーブルの差額に対してのみ料金が発生します。 | スナップショットは、必要に応じてロールバックするバックアップとして機能します。 | リスクのレベルは自分で管理します。すべてのテーブルに対して特定の時点でスナップショットを取得できるため、ロールバックがあっても不整合が軽減されます。 |
| テーブルのコピー | テーブル スナップショットとテーブル クローンを使用する場合よりも費用が高くなります。データ全体が複製されます。ロールバックをサポートするには、同じテーブルの複数のコピーが必要です。 | 可能ですが、テーブルのコピーが 2 つ必要です。1 つのコピーはバックアップとして使用し、もう 1 つのコピーを作業用として、変更を適用します。 | 特定の時点でのクローン作成が困難になります。ロールバックが必要な場合は、すべてのテーブルが同じ時点から取得されるわけではありません。 |
| エクスポートとインポート | テーブル スナップショットとテーブル クローンを使用する場合よりも費用が高くなります。データが複製されます。ロールバックをサポートするには、同じテーブルの複数のコピーが必要です。 | エクスポートされたデータはバックアップとして機能します。 | エクスポートされたデータは、複数のテーブルの特定時点のエクスポートではありません。 |
次のステップ
- テーブル スナップショットの概要で、BigQuery テーブル スナップショットについて確認する。
- DevOps 技術: 継続的インテグレーションで、ソフトウェア開発における継続的インテグレーションについて確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。