Snowflake DCM Projects

Snowflake|dcm|（データベース変更管理プロジェクト）は、Snowflakeオブジェクトをコードとして管理するための宣言型アプローチを可能にします。定義ファイルで、データベース、スキーマ、テーブル、およびその他のオブジェクトの望ましいターゲット状態を定義し、Snowflakeはその状態に達するために必要な変更を決定して適用します。これにより、開発、ステージング、本番などの環境全体で、バージョン管理された反復可能なデプロイメントが可能になります。これは、infrastructure-as-codeツール間で一般的な「計画してからデプロイ」ワークフローを使用して実行されます。

定義に反復パターンが含まれている場合は、Jinjaテンプレートを使用して、ディクショナリ、ループ、条件、マクロを含むコードをパラメーター化できます。

|dcm-object|を管理するための高レベルのワークフローは次のとおりです。

  1. Snowflake Workspace、リモートGitリポジトリ、またはローカルディレクトリに|dcm-object|ファイル（:file:`manifest.yml`およびSQL定義ファイル）を作成します。

  2. 各ターゲット環境用に新しい|dcm-object|を作成します。

  3. |dcm-object|ファイルでSnowflakeオブジェクトを定義します。

    DEFINEキーワードを使用して、既存のSQLデプロイメントスクリプトを変換します（サポートされているオブジェクト型の場合）。

  4. （オプション）共有または代替のテンプレート変数とマクロを追加します。

  5. DCM PLANコマンドを実行して、デプロイメントを模倣し、変更をプレビューします。

  6. Snowflakeで変更を適用するためにプロジェクトバージョンをデプロイします。

  7. プロジェクトの実行をモニターします。

  8. DCMプロジェクトを反復処理します。プロジェクトファイルを更新し、計画の出力を確認して、必要に応じて新しいバージョンをデプロイします。

このライフサイクルは、制御、バージョン管理、監査可能な方法でデータベースの変更を構築、テスト、デプロイ、モニターするのに役立ちます。

次の図は、上記の|dcm|ライフサイクルを示しています。

DCMプロジェクトのライフサイクル

重要な用語

以下は、|dcm|を使用する際に知っておくべき重要な用語です。

宣言型定義

|dcm|では、オブジェクトの現在の状態に関係なく、どのテーブル、スキーマ、ロールが存在するかなど、Snowflake環境の望ましい状態を定義します。それらを作成または変更するための各ステップは指定しません。必要なものを記述し、Snowflakeはそれを実現する方法を把握します。

具体的には、|dcm|はテンプレート機能を備えたDEFINEステートメントを活用します。これにより、プロジェクトファイルは再利用可能で、さまざまな環境でカスタマイズできるようになります。プロジェクト内のDEFINEステートメントの順序と場所は、結果に影響しません。Snowflakeは変更を適用する前にすべてのステートメントを収集およびソートするため、シーケンス処理や依存関係を手動で処理する必要はありません。

DCMプロジェクトファイル

|dcm-object|は、通常、Gitリポジトリまたはローカルワークスペースで管理される一連のSQLおよびYAMLソースファイルに基づいています。プロジェクト定義ファイル（SQLファイル）で、|dcm-object|に対するSnowflakeオブジェクト、その属性、関係、および制約を定義します。開発ワークスペースでプロジェクトファイルを更新します。変更は、|dcm-object|オブジェクトを通じてデプロイした後にのみSnowflakeで有効になります。

DCMプロジェクトオブジェクト

|dcm-object|はSnowflakeのスキーマレベルのオブジェクトで、|dcm-object|ファイルで定義されたオブジェクトのデプロイと管理に使用します。各ターゲット環境に|dcm-object|オブジェクトが必要です。

|dcm-object|オブジェクトは、DCMコマンドを実行するために使用され、実行されたすべてのデプロイメントの不変アーティファクトと定義ファイルを格納します。

|dcm-object|はスキーマレベルのオブジェクトですが、これを使用して他のデータベースのオブジェクトを作成および管理できます。|dcm-object|を実行してワークフローへの変更のドライランを行い、デプロイする前に変更をプレビューすることもできます。

要件

  • |dcm|を管理するには、Snowsight、Snowflake CLI、SQL、またはCortex CLIを使用します。

  • |dcm-object|オブジェクトを作成できるデータベースとスキーマが必要です。

  • |dcm-object|定義は、ローカルまたはSnowflake Workspaceに保存します。

  • 共同作業、バージョン管理、変更の同期にはGitを使用します。

  • |sf-cli|を使用してローカル定義を実行する場合は、ターゲットの|dcm-object|オブジェクトのスキーマに仮ステージを作成する権限も必要です。

考慮事項と制約

  • プロジェクトサイズ

    • 現在、|dcm|は、最大1,000個のソースファイルと、10,000個のレンダリングされたオブジェクトの定義または付与をサポートしています。

      1,000個のファイルまたは10,000個の定義を超えると、パフォーマンスの低下や、場合によっては実行失敗が発生する可能性があります。

      定義をより少ないファイルに統合すると、一般にPLANおよびDEPLOYコマンドの実行時間が速くなります。

      この制限により、パフォーマンスとスケーラビリティが引き続き向上するため、パブリックプレビュー期間中に引き上げられます。

  • 変更セット

    PLANおよびDEPLOYコマンドはどちらも、:file:`plan_result.json`ファイル内のすべてのDDLの変更をリストします。変更セットには、実行または計画された操作（CREATE、ALTER、DROP）と、コメント、スケジュール、タイムアウトなど、影響を受ける個々の属性がリストされます。

    重要

    |dcm|のプレビュー段階では、各オブジェクトのすべてのプロパティにわたるすべての詳細な変更が、変更セットに含まれることは保証されません。

  • テンプレート化

    • 定義ファイルはJinja2テンプレートであるため、Jinja2テンプレートのすべての制限が適用されます。

    • DCMテンプレート化変数は、認証情報のような機密情報を対象とするものではありません。レンダリングされたSQL定義は、環境変数によって挿入された値をマスキングしません。

|dcm|の主なユースケース

このセクションでは、|dcm|の主なユースケースと、データビジネスで大規模に直面する課題に対処する方法について説明します。これらのユースケースは、チームの責任に基づいて、2つの一般的なカテゴリに分類されます。

インフラストラクチャ管理用の|dcm|

|dcm|は、プラットフォームチームが直面することが多い次の課題に対処するのに役立ちます。

プラットフォームチームの課題

プラットフォームチームが複数のビジネスユニットに標準化されたインフラストラクチャをデプロイおよび維持する場合、|dcm|を使用して、SQLファイルとしてコードでオブジェクトの標準セットを定義できます。そして、Jinjaでは、このテンプレートをチーム名などでパラメーター化し、複数回デプロイすることができます。

例:各ビジネスユニット専用の|dcm-object|を作成する

1つのアプローチは、次の:file:`definitions.sql`の例に示すように、すべてのプロジェクトが同じパラメーター化された定義ファイルを参照する、各ビジネスユニット専用の|dcm-object|を作成することです。

DEFINE DATABASE {{team_name}}_DB;

DEFINE ROLE {{team_name}}_ADMIN;

DEFINE WAREHOUSE {{team_name}}_WH WITH
  warehouse_size = '{{wh_size}}'
  auto_suspend = 300;

GRANT OWNERSHIP ON DATABASE {{team_name}}_DB TO ROLE {{team_name}}_ADMIN;

GRANT OWNERSHIP ON WAREHOUSE {{team_name}}_WH TO ROLE {{team_name}}_ADMIN;

GRANT ROLE {{team_name}}_ADMIN TO ROLE SYSADMIN;

次のコマンドで|dcm-object|を実行します。

EXECUTE DCM PROJECT FINANCE_INFRA PLAN
  USING (team_name => 'Finance', wh_size => 'LARGE')
FROM
  ...

例:複数のビジネスユニット用に単一の|dcm-object|を作成する

このアプローチでは、次の:file:`definitions.sql`の例に示すように、Jinjaテンプレートでループを使用して、1つの|dcm-object|で複数のビジネスユニットのインフラストラクチャを管理します。

{% for team_name in teams %}

  DEFINE DATABASE {{team_name}}_DB;
  DEFINE ROLE {{team_name}}_ADMIN;
  DEFINE WAREHOUSE {{team_name}}_WH
    WITH
      warehouse_size = '{{wh_size}}'
      auto_suspend = 300;

  GRANT OWNERSHIP ON DATABASE {{team_name}}_DB TO ROLE {{team_name}}_ADMIN;
  GRANT OWNERSHIP ON WAREHOUSE {{team_name}}_WH TO ROLE {{team_name}}_ADMIN;
  GRANT ROLE {{team_name}}_ADMIN TO ROLE SYSADMIN;

{% endfor %}

次のコマンドで|dcm-object|を実行します。

EXECUTE DCM PROJECT FINANCE_INFRA PLAN
  USING (teams => ['Finance', 'HR', 'Engineering'], wh_size => 'MEDIUM')
FROM
  ...

これにより、プラットフォームチームや管理者は以下のような変更が容易になります。

  • 新しいチームをリストに追加して、そのチームに既存のインフラストラクチャテンプレートをデプロイする。

  • リストからチームを削除して、そのチームのインフラストラクチャをドロップする。

  • すべてのチームに新しいREAD_ONLYロールを追加する。

  • 全チームまたは特定のチームに対する付与やウェアハウスのサイズなど、特定の構成を変更する。

  • PLANを実行して現在の状態を期待される標準と比較し、標準を復元するために再デプロイする。

データパイプライン用の|dcm|

|dcm|は、機能チームがよく直面する次の課題に対処するのに役立ちます。

機能チームの課題

データパイプラインを簡単に作成および管理したいビジネスユニットは、|dcm|を使用してビジネスロジックを定義、テスト、デプロイ、および反復処理できます。

できること:

  • テーブル、動的テーブル、ビュー、ウェアハウス、ロール、付与、データメトリック関数、期待値などのSnowflakeオブジェクトタイプをすべて1つのプロジェクトで管理します。

  • パイプラインへの増分変更をテストし、デプロイします。構成を変更し、変換ロジックを実装し、列とビューを追加することができます。

  • オブジェクトをデプロイする前に変換ロジックを検証するためのデータサンプルをプレビューします。

  • 同じパイプライン定義を複数の環境にデプロイします。

  • 変更を本番環境にデプロイする前に、本番前環境でデータ品質の期待値をテストします。

|dcm|は、データパイプラインを作成および管理するための追加機能を提供します。詳細については データパイプライン用の|dcm| をご参照ください。