セマンティックビューのベストプラクティス¶

所有権とデータアクセス¶

セマンティックビューは、複数の正規データソースに存在する情報へのアクセスを容易にします。セマンティックレイヤーを使うと、特定のデータソースをクエリする方法を考えることから離れて、利用可能なデータの統一ビューでサポートされるユースケースやビジネス上の問題に焦点を当てることに移行できます。データエンジニアリングチームとビジネスチームは、この全体的な目標を念頭に置いて密接に協力する必要があります。ビジネスチームはビジネスケースに関する専門知識を持つ一方、データエンジニアリングチームはテーブルとビューからデータにアクセスする方法を理解しています。両方のチームがセマンティックモデルの所有権を共有する必要があります。

両方のチームのニーズを満たす方法でセマンティックレイヤーを保護するには、ロールベースのアクセス制御（RBAC）を使用して、セマンティックビューとその依存オブジェクトに適切な権限を付与します。最初から始める場合は、作業テンプレートとして次のセクションにある GRANT ステートメントのシーケンスを使用できます。ただし、チームメンバーが既に開発、テスト、本番環境に対して特定の方法で権限を設定している場合は、必要に応じて異なるロールを使用するように指示するか、変更を加える必要がある場合があります。

-- Set variables for the specified role, database, and schema
SET my_role = 'snowflake_intelligence_sales_analysis_role';
SET my_db = 'sales';
SET my_schema = 'sales_analysis';
SET my_full_schema = $my_db || '.' || $my_schema;

-- Grant usage on the database and schema that will contain the tables and views
GRANT USAGE ON DATABASE IDENTIFIER($my_db) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Grant privileges on future objects within the schema
-- For tables and views, SELECT is the typical "usage" grant for read access
GRANT SELECT ON FUTURE TABLES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE SEMANTIC VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- For other object types, USAGE is the correct privilege
GRANT USAGE ON FUTURE FUNCTIONS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE PROCEDURES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE STAGES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE CORTEX SEARCH SERVICES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Grant usage on the database and schema that will contain the tables and views
GRANT USAGE ON DATABASE IDENTIFIER($my_db) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Grant privileges on future objects within the schema
-- For tables and views, SELECT is the typical "usage" grant for read access
GRANT SELECT ON FUTURE TABLES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE SEMANTIC VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- For other object types, USAGE is the correct privilege
GRANT USAGE ON FUTURE FUNCTIONS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE PROCEDURES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE STAGES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE CORTEX SEARCH SERVICES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Row access policy (restricts rows by user email)
CREATE OR REPLACE ROW ACCESS POLICY my_schema.account_row_policy AS (user_email STRING)
  RETURNS BOOLEAN ->
    EXISTS (
      SELECT 1
      FROM my_schema.account_access_list
      WHERE email = user_email()
    );

-- Masking policy (masks "sensitive_col" for users without a privileged role)
CREATE OR REPLACE MASKING POLICY my_schema.sensitive_col_masking_policy AS (val STRING)
RETURNS STRING ->
  CASE
    WHEN current_role() IN ('SENSITIVE_DATA_ACCESS_ROLE') THEN val
    ELSE 'MASKED'
  END;

-- Attach row access policy to the user_email column in the accounts table
ALTER TABLE my_schema.accounts
  ADD ROW ACCESS POLICY account_row_policy ON (user_email);

-- Attach masking policy to the sensitive_col column
ALTER TABLE my_schema.accounts
  MODIFY COLUMN sensitive_col
  SET MASKING POLICY sensitive_col_masking_policy;

-- Create the semantic view on the "accounts" table
CREATE OR REPLACE SEMANTIC VIEW my_schema.account_semantic_view
  TABLES (
    accounts AS my_schema.accounts
    PRIMARY KEY (account_id)
  )
  FACTS (
    account_id AS accounts.account_id,
    account_name AS accounts.account_name
  )
  DIMENSIONS (
    user_email AS accounts.user_email,
    sensitive_col AS accounts.sensitive_col
);

models:
- name: accounts
  description: "Table of accounts for semantic analytics."
  columns:
    - name: account_id
      description: "Unique identifier for the account."
    - name: account_name
      description: "Name of the account."
    - name: user_email
      description: "Email address linked to each account row."
    - name: sensitive_col
      description: "Sensitive information to be masked for non-privileged users."
  post-hook:
    - >
      ALTER TABLE {{ this }}
        ADD ROW ACCESS POLICY account_row_policy ON (user_email);
  ...

SELECT GET_DDL('SEMANTIC_VIEW','TEST_SAMPLE_VALUES');

create or replace semantic view TEST_SAMPLE_VALUES
tables (MARCH_TEMPS
  ...)
facts (MARCH_TEMPS.TEMPERATURE as TEMPERATURE
  ...)
dimensions (MARCH_TEMPS.CITY as CITY,
MARCH_TEMPS.COUNTY as COUNTY,
MARCH_TEMPS.OBSERVED as OBSERVED)
  ...
with extension (CA='{"tables":[{"name":"MARCH_TEMPS","dimensions":[{"name":"CITY","sample_values":["South Lake Tahoe","Big Bear City"]},{"name":"COUNTY","sample_values":["San Bernardino","El Dorado"]}],"facts":[{"name":"TEMPERATURE","sample_values":["44","46","52"]}],"time_dimensions":[{"name":"OBSERVED","sample_values":["2025-03-15T09:50:00.000+0000","2025-03-15T09:55:00.000+0000","2025-03-15T10:10:00.000+0000"]}]}
...);

セマンティックビューの作成、更新、クエリのオプション¶

YAML ファイルを記述する、Snowflake DDL 構文を使用する、または Snowsight で UI を使用することにより、Snowflakeでセマンティックビューを作成できます。Snowflakeは、YAML モデルのインポートと、YAML モデルへのセマンティックビューのエクスポートの両方に便利な関数を提供しています。詳細については、 YAML セマンティックモデルのネイティブセマンティックビューへの変換 をご参照ください。

一般に、セマンティックビュー（セマンティックモデルではなく）の作成から始めることをお勧めします。これは、Snowflakeメタデータオブジェクトであり、RBAC、使用統計、およびCortex AnalystやSnowflake Intelligenceなどの他のSnowflake機能との直接統合によるメリットがあります。

セマンティックビューを作成するには、主に3つのオプションがあります。

• Snowsight でセマンティックビューを作成します。

  • ウィザードを使用するか、YAML 仕様をアップロードします。

  • ウィザードアプローチは、初期セットアップに推奨されます。これには、同義語、サンプル値、列の説明の自動作成が含まれます。手順については、 Snowsight を使用したセマンティックビューの作成と管理 をご参照ください。

• SQL CREATE OR REPLACE SEMANTIC VIEW ステートメントを介して、セマンティックビューを作成します。これには SQL をサポートする任意のインターフェースを使用します。手順については、 SQL コマンドを使用したセマンティックビューの作成と管理 をご参照ください。

  プログラムによる作成とクエリは、JDBC および ODBC ドライバー、または SQL API のようなインターフェースを介して可能です。ただし、 Snowflake REST APIs は使用できません。

• SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML ストアドプロシージャを呼び出して、SQL で YAML 仕様からセマンティックビューを作成します。YAML セマンティックモデルのネイティブセマンティックビューへの変換 をご参照ください。

さらに、dbt を使用している場合は、 dbt_semantic_view パッケージをインストールすることで、Snowflakeでセマンティックビューの作成を構成できます。詳細については、 dbtプロジェクトとの統合 をご参照ください。

チームメンバーのロールと権限の設定は、セマンティックビューを作成する能力に影響を与える可能性があることに注意してください。たとえば、実稼働環境で SERVICE ユーザーとして実行する必要がある場合、その環境で Snowsight にサインインできません。SQL コマンドを使用してセマンティックビューを作成および管理する必要があります。

セマンティックビューがSnowflakeデータベースに作成されていた場合、管理者はその管理に標準の SHOW および DESCRIBE コマンドを使用することができ、ユーザーは下流で SQL SELECT ステートメント を介して、また次の方法で、それらにアクセスすることができます。

• 直接 Cortex Analyst インターフェースを介して

• Streamlit 、またはその他のCortex Analyst API および/または 生成 SELECT FROM SEMANTIC_VIEW ステートメント を使用するカスタムアプリケーションを介して

• Cortex Analyst経由でCortex Agentsを介して（セマンティックビューは新しいまたは既存の エージェント に追加される必要があります）

コメントを除き、既存のセマンティックビュー内でテーブル、列、メタデータを追加したり変更したりすることはできないため、それらを再作成（ CREATE OR REPLACE コマンドを使用）して変更を組み込む必要があります。また、SQL コマンドでセマンティックビューを更新すると、アクティブな Snowsight セッションで行った手動の編集は上書きされることに注意してください。両方の変更セットを保持することはサポートされていません。

YAML セマンティックモデルのネイティブセマンティックビューへの変換¶

SQL システム関数およびストアドプロシージャを使用して、YAML モデルからセマンティックビューを作成することおよびセマンティックビューから YAML モデルを作成することができます。

現在、Snowflakeは一括変換をサポートしていません。YAML ファイルを1つずつネイティブセマンティックビューに変換する必要があります。変換には SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML ストアドプロシージャを使用できます。一括での変換または CI/CD パイプラインへの統合が必要な場合は、一連の変換を記述する必要があります。Snowflakeは、近い将来にバッチ/一括変換をサポートする予定はありません。

ネイティブセマンティックビューを YAML にエクスポートして戻す場合は、 SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW 関数を使用できます。この関数により、自動後処理、ラウンドトリップ、またはバージョン管理へのシリアル化が可能になります。

サイズに関する同じ実用的なガイドラインは、ネイティブセマンティックビューと YAML ベースのモデルの両方に適用されます。最高のパフォーマンスを得るためには、セマンティックビューはすべてのテーブルで合計50～100列以下でなければならないという実用的なガイドラインがあります（絶対的な制限ではありません）。このガイドラインは、ネイティブのセマンティックビューと YAML ベースのモデルの両方に適用されます。これは主にCortex Analystなどの AI コンポーネントにおけるコンテキストウィンドウの制限によるものです。この推奨を超えると、レイテンシや品質の低下につながる可能性がありますが、技術的な境界ではありません。

セマンティックビューの自動デプロイ¶

可能な限り、CI/CD パイプラインとプログラムインターフェースを活用して、セマンティックビューを作成、変更、管理します。理想的には、セマンティックビューの更新がGitリポジトリと自動的に同期されるようにワークフローを設定します。このアプローチにより、変更のコピーアンドペーストやGitへのプッシュによって発生する可能性のある手動エラーを減らすことができます。

• セマンティックビュー YAML（または SQL DDL）をGitリポジトリに保管します。このアプローチは、バージョン管理、ピアレビュー、履歴、ロールバックをサポートします。

• Snowsight を使用している場合、YAML モデルを定期的にエクスポートまたはダウンロードし、Gitにコミットします。

• Gitへの変更時に CI/CD パイプラインをトリガーします（テストと精度チェックを実行し、これらのテストが合格した場合にのみデプロイします）。

• 必要に応じて、以前の既知の良好な YAML または DDL をGitから再デプロイしてロールバックします。

開発環境からテスト環境、または実稼働環境にモデルを昇格させるには、それを目的とする自動デプロイスクリプトを組み込むか、 スキーマレベルのクローニング を使用することができます。セマンティックビューは、それらを含むスキーマがクローンされると、クローンされます。セマンティックビューでは複製がまだサポートされていないため、同じSnowflakeアカウントを使用するデータベースと環境全体でセマンティックビューを昇格させるには、クローニングは良い選択肢です。

セマンティックビューは Snowflake Marketplace および データ共有 を介して直接共有できます。セマンティックビューに基づいて セキュアビュー を作成できます。また、これらのネストされたビューの共有がサポートされています。ただし、一部の再共有シナリオには制限があります（共有のコンシューマーが、セマンティックビュー上に構築されたビューをさらに共有する場合など）。

Snowflakeデータパイプラインの一部としてセマンティックビューの実体化と維持をサポートするには、dbtプロジェクトを使用できます。dbtプロジェクトとの統合 をご参照ください。Snowflake Terraformプロバイダー を使用した同様のプロセスのサポートが計画されています。

最終的な目標は、次のdbtの例に似たワークフローを有効にすることになります。

• IDE（VS Codeなど）でdbtプロジェクトの変更を行います。

• dbtコードに新しいセマンティックビュー定義を追加します。

• 変更をGitにプッシュします。

• 'dbt run' 操作を実行するトリガーをデータパイプラインの一部として設定します。

その結果、セマンティックビューはSnowflakeアカウントで実体化されます。

dbtプロジェクトとの統合¶

Snowflake Labs（ https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/ ）で入手できる dbt_semantic_view パッケージをインストールすると、dbtワークフローにセマンティックビューを統合できます。

このパッケージは、 Snowflakeでのdbtプロジェクト またはSnowflakeアカウントにアクセスできるdbtインストールでネイティブに動作します。このパッケージを使用して、dbtを介してセマンティックビューを実体化し、下流モデルからそれらを参照することができます。

以下の指示は、ユーザーがdbtに精通していることと、Snowflakeに接続できる環境にdbtが既にインストールされていることを前提としています。

dbt_semantic_view パッケージをインストールして使用するには、以下を実行します。

1. 次のコードを packages.yml ファイルに追加します。

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

   Copy

   必ずバージョン番号を含めてください。パッケージのバージョン番号は変更される可能性があります。最新バージョンを使用することをお勧めします。

2. dbt deps コマンドを実行してパッケージをインストールします。

3. dbt models ディレクトリで、セマンティックビューの実体化コードを使用するモデルを作成します。

   {{ config(materialized='semantic_view') }}
   
   TABLES(
   {{ source('<source_name>', '<table_name>') }},
   {{ ref('<another_model>') }}
   )
   [ RELATIONSHIPS ( relationshipDef [ , ... ] ) ]
   [ FACTS ( semanticExpression [ , ... ] ) ]
   [ DIMENSIONS ( semanticExpression [ , ... ] ) ]
   [ METRICS ( semanticExpression [ , ... ] ) ]
   [ COMMENT = '<comment>' ]
   [ COPY GRANTS ]
   

   Copy

   たとえば、単純なセマンティックビューを次のように実体化できます。

   {{ config(materialized='semantic_view') }}
   
   TABLES(t1 AS {{ ref('base_table') }}, t2 as {{ source('seed_sources', 'base_table2') }})
   DIMENSIONS(t1.count as value, t2.volume as value)
   METRICS(t1.total_rows AS SUM(t1.count), t2.max_volume as max(t2.volume))
   COMMENT='test semantic view'
   

   Copy

4. dbtでSnowflakeへの接続を構成し、dbt profiles.yml ファイルで接続の詳細を指定します。詳細については、 dbt のドキュメント をご参照ください。例:

   semantic_project:
     target: snowflake
     outputs:
       snowflake:
       type: "snowflake"
       account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
       user: "{{ env_var('SNOWFLAKE_USER') }}"
       password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
       authenticator: "{{ env_var('SNOWFLAKE_AUTHENTICATOR') }}"
       role: "{{ env_var('SNOWFLAKE_ROLE') }}"
       database: "{{ env_var('SNOWFLAKE_DATABASE') }}"
       warehouse: "{{ env_var('SNOWFLAKE_WAREHOUSE') }}"
       schema: "{{ env_var('SNOWFLAKE_SCHEMA') }}"
       threads: 4
   

   Copy

5. このプロファイルが与えられている場合、以下の環境変数で認証することができます。

   $ export SNOWFLAKE_ACCOUNT=snowflake_acct1
   $ export SNOWFLAKE_USER=sem_user1
   $ export SNOWFLAKE_PASSWORD=**************
   $ export SNOWFLAKE_AUTHENTICATOR=externalbrowser
   $ export SNOWFLAKE_ROLE=semantic_role
   $ export SNOWFLAKE_DATABASE=sem_db
   $ export SNOWFLAKE_WAREHOUSE=sem_wh
   $ export SNOWFLAKE_SCHEMA=sem_schema
   

   Copy

6. dbt build コマンドを実行してSnowflakeアカウントに接続し、モデルを作成します。次の例では、 models/semantic_view_basic として定義された特定のモデルを構築します。別のモデル table_refer_to_semantic_view は、このモデルに依存しているため、このコマンドの最後には + 記号が必要であることに注意してください。

   $ dbt build --target snowflake --select semantic_view_basic+
   23:43:16  Running with dbt=1.11.0-b3
   23:43:17  Registered adapter: snowflake=1.10.2
   23:43:17  Found 9 models, 8 data tests, 1 seed, 2 operations, 2 sources, 500 macros
   23:43:17
   23:43:17  Concurrency: 4 threads (target='snowflake')
   23:43:17
   23:43:32  1 of 2 START hook: dbt_semantic_view_integration_tests.on-run-start.0 .......... [RUN]
   23:43:32  1 of 2 OK hook: dbt_semantic_view_integration_tests.on-run-start.0 ............. [OK in 0.90s]
   23:43:33  2 of 2 START hook: dbt_semantic_view_integration_tests.on-run-start.1 .......... [RUN]
   23:43:33  2 of 2 OK hook: dbt_semantic_view_integration_tests.on-run-start.1 ............. [OK in 0.38s]
   23:43:33
   23:43:33  1 of 6 START sql semantic_view model sem_schema.semantic_view_basic ............ [RUN]
   23:43:33  1 of 6 OK created sql semantic_view model sem_schema.semantic_view_basic ....... [SUCCESS 1 in 0.26s]
   23:43:33  3 of 6 START test semantic_view_basic_has_no_copy_grants ....................... [RUN]
   23:43:33  2 of 6 START test semantic_view_basic_has_comment .............................. [RUN]
   23:43:33  4 of 6 START test semantic_view_sum_matches_base_table ......................... [RUN]
   23:43:33  2 of 6 PASS semantic_view_basic_has_comment .................................... [PASS in 0.23s]
   23:43:34  3 of 6 PASS semantic_view_basic_has_no_copy_grants ............................. [PASS in 0.75s]
   23:43:34  4 of 6 PASS semantic_view_sum_matches_base_table ............................... [PASS in 1.05s]
   23:43:34  5 of 6 START sql table model sem_schema.table_refer_to_semantic_view ........... [RUN]
   23:43:35  5 of 6 OK created sql table model sem_schema.table_refer_to_semantic_view ...... [SUCCESS 1 in 1.22s]
   23:43:35  6 of 6 START test table_refer_semantic_view_matches_semantic_view .............. [RUN]
   23:43:36  6 of 6 PASS table_refer_semantic_view_matches_semantic_view .................... [PASS in 0.26s]
   23:43:36
   23:43:36  Finished running 2 project hooks, 1 semantic view model, 1 table model, 4 data tests in 0 hours 0 minutes and 19.34 seconds (19.34s).
   23:43:36
   23:43:36  Completed successfully
   23:43:36
   23:43:36  Done. PASS=8 WARN=0 ERROR=0 SKIP=0 NO-OP=0 TOTAL=8
   

   Copy

dbt_semantic_view パッケージには、事前構築済みのモデルと実行可能なテストが含まれます。この詳細については README.md ファイルをご参照ください。https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/ に移動し、 View on GitHub を選択します。

https://www.snowflake.com/en/engineering-blog/dbt-semantic-view-package/ もご参照ください。

BI ツールとの統合¶

多くの BI ツールベンダーが、Snowflakeセマンティックビューとの統合を提供しています。これらの統合の詳細については、BI ツールアカウントチームに連絡して、これらのリンクに従ってください。

• Sigma: https://www.sigmacomputing.com/blog/snowflake-semantic-views-launch

• Omni: https://omni.co/snowflake

• Honeydew: https://honeydew.ai/blog/honeydew-and-snowflake-semantic-views/

• Hex: https://hex.tech/blog/introducing-snowflake-semantic-sync-aisql/