Modellmetrikansichten

Metrikansichten erstellen eine semantische Ebene für Ihre Daten, transformieren Tabellen und Ansichten in standardisierte Geschäftsmetriken. Sie definieren, was gemessen werden soll, wie es aggregiert wird und wie es segmentiert wird. Daher meldet jeder Benutzer in der gesamten Organisation den gleichen Wert für denselben KPI, wodurch inkonsistente Berichte beseitigt und flexible Analysen in allen Feldern ermöglicht werden.

Die von Ihnen definierten Kernkomponenten sind Quellen, Verknüpfungen, Filter, Felder und Measures.

Ein vollständiges Beispiel mit Verknüpfungen, Feldern, Measures und Agentmetadaten finden Sie im Lernprogramm: Erstellen einer Metrikansicht mit Verknüpfungen und Datenmodellierung.

Kernkomponenten

Eine Metrikansicht besteht aus den folgenden Elementen:

Definieren einer Quelle

Sie können ein tabellenähnliches Objekt oder eine SQL-Abfrage als Quelle für Ihre Metrikansicht verwenden. Sie müssen mindestens SELECT Privilegien für jede referenzierte Ressource haben.

Ein tabellenähnliches Objekt ist ein Unity Catalog-Objekt , das ein tabellarisches Schema verfügbar macht und Abfragen unterstützt SELECT , einschließlich Tabellen, Ansichten, materialisierte Ansichten, Streamingtabellen, Fremdtabellen, Systemtabellen und Metrikansichten.

Verwenden einer tabellenähnlichen Ressource als Quelle

Wenn Sie ein tabellenähnliches Objekt als Quelle verwenden möchten, geben Sie den vollqualifizierten Namen an. Beispiel: samples.tpch.orders.

Verwenden einer Metrikansicht als Quelle

Sie können eine vorhandene Metrikansicht als Quelle für eine neue Metrikansicht verwenden:

version: 1.1

source: views.examples.source_metric_view

fields:
  - name: Order month
    expr: '`Order Month`'

measures:
  - name: Latest order month
    expr: MAX(`Order month`)
  - name: Latest order year
    expr: "DATE_TRUNC('year', MEASURE(`Latest order month`))"

Bei der Verwendung einer Metrikansicht als Quelle gelten dieselben Kompositionsregeln für die Referenzierung von Feldern und Kennzahlen. Siehe Kompositierbarkeit.

Verwenden einer SQL-Abfrage als Quelle

Um eine SQL-Abfrage zu verwenden, schreiben Sie den Abfragetext direkt in das YAML:

version: 1.1

source: SELECT * FROM samples.tpch.orders o LEFT JOIN samples.tpch.customer c ON o.o_custkey
  = c.c_custkey

fields:
  - name: Order key
    expr: o_orderkey

measures:
  - name: Order Count
    expr: COUNT(o_orderkey)

Arrays und Maps im Quellcode auflösen

Felder, Maße und Joins arbeiten alle auf flachen, skalaren Spalten. Wenn Ihre Quelldaten Spalten haben ARRAY oder MAP typen, lösen Sie sie in der Abfrage in flache source Spalten auf, bevor Sie sie an anderer Stelle in der Metrikansicht referenzieren. Es gibt zwei Transformationsstrategien, je nachdem, ob man pro Array-Element eine Zeile oder einen einzelnen Wert pro Quellzeile möchte. Beides gilt, egal ob das Array in der Top-Level-Quelle oder in einer Tabelle ist, zu der du dich verbindest. Siehe Transformieren komplexer Datentypen für den vollständigen Satz der Transformationsfunktionen.

Kein Datensatz im Katalog samples hat eine Array-Spalte, daher verwenden die Beispiele in diesem Abschnitt eine orders Ansicht mit einem line_items Array von Structs. Verwenden Sie das folgende Beispiel, um eine Ansicht mit einem Feld zu erstellen, das ein Array ist. Ersetzen catalog.schema Sie sie durch den Katalog und das Schema, auf das Sie schreiben möchten. Du musst Berechtigungen haben, um Objekte in diesem Schema zu erstellen.

CREATE OR REPLACE VIEW catalog.schema.orders AS
SELECT
  o.o_orderkey,
  o.o_custkey,
  o.o_orderdate,
  o.o_orderstatus,
  collect_list(named_struct(
    'product_id', l.l_partkey,
    'quantity', cast(l.l_quantity as int)
  )) AS line_items
FROM samples.tpch.orders o
JOIN samples.tpch.lineitem l ON o.o_orderkey = l.l_orderkey
GROUP BY o.o_orderkey, o.o_custkey, o.o_orderdate, o.o_orderstatus;

Flache ein Array in Reihen auf

Um jedes Array-Element als eigene Zeile zu analysieren, verwenden explode() Sie in der source Abfrage, um das Array zu entpacken. Jedes Element wird zu einer eigenen Zeile, und die anderen Spalten der Quellzeile wiederholen sich für jedes Element. Siehe Verschachtelte verschachtelte Elemente aus einer Karte oder einem Array.

Das folgende Beispiel entpackt das line_items Array, sodass jedes Element zu einer Zeile wird:

version: 1.1
source: |
  SELECT o_orderkey, o_custkey, item.product_id, item.quantity
  FROM catalog.schema.orders
  LATERAL VIEW explode(line_items) AS item

fields:
  - name: Product
    expr: product_id

measures:
  - name: Total quantity
    expr: SUM(quantity)
  - name: Line item count
    expr: COUNT(1)

Das Explodieren des Arrays multipliziert source die Quellzeilen, sodass eine Aggregation wie COUNT(1) Array-Elemente zählt, nicht die ursprünglichen Zeilen. Um auch die ursprünglichen Reihen ohne Fan-out zu messen, modellieren Sie die explodierte Tabelle stattdessen als Verbindung one_to_many . Siehe 1:n-Verknüpfungen.

Aggregiere ein Array zu einem einzigen Wert

Um ein Array auf einen Wert pro Quellzeile zu reduzieren, ohne die Zeilenanzahl zu ändern, wenden Sie eine skalare Array-Funktion in der source Abfrage an, wie z. aggregate()B. , array_size(), oder reduce(). Jede Quellzeile behält ihr Korn, und die berechnete Spalte steht Feldern und Maßen zur Verfügung.

Das folgende Beispiel berechnet die Anzahl der Items und die Gesamtmenge des line_items Arrays pro Ordnung:

version: 1.1
source: |
  SELECT o_orderkey, o_custkey,
    array_size(line_items) AS item_count,
    aggregate(line_items, 0, (acc, x) -> acc + x.quantity) AS total_quantity
  FROM catalog.schema.orders

measures:
  - name: Total quantity
    expr: SUM(total_quantity)
  - name: Average items per order
    expr: AVG(item_count)

Da die Quellanfrage das Array reduziert, bevor die Metrikansicht es verarbeitet, behält die Quelle pro Bestellung eine Zeile und misst wie üblich die Aggregation über Ordnungen hinweg.

Auflösen eines Arrays in einer verbundenen Tabelle

Die gleiche Regel gilt, wenn das Array in einer Tabelle liegt, der du beitreten möchtest, und nicht in der obersten Quellcode. Ein Join arbeitet auf flachen Spalten, also löst das Array in der eigenen source Unterabfrage der joined-Tabelle vor dem Join auf. Schreibe das Join source als SQL-Abfrage, die das Array abflacht oder aggregiert, und join dann auf den resultierenden Spalten. Siehe Joins in metrischen Ansichten.

Das folgende Beispiel verwendet customer als Quelle und verbindet die orders Ansicht mit cardinality: one_to_many. Der Join source aggregiert das line_items Array jeder Bestellung zu einem Skalar total_quantity vor dem Join, sodass die Metrikansicht es pro Kunden summieren kann, ohne Kundenzeilen zu duplizieren:

version: 1.1
source: samples.tpch.customer

joins:
  - name: orders
    source: |
      SELECT o_orderkey, o_custkey,
        aggregate(line_items, 0, (acc, x) -> acc + x.quantity) AS total_quantity
      FROM catalog.schema.orders
    on: orders.o_custkey = source.c_custkey
    cardinality: one_to_many

fields:
  - name: Customer name
    expr: c_name

measures:
  - name: Total quantity
    expr: SUM(orders.total_quantity)
  - name: Order count
    expr: COUNT(orders.o_orderkey)

Um stattdessen jedes Array-Element als eigene Zeile in der joined-Tabelle zu behandeln, flachen Sie das Array mit explode() im Join source auf die gleiche Weise ab. Sieh Sie: Abflache ein Array in Reihen.

Felder

Felder, auch als Dimensionen bezeichnet, sind Metrikansichtsspalten, die Sie zur Abfragezeit in SELECT, WHEREund GROUP BY Klauseln verwenden können. Ein Feld kann eine kategorisierte Spalte sein, z. B. Region oder Status, oder eine nicht aggregierte numerische Spalte, z. B. Preis oder Menge, die Sie zur Abfragezeit aggregieren können. Jeder Feldausdruck muss einen skalaren Wert zurückgeben. Sie kann auf Spalten aus den Zuvor in der Metrikansicht definierten Quelldaten oder -feldern verweisen. Jedes Feld besteht aus zwei Komponenten:

• name: Der Alias der Spalte
• expr: Ein SQL-Ausdruck, der auf die Quelldaten oder zuvor definierten Felder in der Metrikansicht verweist

Maßnahmen

Measures sind Ausdrücke, die Ergebnisse ohne eine vordefinierte Aggregationsebene erzeugen. Sie müssen mithilfe von Aggregatfunktionen ausgedrückt werden. Verwenden Sie die MEASURE Funktion, um auf ein Measure in einer Abfrage zu verweisen. Kennzahlen können auf Basisspalten in den Quelldaten, zuvor definierten Feldern oder zuvor definierten Kennzahlen verweisen. Jede Maßnahme besteht aus den folgenden Komponenten:

• name: Der Alias des Measures
• expr: Ein Aggregat-SQL-Ausdruck, der SQL-Aggregatfunktionen enthalten kann

Im folgenden Beispiel werden allgemeine Muster von Maßzahlen zum Analysieren von Auftrag- und Umsatzdaten veranschaulicht. In diesen Beispielen wird die Tabelle TPC-H Bestellungen verwendet, die Transaktionsdaten enthält, einschließlich Bestellpreise (o_totalprice), Kunden-IDs (o_custkey), Bestellschlüssel (o_orderkey), Bestelldaten (o_orderdate) und Prioritätsstufen (o_orderpriority):

measures:
  # Simple count measure
  - name: Order Count
    expr: COUNT(1)

  # Sum aggregation measure
  - name: Total Revenue
    expr: SUM(o_totalprice)

  # Distinct count measure
  - name: Unique Customers
    expr: COUNT(DISTINCT o_custkey)

  # Calculated measure combining multiple aggregations
  - name: Average Order Value
    expr: SUM(o_totalprice) / COUNT(DISTINCT o_orderkey)

  # Filtered measure with WHERE condition
  - name: High Priority Order Revenue
    expr: SUM(o_totalprice) FILTER (WHERE o_orderpriority = '1-URGENT')

  # Measure using a field
  - name: Average Revenue per Month
    expr: SUM(o_totalprice) / COUNT(DISTINCT DATE_TRUNC('MONTH', o_orderdate))

Eine Liste der Aggregatfunktionen finden Sie unter " Aggregatfunktionen ".

Anwenden von Filtern

Ein Filter gilt für alle Abfragen, die auf die Metrikansicht verweisen. Informationen zum Definieren eines Filters in der Benutzeroberfläche finden Sie unter Schritt 3: Definieren eines Filters.

Um einen Filter in der YAML-Definition zu definieren, schreiben Sie einen booleschen Ausdruck. Das folgende Beispiel zeigt allgemeine Filtermuster:

# Single condition
filter: o_orderdate > '2024-01-01'

# Multiple conditions
filter: o_orderdate > '2024-01-01' AND o_orderstatus = 'F'

# IN clause
filter: o_orderstatus IN ('F', 'P') AND o_orderdate >= '2024-01-01'

Arbeiten mit Verknüpfungen

Metrikansichten unterstützen Verknüpfungen, um Ihre Quelldaten mit Attributen aus verknüpften Tabellen zu bereichern. Sie können Sternschemas modellieren (Faktentabelle, die mit Dimensionstabellen verknüpft ist), Schneeflockenschemas (mehrstufige Dimensionsverknüpfungen) und 1:n-Beziehungen (Fakterweiterung aus einer Dimensionsquelle). Ausführliche Informationen zu Verknüpfungstypen, Kardinalität, Schemamustern und Einschränkungen finden Sie unter Verknüpfungen in Metrikansichten.

Informationen zum Definieren von Verknüpfungen in der Benutzeroberfläche finden Sie unter Schritt 2: Hinzufügen einer Verknüpfung. Verwenden Sie die Muster in den folgenden Abschnitten, um Verknüpfungen in der YAML-Definition zu definieren.

Modellsternschemas

In einem Sternschema ist die source die Faktentabelle und wird mit einer oder mehreren Dimensionstabellen mithilfe eines LEFT OUTER JOIN verbunden. Metrikansichten verknüpfen die Fakten- und Dimensionstabellen, die für die jeweilige Abfrage auf Grundlage der ausgewählten Felder und Kennzahlen erforderlich sind.

Geben Sie Verknüpfungsspalten entweder mit einer on-Klausel (boolescher Ausdruck) oder mit einer using-Klausel (gemeinsame Spaltennamen) an. Die Verknüpfung muss einer n:1-Beziehung folgen. Bei Viele-zu-viele-Beziehungen wählt die Engine die erste übereinstimmende Zeile aus der verknüpften Dimensionstabelle aus.

Das folgende Beispiel verknüpft orders (Faktentabelle) mit customer (Dimensionstabelle) und macht Kundenattribute als Felder verfügbar. Die Einstellung rely.at_most_one_match: true gibt an, dass es sich bei der Verknüpfung um eine Many-to-one-Beziehung handelt (jede Bestellung hat genau einen Kunden), was der Engine ermöglicht, Abfragen zu optimieren, die nach Feldern aus der verknüpften Tabelle filtern.

Siehe Optimieren von Verknüpfungen mit rely.

version: 1.1
source: samples.tpch.orders

joins:
  - name: customer
    source: samples.tpch.customer
    on: source.o_custkey = customer.c_custkey

fields:
  - name: Customer name
    expr: customer.c_name

measures:
  - name: Total revenue
    expr: SUM(o_totalprice)

YAML-Syntax und -Formatierung

Metrische Ansichtsdefinitionen folgen der standardmäßigen YAML-Notationssyntax. Informationen zur erforderlichen Syntax und Formatierung finden Sie in der YaML-Syntaxreferenz zur Metrikansicht .

Bewährte Methoden

Verwenden Sie beim Modellieren von Metrikansichten die folgenden Richtlinien:

• Modell atomische Measures: Beginnen Sie mit der Definition der einfachsten Measures zuerst (z. B SUM(revenue). , COUNT(DISTINCT customer_id)). Erstellen Sie komplexe Measures mithilfe der Kompositierbarkeit.
• Feldwerte standardisieren: Verwenden Sie Transformationen (wie CASE Anweisungen), um Datenbankcodes in eindeutige Bezeichnungen umzuwandeln (z. B. den Bestellstatus „O“ in „Offen“ und „F“ in „Erfüllt“).
• Definieren sie den Bereich mit Filtern: Wenn eine Metrikansicht nur abgeschlossene Bestellungen enthalten soll, definieren Sie diesen Filter in der Metrikansicht, damit Benutzer nicht versehentlich unvollständige Daten einschließen können.
• Verwenden Sie eine klare Benennung: Metrische Namen sollten für Geschäftsbenutzer erkennbar sein (z. B. "Customer Lifetime Value" anstelle von cltv_agg_measure).
• Separate Zeitfelder: Fügen Sie granulare Zeitfelder (z. B. "Bestelldatum") und abgeschnittene Zeitfelder (z. B. "Bestellmonat" oder "Bestellwoche") ein, um sowohl Detailebene als auch Trendanalyse zu ermöglichen.

Weitere Ressourcen

• Verknüpfungen in Metrikansichten
• Erweiterte Techniken für Metrikansichten
• Agentmetadaten in Metrikansichten
• Materialisierung für Metrikansichten
• Referenz zur YaML-Syntax der Metrikansicht