Snowflake Semantic View の解像度を上げたい
はじめに
Snowflake Intelligence の登場に伴い、Snowflake Semantic View（以下、Semantic View）を作成する機会が増えてきました。
当初、Semantic View に対する自分の理解は浅く、「Snowflake Intelligence の入力」程度の認識にとどまっていました。
さらに、似た用語として「Semantic Model」もあり、その違いを十分に把握できていませんでした。
そこで Semantic View を使いこなすために理解を深めようと、Semantic View および Semantic Model について調べました。
調査の結果得られた自分なりのイメージを記載していきます。
目的
- Semantic Model のイメージを掴む
- Semantic Model と Semantic View の違いを掴む
Semantic Model とは
以下、公式ドキュメントより引用。
セマンティックモデルは、ビジネス用語をデータベーススキーマにマッピングし、文脈上の意味を追加します。例えば、ユーザーが「先月の総収入」について質問した場合、セマンティックモデルは「収入」を純収入と定義し、「先月」を前の暦月と定義することができます。このマッピングは、 Cortex Analyst にとって、ユーザーの意図を理解し、正確な回答を提供するのに役立ちます。
各種テーブルやビュー（およびそのカラム）に別名をつけたり、追加情報を設定するとのことです。
なぜこのようなことをするのでしょうか。
なぜ Semantic Model を使用するのか
テーブル設計とビジネス側の定義の間では、どうしても乖離が生じます。
これは主に、RDBMSなどのデータストア技術に合わせて正規化・最適化するためです。
上記の例では、ビジネス側では「売上伝票」という単位でデータを扱っています。
この「売上伝票」をシステムで扱う形（ここではRDB）へ最適化した結果、ここでは四つのテーブルに分割されています。
Semantic Model では、こういった技術側へ最適化したデータを参照し、ビジネス側の定義を再現します。
Semantic Model を使用することで、正規化によって細かく分割される中で見えにくくなるビジネスの文脈を取り戻せます。
そして「売上伝票」など、ビジネスにとって意味のある単位でデータを扱えるようになります。
Semantic Model では、以下のような機能を使用することで、ビジネス側の定義を再現します。
- テーブル上のカラム名（物理名）とは別に、ビジネス用の名前（論理カラム名）を設定
- Description, sample_values, synonyms といった追加の補足情報（≒コンテキスト）を設定
- テーブル間のリレーション情報を追加
上記の例では「正規化されたデータをビジネス側の定義へ再構成」という側面が強いですが、正規化と無関係のテーブルを関連付けることも可能です。
大事なのは、「ビジネス上意味のある単位でデータを表現する」ことです。
ビジネス側のコンテキストを補足できる有用な情報であれば、正規化に関係なく関連付ける価値はあります。
複数のデータソースをまとめ上げ、必要に応じてコンテキストを追加し、ビジネスにとって意味のある単位を構成する。
そして、構成した単位でやり取りできるようになる...というのが、 Semantic Model の大きな価値であると理解しました。
Semantic Model の立ち位置
Semantic Model は、ビジネス上の意味を定義する抽象レイヤーとして機能します。
一方で、「ビジネス上の意味を補完する」考え方にはデータカタログ（より正確にはビジネスカタログ）が存在しますが、Semantic Model と同一ではないという理解です。
Semantic Model を中心に整理すると、 次のような層構造として捉えることが出来ます。
- 物理データレイヤー : Semantic Model の構成要素となるテーブル・ビューで構成される層
- セマンティックレイヤー : 物理データをまとめ、ビジネス上の意味ある単位を構成する層
- データカタログレイヤー : Semantic Model を基盤とし、さらにコンテキスト情報を追加してビジネスカタログ化する層
Semantic View と Semantic Model の違い
「Semantic Model」の解釈
「Semantic Model」は文脈に応じて二つの解釈に分かれます。
- 概念レベル : 「ビジネス上の意味を定義する」という抽象的な考え方としての Semantic Model
- Snowflake リソースレベル : Snowflake Cortex Analyst を利用するために必要な、 Snowflake 上のリソースとしての Semantic Model
そして、概念としての「Semantic Model」 を実装する手段として以下二つが存在すると理解しました。
- Semantic View
- Snowflake Cortex Analyst 用のリソースであるSemantic Model
この前提を踏まえ、両者の違いを整理します。
違い
両者は、目的が明確に異なります。
Semantic Model (リソース)は、 (LLM アプリのように) 自然言語によるクエリを理解するためのインターフェースとして機能します。
自然言語によるクエリを正確に理解するために、Description や Synonyms といったコンテキストを補強する仕組みが用意されています。
こうしてコンテキストを補強された Semantic Model は、 Cortex Analyst から参照され、自然言語をSQLに変換する際に活躍します。
一方の Semantic View は、ビジネス上の意味を持つ、一貫した構造を定義することが目的です。
View の一種としてSnowflakeスキーマに保存され、BIツールやSQLから直接利用可能です。
また、Snowflake Intelligence の入力として参照することも可能です。
まとめ
Semantic Model と Semantic View は、どちらも「ビジネス上の意味を持つデータ単位」を定義し、ビジネス上の文脈を再現することは共通のようです。
その一方で、Semantic Model は言語的コンテキスト（自然言語クエリの理解を助ける追加のコンテキストを提供）に、
Semantic View は構造的コンテキスト（一貫したビジネス定義の提供）に重きを置いているというのが、大きな違いのようです。
Discussion