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
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 dimensionsynonyms: Termes alternatifs que les utilisateurs peuvent utiliserunique: Si les valeurs sont uniques à travers les lignesis_enum: Si la dimension possède un ensemble fixe de valeurscortex_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.
synonymsUne 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.
descriptionBrève description de cette dimension. Incluez des informations qui fournissent un contexte utile, comme les données que représente cette dimension.
uniqueUne valeur booléenne qui indique que cette dimension a des valeurs uniques.
sample_valuesExemples 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_enumUne valeur booléenne. Si
True, les valeurs du champsample_valuessont 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_serviceSpé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 debase_table.schema: (facultatif) Le schéma dans lequel le Cortex Search Service est situé. La valeur par défaut est le schéma debase_table.
cortex_search_serviceremplace le champcortex_search_service_name, qui ne pouvait spécifier que le nom.cortex_search_service_nameest 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.
synonymsUne 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.
descriptionBrè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 faitaccess_modifier: Définissez cette propriété surprivate_accesspour 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 :
Métriques au niveau de la table : Scopées à une table logique spécifique, agrégation des données au sein de cette table
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égationaccess_modifier: Définissez cette propriété surprivate_accesspour 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
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èreright_table: Table référencéerelationship_columns: Paires de colonnes sur lesquelles joindre, commeleft_columnetright_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())"
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 naturelsql: requête SQL qui répond à la questionverified_by: Personne facultative ayant vérifié que la requête est correcteverified_at: Horodatage facultatif lorsque vérifiéeuse_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 utilisateursprivate_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
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
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 |
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 |
|
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 :
Supprimez
join_typeetrelationship_typedes relationsEnvisagez d’utiliser des métriques dérivées pour les calculs au niveau des vues
Ajoutez
access_modifieraux faits/métriques que vous souhaitez rendre privésDéplacez les instructions personnalisées vers la commande SQL CREATE SEMANTIC VIEW