Snowflake CLIで実現するdbt Project on Snowflakeでのモダンな開発フロー

はじめに

こんにちは、NTTドコモデータプラットフォーム部の田中です。私が所属する組織では、データ変換パイプラインの中核として dbt (data build tool) を活用しています。

dbtはSQLベースでデータ変換ロジックを記述でき、テストやドキュメント生成も可能な非常に強力なツールです。しかし、大規模に運用するには実行環境の構築・運用課題が常につきまといます。これまではAWS上でECSとAirflowを組み合わせて運用してきましたが、インフラ管理やバージョンアップ対応などの運用負荷は無視できないコストとなっていました。

基盤構築時の記事：MWAA、dbt、ECSを利用したデータパイプライン構築

そんな中、Snowflakeから Snowflake上でネイティブにdbtを実行できる機能であるdbt Project on Snowflake がリリースされました。

これを使えば、インフラ管理から解放されるのでは？と期待し、商用利用を見据えた検証を開始しました。本記事では、検証の過程で直面した商用適用の壁と、それを Snowflake CLI を活用して乗り越え、モダンな開発フロー（CI/CD、AIコーディング）を実現する方法ついて紹介します。
なお、本記事の掲載の取組・執筆については、株式会社シイエヌエスの支援メンバーである小倉さんと協働で行っています。

1. dbt Project on Snowflakeとは？

従来のdbt運用

これまでのdbt Coreを用いた運用には、基盤管理の悩みがありました。

インフラ管理: dbtを実行するためのコンテナ基盤やオーケストレーターの管理が必要。Pythonのバージョン管理やライブラリ依存関係のメンテナンスも発生。
コスト: dbtを実行するためだけの常時稼働、あるいは都度起動するComputeリソースの確保。

Snowflakeマネージドのdbtの登場

今回検証したdbt Project on Snowflake1は、 Snowflake内部にdbtプロジェクトをホストし、コンパイルから実行までをSnowflake上のウェアハウスで完結 させることができます。

dbtプロジェクトの資材をSnowflakeにアップロードするだけで良く、dbtを動かすためのPython環境を自前で用意・管理する必要がなくなります。これにより、インフラ管理コストがゼロになる点が本機能の魅力です。

dbt Project on Snowflakeでは、デプロイしたdbtプロジェクトは、dbt Project Objectというスキーマ配下のオブジェクトとして確立します。

2. 検証初期に直面した課題

最初に試したのは、SnowflakeのWeb UI上にあるWorkspaces機能2を使い、GitHubリポジトリと連携させる構成でした。

構成イメージ

コード管理: GitHubをWorkspacesと連携しコード管理。
開発環境: Workspaces (Web UI) で開発・デプロイ。
スケジューラ: Snowflake Tasksで定期実行。

この構成は、Webブラウザさえあれば開発ができ、セットアップも非常に簡単でした。初期導入のハードルは非常に低く、まずはdbtを試してみたい際には最適です。

商用利用するうえでの課題

しかし、検証を進める中で、商用運用を妨げる2つの課題に直面しました。

課題①：商用運用におけるガバナンス・CI/CDが組めない

最大の懸念点は、誰がどのコードをデプロイしたかの担保が難しい点です。
Workspacesはユーザーごとに環境が分離されているのが特徴ですが、これはつまりデプロイ作業が各個人の環境に依存することを意味します。GitHub Actions等による自動化（CI/CD）が組めないこの構成では、以下のリスクを排除できませんでした。

レビュー済みコードとの乖離リスク: デプロイされているdbt Project Objectは、本当にmainブランチのコードなのか？誰かが手元で書き換えたコードではないか？という証明がシステマチックにできない。

課題②：開発体験の低下

もう一つのネックは、WorkspacesではGitHub CopilotやClineなどのAIコーディングツールが利用できないことでした。現代のデータエンジニアリングにおいて、AIによるコード補完は生産性に直結します。また、使い慣れたVS Codeの拡張機能やローカルスクリプトも使えず、開発効率が低下してしまいます。

インフラ管理は楽になるが、開発効率とガバナンスが犠牲になる。これでは商用環境での採用は難しいという結論に至りました。

3. Snowflake CLI の導入による解決

そこで目をつけたのが Snowflake CLI (snow コマンド) です。 Snowflake CLIはコマンドラインからSnowflakeを操作するためのツールであり、dbt Project on Snowflakeにも対応しています。このツールを活用することで、dbtの実行自体はSnowflakeに任せるインフラレスメリットを享受しつつ、開発はローカル環境で行うことが可能になります。

Snowflake CLIを用いた構成

下記図の構成を考えました。

任意の開発環境: ローカルのVS Codeが使えるため、GitHub CopilotやClineがフル活用できます。
CI/CDによる整合性の担保: snow コマンドはCLIツールなので、GitHub Actions上で実行可能です。これによりmainブランチにマージされた承認済みコードのみが、CI/CDパイプライン経由で自動的に商用環境へデプロイされるという、あるべきガバナンス体制を構築できます。
スケジューラのコード管理: Snowflake Taskの作成・更新もコード管理することで、パイプライン上必要な資材を一元的に管理し、更新漏れや設定ミスを防ぎます。

これで、Workspacesを使う場合の「商用コード担保・CI/CD構築ができない」「任意のAIコーディングツールが使えない」という課題を解決できないかと考えました。

4. 商用を見据えたdbt on Snowflake開発フロー

dbtコード開発フェーズと、承認済みコードの商用デプロイフェーズに分けて商用利用を想定したワークフローを説明します。

任意の開発環境でのコード開発

開発者は手元のVS Code等任意の開発環境でコードを書き、以下のコマンドで実行確認を行います。この裏側では、ローカルのdbtソースコードが一時的なステージにアップロードされ、Snowflake上の環境で実行されます。

事前設定: config.tomlへの設定追加

ローカルに構築するSnowflake CLI接続情報設定ファイルであるconfig.tomlに、dbt機能の有効化設定を追加する必要があります。

[cli.features]
enable_dbt = true

①dbt deploy: ローカルにあるdbtプロジェクトファイルをSnowflakeにアップロードし、オブジェクト化

snow dbt deploy [オブジェクト名] --source [ローカルdbtのフォルダパス]

②dbt execute: Snowflakeにデプロイしたdbtプロジェクトの実行操作

#dbt runする場合
snow dbt execute [オブジェクト名] run --target dev --select [実行モデル指定]

#dbt testする場合
snow dbt execute [オブジェクト名] test --target dev --select [実行モデル指定]

ポイントは、開発時もローカルで直接dbt実行するのではなく、①Snowflakeにdbt Projectオブジェクトを作り、②Snowflakeにあるdbtオブジェクトを実行するという流れにしたことです。

これにより、ローカルで開発し、実行はSnowflake という開発フローが実現し、AIコーディングツールなど自分が利用したものを使いつつ、実行環境は商用と全く同じ構成で検証することができます。

dbt deployというひと手間がかかってしまう手順にはなりますが、開発環境にdbt環境を構築する必要がなく、開発商用差分なく検証を進められることは大きなメリットと感じます。

承認済みコードの商用デプロイCI/CD

続いて、承認されたmainコードを商用デプロイするCI/CDを構築するフローの検証を行います。

Snowflake CLIで、任意の環境からdbtプロジェクトが扱えることで、GitHub Actionsを用いてCI/CDを構築することが可能になります。これにより、個人の環境に依存したデプロイを防ぎ、コードの整合性を担保します。

今回はこの自動デプロイにフォーカスして、下記図の通りCI/CDフローを検証しました。

CI/CDの処理の流れ

dbt deployを実行し、mainブランチにあるdbtコードをSnowflakeにdbt Objectとしてデプロイ
Snowflake Taskの作成・更新SQLを実行し、デプロイしたdbt Objectのスケジューラを更新

Github Actions設定コード

Github Actionsの設定yamlの中で、今回のCI/CDに関わる実装を紹介します。

Snowflake CLIでの接続情報を環境変数として定義し、一時接続フラグ-xをつけることで疎通ができます。今回のフローでは省略していますが、dbt executeを実行する場合は、snow dbt execute -x [dbt object name] runの順序で指定しないとエラーが発生します。
Snowflake Taskの作成を定義したSQLファイルをsnowflake_tasksフォルダ配下においておき、dbt Projectのデプロイ後にTask作成SQLをすべて実行する形にしています。

jobs:
  deploy-production:
    # 実行タイミング定義
    
    steps:
      # Snowflake CLIのインストール
      - name: Install Snowflake CLI
        run: |
          pip install snowflake-cli-labs

      # dbt Projectのデプロイ
      - name: Deploy dbt project with snow dbt deploy
        env:
          # Snowflakeへの接続情報を定義
        run: |
          snow dbt deploy dbt_cicd --force --source dbt_pipeline -x

      # Snowflake Taskの作成クエリを実行
      - name: Deploy Snowflake tasks
        env:
          # Snowflakeへの接続情報を定義
        run: |
          # snowflake_tasksディレクトリ内のすべてのSQLファイルを実行
          for sql_file in snowflake_tasks/*.sql; do
            if [ -f "$sql_file" ]; then
              echo "Executing $sql_file..."
              snow sql -f "$sql_file" -x
            fi
          done

Snowflake Task作成SQL

デプロイしたdbtプロジェクトをスケジューリングするためのSnowflake Taskの作成SQLについて解説します。dbtプロジェクトは、SnowflakeのSQL構文ではEXECUTE DBT PROJECTで実行されます。

過去はSnowflake Taskが一時停止状態Suspendでないと、REPLACEができませんでしたが、最近のアップデートで起動状態ResumeのままでもREPLACEが実行されるようになったため、タスクの状態を気にせず更新することができます。

-- dbt モデルを定期実行するSnowflake Task
CREATE OR REPLACE TASK POC_DB.DBT_SCHEMA_PROD.DAILY_DBT_RUN_TASK
  WAREHOUSE = POC_WH_XSMALL
  SCHEDULE = 'USING CRON 0 3 * * * Asia/Tokyo'
  COMMENT = 'Daily dbt models refresh task for production'
AS
  EXECUTE DBT PROJECT POC_DB.DBT_SCHEMA_PROD.dbt_cicd 
  ARGS='build --target prod';

-- Taskを有効化
ALTER TASK POC_DB.DBT_SCHEMA_PROD.DAILY_DBT_RUN_TASK RESUME;

今回は自動デプロイにフォーカスしましたが、これまでの仕組みを使えば、自動テストなど様々なワークフローをdbt Project on Snowflakeで組むことが可能になります。

5. まとめ

今回の検証を通じて、Snowflake CLI を活用することで、以下の成果が得られることがわかりました。

運用負荷の削減: ECSやAirflowなどの外部実行基盤が不要になり、アーキテクチャがシンプルになりました。
モダンな開発体験の維持: Workspacesの制約に縛られず、VS Code + AIコーディングツールでの開発が可能になりました。
コードの整合性担保: GitHub Actionsと連携させることで、CI/CDパイプラインを構築でき、商用レベルのコード管理が可能になりました。

dbt Project on Snowflakeはまだリリースされたばかりの機能であり、dbt Coreの全ての機能が使えるわけではないですが、手軽にdbtを試す・導入するには有力な手段の一つとなります。今後のDWHでマネージドに扱えるからこその機能アップデートにも期待しつつ、ドコモでも活用検証を続けていきたいと思っています。