Meilleures pratiques pour les vues sémantiques¶

Propriété et accès aux données¶

Les vues sémantiques facilitent l’accès aux informations qui existent dans plusieurs sources de données canoniques. La couche sémantique permet de passer de la réflexion sur la manière d’interroger une source de données spécifique à la focalisation sur les cas d’utilisation et les questions métier pris en charge par une vue unifiée des données disponibles. Dans cet objectif global, les équipes chargées de l’ingénierie des données et des entreprises doivent collaborer étroitement. Les équipes commerciales ont une expertise dans les business cases, tandis que les équipes d’ingénierie des données comprennent comment accéder aux données des tables et des vues. Les deux équipes doivent partager la propriété du modèle sémantique.

Pour sécuriser la couche sémantique de manière à répondre aux besoins des deux équipes, utilisez un contrôle d’accès basé sur les rôles (RBAC) pour accorder des privilèges appropriés aux vues sémantiques et à leurs objets dépendants. Si vous partez de zéro, vous pouvez utiliser la séquence des instructions GRANT dans la section suivante comme modèle de travail. Toutefois, si les membres de votre équipe disposent déjà d’autorisations configurées d’une certaine manière pour les environnements de développement, de test et de production, vous devrez peut-être apporter quelques modifications ou leur demander d’utiliser différents rôles selon les besoins.

-- 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"]}]}
...);

Options pour créer, mettre à jour et interroger des vues sémantiques¶

Vous pouvez créer des vues sémantiques dans Snowflake en écrivant un fichier YAML, avec la syntaxe Snowflake DDL, ou en utilisant la syntaxe UI dans Snowsight. Snowflake propose des fonctions pratiques pour l’importation des modèles YAML et l’exportation des vues sémantiques vers des modèles YAML. Pour plus de détails, voir Conversion des modèles sémantiques YAML en vues sémantiques natives.

En général, il est préférable de commencer par créer des vues sémantiques (plutôt que des modèles sémantiques), qui sont des objets de métadonnées Snowflake qui bénéficient de RBAC, des statistiques d’utilisation et d’une intégration directe à d’autres fonctionnalités de Snowflake, dont Cortex Analyst et Snowflake Intelligence.

Pour créer une vue sémantique, vous disposez de trois options principales :

• Créez une vue sémantique dans Snowsight :

  • Vous pouvez utiliser l’assistant, ou vous pouvez charger une spécification YAML.

  • L’approche de l’assistant est recommandée pour la configuration initiale et inclut la création automatique de synonymes, de valeurs d’échantillon et de descriptions de colonnes. Pour obtenir des instructions, voir Utiliser Snowsight pour créer et gérer des vues sémantiques.

• Créez une vue sémantique via une instruction SQL CREATE OR REPLACE SEMANTIC VIEW, en utilisant une interface quelconque qui prend en charge SQL. Pour obtenir des instructions, voir Utiliser des commandes SQL pour créer et gérer des vues sémantiques.

  La création et l’interrogation programmatiques sont possibles via des interfaces telles que les pilotes JDBC et ODBC ou l’API SQL. Cependant, vous ne pouvez pas utiliser l”Snowflake REST APIs.

• Vous pouvez également créer une vue sémantique à partir d’une spécification YAML dansSQL en appelant la procédure stockée SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML. Voir Conversion des modèles sémantiques YAML en vues sémantiques natives.

De plus, si vous utilisez dbt, vous pouvez configurer la création de vues sémantiques dans Snowflake en installant le package``dbt_semantic_view``. Pour plus d’informations, voir Intégration à des projets dbt.

Gardez à l’esprit que la configuration des rôles et des privilèges pour les membres de votre équipe peut avoir un impact sur leur capacité à créer des vues sémantiques. Par exemple, si votre environnement de production exige que vous exécutiez en tant qu’utilisateur SERVICE, vous ne pouvez pas vous connecter à Snowsight dans cet environnement ; vous devez utiliser les commandes SQL pour créer et gérer des vues sémantiques.

Lorsque des vues sémantiques ont été créées dans une base de données Snowflake, les administrateurs peuvent les gérer en utilisant des commandes SHOW et DESCRIBE et les utilisateurs peuvent y accéder en aval via les instructions SQL SELECT et des manières suivantes :

• Directement par l’intermédiaire de l’interface utilisateur Cortex Analyst

• Par le biais de Streamlit ou d’autres applications personnalisées qui utilisent Cortex Analyst API et/ou génèrent des instructions SELECT FROM SEMANTIC_VIEW

• Par le biais de Cortex Agents via Cortex Analyst (les vues sémantiques doivent être ajoutées à un :ref:`agent <label_snowflake_agents_modify_agents>`nouveau ou existant)

À l’exception des commentaires, vous ne pouvez pas ajouter ou modifier des tables, des colonnes ou des métadonnées dans des vues sémantiques existantes. Vous devez donc les recréer (avec les commandes CREATE OR REPLACE) pour intégrer toute modification. Notez également que la mise à jour d’une vue sémantique via une commande SQL écrase toutes les modifications manuelles que vous avez effectuées dans une session Snowsight active. La conservation des deux ensembles de modifications n’est pas prise en charge.

Conversion des modèles sémantiques YAML en vues sémantiques natives¶

Vous pouvez utiliser les fonctions système SQL et les procédures stockées pour créer des vues sémantiques à partir de modèles YAML et créer des modèles YAML à partir de vues sémantiques.

Actuellement, Snowflake ne prend pas en charge la conversion en masse ; vous devez convertir les fichiers YAML en vues sémantiques natives, une à la fois. Vous pouvez utiliser la procédure stockée SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML pour la conversion. Si vous avez besoin d’une conversion en masse ou d’une intégration dans un pipeline CI/CD, vous devez scripter les conversions dans une série. Snowflake ne prévoit pas de prendre en charge la conversion par lots/en masse dans un avenir proche.

Pour exporter à nouveau une vue sémantique native vers YAML, vous pouvez utiliser la fonction SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW. Cette fonction permet d’automatiser le post-traitement, l’aller-retour ou la sérialisation dans le contrôle de version.

Les mêmes directives pratiques concernant la taille s’appliquent à la fois aux vues sémantiques natives et aux modèles basés sur YAML. Il existe un guide pratique (pas une limite stricte) selon lequel pour de meilleures performances, les vues sémantiques ne doivent pas comporter plus de 50-100 colonnes au total dans toutes les tables. Cette directive s’applique à la fois aux vues sémantiques natives et aux modèles basés sur YAML, et est principalement due aux limites de la fenêtre contextuelle dans des composants AI tels que Cortex Analyst. Le dépassement de cette recommandation peut entraîner une latence ou une dégradation de la qualité, mais il ne s’agit pas d’une limite technique.

Déploiement automatisé des vues sémantiques¶

Lorsque cela est possible, utilisez les pipelines CI/CD et les interfaces programmatiques pour créer, modifier et gérer des vues sémantiques. Idéalement, configurez votre workflow de manière à ce que les mises à jour des vues sémantiques soient synchronisées automatiquement avec votre référentiel Git. Cette approche réduit les erreurs manuelles qui peuvent être causées par le copier-coller ou la poussée de modifications vers Git.

• Stockez la vue sémantique YAML (ou SQL DDL) dans un référentiel Git ; cette approche prend en charge le contrôle des versions, l’examen par les pairs, l’historique et la restauration.

• Si vous utilisez Snowsight, exportez ou téléchargez le modèle YAML régulièrement et validez-le dans Git.

• Déclenchez les pipelines CI/CD au moment des modifications apportées à Git (pour exécuter des tests et des contrôles de précision, puis n’effectuer un déploiement que si ces tests réussissent).

• Si nécessaire, effectuez une restauration en redéployant l’ancienne version bien connue YAML ou DDL à partir de Git.

Pour faire passer des modèles des environnements de développement à des environnements de test ou de production, vous pouvez incorporer des scripts de déploiement automatisés à cet effet, ou vous pouvez utiliser le clonage au niveau du schéma. Les vues sémantiques sont clonées lorsque les schémas qui les contiennent sont clonés. Étant donné que la réplication n’est pas encore prise en charge pour les vues sémantiques, le clonage est une bonne alternative pour promouvoir les vues sémantiques dans les bases de données et les environnements qui utilisent le même compte Snowflake.

Les vues sémantiques peuvent être partagées directement via Snowflake Marketplace et le partage de données. Vous pouvez créer des vues sécurisées basées sur des vues sémantiques, et le partage de ces vues imbriquées est pris en charge. Cependant, certains scénarios de repartage présentent des limites (par exemple, lorsqu’un consommateur d’un partage souhaite partager davantage une vue basée sur une vue sémantique).

Pour prendre en charge la matérialisation et la gestion des vues sémantiques dans le cadre d’un pipeline de données Snowflake, vous pouvez utiliser un projet dbt ; voir Intégration à des projets dbt. La prise en charge d’un processus similaire à l’aide de Fournisseur Snowflake Terraform est prévue.

En fin de compte, votre objectif devrait consister à activer un workflow semblable à l’exemple dbt suivant :

• Travailler sur des modifications de projet dbt dans un IDE, par exemple VS Code.

• Ajouter une nouvelle définition de vue sémantique au code dbt.

• Transférer les modifications vers Git.

• Configurer des déclencheurs qui effectuent une opération 'dbt run' dans le cadre du pipeline de données.

En conséquence, la vue sémantique serait matérialisée dans le compte Snowflake.

Intégration à des projets dbt¶

Vous pouvez intégrer des vues sémantiques dans votre workflow dbt en installant le package dbt_semantic_view disponible depuis Snowflake Labs : https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/.

Ce package fonctionne nativement avec Projets dbt sur Snowflake ou toute installation dbt qui a accès à un compte Snowflake. Vous pouvez utiliser ce package pour matérialiser des vues sémantiques via dbt et les référencer à partir de modèles en aval.

Les instructions suivantes supposent que vous connaissez dbt et que vous l’avez déjà installé dans un environnement qui peut se connecter à Snowflake.

Pour installer et utiliser le package dbt_semantic_view :

1. Ajoutez le code suivant à votre fichier packages.yml :

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

   Copy

   Veillez à inclure le numéro de version. Le numéro de version du package peut changer ; l’utilisation de la dernière version est recommandée.

2. Exécutez la commande dbt deps pour installer le package.

3. Dans le répertoire des models dbt, créez un modèle qui utilise le code de matérialisation de la vue sémantique :

   {{ 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

   Par exemple, vous pouvez matérialiser une vue sémantique simple comme suit :

   {{ 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. Configurez votre connexion à Snowflake dans dbt, en spécifiant les détails de la connexion dans votre fichier profiles.yml dbt. Pour plus d’informations, consultez la documentation dbt. Par exemple :

   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. Étant donné ce profil, vous pouvez vous authentifier avec les variables d’environnement suivantes :

   $ 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. Exécutez la commande dbt build pour vous connecter à votre compte Snowflake et créer le modèle. L’exemple suivant construit un modèle spécifique défini comme models/semantic_view_basic. Notez qu’un autre modèle, table_refer_to_semantic_view, dépend de ce modèle, donc la commande nécessite le signe + à la fin.

   $ 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

Pour plus d’informations sur le package dbt_semantic_view, qui comprend des modèles pré-construits et des tests que vous pouvez exécuter, voir le fichier README.md. Accédez à https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/ et sélectionnez View on GitHub.

Voir aussi https://www.snowflake.com/en/engineering-blog/dbt-semantic-view-package/.

Intégration aux outils BI¶

Un certain nombre de fournisseurs d’outils BI proposent des intégrations aux vues sémantiques de Snowflake. Pour en savoir plus sur ces intégrations, veuillez contacter vos équipes de compte des outils BI et suivez ces liens :

• 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/