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. Ein trailing oder leading Bereich nimmt eine Zeiteinheit auf einem Datums- oder Zeitstempelfeld order an, wie zum Beispiel trailing 7 day, oder gar keine Einheit auf einer aufeinanderfolgenden ganzzahligen order Spalte, wie zum Beispiel trailing 3. 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.

Eine Fenstermetrik unterstützt außerdem die folgenden optionalen Felder:

• semiadditiv: Gibt an, wie die Kennzahl aggregiert wird, wenn das Bestellfeld nicht in die Abfrage GROUP BYeinbezogen wird. Mögliche Werte: first und last. Der Standardwert lautet last.

• Offset: Verschiebt den Fensterrahmen entlang des Felds order um einen festen Betrag nach hinten oder vorn. Verwenden Sie einen datierten Offset wie -12 month auf einem Datums- oder Zeitstempelfeld order, um Periodenvergleiche wie Monats- oder Jahresvergleiche durchzuführen. Verwenden Sie einen einheitslosen numerischen Versatz, wie zum Beispiel -1 auf einer aufeinanderfolgenden ganzzahligen order Spalte, um über einen Geschäftszeitraum hinweg zu vergleichen, der kein Kalenderdatum ist. Informationen zu Syntax, unterstützten Einheiten und Einschränkungen finden Sie unter Window-Measures.

Man kann auch einen ganzzahligen Parameter als Wert eines Fenstermaßes range oder offsetverweisen, sodass ein Aufrufer die Fenstergröße zur Abfragezeit eingibt. Siehe Übergeben einer Fenstergröße als Parameter.

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 Rahmen für jeden range-Wert mit und ohne ein offset von k, relativ zur Ankerzeile t an:

offset ist unabhängig von semiadditive. Die Auswahl first oder last steuert weiterhin, wie die Kennzahl 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:

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

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.
• Das Maß lässt semiadditive aus, also verwendet es den Standard last und 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
$$

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
  - name: current_day_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: current
  - 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 Fensterkennzahlen 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

  - name: monthly_sales_py
    expr: SUM(sales)
    window:
      - order: month
        range: current
        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.

Fenstermaße in einer numerischen Indexspalte

Benötigt Databricks Runtime 19 oder höher und YAML-Spezifikation Version 1.1 oder höher.

Ein offset mit Datumsangabe, wie z. B. -12 month, durchläuft eine Datums- oder Zeitstempelspalte schrittweise. Eine Datumsspalte passt nicht mehr, wenn Ihre Vergleichsachse ein Geschäftszeitraum ist, der kein Kalenderdatum ist. Geschäftswochen, ISO-Wochen und Buchhaltungsperioden 4-4-5 sind alles Beispiele. Ordnen Sie stattdessen Fenstermessungen in einer integralen Indexspalte und wenden Sie einen einheitenlosen numerischen Wert offset oder range an. Ein numerischer Offset führt ganzzahlige Berechnungen mit dem Index aus; das heißt, offset: -1 bezeichnet die vorangehende Position in der Sequenz, und range: trailing 3 bezeichnet die drei letzten Positionen.

Ein numerischer Offset oder Bereich liefert das korrekte Ergebnis nur, wenn die Spalte order alle folgenden Anforderungen erfüllt. Nur die erste Anforderung wird zur Abfragezeit validiert. Eine Spalte, die eine der anderen beiden unterbricht, liefert falsche Zahlen statt eines Fehlers, also überprüfen Sie sie selbst:

• Integral: Die Spalte ist eine der folgenden: TINYINT, SMALLINT, INT oder BIGINT. DATE, TIMESTAMP, DECIMAL, , DOUBLE, und STRING Spalten sind keine gültigen Indexspalten. Verwenden Sie zum Vergleichen anhand eines Datums stattdessen einen datierten offset. Erfahren Sie , wie offset der Fensterrahmen verschoben wird.
• Monoton und aufeinanderfolgend (dicht): Der Wert erhöht sich von einer tatsächlichen Periode zur nächsten um genau 1, auch über Jahres- oder Quartalsgrenzen hinweg. Eine Lücke oder ein wiederholter Wert führt dazu offset: -1 , einen Zeitraum zu überspringen oder doppelt zu zählen. Eine Rohbezeichnung wie fiscal_week, die jedes Jahr auf 1 zurückgesetzt wird, ist für sich genommen kein gültiger Index.
• An das Vergleichs-Aggregationsintervall angepasst: Der Offset oder die Bereichsschritte im Aggregationsintervall des Indexes. Im Monatsindex offset: -1 ist der vorherige Monat und range: trailing 3 die letzten drei Monate. Für einen gröberen Vergleich, wie zum Beispiel im Jahresvergleich, beauftragen Sie eine separate Messgröße für einen Jahresindex oder verwenden Sie eine Messung mit gleicher Position und Vorzyklus. Verwenden Sie keinen feineren (Monats)-Index erneut und fassen Sie die Daten nicht weiter zusammen. Siehe Gleiche Position in einem vorherigen Zyklus (zwei Fensterspezifikationen, kein Index).

Erhalten Sie eine Indexspalte

Du kannst eine vorab berechnete Indexspalte aus der Quelle benennen oder eine in der Metrikansicht ableiten. Das Rezept hängt von der Kalenderform ab:

Richten Sie die Dimensionen aus, auf denen der Index abhängt

Weisen Sie jedem Metrikansichtsfeld, aus dem der Index berechnet wird, eine range: all Sortierspezifikation zu, wie order_year und order_month für month_index = order_year * 12 + order_month. Dies gilt, egal ob der Index in der metrischen Ansicht abgeleitet oder stromaufwärts als nackte Spalte vorberechnet ist. Die Spezifikation range: all lässt diese Felder während der Fensterkonstruktion ignorieren, wie beabsichtigt, wenn eine Abfrage sie gruppiert oder filtert.

Diese Spezifikationen sind nicht optional. Ohne sie partitioniert eine Abfrage, die nach order_year oder order_month gruppiert, das Fenster nach diesen Feldern, wodurch der verschobene Frame auf einen einzigen Zeitraum beschränkt wird und das Vergleichsmaß NULL ergibt.

Jedes andere Feld erhält keine range: all-Spezifikation. Ein Feld, das unabhängig vom Index ist, wie region, wird normal gruppiert, und das Fenster wird pro Wert partitioniert.

Aufeinanderfolgender Vergleich oder gleitendes Fenster (Index plus numerischer Bereich)

Verwenden Sie einen Index mit numerischem Offset oder Bereich, wenn Sie „benachbart in der Reihenfolge“ meinen, z. B. den vorherigen Zeitraum, rollierende N Zeiträume oder den Zeitraum bis dato. Ordnen Sie nach dem Index, wenden Sie einen numerischen Versatz oder Bereich an und fügen Sie für jede Kalenderspalte, von der der Index abhängt, eine range: all-Spezifikation hinzu. Im folgenden Beispiel hängt der Index von order_year und order_monthab:

version: 1.1
source: samples.tpch.orders

fields:
  - name: order_year
    expr: YEAR(o_orderdate) # INT breakdown column
  - name: order_month
    expr: MONTH(o_orderdate) # INT breakdown column
  - name: month_index # consecutive monotonic index across years
    expr: order_year * 12 + order_month

measures:
  - name: monthly_sales
    expr: SUM(o_totalprice)
    window:
      - order: order_year # breakdown, so range: all keeps GROUP BY order_year working
        range: all
      - order: order_month # breakdown
        range: all
      - order: month_index # the axis you compare along
        range: current

  - name: monthly_sales_prev # previous month: same specs plus a unitless offset of -1 on the index
    expr: SUM(o_totalprice)
    window:
      - order: order_year
        range: all
      - order: order_month
        range: all
      - order: month_index
        range: current
        offset: -1 # one position back, crosses the year boundary correctly

  - name: sales_trailing_3mo # rolling 3 months: unitless range on the index
    expr: SUM(o_totalprice)
    window:
      - order: order_year
        range: all
      - order: order_month
        range: all
      - order: month_index
        range: trailing 3 # the three index positions before the current month

  - name: mom_pct_change
    expr: (MEASURE(monthly_sales) - MEASURE(monthly_sales_prev))
      / NULLIF(MEASURE(monthly_sales_prev), 0) * 100

In diesem Beispiel gilt die folgende Konfiguration:

• month_index ist ein aufeinanderfolgender monotoner Index, der jeden Monat über Jahresgrenzen hinweg um 1 steigt.
• monthly_sales ordnet im Index mit range: current und gibt den Aufschlüsselungsspalten order_year und order_month eine range: all-Spezifikation, damit die Gruppierung danach funktioniert.
• monthly_sales_prev Fügt offset: -1 zum Index hinzu, um einen Monat zurückzublicken, wodurch die Jahresgrenze korrekt überschritten wird.
• sales_trailing_3mo verwendet den einheitslosen Bereich, trailing 3 um drei Indexpositionen zu summieren. Da der Index aufeinanderfolgend ist, entspricht drei Positionen drei Monaten, ohne Zeit-Einheiten-Arithmetik zu verwenden. Dies setzt voraus, dass für jeden Monat im Bereich eine Quellzeile vorhanden ist. Wenn ein Monat fehlt, lässt sich das Fenster nicht mehr eindeutig drei Kalendermonaten zuordnen. Verdichten Sie daher die Quelldaten zu einem vollständigen Satz von Zeiträumen, wenn Lücken möglich sind. Der Bereich ist standardmäßig auf exclusive gesetzt, sodass er die drei Monate vor dem aktuellen Monat umfasst. Fügen Sie inclusive hinzu, um stattdessen den aktuellen Monat einzubeziehen.
• mom_pct_change komponiert die Grund- und verschobenen Takte. Die Verwendung von NULLIF vermeidet Division-durch-Null-Fehler, wenn der vorherige Wert null ist.

Fragen Sie die Messung ab, indem Sie nach den ausgerichteten Aufschlüsselungsspalten gruppieren, nicht nach dem rohen Index:

SELECT
  order_year,
  order_month,
  MEASURE(monthly_sales),
  MEASURE(monthly_sales_prev),
  MEASURE(sales_trailing_3mo),
  MEASURE(mom_pct_change)
FROM catalog.schema.monthly_sales_mv
GROUP BY ALL

Gleiche Position in einem vorherigen Zyklus (zwei Fensterspezifikationen, kein Index)

Ein Vergleich wie "derselbe Monat im letzten Jahr" ist nach Position ausgerichtet, nicht nach absoluter Entfernung, daher benötigt er keine Indexspalte. Verwenden Sie zwei Fensterspezifikationen: eine verschiebt den übergeordneten Zyklus, und eine fixiert die innere Position.

version: 1.1
source: samples.tpch.orders

fields:
  - name: order_year
    expr: YEAR(o_orderdate)
  - name: order_month
    expr: MONTH(o_orderdate)

measures:
  - name: monthly_sales
    expr: SUM(o_totalprice)

  - name: monthly_sales_py # same month, prior year
    expr: SUM(o_totalprice)
    window:
      - order: order_year # shift the year coordinate
        range: current
        offset: -1
      - order: order_month # hold the month fixed
        range: current

  - name: yoy_pct_change
    expr: (MEASURE(monthly_sales) - MEASURE(monthly_sales_py))
      / NULLIF(MEASURE(monthly_sales_py), 0) * 100

In diesem Beispiel gilt die folgende Konfiguration:

• monthly_sales_py Verwendet zwei Fensterspezifikationen. Die Spezifikation order_year verschiebt die Jahreskoordinate mit offset: -1 um eins nach hinten, und die Spezifikation order_month hält die Monatskoordinate mit range: current fest.
• Der Vergleich richtet sich nach Position aus, daher benötigt er keine Indexspalte.
• yoy_pct_change setzt die beiden Messgrößen zusammen, um die prozentuale Veränderung darzustellen.

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

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.
• Das Maß lässt semiadditive aus, also verwendet es den Standardwert last. Das Maß liefert den aktuellsten kumulativen Wert zurück, wenn date nicht in der GROUP BY der Abfrage enthalten ist, anstatt über alle Datumswerte 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
      - order: year
        range: current

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. last ist der Standardwert, daher kannst du diese Zeile weglassen. Verwenden Sie stattdessen semiadditive: first , um den frühesten Saldo zurückzugeben.

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