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

This section describes best practices for the development of data pipelines and data products that incorporate semantic views. These recommendations are primarily intended for data engineering and data science professionals who need assistance with the following development processes:

注釈

このセクションでは、セマンティックビューの モデリング のベストプラクティスについては説明しません。このセクションの情報では、Snowflakeのセマンティックビューが反復的に設計されている最中であり、データエンジニアリングパイプラインまたはデータ製品の一部として管理する必要があることを前提としています。

所有権とデータアクセス

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

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

セマンティックビューオブジェクトに対する権限の付与

4つのキータイプのオブジェクトに、適切な付与が必要です。

  • セマンティックビュー自体

  • セマンティックビュー定義で使用されるテーブル

  • セマンティックビュー定義で使用されるビュー

  • Cortex Search Serviceオブジェクト(通常、ビューとテーブル内のカテゴリデータに適用)。

特定のドメインの権限を簡素化するために、Snowflakeは同じデータベーススキーマ内にオブジェクトを作成することをお勧めしています。そうすると、特定のカスタムロールを使用して、そのオブジェクト全体のエンドユーザーにアクセス権を付与できます。たとえば、「売上分析」を行うCortexエージェントの場合、 sales データベース内に sales_analysis スキーマを作成し、セマンティックビューとエージェントが必要とするその他のデータにアクセス権を付与するための専用ロールを作成できます(例: snowflake_intelligence_sales_analysis_role )。スキーマとロールが準備できたら、将来のオブジェクトに対する権限をこのロールに付与する必要があります。

次のコマンドは、このアプローチを示しています。

-- 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);
Copy

この例には、ユーザーがセマンティックビューに加えて、基になるデータオブジェクトへの直接アクセスが必要になるシナリオをサポートするために、将来のテーブルとビューに対する権限を付与することが含まれています。セマンティックビューのクエリに必要なのは、セマンティックビュー自体の SELECT 権限のみですが、テーブルとビューへのアクセス権を付与すると、セマンティックレイヤーの外部でベースデータを直接クエリまたは分析する必要があるユーザーに対する柔軟性が確保されます。セマンティックビューに対してユーザーを厳密に制限したい場合は、テーブルとビューに対する付与を省略し、セマンティックビューオブジェクトに対する権限のみを付与できます。ただし、Cortex AnalystおよびCortex Analystに依存するCortex Agentsでは、クエリを実行するロールに、セマンティックビューとその基になるテーブルの両方に対する SELECT 権限が必要であることに注意してください。

付与の設定中は、その他、以下の点にも注意してください。

  • エンドデータが既にエンドユーザーと正しく共有されている場合は、そのまま進むことができます。ただし、Snowflakeデータがサービスアカウントを介して、または BI レイヤーで一般的に共有されている場合は、基礎となるデータをエンドユーザーと共有するために追加の手順を実行する必要があります。

  • セマンティックビューはSnowflakeの新しいオブジェクト型です。したがって、ほとんどのロールタイプには、これらのビューに対するデフォルトまたは継承された読み取り/書き込みアクセス権限はありません。基礎となるデータ共有に関係なく、Snowflakeのコア管理チームと協力して、この新しいオブジェクト型へのアクセスをプロビジョニングします。

  • Snowflake Intelligenceの利点(およびエージェントの機能をそこで拡張する可能性)のために、ステージ、プロシージャ、関数に対する USAGE 権限(例に示すとおり)を付与する価値があります。これらのオブジェクトを使用して、Snowflake Intelligence内でカスタムツールを作成できます。

  • CREATE SEMANTIC VIEW は、セマンティックビューを作成したり、Snowsight でセマンティックビューを編集したりするユーザーに必要なスキーマレベルの権限です。

マスキングポリシーおよび行アクセスポリシーによるアクセス制限

セマンティックビューは 所有者の権利 を使用します。つまり、セマンティックビューにアクセスできるユーザーは、その基になるテーブルに個別にアクセスする必要はありません。ビューの所有者(ロール)がアクセスを制御します。ユーザーがセマンティックビューオブジェクト自体の SELECT 権限を持っている限り、ベースデータを表示する権限は必要ありません。この動作は、 標準ビューへのクエリに必要な 権限と一貫性があります。

セマンティックビューやCortex Agentsの基になるデータによっては、カスタムロールを通じて権限を付与されていても、すべてのエンドユーザーがそのデータすべてに無制限にアクセスできるようにはしたくない場合があります。ダイナミックデータマスキングポリシー および 行アクセスポリシー を使用して、基になるデータへのアクセスを行レベルで制御できます。これらのポリシーはセマンティックビューの属性に直接設定することはできませんが、基になるテーブルと列に設定されている場合は、セマンティックビューに反映され、強制されます。これは、機密データを扱うアプリケーションにとってセキュリティ上の利点です。ただし、メタデータとして保存されるサンプル値はマスクされないことに注意してください。サンプル値はマスクされない をご参照ください。

たとえば、行アクセスポリシーとマスキングポリシーを作成し、それらの両方を account_semantic_view というセマンティックビューの基になる accounts テーブルに適用できます。この例では、セマンティックビューをクエリするユーザーが、承認されたアカウントに一致するメールを持っている場合にのみ、行が表示されます。次に、機密性の高い列( sensitive_col )は、セマンティックビューを介しても、権限のないロールに対しては動的にマスクされます。

-- 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
);
Copy

dbtを使用している場合は、 ポストフック でこれらのポリシーを適用できます。例:

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);
  ...
Copy

コード ALTER TABLE {{ this }} は、完全修飾テーブル名にdbtランタイム変数を使用します。dbtが accounts テーブルをビルドまたは更新するたびに、ポリシーが適用されます。

サンプル値はマスクされない

マスキングポリシーが適用されたセマンティックビューをクエリできるユーザーは、クエリ結果の実際のデータ値を表示できませんが、マスキングポリシーはメタデータには適用されないため、Cortex Analystにより Snowsight で定義されたサンプル値はマスキングされません。ユーザーがディメンションのサンプル値が定義されたセマンティックビューで GET_DDL 関数を実行する場合、正確なサンプル値が表示されます。たとえば、次の DDL で WITH EXTENSION 句の値に注目してください。

SELECT GET_DDL('SEMANTIC_VIEW','TEST_SAMPLE_VALUES');
Copy
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"]}]}
...);

必要に応じて、ビューを作成するときに、実際の値を使用するのではなく、代表的な機密性のないサンプル値を提供することができます。Cortex Analystは、実際の値を表す任意の値を使用して、列のコンテンツを決定できます。

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

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

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

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

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

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

When semantic views have been created in a Snowflake database, administrators can manage them by using standard SHOW and DESCRIBE commands, and users can access them downstream via SQL SELECT statements and in the following ways:

コメントを除き、既存のセマンティックビュー内でテーブル、列、メタデータを追加したり変更したりすることはできないため、それらを再作成( 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を介してセマンティックビューを実体化し、下流モデルからそれらを参照することができます。

注釈

Snowflakeラボのコードサンプルは、参照、テスト、および教育を目的としています。これらのコードサンプルはサービスレベル契約の対象ではありません。

以下の指示は、ユーザーが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 ( factExpression [ , ... ] ) ]
    [ DIMENSIONS ( dimensionExpression [ , ... ] ) ]
    [ METRICS ( metricExpression [ , ... ] ) ]
    [ 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 ツールアカウントチームに連絡して、これらのリンクに従ってください。