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
Copy

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 Dimensionswerts

  • synonyms: Alternative Begriffe, die von Benutzenden verwendet werden

  • unique: Gibt an, ob Werte über Zeilen hinweg eindeutig sind

  • is_enum: Gibt an, ob die Dimension einen festen Satz von Werten hat

  • cortex_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.

synonyms

Eine Liste anderer Begriffe/Phrasen, die sich auf diese Dimension beziehen. Muss für alle Synonyme in diesem semantischen Modell eindeutig sein.

description

Eine kurze Beschreibung dieser Dimension. Fügen Sie Informationen hinzu, die nützlichen Kontext liefern, z. B. Daten, die diese Dimension repräsentiert.

unique

Ein boolescher Wert, der angibt, dass diese Dimension 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.

is_enum

Ein boolescher Wert. Wenn Sie True wählen, werden die Werte im Feld sample_values als 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_service

Gibt 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 von base_table verwendet.

  • schema: (optional) Das Schema, in dem sich der Cortex Search Service befindet. Standardmäßig wird das Schema von base_table verwendet.

cortex_search_service ersetzt das Feld cortex_search_service_name, in dem nur der Name angegeben werden konnte. cortex_search_service_name ist 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.

synonyms

Eine Liste anderer Begriffe/Phrasen, die sich auf diese Zeitdimension beziehen. Muss für alle Synonyme in diesem semantischen Modell eindeutig sein.

description

Eine 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 Faktenwerts

  • access_modifier: Auf private_access festlegen, 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:

  1. Kennzahlen auf Tabellenebene: Bereich auf eine bestimmte logische Tabelle festgelegt, Aggregieren von Daten innerhalb dieser Tabelle

  2. Abgeleitete Kennzahlen: Kennzahlen auf Ansichtsebene, die Kennzahlen aus mehreren Tabellen kombinieren

Eigenschaften von Kennzahlen:

  • expr: SQL-Ausdruck mit Aggregationsfunktion

  • access_modifier: Auf private_access festlegen, 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
Copy

Beziehungen

Beziehungen definieren, wie logische Tabellen miteinander verknüpft werden. Jede Beziehung legt Folgendes fest:

  • left_table: Die Tabelle, die den Fremdschlüssel enthält

  • right_table: Die Tabelle, auf die verwiesen wird

  • relationship_columns: Paare von Spalten für die Verknüpfung, wie left_column und right_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())"
Copy

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 Sprache

  • sql: SQL-Abfrage, die die Frage beantwortet

  • verified_by: Optional die Person, die verifiziert hat, dass die Abfrage korrekt ist

  • verified_at: Optionaler Zeitstempel der Überprüfung

  • use_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 abfragbar

  • private_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
Copy

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
Copy

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 join_type und relationship_type

Automatisch abgeleitet

Abgeleitete Kennzahlen

Nicht unterstützt

Vollständig unterstützt

Zugriffsmodifikatoren

Nicht unterstützt

public_access / private_access

Kundenspezifische Anweisungen

In YAML-Datei

Über SQL-Befehle festgelegt

Bei der Konvertierung von einem älteren semantischen Modell in eine semantische Ansicht:

  1. join_type und relationship_type aus Beziehungen entfernen

  2. Die Verwendung abgeleiteter Kennzahlen für Berechnungen auf Ansichtsebene in Erwägung ziehen

  3. access_modifier zu Fakten/Kennzahlen hinzufügen, die privat gemacht werden sollen

  4. Verschieben kundenspezifischer Anweisungen zum Befehl SQL CREATE SEMANTIC VIEW