Spécification YAML pour les vues sémantiques

Les vues sémantiques sont des objets de niveau schéma qui définissent des concepts métier sur vos données, facilitant ainsi l’interrogation et l’analyse des données par les utilisateurs à l’aide d’une terminologie métier. Vous pouvez utiliser la spécification YAML pour créer une vue sémantique dans Cortex Analyst ou utiliser la procédure stockée SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML pour créer une vue sémantique à partir d’une spécification YAML.

Vue d’ensemble

Les vues sémantiques sont l’approche recommandée pour définir la sémantique métier dans Snowflake. Elles sont des objets de niveau schéma qui s’intègrent au système de privilèges, aux mécanismes de partage et au catalogue de métadonnées de Snowflake.

Note

Les fichiers YAML du modèle sémantique hérité (stockés dans des zones de préparation) peuvent toujours être utilisés avec Cortex Analyst pour la rétrocompatibilité, mais nous vous recommandons d’utiliser les vues sémantiques pour les nouvelles implémentations.

Les avantages des vues sémantiques par rapport aux modèles sémantiques hérités sont les suivants :

  • Intégration native de Snowflake : Objets de niveau schéma avec prise en charge complète du RBAC, du partage et du catalogue

  • Fonctionnalités avancées : Prise en charge des métriques dérivées et des modificateurs d’accès (public/privé)

  • Meilleure gouvernance : Intégration aux systèmes de privilèges et de partage de Snowflake

  • Gestion simplifiée : Gestion des fichiers YAML dans les zones de préparation non nécessaire

Format YAML

Les vues sémantiques peuvent prendre une spécification YAML pour définir leur comportement, permettant des définitions lisibles et en texte brut.

La syntaxe générale d’une spécification YAML de vue sémantique est :

# Name and description of the semantic view.
name: <name>
description: <string>
comments: <string>

# Logical table-level concepts
# A semantic view can contain one or more logical tables.
tables:
  # A logical table on top of a base table.
  - name: <name>
    description: <string>
    # The fully qualified name of the base table.
    base_table:
      database: <database>
      schema: <schema>
      table: <base table name>

    # Dimension columns in the logical table.
    dimensions:
      - name: <name>
        synonyms: <array of strings>
        description: <string>
        expr: <SQL expression>
        data_type: <data type>
        unique: <boolean>
        cortex_search_service:
          service: <string>
          literal_column: <string>
          database: <string>
          schema: <string>
        is_enum: <boolean>
    - ...
    # Time dimension columns in the logical table.
    time_dimensions:
      - name: <name>
        synonyms: <array of strings>
        description: <string>
        expr: <SQL expression>
        data_type: <data type>
        unique: <boolean>

    # Fact columns in the logical table.
    facts:
      - name: <name>
        synonyms: <array of strings>
        description: <string>
        access_modifier: <public_access | private_access>  # Default is public_access.
        expr: <SQL expression>
        data_type: <data type>

    # Regular metrics scoped to the logical table.
    metrics:
      - name: <name>
        synonyms: <array of strings>
        description: <string>
        access_modifier: <public_access | private_access>  # Default is public_access.
        expr: <SQL expression>

    # Commonly used filters over the logical table.
    filters:
      - name: <name>
        synonyms: <array of strings>
        description: <string>
        expr: <SQL expression>

# View-level concepts
# Relationships between logical tables
relationships:
  - name: <string>
    left_table: <table>
    right_table: <table>
    relationship_columns:
      - left_column: <column>
        right_column: <column>
      - left_column: <column>
        right_column: <column>

# Derived metrics scoped to the semantic view.
# Derived metrics combine metrics from multiple tables.
metrics:
  - name: <name>
    synonyms: <array of strings>
    description: <string>
    access_modifier: <public_access | private_access>  # Default is public_access
    expr: <SQL expression>

# Additional context concepts
# Verified queries with example questions and queries that answer them
verified_queries:
  - name: <string>       # A descriptive name of the query.
    question: <string>   # The natural language question that this query answers.
    verified_at: <int>   # Optional: Time (in seconds since the UNIX epoch, January 1, 1970) when the query was verified.
    verified_by: <string> # Optional: Name of the person who verified the query.
    use_as_onboarding_question: <boolean>  # Optional: Marks this question as an onboarding question for the end user.
    sql: <string>        # The SQL query for answering the question
Copy

Important

Les vues sémantiques ne requièrent pas les champs join_type ou relationship_type qui étaient utilisés dans les modèles sémantiques hérités. Le type de relation est automatiquement déduit des données.

Concepts clés

Tables

Les tables logiques représentent des entités commerciales (telles que des clients, des commandes ou des produits) et sont mappées à des tables de bases de données physiques. Chaque table logique peut définir :

  • Table de base : Nom entièrement qualifié de la table physique

  • Clé principale : Colonnes qui identifient les lignes de manière unique

  • Synonymes : Noms alternatifs de la table

  • Description : Explication commerciale conviviale de ce que représente la table

Dimensions

Les dimensions représentent des attributs catégoriques qui fournissent du contexte pour l’analyse. Elles répondent aux questions « qui », « quoi », « où » et « quand ». Les dimensions peuvent être :

  • Dimensions ordinaires : Valeurs textuelles ou numériques, ou autres valeurs catégorielles

  • Dimensions temporelles : Colonnes de date ou d’horodatage avec traitement spécial basé sur le temps

Propriétés des dimensions

  • expr : expression SQL pour calculer la valeur de la dimension

  • synonyms : Termes alternatifs que les utilisateurs peuvent utiliser

  • unique : Si les valeurs sont uniques à travers les lignes

  • is_enum : Si la dimension possède un ensemble fixe de valeurs

  • cortex_search_service : Cortex Search Service facultatif pour la recherche sémantique

Propriétés facultatives pour les dimensions physiques

Ces champs sont facultatifs, mais recommandés pour produire des résultats de meilleure qualité à partir d’une recherche de vues sémantiques.

synonyms

Une liste d’autres termes/expressions utilisés pour désigner cette dimension. Doit être unique parmi tous les synonymes de ce modèle sémantique.

description

Brève description de cette dimension. Incluez des informations qui fournissent un contexte utile, comme les données que représente cette dimension.

unique

Une valeur booléenne qui indique que cette dimension a des valeurs uniques.

sample_values

Exemples de valeurs de cette colonne, le cas échéant. Ajoutez toute valeur susceptible d’être référencée dans les questions des utilisateurs.

is_enum

Une valeur booléenne. Si True, les valeurs du champ sample_values sont considérées comme la liste complète des valeurs possibles, et le modèle ne choisit que parmi ces valeurs lors du filtrage sur cette colonne.

cortex_search_service

Spécifie le service Cortex Search Service à utiliser pour cette dimension. Elle contient les domaines suivants :

  • service : Le nom du Cortex Search Service.

  • literal_column : (facultatif) La colonne du Cortex Search Service qui contient les valeurs littérales.

  • database : (facultatif) La base de données dans laquelle se trouve le Cortex Search Service. La valeur par défaut est la base de données de base_table.

  • schema : (facultatif) Le schéma dans lequel le Cortex Search Service est situé. La valeur par défaut est le schéma de base_table.

cortex_search_service remplace le champ cortex_search_service_name, qui ne pouvait spécifier que le nom. cortex_search_service_name est obsolète.

Propriétés facultatives pour les dimensions temporelles

Ces champs sont facultatifs, mais recommandés pour produire des résultats de meilleure qualité à partir d’une recherche de vues sémantiques.

synonyms

Une liste d’autres termes/expressions utilisés pour faire référence à cette dimension temporelle. Doit être unique parmi tous les synonymes de ce modèle sémantique.

description

Brève description de cette dimension. Incluez des informations qui fournissent un contexte utile, comme le fuseau horaire que cette dimension utilise comme point de référence.

unique :

Une valeur booléenne qui indique que cette colonne a des valeurs uniques.

sample_values :

Exemples de valeurs de cette colonne, le cas échéant. Ajoutez toutes les valeurs susceptibles d’être référencées dans les questions des utilisateurs.

Faits

Les faits sont des attributs quantitatifs au niveau des lignes qui représentent des événements commerciaux ou des transactions spécifiques. Les faits permettent de capturer les réponses à la question « combien » au niveau le plus fin, comme dans le cas de montants des ventes, de quantités achetées ou de coûts à l’échelon individuel.

Les faits interviennent généralement dans la vue sémantique comme des concepts « de support » facilitant la construction des dimensions et des métriques.

Les propriétés des faits sont les suivantes :

  • expr : expression SQL pour calculer la valeur du fait

  • access_modifier : Définissez cette propriété sur private_access pour masquer le fait des requêtes (utile pour les calculs intermédiaires)

  • data_type : Type de données du fait

Métriques

Les métriques sont des mesures quantifiables de performances métier, calculées en agrégeant des faits ou d’autres colonnes à l’aide de fonctions telles que SUM, AVG et COUNT.

Deux types de métriques :

  1. Métriques au niveau de la table : Scopées à une table logique spécifique, agrégation des données au sein de cette table

  2. Métriques dérivées : Métriques au niveau de la vue qui combinent les métriques de plusieurs tables

Propriétés des métriques :

  • expr : expression SQL avec fonction d’agrégation

  • access_modifier : Définissez cette propriété sur private_access pour masquer le fait des requêtes (utile pour les calculs intermédiaires)

  • synonyms : Termes alternatifs pour la métrique

Métriques dérivées

Les métriques dérivées sont des métriques de niveau vue qui ne sont pas liées à une table spécifique. Elles peuvent combiner les métriques de plusieurs tables ou effectuer des calculs sur l’ensemble de la vue.

Exemple de métrique dérivée :

metrics:
  - name: total_profit_margin
    description: "Overall profit margin across all products"
    expr: (orders.total_revenue - orders.total_cost) / orders.total_revenue
    access_modifier: public_access
Copy

Relations

Les relations définissent la manière dont les tables logiques sont jointes entre elles. Chaque relation spécifie :

  • left_table : Table contenant la clé étrangère

  • right_table : Table référencée

  • relationship_columns : Paires de colonnes sur lesquelles joindre, comme left_column et right_column

Le type de relation (une à une, plusieurs à une) est automatiquement déduit des données et des définitions de clés primaires.

Note

Contrairement aux modèles sémantiques hérités, les vues sémantiques ne nécessitent pas de spécifications join_type ou relationship_type explicites. Celles-ci sont déterminées automatiquement.

Filters

Les filtres définissent des conditions de filtrage couramment utilisées qui peuvent être référencées par leur nom. Cela permet de garantir une logique de filtrage cohérente entre les requêtes.

Exemple :

filters:
  - name: active_customers
    description: "Customers who have made a purchase in the last 12 months"
    expr: "customer_last_purchase_date >= DATEADD(month, -12, CURRENT_DATE())"
Copy

Requêtes vérifiées

Les requêtes vérifiées sont des exemples de questions accompagnées des requêtes SQL correspondantes. Elles aident Cortex Analyst à comprendre comment répondre à des questions similaires et servent de documentation aux utilisateurs.

Propriétés :

  • question : Question en langage naturel

  • sql : requête SQL qui répond à la question

  • verified_by : Personne facultative ayant vérifié que la requête est correcte

  • verified_at : Horodatage facultatif lorsque vérifiée

  • use_as_onboarding_question : Indicateur facultatif pour afficher ceci sous forme de suggestion aux utilisateurs

Modificateurs d’accès

Les vues sémantiques prennent en charge les modificateurs d’accès pour les faits et les métriques, ce qui vous permet de contrôler la visibilité :

  • public_access (par défaut) : Visible et interrogeable par les utilisateurs

  • private_access : Masqué des requêtes, utilisé uniquement pour les calculs intermédiaires

Exemple :

facts:
  - name: internal_cost
    expr: unit_cost * quantity
    data_type: NUMBER
    access_modifier: private_access  # Not visible in queries

metrics:
  - name: total_revenue
    expr: SUM(sale_amount)
    access_modifier: public_access  # Visible in queries
Copy

Instructions personnalisées dans Cortex Analyst

Vous pouvez utiliser des commandes SQL pour fournir des instructions personnalisées dans la définition de la vue sémantique. Ces instructions expliquent comment les requêtes sont générées et comment les questions sont classées. Ces instructions ne font pas partie de la spécification YAML, mais sont définies à l’aide de la commande CREATE SEMANTIC VIEW.

Pour plus d’informations, voir Fournir des instructions personnalisées pour Cortex Analyst.

Exemple de YAML de vue sémantique

Voici un exemple complet de spécification YAML de vue sémantique :

name: revenue_analysis
description: "Semantic view for analyzing revenue across products and customers"

tables:
  - name: customers
    description: "Customer information"
    base_table:
      database: sales_db
      schema: public
      table: customers
    dimensions:
      - name: customer_name
        synonyms: ["client name", "customer"]
        description: "Full name of the customer"
        expr: c_name
        data_type: VARCHAR
      - name: customer_segment
        synonyms: ["segment", "market segment"]
        description: "Customer market segment"
        expr: c_mktsegment
        data_type: VARCHAR
        is_enum: true

  - name: orders
    description: "Order information"
    base_table:
      database: sales_db
      schema: public
      table: orders
    dimensions:
      - name: order_date
        description: "Date when order was placed"
        expr: o_orderdate
        data_type: DATE
    time_dimensions:
      - name: order_year
        description: "Year when order was placed"
        expr: YEAR(o_orderdate)
        data_type: NUMBER
    facts:
      - name: order_total
        description: "Total order amount"
        expr: o_totalprice
        data_type: NUMBER
    metrics:
      - name: total_orders
        description: "Total number of orders"
        expr: COUNT(*)
      - name: average_order_value
        description: "Average order value"
        expr: AVG(o_totalprice)

relationships:
  - name: orders_to_customers
    left_table: orders
    right_table: customers
    relationship_columns:
      - left_column: o_custkey
        right_column: c_custkey

metrics:
  - name: revenue_per_customer
    description: "Average revenue per customer"
    expr: orders.total_revenue / customers.customer_count
    access_modifier: public_access

verified_queries:
  - name: top_customers_by_revenue
    question: "Who are the top 10 customers by revenue?"
    sql: |
      SELECT
        customer_name,
        SUM(order_total) as total_revenue
      FROM revenue_analysis
      GROUP BY customer_name
      ORDER BY total_revenue DESC
      LIMIT 10
    use_as_onboarding_question: true
Copy

Création d’une vue sémantique à partir de YAML

Pour créer une vue sémantique à partir d’une spécification YAML, utilisez la procédure stockée SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML.

Pour plus d’informations, voir Création d’une vue sémantique à partir d’une spécification YAML.

Obtention de YAML à partir d’une vue sémantique

Pour exporter une vue sémantique au format YAML, utilisez la fonction SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW.

Pour plus d’informations, voir Obtenir la spécification YAML pour une vue sémantique.

Différences par rapport aux modèles sémantiques hérités

Si vous effectuez une migration à partir de fichiers YAML du modèle sémantique hérité vers des vues sémantiques, notez ces principales différences :

Fonctionnalité

Modèles sémantiques hérités

Vues sémantiques

Stockage

Fichiers YAML dans les zones de préparation

Objets de niveau schéma dans la base de données

Privilèges

Contrôle d’accès basé sur les rôles

Intégration RBAC Snowflake complète

Partage

Partage de fichiers manuel

Partage Snowflake natif

Type de jointure

Nécessite join_type et relationship_type

Déduit automatiquement

Métriques dérivées

Non pris en charge

Entièrement prise en charge

Modificateurs d’accès

Non pris en charge

public_access / private_access

Instructions personnalisées

Dans un fichier YAML

Défini via des commandes SQL

Lors de la conversion d’un modèle sémantique hérité en une vue sémantique :

  1. Supprimez join_type et relationship_type des relations

  2. Envisagez d’utiliser des métriques dérivées pour les calculs au niveau des vues

  3. Ajoutez access_modifier aux faits/métriques que vous souhaitez rendre privés

  4. Déplacez les instructions personnalisées vers la commande SQL CREATE SEMANTIC VIEW