Erweiterte Techniken für Metrikansichten

Mit erweiterten Techniken für Metrikansichten können Sie komplexe Geschäftslogik ausdrücken und Definitionen auf der semantischen Ebene wiederverwenden. Auf dieser Seite werden zwei solche Techniken erläutert:

• Fenstermaße: für Zeitreihenberechnungen wie gleitende Mittelwerte, laufende Summen und Periodenüberlaufzeitänderungen.
• Komponierbarkeit: zum Erstellen komplexer Kennzahlen durch Verweis auf andere Kennzahlen, anstatt ihre Logik neu zu schreiben.

Diese Seite setzt voraus, dass Sie mit grundlegenden Konzepten der Metrikansichtsmodellierung vertraut sind. Siehe Modellmetrikansichten.

Fenstermaße

Mit Windows-Measures können Sie in Ihren Metrik-Ansichten Kennzahlen mit windowed, kumulativen oder semiadditiven Aggregationen definieren. Sie unterstützen Berechnungen wie gleitende Durchschnittswerte, Periodenüberlaufzeitänderungen und laufende Summen.

Sie können ein Fenstermaß im Katalog-Explorer-Editor oder in YAML hinzufügen.

Hinzufügen eines Fenstermaßs im Editor

Klicken Sie beim Bearbeiten einer Kennzahl auf der Registerkarte „UI“ des Editors für die Metrikansicht auf + Window. + Fenster ist sowohl im Builder- als auch im Benutzerdefiniert-Modus verfügbar. Die Fensteroptionen im Editor entsprechen den yaML-Feldern, die in "Fenstermaß definieren" beschrieben sind.

Weitere Informationen zum Erstellen und Bearbeiten von Measures finden Sie unter Erstellen einer Metrikansicht.

Definieren eines Fenstermaßs

Ein Fenstermaß enthält die folgenden erforderlichen Felder:

• order: Das Feld, das die Reihenfolge des Fensters bestimmt.

• range: Definiert den Umfang des Fensters. Unterstützte Werte: current, cumulative, trailing, leading und all. Vollständige Syntax und Beschreibungen finden Sie unter "Unterstützte range Werte". Weitere Informationen zu den Modifikatoren inclusive und exclusive bei trailing und leading finden Sie unter Ein- oder Ausschließen der Ankerzeile.

• semiadditive: Gibt an, wie das Measure aggregiert wird, wenn das Bestellfeld nicht in die Abfrage GROUP BYeinbezogen wird. Mögliche Werte: first und last.

Ein Fenstermaß unterstützt auch das folgende optionale Feld:

• offset: Verschiebt den Fensterrahmen um ein festes Intervall rückwärts oder vorwärts entlang des order Felds. Verwenden Sie diese für Kennzahlen im Periodenvergleich wie im Monats- oder Jahresvergleich. Informationen zu Syntax, unterstützten Einheiten und Einschränkungen finden Sie unter Window-Measures.

Wie offset den Fensterrahmen verschiebt

Informationen zu Verfügbarkeit der Funktion „Metrikansicht“ finden Sie unter Mindestanforderungen an Compute und die Version der YAML-Spezifikation.

Das Feld range definiert die Form des Fensters relativ zur Verankerungszeile, und offset verschiebt diesen Rahmen um das angegebene Intervall entlang order. Die folgende Tabelle zeigt den Frame für jeden range-Wert mit und ohne ein offset von k, relativ zur Ankerzeile t:

offset ist unabhängig von semiadditive. Die Auswahl first oder last steuert weiterhin, wie das Measure zusammengefasst wird, wenn sich order nicht im GROUP BY der Abfrage befindet.

Passen Sie offset für optimale Ergebnisse an die natürliche Maserung von order an. Bei monatlichen Daten wird offset: -12 month gegenüber offset: -365 day bevorzugt, da die Arithmetik mit Monaten und Jahren unterschiedlich lange Monate und Schaltjahre berücksichtigt, während dies bei der Arithmetik mit day nicht der Fall ist.

Ankerzeile ein- oder ausschließen

Informationen zu Verfügbarkeit der Funktion „Metrikansicht“ finden Sie unter Mindestanforderungen an Compute und die Version der YAML-Spezifikation.

Für die Bereiche trailing und leading steuert das optionale Schlüsselwort inclusive oder exclusive, ob der Fensterwert der Ankerzeile (z. B. heute) Teil des gleitenden Fensters ist:

Das folgende Beispiel zeigt, wie sich inclusive und exclusive auf das rollierende Fenster für das Ankerdatum 2025-01-05 mit trailing 3 day auswirken.

Gehen Sie davon aus, dass die zugrunde liegenden Daten pro Tag eine Zeile mit den folgenden Werten aufweisen:

Jeder Modifizierer wählt die Zeilen von drei Tagen relativ zum Ankerpunkt aus und summiert deren Werte:

Die leading Bereiche folgen derselben Logik in die entgegengesetzte Richtung.

Beispiel für nachfolgendes, verschiebendes oder führendes Fenstermaß

Im folgenden Beispiel wird eine fortlaufende 7-Tage-Anzahl von Kunden berechnet, die Bestellungen getätigt haben. Diese Metrik verfolgt Trends der Kundeninteraktion im Zeitverlauf, indem sie zeigt, wie viele unterschiedliche Kunden in der Woche vor dem jeweiligen Datum Käufe getätigt haben.

version: 1.1

source: samples.tpch.orders
filter: o_orderdate > DATE'1998-01-01'

fields:
  - name: date
    expr: o_orderdate

measures:
  - name: t7d_customers
    expr: COUNT(DISTINCT o_custkey)
    window:
      - order: date
        range: trailing 7 day
        semiadditive: last

In diesem Beispiel gilt die folgende Konfiguration:

• order: date Gibt an, dass das Feld das date Fenster sortiert.
• range: trailing 7 day definiert das Fenster als die sieben Tage vor jedem Datum, mit Ausnahme des Datums selbst.
• semiadditive: last gibt den letzten Wert im 7-Tage-Fenster zurück, wenn date keine Gruppierungsspalte ist.

CREATE OR REPLACE VIEW catalog.schema.rolling_customers WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: samples.tpch.orders
  filter: o_orderdate > DATE'1998-01-01'

  fields:
    - name: date
      expr: o_orderdate

  measures:
    - name: t7d_customers
      expr: COUNT(DISTINCT o_custkey)
      window:
        - order: date
          range: trailing 7 day
          semiadditive: last
$$

Beispiel für Perioden-zu-Perioden-Fenstermessung

Im folgenden Beispiel wird das tägliche Umsatzwachstum berechnet, indem der Umsatz von heute (Summe aller Bestellpreise) mit dem Umsatz von gestern verglichen wird. Diese Metrik identifiziert tagesaktuelle Umsatztrends und zeigt die prozentuale Umsatzänderung an.

version: 1.1

source: samples.tpch.orders
filter: o_orderdate > DATE'1998-01-01'

fields:
  - name: date
    expr: o_orderdate
measures:
  - name: previous_day_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: trailing 1 day
        semiadditive: last
  - name: current_day_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: current
        semiadditive: last
  - name: day_over_day_growth
    expr: (MEASURE(current_day_sales) - MEASURE(previous_day_sales)) / MEASURE(previous_day_sales) * 100

In diesem Beispiel gilt die folgende Konfiguration:

• Im Beispiel werden zwei Fenstermaße verwendet: eine für die Berechnung des Gesamtumsatzes am vorherigen Tag und eine für den aktuellen Tag.
• Ein drittes Maß berechnet die prozentuale Änderung (Wachstum) zwischen den aktuellen und vorherigen Tagen.

Beispiel für ein Fenstermesswert im Jahresvergleich mit offset

Der offset-Modifikator ist der Grundbaustein für Kennzahlen im Periodenvergleich. Definieren Sie eine verschobene Kopie eines Basismaßes, und erstellen Sie dann die beiden, um Deltas, Verhältnisse oder Wachstumsraten direkt in der Metrikansicht auszudrücken.

Im folgenden Beispiel wird das Umsatzwachstum im Jahr über das Jahr berechnet, indem der Umsatz jedes Monats mit dem gleichen Monat im Vorjahr verglichen wird. Das verschobene Maß verwendet offset: -12 month, um im Feld month 12 Monate zurückzublicken.

version: 1.1
source: main.default.monthly_sales

fields:
  - name: month
    expr: month
  - name: category
    expr: category

measures:
  - name: monthly_sales
    expr: SUM(sales)
    window:
      - order: month
        range: current
        semiadditive: last

  - name: monthly_sales_py
    expr: SUM(sales)
    window:
      - order: month
        range: current
        semiadditive: last
        offset: -12 month

  - name: yoy_growth
    expr: MEASURE(monthly_sales) - MEASURE(monthly_sales_py)

  - name: yoy_growth_pct
    expr: (MEASURE(monthly_sales) - MEASURE(monthly_sales_py))
      / NULLIF(MEASURE(monthly_sales_py), 0)

In diesem Beispiel gilt die folgende Konfiguration:

• monthly_sales ist das Basismaß, das den Umsatz für den aktuellen Monat addiert.
• monthly_sales_py ist dasselbe Maß, um 12 Monate nach hinten verschoben mit offset: -12 month. Für Januar 2025 gibt sie den Wert für Januar 2024 zurück.
• yoy_growth und yoy_growth_pct bilden die beiden Measures, mit denen die absolute und prozentuale Änderung ausgedrückt wird. Die Verwendung NULLIF vermeidet Divid-by-Zero-Fehler, wenn der Wert des Vorherigen Jahres null ist.

Beispiel für kumulatives (laufendes) Gesamtmaß

Im folgenden Beispiel werden die kumulierten Umsatzerlöse vom Anfang des Datasets bis zu jedem Datum berechnet. Diese laufende Summe zeigt, wie viel Gesamtumsatz im Laufe der Zeit generiert wurde, nützlich für die Verfolgung des Fortschritts in Richtung jährlicher Umsatzziele oder die Analyse langfristiger Wachstumsmuster.

version: 1.1
source: samples.tpch.orders

filter: o_orderdate > DATE'1998-01-01'

fields:
  - name: date
    expr: o_orderdate
  - name: customer
    expr: o_custkey

measures:
  - name: running_total_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: cumulative
        semiadditive: last

In diesem Beispiel gilt die folgende Konfiguration:

• order: date sortiert das Fenster chronologisch.
• range: cumulative definiert das Fenster als alle Daten vom Anfang des Datasets bis einschließlich jedes Datums.
• semiadditive: last gibt den aktuellsten kumulierten Wert zurück, wenn date nicht im GROUP BY der Abfrage enthalten ist, anstatt die Werte über alle Datumsangaben hinweg zu summieren.

Beispiel für eine Kennzahl seit Periodenbeginn

Im folgenden Beispiel wird der Umsatzumsatz (Year-to-Date, YTD) berechnet. Diese Maßnahme zeigt den kumulierten Umsatz, der vom 1. Januar jedes Jahres bis zum aktuellen Datum generiert wurde und zu Beginn jedes neuen Jahres zurückgesetzt wird.

version: 1.1

source: samples.tpch.orders
filter: o_orderdate > DATE'1997-01-01'

fields:
  - name: date
    expr: o_orderdate
  - name: month
    expr: DATE_TRUNC('MONTH', date)
  - name: year
    expr: DATE_TRUNC('year', date)
measures:
  - name: ytd_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: cumulative
        semiadditive: last
      - order: year
        range: current
        semiadditive: last

In diesem Beispiel gilt die folgende Konfiguration:

• Im Beispiel werden zwei Fensterspezifikationen verwendet: eine für die kumulierte Summe über das date Feld und eine andere, um die Summe auf das current Jahr zu begrenzen.
• Das year Feld schränkt die kumulierte Summe so ein, dass sie zu Beginn jedes neuen Jahres zurückgesetzt wird.
• Die Felder month und year bilden für das Bestellfeld date eine Datumshierarchie: Jedes wird im Feld date über den Namen definiert, nicht in der zugrunde liegenden Spalte o_orderdate, sodass Abfragen diese Kennzahl nach diesen Feldern gruppieren können. Siehe Gruppieren nach einem Datumshierarchiefeld.

Beispiel einer semiadditiven Kennzahl

Im folgenden Beispiel werden Kontosaldos berechnet, die nicht über Datumsangaben summiert werden dürfen (Sie können den Saldo von Montag nicht zum Guthaben am Dienstag hinzufügen, um den Gesamtsaldo zu erhalten). Stattdessen gibt die Maßnahme beim Aggregieren über mehrere Tage hinweg den letzten Saldo zurück. Die Maßnahme kann jedoch weiterhin über Kunden hinweg addiert werden, um das Gesamtguthaben für alle Konten an einem bestimmten Tag anzuzeigen.

version: 1.1

fields:
  - name: date
    expr: date
  - name: customer
    expr: customer_id

measures:
  - name: semiadditive_balance
    expr: SUM(balance)
    window:
      - order: date
        range: current
        semiadditive: last

In diesem Beispiel gilt die folgende Konfiguration:

• order: date sortiert das Fenster chronologisch.
• range: current Beschränkt das Fenster auf einen einzelnen Tag ohne Aggregation über Tage hinweg.
• semiadditive: last gibt den letzten Saldo zurück, wenn er über mehrere Tage aggregiert wird.

Fenstergröße abfragen

Sie können eine Metrikansicht mit einem Fenstermaß genauso abfragen wie jede andere Metrikansicht. Ein Fenstermesswert wird entlang seines Felds order berechnet, sodass eine Abfrage, die Ergebnisse im Zeitverlauf aufschlüsselt, auf dieses Feld Bezug nehmen muss, entweder direkt oder über ein darauf definiertes Datumshierarchiefeld. Wenn die Abfrage nicht auf das Bestellfeld verweist, bestimmt das semiadditive Schlüsselwort den zurückgegebenen Wert, wie im Beispiel für semiadditives Measure beschrieben.

Im folgenden Beispiel wird ein Fenstermaß nach state und nach einem Monatsausdruck über das Bestellfeld dategruppiert:

SELECT
   state,
   DATE_TRUNC('month', date),
   MEASURE(t7d_customers) as m
FROM my_metric_view
WHERE date >= DATE'2024-06-01'
GROUP BY ALL

Gruppieren nach einem Datumshierarchiefeld

Eine Datumshierarchie fasst das Sortierfeld auf gröbere Granularitäten wie Woche, Monat oder Jahr zusammen. Definieren Sie jede Ebene als Feld über den Namen des Sortierfelds, nicht über die zugrunde liegende Quellspalte:

fields:
  - name: date
    expr: o_orderdate
  # Date hierarchy: each level is defined on the order field `date`,
  # not on the underlying o_orderdate column.
  - name: month
    expr: DATE_TRUNC('MONTH', date)
  - name: year
    expr: DATE_TRUNC('year', date)

Die Gruppierung eines Fenstermaßes nach einer Hierarchieebene liefert das Maß auf dieser Granularitätsebene. Wenn das Period-to-date-Beispiel wie im ytd_metric_view als erstellt wird, gibt die folgende Abfrage den YTD-Wert zum letzten Datum eines jeden Monats zurück:

SELECT month, MEASURE(ytd_sales) AS ytd_sales
FROM ytd_metric_view
GROUP BY month
ORDER BY month;

Kombinierbarkeit

Metrikansichten sind kombinierbar. Sie können neue Felder und Measures erstellen, die auf vorhandene Felder verweisen, anstatt Logik von Grund auf neu zu schreiben. Dadurch wird die Duplizierung reduziert und die Verwaltung komplexer Metrikdefinitionen vereinfacht.

Die Kombinierbarkeit funktioniert auf zwei Ebenen: innerhalb einer einzelnen Metrikansicht und über mehrere Metrikansichten hinweg, wenn eine Metrikansicht als Quelle für eine andere verwendet wird.

Die Komponierbarkeit unterstützt die folgenden Referenzmuster:

• Frühere Felder in neuen Feldern.
• Felder und frühere Messungen in neuen Messungen.
• Felder aus Metrikansichten, die als Quelle in neuen Feldern verwendet werden.
• Felder und Kennzahlen aus Metrikansichten, die in neuen Kennzahlen als Quelle verwendet werden.

Maßnahmen mit Komponierbarkeit definieren

Im measures-Abschnitt können Sie auf Maßnahmen aus der Quellmetrikansicht oder auf Maßnahmen verweisen, die zuvor in derselben Metrikansicht definiert wurden. Dieser Ansatz verbessert Konsistenz, Auditierbarkeit und Wartung Ihrer semantischen Ebene.

Beispiel: Durchschnittlicher Bestellwert (AOV)

Im folgenden Beispiel wird der durchschnittliche Bestellwert (Average Order Value, AOV) mithilfe von zwei Atommaßen definiert: total_revenue (Summe der Auftragspreise) und order_count (Anzahl der Bestellungen). Die avg_order_value Messung bezieht sich auf beide atomaren Messungen.

version: 1.1

source: samples.tpch.orders

measures:
  # Total Revenue
  - name: total_revenue
    expr: SUM(o_totalprice)

  # Order Count
  - name: order_count
    expr: COUNT(1)

  # Composed Measure: Average Order Value (AOV)
  - name: avg_order_value
    # Defines AOV as Total Revenue divided by Order Count
    expr: MEASURE(total_revenue) / MEASURE(order_count)

Wenn sich die total_revenue Definition ändert (z. B. um Steuern auszuschließen), avg_order_value wird automatisch die aktualisierte Definition verwendet.

Kompositierbarkeit mit bedingter Logik

Sie können die Komponierbarkeit verwenden, um komplexe Verhältnisse, bedingte Prozentsätze und Wachstumsraten zu erstellen, ohne sich auf Fensterfunktionen für einfache Periodenberechnungen zu verlassen.

Beispiel: Erfüllungsrate

Im folgenden Beispiel wird die Erfüllungsrate berechnet: der Prozentsatz der Bestellungen mit dem Status 'F' (erfüllt). Die Maßnahme teilt die erfüllten Bestellungen durch die Gesamtaufträge.

version: 1.1

source: samples.tpch.orders

measures:
  # Total Orders (denominator)
  - name: total_orders
    expr: COUNT(1)

  # Fulfilled Orders (numerator)
  - name: fulfilled_orders
    expr: COUNT(1) FILTER (WHERE o_orderstatus = 'F')

  # Composed Measure: Fulfillment Rate (Ratio)
  - name: fulfillment_rate
    expr: MEASURE(fulfilled_orders) / MEASURE(total_orders)
    format:
      type: percentage

Bewährte Methoden für die Komponierbarkeit

1. Definieren Sie zuerst atomare Maßeinheiten: Legen Sie grundlegende Maßeinheiten (SUM, COUNT, AVG) fest, bevor Sie Maßnahmen definieren, die auf diese Bezug nehmen.
2. Verwenden Sie für VerweiseMEASURE(): Verwenden Sie die MEASURE()-Funktion zum Verweisen auf ein anderes Maß innerhalb eines expr. Wiederholen Sie die Aggregationslogik nicht manuell. Beispielsweise vermeiden Sie SUM(a) / COUNT(b), wenn Maßnahmen für beide Werte bereits vorhanden sind.
3. Lesbarkeit priorisieren: Verfassen von Maßnahmen mit klaren mathematischen Formeln. Ist beispielsweise MEASURE(gross_profit) / MEASURE(total_revenue) klarer als ein einzelner komplexer SQL-Ausdruck.
4. Fügen Sie semantische Metadaten hinzu: Verwenden Sie semantische Metadaten, um zusammengesetzte Measures (z. B. Prozentsätze oder Währungen) für nachgeschaltete Tools zu formatieren. Siehe Agentmetadaten in Metrikansichten.

Weitere Ressourcen

• Modellmetrikansichten
• Agentmetadaten in Metrikansichten
• Materialisierung für Metrikansichten
• Referenz zur YaML-Syntax der Metrikansicht