YAML-Spezifikation für semantische Ansichten¶
Semantische Ansichten sind Objekte auf Schemaebene, die Geschäftskonzepte für Ihre Daten definieren und es Benutzenden erleichtern, Daten mithilfe von Geschäftsterminologie abzufragen und zu analysieren. Sie können mit der YAML-Spezifikation eine semantische Ansicht in Cortex Analyst erstellen oder die SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML gespeicherte Prozedur verwenden, um eine semantische Ansicht anhand einer YAML-Spezifikation zu erstellen.
Übersicht¶
Semantische Ansichten sind der empfohlene Ansatz für die Definition von Geschäftssemantik in Snowflake. Semantische Ansichten sind Objekte auf Schemaebene, die sich in das Berechtigungssystem, die Freigabemechanismen und den Metadatenkatalog von Snowflake integrieren lassen.
Bemerkung
YAML-Dateien älterer semantischer Modelle (in Stagingbereichen gespeichert) können weiterhin mit Cortex Analyst verwendet werden (aus Gründen der Abwärtskompatibilität). Wir empfehlen jedoch die Verwendung semantischer Ansichten für neue Implementierungen.
Die Vorteile semantischer Ansichten gegenüber älteren semantischen Modellen sind:
Native Snowflake-Integration: Objekte auf Schemaebene mit vollständiger RBAC, Freigabe und Katalogunterstützung
Erweiterte Features: Unterstützung für abgeleitete Kennzahlen und Zugriffsmodifikatoren (öffentlich/privat)
Verbesserte Governance: Integriert in die Berechtigungs- und Freigabesysteme von Snowflake
Vereinfachte Verwaltung: Kein Verwalten von YAML-Dateien in Stagingbereichen
YAML-Format¶
Semantische Ansichten können eine YAML-Spezifikation nutzen, um ihr Verhalten zu definieren und so lesbare Definitionen in Klartext zu ermöglichen.
Die allgemeine Syntax einer semantischen Ansicht mit YAML-Spezifikation lautet wie folgt:
# 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
Wichtig
Für semantische Ansichten wird Folgendes nicht benötigt: Feld join_type oder relationship_type, die in älteren semantischen Modellen verwendet wurden. Der Beziehungstyp wird automatisch aus den Daten abgeleitet.
Die wichtigsten Konzepte¶
Tabellen¶
Logische Tabellen repräsentieren Geschäftseinheiten (wie Kunden, Aufträge oder Produkte) und werden physischen Datenbanktabellen zugeordnet. Jede logische Tabelle kann Folgendes definieren:
Basistabelle: Der vollqualifizierte Name der physischen Tabelle
Primärschlüssel: Spalten, die Zeilen eindeutig identifizieren
Synonyme: Alternative Namen für die Tabelle
Beschreibung: Geschäftsfreundliche Erklärung, was die Tabelle darstellt
Dimensionen¶
Dimensionen stellen Kategorie-Attribute dar, die Kontext für die Analyse bereitstellen. Sie beantworten die Fragen „Wer“, „Was“, „Wo“ und „Wann“. Dimensionen können Folgendes sein:
Reguläre Dimensionen: Text, numerische oder andere Kategoriewerte
Zeitdimensionen: Datums- oder Zeitstempelspalten mit spezieller zeitbasierter Behandlung
Eigenschaften von Dimensionen¶
expr: SQL-Ausdruck zum Berechnen des Dimensionswertssynonyms: Alternative Begriffe, die von Benutzenden verwendet werdenunique: Gibt an, ob Werte über Zeilen hinweg eindeutig sindis_enum: Gibt an, ob die Dimension einen festen Satz von Werten hatcortex_search_service: Optionaler Cortex Search Service für die semantische Suche
Optionale Eigenschaften für physische Dimensionen¶
Diese Felder sind optional, werden aber empfohlen, um bei einer Suche aus einer semantischen Ansicht qualitativ bessere Ergebnisse zu erzielen.
synonymsEine Liste anderer Begriffe/Phrasen, die sich auf diese Dimension beziehen. Muss für alle Synonyme in diesem semantischen Modell eindeutig sein.
descriptionEine kurze Beschreibung dieser Dimension. Fügen Sie Informationen hinzu, die nützlichen Kontext liefern, z. B. Daten, die diese Dimension repräsentiert.
uniqueEin boolescher Wert, der angibt, dass diese Dimension eindeutige Werte hat.
sample_valuesBeispielwerte für diese Spalte, falls vorhanden. Fügen Sie alle Werte hinzu, auf die in den Fragen der Benutzer wahrscheinlich Bezug genommen wird.
is_enumEin boolescher Wert. Wenn Sie
Truewählen, werden die Werte im Feldsample_valuesals die vollständige Liste der möglichen Werte betrachtet und das Modell wählt nur aus diesen Werten, wenn es nach dieser Spalte filtert.cortex_search_serviceGibt den Cortex Search Service an, der für diese Dimension verwendet werden soll. Es hat die folgenden Felder:
service: Der Name des Cortex Search Service.literal_column: (optional) Die Spalte im Cortex Search Service, die die literalen Werte enthält.database: (optional) Die Datenbank, in der sich der Cortex Search Service befindet. Standardmäßig wird die Datenbank vonbase_tableverwendet.schema: (optional) Das Schema, in dem sich der Cortex Search Service befindet. Standardmäßig wird das Schema vonbase_tableverwendet.
cortex_search_serviceersetzt das Feldcortex_search_service_name, in dem nur der Name angegeben werden konnte.cortex_search_service_nameist veraltet.
Optionale Eigenschaften für Zeitdimensionen¶
Diese Felder sind optional, werden aber empfohlen, um bei einer Suche aus einer semantischen Ansicht qualitativ bessere Ergebnisse zu erzielen.
synonymsEine Liste anderer Begriffe/Phrasen, die sich auf diese Zeitdimension beziehen. Muss für alle Synonyme in diesem semantischen Modell eindeutig sein.
descriptionEine kurze Beschreibung dieser Dimension. Fügen Sie Informationen hinzu, die einen nützlichen Kontext liefern, z. B. die Zeitzone, die diese Dimension als Referenzpunkt verwendet.
unique:Ein boolescher Wert, der angibt, dass diese Spalte eindeutige Werte hat.
sample_values:Beispielwerte für diese Spalte, falls vorhanden. Fügen Sie alle Werte hinzu, auf die in den Fragen der Benutzer wahrscheinlich Bezug genommen wird.
Fakten¶
Fakten sind quantitative Attribute auf Zeilenebene, die bestimmte Geschäftsereignisse oder Transaktionen darstellen. Fakten erfassen das „wie viel“ auf der detailliertesten Ebene, z. B. einzelne Verkaufsbeträge, gekaufte Mengen oder Kosten.
Fakten fungieren in der Regel als „Hilfskonzepte“ innerhalb der semantischen Ansicht, um Dimensionen und Kennzahlen zu konstruieren.
Die Eigenschaften von Fakten sind:
expr: SQL-Ausdruck zum Berechnen des Faktenwertsaccess_modifier: Aufprivate_accessfestlegen, um vor Abfragen zu verbergen (nützlich für Zwischenberechnungen)data_type: Der Datentyp des Fakts
Kennzahlen¶
Kennzahlen sind quantifizierbare Messgrößen der Geschäftsleistung, die durch Aggregieren von Fakten oder anderen Spalten mit Funktionen wie SUM, AVG und COUNT berechnet werden.
Zwei Arten von Kennzahlen:
Kennzahlen auf Tabellenebene: Bereich auf eine bestimmte logische Tabelle festgelegt, Aggregieren von Daten innerhalb dieser Tabelle
Abgeleitete Kennzahlen: Kennzahlen auf Ansichtsebene, die Kennzahlen aus mehreren Tabellen kombinieren
Eigenschaften von Kennzahlen:
expr: SQL-Ausdruck mit Aggregationsfunktionaccess_modifier: Aufprivate_accessfestlegen, um vor Abfragen zu verbergen (nützlich für Zwischenberechnungen)synonyms: Alternative Begriffe für Kennzahlen
Abgeleitete Kennzahlen¶
Abgeleitete Kennzahlen sind Kennzahlen auf Ansichtsebene, die nicht an eine bestimmte Tabelle gebunden sind. Sie können Kennzahlen aus mehreren Tabellen kombinieren oder Berechnungen über die gesamte Ansicht hinweg durchführen.
Beispiel für eine abgeleitete Kennzahl:
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
Beziehungen¶
Beziehungen definieren, wie logische Tabellen miteinander verknüpft werden. Jede Beziehung legt Folgendes fest:
left_table: Die Tabelle, die den Fremdschlüssel enthältright_table: Die Tabelle, auf die verwiesen wirdrelationship_columns: Paare von Spalten für die Verknüpfung, wieleft_columnundright_column
Der Beziehungstyp (1:1, n:1) wird automatisch aus den Definitionen der Daten und der Primärschlüssel abgeleitet.
Bemerkung
Im Gegensatz zu älteren semantischen Modellen erfordern semantische Ansichten keine expliziten join_type- oder relationship_type-Spezifikationen. Diese werden automatisch ermittelt.
Filter¶
Filter definieren häufig verwendete Filterbedingungen, die über den Namen referenziert werden können. Dadurch wird eine konsistente Filterlogik über alle Abfragen hinweg sichergestellt.
Beispiel:
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())"
Geprüfte Abfragen¶
Verifizierte Abfragen sind Beispielfragen mit den entsprechenden SQL-Abfragen. Sie unterstützen Cortex Analyst dabei zu verstehen, wie ähnliche Fragen beantwortet werden können, und dienen als Dokumentation für Benutzende.
Eigenschaften:
question: Frage in natürlicher Sprachesql: SQL-Abfrage, die die Frage beantwortetverified_by: Optional die Person, die verifiziert hat, dass die Abfrage korrekt istverified_at: Optionaler Zeitstempel der Überprüfunguse_as_onboarding_question: Optionales Flag, um dies den Benutzenden als Vorschlag anzuzeigen
Zugriffsmodifikatoren¶
Semantische Ansichten unterstützen Zugriffsmodifikatoren für Fakten und Kennzahlen, mit denen Sie die Sichtbarkeit steuern können:
public_access(Standard): Für Benutzende sichtbar und abfragbarprivate_access: Für Abfragen verborgen, wird nur für Zwischenberechnungen verwendet
Beispiel:
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
Kundenspezifische Anweisungen in Cortex Analyst¶
Sie können SQL-Befehle verwenden, um benutzerdefinierte Anweisungen in der Definition der semantischen Ansicht bereitzustellen. Diese Anweisungen steuern, wie die Abfragen generiert und die Fragen kategorisiert werden. Diese Anweisungen sind nicht Teil der YAML-Spezifikation, werden jedoch mit dem Befehl CREATE SEMANTIC VIEW festgelegt.
Weitere Informationen dazu finden Sie unter Bereitstellung kundenspezifischer Anweisungen für Cortex Analyst.
Beispiel für eine semantische YAML-Ansicht¶
Hier ist ein vollständiges Beispiel für eine semantische Ansicht einer YAML-Spezifikation:
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
Erstellen einer semantischen Ansicht aus YAML¶
Verwenden Sie zum Erstellen einer semantischen Ansicht anhand einer YAML-Spezifikation die gespeicherte Prozedur SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML.
Weitere Informationen dazu finden Sie unter Semantischen Ansicht aus einer YAML-Spezifikation erstellen.
Abrufen von YAML aus einer semantischen Ansicht¶
Um eine semantische Ansicht in das YAML-Format zu exportieren, verwenden Sie die Funktion SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW.
Weitere Informationen dazu finden Sie unter YAML-Spezifikation für eine semantische Ansicht abrufen.
Unterschiede zu älteren semantischen Modellen¶
Wenn Sie von YAML-Dateien eines älteren semantischen Modells zu semantischen Ansichten migrieren, beachten Sie folgende wichtige Unterschiede:
Feature |
Ältere semantische Modelle |
Semantische Ansichten |
|---|---|---|
Speicher |
YAML-Dateien in Stagingbereichen |
Objekte auf Schemaebene in Datenbank |
Berechtigungen |
Stagingbereich-basierte Zugriffssteuerung |
Vollständige Snowflake RBAC-Integration |
Freigeben |
Manuelle Dateifreigabe |
Native Snowflake-Freigabe |
Join-Typen |
Erfordert |
Automatisch abgeleitet |
Abgeleitete Kennzahlen |
Nicht unterstützt |
Vollständig unterstützt |
Zugriffsmodifikatoren |
Nicht unterstützt |
|
Kundenspezifische Anweisungen |
In YAML-Datei |
Über SQL-Befehle festgelegt |
Bei der Konvertierung von einem älteren semantischen Modell in eine semantische Ansicht:
join_typeundrelationship_typeaus Beziehungen entfernenDie Verwendung abgeleiteter Kennzahlen für Berechnungen auf Ansichtsebene in Erwägung ziehen
access_modifierzu Fakten/Kennzahlen hinzufügen, die privat gemacht werden sollenVerschieben kundenspezifischer Anweisungen zum Befehl SQL CREATE SEMANTIC VIEW