dbtを用いたSemantic Viewの開発・デプロイ手順を考えてみた

さがらです。

Semantic Viewの定義を行えるdbtパッケージとして、dbt_semantic_viewが提供されています。

https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/

このdbtパッケージを用いて、どのようにSemantic Viewを開発・デプロイしていくべきか手順を考えてみたので、本記事でまとめてみます。

参考資料

まず今回の手順を考えるにあたり、以下の記事を大変参考にさせて頂きました。Semantic Viewの実装に当たってのプラクティスが体系的にまとめられているため、ぜひご一読ください。

https://zenn.dev/finatext/articles/tips-for-maintaining-semantic-view

前提条件

dbtについて

dbtの開発環境としては、「Snowflake Workspace（dbt Projects on Snowflake）」を使用します。外部パッケージをインストールするためのExternal Access Integrationなどは既に定義済みとします。（参考ブログ）

また、下図のようにdbtで必要なテーブルをすでにJOIN済のmodelを1つ定義済みであるとします。

Snowflake上の開発・本番の分離について

データベースレベルで開発環境と本番環境を分離しているSnowflakeアカウントで検証します。

• 開発環境：DEV_DB
  • Semantic Viewは、各開発者専用のスキーマで出力する（今回はSAMPLE_DEVELOPERスキーマに出力）
  • 各開発者専用のスキーマでは、dbtで開発途中のmodelのテーブルやビューの出力も行う
  • 各開発者専用のスキーマでは、Agentの作成も許可する（Snowflake IntelligenceオブジェクトへのAgent追加権限の付与は任意です。開発者スキーマのAgentをSnowflake Intelligenceオブジェクトに追加しても、閲覧ユーザーがAgentの権限を持っていなければSnowflake Intelligenceオブジェクト上には表示されません。）
• 本番環境：PROD_DB
  • Semantic Viewは、AIML_SAMPLEスキーマに出力する

概要：dbtを用いたSemantic Viewの開発・デプロイ手順

今回考えた開発・デプロイ手順は図にまとめると、下図のような手順となります。

ポイントは、最初からdbtでコーディングを行わず、Snowsight上でSemantic Viewを開発していくことです。この理由ですが、SnowsightでのSemantic View作成画面はとても使いやすいと感じており、回答精度の検証もSnowsight上で試行錯誤していく方が楽だと考えているためです。

1.Snowsightで開発者スキーマに対してSemantic Viewを作成

まず、SnowsightのAI&ML⇛AnalystからSemantic Viewを作成します。

以下、詳細な手順は割愛しますが、SnowsightでSemantic Viewを作る際の手順を画像と少しの説明文と共に載せておきます。ポイントは、dbtでも使用している開発者ロール・開発者スキーマでSemantic Viewを作成することです。

Provide contextでは、できる限り実際に使っているクエリを多く登録します。（この情報もSemantic Viewに登録されます。）

テーブルとカラムを選択し、Semantic Viewを作成します。

下図のように表示されたら、SnowsightからのSemantic View作成は完了です。

これはおまけですが、Suggestionsタブを見て、良いと感じた提案があれば、Acceptを押して追加しましょう。Provide contextでサンプルクエリを多く登録していると、提案の質も上がります。

2.開発者スキーマでSemantic ViewをToolとしたAgentを作成し、精度検証

次に、開発者スキーマでSemantic ViewをToolとしたAgentを作成し、精度検証を行います。

Agentをわざわざ作成して精度検証を行う理由は、主にコスト面です。下図はSnowflakeのConsumption Tableからの抜粋ですが、Table 6(f)とTable 6(h)にある通り、Cortex Analyst(Semantic View)はCortex Agentsを介すかどうかで単価が大きく異なります。基本的にはCortex Agentsを介したほうが安く済むと思いますので、Agentを作成してSemantic Viewの精度検証を行うことを推奨します。

Agentの作成はSQLでもSnowsightでも可能ですが、今回はSnowsightで行います。

SnowsightのAI&ML⇛Agentsから、Agentを作成していきます。

Agentの作成先も、dbtで使用している開発者ロール・開発者スキーマにすることを推奨します。

Agentの編集画面となったら、ToolsからCortex Analystの横の+ Addを押して、先程作成したSemantic Viewを追加します。（DescriptionはGenerate with Cortexで生成すると下図の通り英語になりますが、必要に応じて日本語に翻訳して修正しましょう）

Cortex AnalystからSemantic Viewの追加を終えたら、右上のSaveを押して保存します。

Saveを終えたら、Agentの右側の画面で、質問を行って回答精度の検証を行います。

もし、回答精度に誤りがあったら、AgentにToolとして登録したSemantic Viewの編集画面に戻り、Custom Instructionsの追加、各フィールドへのDescriptionやSynonymsやSample valuesの追加、新しいMetricsの追加、など必要と思われることを行い、修正を行います。（修正したら右上のSaveを押すことを忘れないようにしましょう）

※これは余談ですが、先程Agentの画面で質問した内容が早速Suggestionsに追加されていました。Semantic ViewのSuggestionsはとても優秀なため、良いと感じた提案は積極的に採用していきましょう。

3.Semantic ViewのDDL文を確認し、dbtでSemantic Viewを定義

これまでの工程でSemantic Viewが問題なく開発できたら、dbtでSemantic Viewを定義していきます。

前提として、パッケージのインストールと、Materializationの設定は下記のように行っているとします。

• packages.yml

packages:
  - package: Snowflake-Labs/dbt_semantic_view
    version: 1.0.3

• dbt_project.yml：svフォルダ内は全てSemantic Viewで作るように定義

name: 'sample_dbt_project'
version: '1.9.0'
config-version: 2

profile: 'sample_project'

models:
  sample_dbt_project:
    +persist_docs:  
      relation: true  
      columns: true
    +materialized: view
    staging:
      +materialized: view
      sample_source_snowpipe:
        +schema: staging_sample
    dwh:
      +materialized: table
      sample:
        +schema: dwh_sample
    mart:
      +materialized: table
      sample:
        +schema: mart_sample
    sv:
      +materialized: semantic_view
      sample:
        +schema: aiml_sample

続いて、定義したSemantic ViewのDDL文を、SnowsightのDatabase Explorerから確認してコピーします。各フィールドのサンプル値や、Snowsightから登録したサンプルクエリも、with extensionの中で定義されていることがわかります。

新しいdbtのmodelを作成し、コピーしたDDL文を貼り付け、tables以降のクエリだけを残します。

次に、tablesで記述されているテーブル名を、dbtのref関数に書き換えます。これにより、開発環境に作られるSemantic Viewは開発環境のテーブルを、本番環境に作られるSemantic Viewは本番環境のテーブルを、というように動的に参照先を切り替えたSemantic Viewが構築できます。

ちなみに、ref関数に書き換えると、使用しているテーブル間のリネージが確認できるのも嬉しいポイントですね。

この上で、一度開発環境に対してdbt buildまたはdbt runを実行して、Semantic Viewを生成します。（dbt Projects on Snowflakeでの開発者ごとの出力先スキーマの変更は、こちらのブログをご覧ください。）

生成したSemantic Viewを見て、Snowsightで作成したときと同様に作られているかを確認します。

必要に応じて、Agentからも動作確認します。これで、問題なければ、開発環境におけるdbtを用いたSemantic Viewの定義は完了です。

4.プルリクエストを発行してマージし、本番環境でdbt build/runを実行して反映

開発を終えたので、プルリクエストを発行してマージし、本番環境でdbt build/runを実行して反映します。

下図は、本番環境でdbt build実行後のSemantic Viewの作成された様子です。

あとはこのSemantic Viewを本番環境のAgentにToolとして追加して、対象のAgentをSnowflake Intelligenceに追加すれば、自然言語での分析が可能となります。

最後に

dbtを用いたSemantic Viewの開発・デプロイ手順を考えてみたので、その内容についてまとめてみました。

「dbtを用いた」とは書いていますが、Semantic ViewのコードをGit管理したいという文脈でdbtを使っているだけであって、実際の開発・精度検証はSnowsightで全て行っています。これも、SnowsightでSemantic Viewを構築する開発体験がとても優れているためです！

dbt_semantic_viewパッケージの導入を検討している方の一助になると幸いです！