データの整備を維持し、開発プロセスを最適化する Dataform SQL ワークフローの標準化されたライフサイクルを作成するには、次のことをおすすめします。
開発中に作成されたテーブルを、エンドユーザーが使用できるテーブルから分離する実行環境を作成します。
本番環境とステージング環境（省略可）でワークフローを実行するように、リリースとワークフローの構成を設定します。
このドキュメントでは、ワークスペースのコンパイルのオーバーライドを使用して開発テーブルを分離するためのソリューション、およびステージング環境と本番環境のリリース構成およびワークフロー構成の設定のためのソリューションについて説明します。
これらのソリューションを使用すると、単一の Dataform リポジトリと Google Cloud プロジェクト内に実行環境を作成できます。Dataform リポジトリの複数のコピーを各 Google Cloud プロジェクトに保存することもできます。各プロジェクトはコード ライフサイクルのステージ（開発、ステージング、本番環境など）に対応します。このアプローチにより、コード ライフサイクルの各ステージで Identity and Access Management の権限をカスタマイズできます。
分離された実行環境のベスト プラクティス
開発 SQL ワークフローの実行中に作成されたテーブルは、BigQuery の本番環境テーブルから分離することをおすすめします。 これにより、エンドユーザーが本番環境テーブルに確実に移動できるようになり、また、エンドユーザーが誤ったデータに間違えてアクセスするリスクを排除できます。
分離された実行環境は次の方法で作成できます。
- スキーマごとに開発テーブルと本番環境テーブルを分割する
- 小規模なチームに推奨できます。Dataform は、BigQuery の異なるスキーマに開発テーブルと本番環境テーブルを作成します。 Dataform は、開発中に作成されたことを示す、同じ接尾辞を持つスキーマですべての開発テーブルを実行します。 デベロッパーは互いの開発テーブルを上書きできます。
- スキーマと Google Cloud プロジェクトごとに開発テーブルと本番環境テーブルを分割する
- 中規模のチームに推奨。Dataform は、BigQuery の異なるスキーマとプロジェクトに開発テーブルと本番環境テーブルを作成します。 Dataform は、専用の開発 Google Cloud プロジェクトですべての開発テーブルを公開しました。Dataform デベロッパーは、デベロッパー テーブルに対する固有のスキーマを持ちます。このソリューションにより、デベロッパーが互いの開発テーブルを誤って上書きするリスクを排除できます。このアプローチの欠点は、開発テーブルとスキーマを削除し、各環境内のすべてのテーブルを再作成するのに時間がかかる場合があることです。
- 開発、ステージング、本番環境のテーブルを Google Cloud プロジェクトごとに分割する
- 大規模なチームやステージング環境を必要とするチームに推奨。 Dataform は、BigQuery の専用の Google Cloud プロジェクトの各環境からのテーブルを実行します。このソリューションでは、コード ライフサイクルを最も細かく制御できます。
すべてのソリューションで、単一の Dataform リポジトリが単一のサードパーティのリモート リポジトリに接続されている必要があります。
すべてのソリューションで、デベロッパーは Dataform ワークスペース内の開発テーブルの実行を手動でトリガーします。Dataform は、リリース構成で本番環境テーブルとステージング テーブルを自動的にコンパイルし、ワークフロー構成に設定された頻度で実行します。
スキーマごとに開発と本番環境を分割する
このソリューションでは、Dataform が開発と本番環境の SQL ワークフローを実行する 2 つの実行環境を作成します。 開発テーブルと本番環境テーブルをスキーマごとに分割するには、ワークフロー設定、ワークスペースのコンパイルのオーバーライド、リリース構成を設定する必要があります。本番環境の実行をスケジュールするには、ワークフロー構成を作成する必要があります。
Dataform は、開発中に作成されたことを示す、同じ接尾辞を持つスキーマですべての開発テーブルを実行します。Dataform は、接尾辞のないスキーマですべての本番環境テーブルを実行します。
次の表は、開発テーブルと本番環境テーブルをスキーマごとに 1 つの開発スキーマで分割する構成を示しています。
| 設定 | 開発 | 本番環境 |
|---|---|---|
| Google Cloud プロジェクト | enterprise-analytics |
enterprise-analytics |
| Git のブランチ。 | ワークスペースの名前 | main |
| ワークスペースのコンパイルのオーバーライド | スキーマの接尾辞: dev |
- |
| リリース構成 | - | production |
| ワークフロー構成 | - | production |
このソリューションでは、開発テーブルと本番環境テーブルが単一の Google Cloud プロジェクトに保存されます。
デベロッパーは、Dataform ワークスペースで手動で実行をトリガーします。手動でトリガーされたすべての実行で、Dataform は、開発中に作成されたことを示す、同じ接尾辞を持つスキーマでテーブルを実行します。デベロッパーは、互いのテーブルを上書きできてしまうことを認識する必要があります。
Dataform で、デベロッパーは変更を commit してリモート リポジトリのカスタム ブランチに push します。次に、サードパーティの Git ホスティング プラットフォームで、pull リクエストを送信します。pull リクエストが承認されると、リモート リポジトリの main ブランチへの変更がマージされます。
Dataform は、production リリース構成の設定に従って、本番環境リポジトリをリモート リポジトリの main ブランチからコンパイル結果に自動的にコンパイルします。
Dataform は、production ワークフロー構成に設定されたスケジュールに従って、production コンパイル結果を自動的に実行します。
このソリューションを実装するには、次の Dataform 設定を構成します。
ワークフローの設定
Dataform コアのバージョンに応じて、ワークフロー設定は workflow_settings.yaml または dataform.json に保存されます。詳細については、Dataform ワークフロー設定の構成をご覧ください。
workflow_settings.yaml で、次のように設定します。
defaultProject: enterprise-analytics
defaultDataset: analytics
dataform.json で、次のように設定します。
{
defaultSchema: "analytics",
defaultDatabase: "enterprise-analytics"
}
ワークスペースのオーバーライド
スキーマの接尾辞: "dev"
リリース構成
Git commitish: "main"
production コンパイル結果の実行をスケジュールするには、ワークフロー構成を作成します。
開発プロセスの例
この例では、デベロッパーの Sasha と Kai は同じ Dataform リポジトリで作業しています。Dataform リポジトリは、リモートのサードパーティ Git リポジトリに接続されます。
変更を commit し、リモート リポジトリ内のカスタム ブランチ（sasha と kai）に push します。
次の表に、Ssha、Kai、本番環境に適用された環境設定を示します。
| 設定 | Sasha | Kai | 本番環境 |
|---|---|---|---|
| Google Cloud プロジェクト | enterprise-analytics |
enterprise-analytics |
enterprise-analytics |
| Git のブランチ。 | sasha |
kai |
main |
| スキーマ | analytics_dev |
analytics_dev |
analytics |
Sasha は、新しいテーブルを作成して、以下のプロセスでこれを本番環境にデプロイします。
- Dataform ワークスペースで、Sasha は
user_stats.sqlxテーブルを作成します。 - ワークスペースで、Sasha はテーブルの実行を手動でトリガーします。
- Dataform は、BigQuery の
enterprise-analyticsGoogle Cloud プロジェクトのanalytics_devスキーマにenterprise-analytics.analytics_dev.user_statsテーブルを作成します。 - ワークスペースで、Sasha は変更を commit して、リモートの Git リポジトリの
sashaブランチにこれを push します。 - リモート リポジトリで、Sasha が pull リクエストを送信します。
- リモート リポジトリで Kai が pull リクエストを確認して承認し、変更を
mainブランチにマージします。 - Dataform は、指定された頻度で
productionリリースのコンパイル結果を自動的に更新します。productionコンパイル結果の次の更新中に、Dataform はコンパイル結果にenterprise-analytics.analytics.user_statsテーブルを追加します。 - ワークフロー構成のスケジュールされた実行中、Dataform は BigQuery の
enterprise-analyticsGoogle Cloud プロジェクトのanalyticsスキーマでenterprise-analytics.analytics.user_statsテーブルを実行します。 user_stats.sqlxテーブルは、BigQuery のenterprise-analyticsGoogle Cloud プロジェクトのanalyticsスキーマのエンドユーザーが使用できます。
スキーマとプロジェクトごとに開発と本番環境を分割する
このソリューションでは、開発と本番環境の 2 つの実行環境が作成されます。開発テーブルと本番環境テーブルをスキーマと Google Cloud プロジェクトごとに分割するには、ワークフローの設定、ワークスペースのコンパイルのオーバーライド、リリース構成を設定する必要があります。本番環境の実行をスケジュールするには、ワークフロー構成を作成する必要があります。
このソリューションでは、Dataform は、それぞれのワークスペースに対して異なるスキーマ接尾辞を持つスキーマで、専用の Google Cloud プロジェクトの開発テーブルを実行します。
Dataform は、スキーマ接尾辞のない、専用の本番環境 Google Cloud プロジェクトの BigQuery 内のすべての本番環境テーブルを実行します。
次の表は、Dataform ワークスペースごとに 1 つの開発スキーマを使用して、スキーマと Google Cloud プロジェクトごとに開発テーブルと本番環境テーブルを分割する構成を示しています。
| 設定 | 開発 | 本番環境 |
|---|---|---|
| Google Cloud プロジェクト | enterprise-dev |
enterprise-prod |
| Git のブランチ。 | ワークスペースの名前 | main |
| ワークスペースのコンパイルのオーバーライド | スキーマの接尾辞: ${workspaceName} |
- |
| リリース構成 | - | production |
| ワークフロー構成 | - | production |
このソリューションでは、Dataform は、BigQuery 内の異なるスキーマと Google Cloud プロジェクトの開発テーブルと本番環境テーブルを実行します。
デベロッパーは、Dataform ワークスペースで手動で実行をトリガーします。各デベロッパーは、専用の名前が付けられた専用のワークスペース（sasha など）で作業します。
デベロッパーがワークスペースで実行をトリガーすると、Dataform はすべてのスキーマにスキーマ接尾辞としてワークスペース名を追加します。次に、Dataform はカスタム スキーマ内のテーブルを実行します。
たとえば、Dataform は、BigQuery の analytics_sasha スキーマの sasha ワークスペースからテーブルを作成します。このようにして、各デベロッパーが開発テーブルを独自のスキーマに保存します。他のデベロッパーのテーブルを誤って上書きしてしまうリスクはありません。
Dataform で、デベロッパーは変更を commit してリモート リポジトリのカスタム ブランチに push します。次に、サードパーティの Git ホスティング プラットフォームで、pull リクエストを送信します。pull リクエストが承認されると、リモート リポジトリの main ブランチへの変更がマージされます。
Dataform は、production リリース構成の設定に従って、本番環境リポジトリをリモート リポジトリの main ブランチからコンパイル結果に自動的にコンパイルします。
Dataform は、production ワークフロー構成に設定されたスケジュールに従って、production コンパイル結果を自動的に実行します。
このソリューションを実装するには、次の Dataform 設定を構成します。
ワークフローの設定
Dataform コアのバージョンに応じて、ワークフロー設定は workflow_settings.yaml または dataform.json に保存されます。詳細については、Dataform ワークフロー設定を構成するをご覧ください。
workflow_settings.yaml で、次のように設定します。
defaultProject: enterprise-dev
defaultDataset: analytics
dataform.json で、次のように設定します。
{
defaultSchema: "analytics",
defaultDatabase: "enterprise-dev"
}
ワークスペースのオーバーライド
スキーマの接尾辞: "${workspaceName}"
リリース構成
- Git commitish:
"main" - Google Cloud プロジェクト ID:
"enterprise-prod"
production コンパイル結果の実行をスケジュールするには、ニーズに最も適したカスタム スケジュールでワークフロー構成を作成します。
開発プロセスの例
この例では、デベロッパーの Sasha と Kai は同じ Dataform リポジトリで作業しています。Dataform リポジトリは、リモートのサードパーティ Git リポジトリに接続されます。
Sasha は sasha という専用ワークスペースで作業し、Kai は Kai という専用のワークスペースで作業しています。変更を commit し、リモート リポジトリ内のカスタム ブランチ（sasha と kai）に push します。
次の表に、Ssha、Kai、本番環境に適用された環境設定を示します。
| 設定 | Sasha | Kai | 本番環境 |
|---|---|---|---|
| Google Cloud プロジェクト | enterprise-dev |
enterprise-dev |
enterprise-prod |
| Git のブランチ。 | sasha |
kai |
main |
| ワークスペースのコンパイルのオーバーライド | スキーマの接尾辞: ${workspaceName} |
スキーマの接尾辞: ${workspaceName} |
- |
| リリース構成 | - | - | production |
| ワークフロー構成 | - | - | production |
Sasha は、新しいテーブルを作成して、以下のプロセスでこれを本番環境にデプロイします。
sashaDataform ワークスペースで、Sasha はuser_stats.sqlxテーブルを作成します。sashaワークスペースで、Sasha はテーブルの実行を手動でトリガーします。- Dataform は、BigQuery の
enterprise-devGoogle Cloud プロジェクトのanalytics_sashaスキーマにあるenterprise-dev.analytics_sasha.user_statsテーブルを実行します。 sashaワークスペースで、Sasha は変更を commit して、リモートの Git リポジトリのsashaブランチにこれを push します。- リモート リポジトリで、Sasha が pull リクエストを送信します。
- リモート リポジトリで Kai が pull リクエストを確認して承認し、変更を
mainブランチにマージします。 - Dataform は、指定された頻度で
productionリリースのコンパイル結果を自動的に更新します。productionコンパイル結果の次の更新中に、Dataform はコンパイル結果にenterprise-prod.analytics.user_statsテーブルを追加します。 - ワークフロー構成のスケジュールされた実行中、Dataform は BigQuery の
enterprise-prodGoogle Cloud プロジェクトのanalyticsスキーマでenterprise-prod.analytics.user_statsテーブルを実行します。 user_stats.sqlxテーブルは、BigQuery のenterprise-prodGoogle Cloud プロジェクトのanalyticsスキーマのエンドユーザーが使用できます。
スキーマとプロジェクトごとに開発、ステージング、本番環境を分割する
このソリューションでは、開発、ステージング、本番環境の 3 つの実行環境を作成します。すべての環境は Google Cloud プロジェクトごとに分割されます。 さらに、開発はスキーマごとにステージングと本番環境から分割されます。
開発テーブル、ステージング テーブル、本番環境テーブルをスキーマと Google Cloud プロジェクトごとに分割するには、ワークフロー設定、ワークスペースのコンパイルのオーバーライド、2 つのリリース構成を設定する必要があります。ステージングと本番環境の実行をスケジュールするには、2 つの個別のワークフロー構成を作成する必要があります。
このソリューションでは、Dataform は専用の開発 Google Cloud プロジェクトで、Dataform ワークスペースごとに 1 つずつ、複数の開発スキーマで BigQuery の開発テーブルを実行します。
Dataform は、ステージングで開発されたことを示す、同じ接尾辞を持つスキーマで、専用のステージング Google Cloud プロジェクトの BigQuery 内のすべてのステージング テーブルを実行します。
Dataform は、本番環境で作成されたことを示す、同じ接尾辞を持つスキーマで、専用の本番環境 Google Cloud の専用プロジェクトの BigQuery 内のすべての本番環境テーブルを実行します。
次の表は、Dataform ワークスペースごとに 1 つの開発スキーマを使用して、開発テーブル、ステージング テーブル、本番環境テーブルをスキーマと Google Cloud プロジェクトごとに分割する構成の例を示しています。
| 設定 | 開発 | ステージング | 本番環境 |
|---|---|---|---|
| Google Cloud プロジェクト | enterprise-dev |
enterprise-staging |
enterprise-prod |
| Git のブランチ。 | ワークスペースの名前 | main |
prod |
| ワークスペースのコンパイルのオーバーライド | スキーマの接尾辞: ${workspaceName} |
- | - |
| リリース構成 | - | staging |
production |
| ワークフロー構成 | - | staging |
production |
このソリューションでは、Dataform は、BigQuery の異なる Google Cloud プロジェクトの開発テーブル、ステージング テーブル、本番環境テーブルを実行します。 さらに、Dataform は、ワークスペースごとに 1 つずつ、複数のカスタム スキーマで開発テーブルを実行します。Dataform は、異なる Google Cloud プロジェクトでステージング テーブルと本番環境テーブルを同じスキーマで実行します。
デベロッパーは、Dataform ワークスペースで手動で実行をトリガーします。各デベロッパーは、専用の名前が付けられた専用のワークスペース（sasha など）で作業します。
各ワークスペースは、ワークスペースにちなんで名付けられたカスタム BigQuery スキーマに対応しています。デベロッパーがワークスペースでの実行をトリガーすると、Dataform はデフォルトのスキーマにスキーマ接尾辞としてワークスペース名を追加します。次に、Dataform は、BigQuery のカスタム スキーマのテーブルを実行します。
たとえば、Dataform は、BigQuery の analytics_sasha スキーマの sasha ワークスペースからテーブルを実行します。このようにして、各デベロッパーが開発テーブルを独自のスキーマに保存します。他のデベロッパーのテーブルを誤って上書きしてしまうリスクはありません。
Dataform で、デベロッパーは変更を commit してリモート リポジトリのカスタム ブランチに push します。次に、サードパーティの Git ホスティング プラットフォームで、pull リクエストを main ブランチに送信します。pull リクエストが承認されると、リモート リポジトリの main ブランチへの変更がマージされます。
Dataform は、staging リリース構成の設定に従って、リモート リポジトリの main ブランチからステージング テーブルをコンパイル結果に自動的にコンパイルします。
Dataform は、staging ワークフロー構成に設定されたスケジュールに従って、staging コンパイル結果を自動的に実行します。
ステージングから本番環境にテーブルを昇格させるには、サードパーティの Git ホスティング プラットフォームで、デベロッパーが main ブランチから prod ブランチに pull リクエストを送信します。pull リクエストが承認されると、リモート リポジトリの prod ブランチへの変更がマージされます。
Dataform は、production リリース構成の設定に従って、本番環境リポジトリをリモート リポジトリの prod ブランチからコンパイル結果に自動的にコンパイルします。
Dataform は、production ワークフロー構成に設定されたスケジュールに従って、production コンパイル結果を自動的に実行します。
このソリューションを実装するには、次の Dataform 設定を構成します。
ワークフローの設定
Dataform コアのバージョンに応じて、ワークフロー設定は workflow_settings.yaml または dataform.json に保存されます。詳細については、Dataform ワークフロー設定を構成するをご覧ください。
workflow_settings.yaml で、次のように設定します。
defaultProject: enterprise-dev
defaultDataset: analytics
dataform.json で、次のように設定します。
{
defaultSchema: "analytics",
defaultDatabase: "enterprise-dev"
}
ワークスペースのオーバーライド
スキーマの接尾辞: "${workspaceName}"
staging リリース構成
- Git commitish:
"main" - Google Cloud プロジェクト ID:
"enterprise-staging"
prod リリース構成
- Git commitish:
"prod" - Google Cloud プロジェクト ID:
"enterprise-prod"
staging と production のコンパイル結果の実行をスケジュールするには、ニーズに最適なカスタム スケジュールで 2 つの別のワークフロー構成を作成します。
開発プロセスの例
この例では、デベロッパーの Sasha と Kai は同じ Dataform リポジトリで作業しています。Dataform リポジトリは、リモートのサードパーティ Git リポジトリに接続されます。
Sasha は sasha という専用ワークスペースで作業し、Kai は Kai という専用のワークスペースで作業しています。変更を commit し、リモート リポジトリ内のカスタム ブランチ（sasha と kai）に push します。
次の表に、Ssha、Kai、本番環境に適用された環境設定を示します。
| 設定 | Sasha | Kai | ステージング | 本番環境 |
|---|---|---|---|---|
| Google Cloud プロジェクト | enterprise-dev |
enterprise-dev |
enterprise-staging |
enterprise-prod |
| Git のブランチ。 | sasha |
kai |
main |
prod |
| スキーマ | analytics_sasha |
analytics_kai |
analytics |
analytics |
Sasha は、新しいテーブルを作成して、以下のプロセスでこれを本番環境にデプロイします。
sashaDataform ワークスペースで、Sasha はuser_stats.sqlxテーブルを作成します。sashaワークスペースで、Sasha はテーブルの実行を手動でトリガーします。- Dataform は、BigQuery の
enterprise-devGoogle Cloud プロジェクトのanalytics_sashaスキーマにあるenterprise-dev.analytics_sasha.user_statsテーブルを実行します。 sashaワークスペースで、Sasha は変更を commit して、リモートの Git リポジトリのsashaブランチにこれを push します。- リモート リポジトリで、Sasha が pull リクエストを
mainブランチに送信します。 - リモート リポジトリで Kai が pull リクエストを確認して承認し、変更を
mainブランチにマージします。 - Dataform は、指定された頻度で
stagingリリースのコンパイル結果を自動的に更新します。stagingコンパイル結果の次の更新中に、Dataform はコンパイル結果にenterprise-staging.analytics.user_statsテーブルを追加します。 - ワークフロー構成のスケジュールされた実行中、Dataform は BigQuery の
enterprise-stagingGoogle Cloud プロジェクトのanalyticsスキーマでenterprise-staging.analytics.user_statsテーブルを実行します。 - リモート リポジトリで、Sasha が pull リクエストを
prodブランチに送信します。 - リモート リポジトリで Kai が pull リクエストを確認して承認し、変更を
prodブランチにマージします。 - Dataform は、指定された頻度で
productionリリースのコンパイル結果を自動的に更新します。productionコンパイル結果の次の更新中に、Dataform はコンパイル結果にenterprise-prod.analytics.user_statsテーブルを追加します。 - ワークフロー構成のスケジュールされた実行中、Dataform は BigQuery の
enterprise-prodGoogle Cloud プロジェクトのanalyticsスキーマでenterprise-prod.analytics.user_statsテーブルを実行します。 user_stats.sqlxテーブルは、BigQuery のenterprise-prodGoogle Cloud プロジェクトのanalyticsスキーマのエンドユーザーが使用できます。
次のステップ
- Dataform のコード ライフサイクルと構成方法の詳細について、Dataform のコード ライフサイクルの概要を確認する。
- Dataform ワークスペース コンパイル オーバーライドを作成する方法については、ワークスペース コンパイル オーバーライドを作成するをご覧ください。
- Dataform リリース構成の作成方法については、リリース構成を作成するをご覧ください。
- Dataform ワークフロー構成の作成方法については、ワークフロー構成で実行をスケジュールするをご覧ください。