Snowflakeを使用した DevOps¶

DCM プロジェクト（推奨）¶

DCM プロジェクト （データベース変更管理プロジェクト）は、Snowflake環境を管理するための宣言的でコードとしてのインフラストラクチャのアプローチを提供します。各ステップを指定する命令スクリプトを記述する代わりに、オブジェクトの望ましいターゲット状態を定義します。Snowflakeはこれらの定義を現在の状態と比較し、必要な変更を決定します。

DCM プロジェクトの構成は次のとおりです。

• マニフェストファイル （ manifest.yml ）は、各環境のデプロイターゲット、所有者ロール、テンプレート化構成を指定します。

• 定義ファイル （ sources/definitions/ の下にある SQL ファイル）には、Snowflakeオブジェクトの DEFINE ステートメント、アクセス制御の GRANT ステートメント、およびデータ品質に期待される ATTACH ステートメントが含まれます。

次の例は、Jinja2テンプレートを使用して複数チームのインフラストラクチャを作成する定義ファイルを示しています。

{% for team in teams %}

  DEFINE DATABASE {{team.name}}_DB;

  DEFINE WAREHOUSE {{team.name}}_WH
    WITH
      warehouse_size = '{{team.wh_size}}'
      auto_suspend = 300;

  DEFINE ROLE {{team.name}}_ADMIN;

  GRANT OWNERSHIP ON DATABASE {{team.name}}_DB TO ROLE {{team.name}}_ADMIN;
  GRANT OWNERSHIP ON WAREHOUSE {{team.name}}_WH TO ROLE {{team.name}}_ADMIN;

{% endfor %}

プロジェクトファイルの設定方法、複数の環境の管理方法、デプロイの自動化方法など DCM プロジェクトの完全なドキュメントについては、 Snowflake DCM Projects を参照してください。

Snowflakeでのdbtプロジェクト¶

:doc:` Snowflakeでのdbtプロジェクト </user-guide/data-engineering/dbt-projects-on-snowflake>` をデプロイして ` dbtコア <https://www.getdbt.com/>`_ プロジェクトをネイティブSnowflakeオブジェクトとして実行します。dbtモデルの SQL 変換を定義し、バージョン管理された DBT PROJECT オブジェクトとしてデプロイし、Snowflake SQL またはSnowflake CLI でそれらを実行します。Snowflakeタスクで実行をスケジュールし、 CI/CD パイプラインにデプロイを統合することができます。

詳細については、 Snowflakeでのdbtプロジェクト をご参照ください。

代替候補: バージョン管理されたスクリプトを使用してCREATE OR ALTER¶

DCM プロジェクトの外側にある個々のオブジェクトの変更については、 CREATE OR ALTER <オブジェクト> コマンドを使用できます。このコマンドは、オブジェクトを作成したり、コマンドで指定された定義と一致するようにオブジェクトを変更したりします。リモートリポジトリ内のバージョン管理されたファイルからこのコマンドを使用すると、ファイルの以前のバージョンを実行することで以前のバージョンへの変更をロールバックできます。

CREATE OR ALTER TABLE vacation_spots (
  city VARCHAR,
  airport VARCHAR,
  avg_temperature_air_f FLOAT,
  avg_relative_humidity_pct FLOAT,
  avg_cloud_cover_pct FLOAT,
  precipitation_probability_pct FLOAT
) data_retention_time_in_days = 1;

from snowflake.core import Root
from snowflake.core.table import PrimaryKey, Table, TableColumn

my_table = root.databases["my_db"].schemas["my_schema"].tables["vacation_spots"].fetch()
my_table.columns.append(TableColumn(name="city", datatype="varchar", nullable=False))
my_table.columns.append(TableColumn(name="airport", datatype="varchar", nullable=False))
my_table.columns.append(TableColumn(name="avg_temperature_air_f", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="avg_relative_humidity_pct", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="avg_cloud_cover_pct", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="precipitation_probability_pct", datatype="float", nullable=False))

my_table_res = root.databases["my_db"].schemas["my_schema"].tables["vacation_spots"]
my_table_res.create_or_alter(my_table)

DCM プロジェクトを含む計画¶

DCM プロジェクトは、計画の後におけるデプロイモデルを使用します。PLAN コマンドは、定義ファイルとアカウントの現在の状態を比較し、何も変更せずに、提案された変更のリストを生成します。

Snowflake CLI: を使用してプランを実行できます。

snow dcm plan --target PROD

または SQL: を使用します。

EXECUTE DCM PROJECT my_db.my_schema.my_project
  PLAN
  USING CONFIGURATION PROD
FROM
  '@my_stage/my_project/';

デプロイに進む前に、出力を精査して、予想される作成、変更、およびドロップを確認します。

GitHub アクション¶

GitHub アクション を使用して、 CI/CD パイプラインを構成するジョブを自動化できます。

安全に認証するために、Snowflakeはパスワードや秘密キーなどの静的認証情報の代わりに、 OpenID 接続（ OIDC ）でのワークロードIDフェデレーション（ WIF ）の使用を推奨します。WIF OIDC 、 GitHub アクションは、 GitHub の OIDC プロバイダーから有効期限の短いトークンをリクエストし、Snowflakeはトークンを直接検証します。リポジトリに長期間有効なシークレットは格納されません。

WIF OIDC を設定するには、 GitHub の OIDC プロバイダーを信頼するSnowflakeサービスユーザーを作成します。

CREATE USER github_deployer
  TYPE = SERVICE
  DEFAULT_ROLE = deployer_role
  WORKLOAD_IDENTITY = (
    TYPE = OIDC
    ISSUER = 'https://token.actions.githubusercontent.com'
    SUBJECT = 'repo:<owner>/<repo>:environment:<environment_name>'
  );

サブジェクトクレームの構成と一般的な WIF について詳しくは ワークロードIDフェデレーション を参照してください。

次の例は、 WIF OIDC および DCM プロジェクトを使用して main ブランチに変更をプッシュすることで変更を計画し、デプロイするワークフローを示しています。

name: Deploy DCM project to production

on:
  push:
    branches:
      - main

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Set up Snowflake CLI
        uses: snowflakedb/snowflake-cli-action@v2
        with:
          use-oidc: true
          cli-version: "3.11"

      - name: Plan DCM project
        env:
          SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
        run: snow dcm plan --target PROD --save-output -x

      - name: Deploy DCM project
        env:
          SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
        run: snow dcm deploy --target PROD -x

代替認証メソッドを含む、Snowflake CLI での CI/CD の設定について詳しくは、 CI/CD と Snowflake CLI の統合 を参照してください。

環境ターゲットの接続プロファイル¶

DCM プロジェクトを使用すると、 manifest.yml ファイルで複数のデプロイターゲットを定義できます。各ターゲットは、特定のSnowflakeアカウント（またはデータベース）、プロジェクトオブジェクト、所有者ロール、テンプレート化構成にマップされます。同じ定義ファイルは、構成プロファイルを通じて環境固有の設定を適用して、すべての環境にデプロイできます。

targets:
  DEV:
    account_identifier: MYORG-MYACCOUNT_DEV
    project_name: MY_DB.MY_SCHEMA.MY_PROJECT_DEV
    project_owner: DEV_DEPLOYER
    templating_config: DEV

  PROD:
    account_identifier: MYORG-MYACCOUNT_PROD
    project_name: MY_DB.MY_SCHEMA.MY_PROJECT_PROD
    project_owner: PROD_DEPLOYER
    templating_config: PROD

templating:
  configurations:
    DEV:
      wh_size: "X-SMALL"
    PROD:
      wh_size: "LARGE"

複数プロジェクトのセットアップやチームコラボレーションなどのエンタープライズパターンについては、 。エンタープライズにおける|dcm|のユースケース を参照してください。

詳細:カスタムスクリプトのJinjaパラメーター化¶

DCM プロジェクトは、定義ファイルでのJinja2テンプレート化をネイティブでサポートしています。テンプレート変数、ループ、条件、マクロ、およびディクショナリを使用して、環境全体で定義を再利用できるようにすることができます。変数の値は manifest.yml の構成プロファイル、またはランタイムオーバーライドから取得されます。

DCM テンプレート化について詳しくは、 |dcm|ファイルとテンプレート を参照してください。

また、 EXECUTE IMMEDIATE FROM でJinja2を使用したスタンドアロン SQL スクリプト（ DCM プロジェクトの外部）でパラメーター化することもできます。Snowflake CLI では Python スクリプトに環境変数を渡すこともできます。

たとえば、展開ターゲットを変更するには、 SQL スクリプトでは {{ environment }} のようなJinja変数、Pythonスクリプトでは環境変数でターゲットデータベースの名前を置き換えます。このテクニックは、次の SQL とPythonのコード例で示されています。

CREATE OR ALTER TASK {{ environment }}.my_schema.my_task
  WAREHOUSE = my_warehouse
  SCHEDULE = '60 minute'
  AS select pi();

import os
from snowflake.core import Root, CreateMode
from datetime import timedelta
from snowflake.core.task import Task

my_task = Task(
    name="my_task",
    warehouse="my_warehouse",
    definition="select pi()",
    schedule=timedelta(minutes=60)
)
root = Root(Session.builder.getOrCreate())
tasks = root.databases[os.environ["environment"]].schemas["my_schema"].tasks
tasks.create(my_task, mode=CreateMode.or_replace)