Zaawansowane techniki widoków metryk

Zaawansowane techniki widoków metryk umożliwiają wyrażanie złożonej logiki biznesowej i ponowne używanie definicji w warstwie semantycznej. Na tej stronie opisano dwie takie techniki:

• Miary okna: do obliczeń szeregów czasowych, takich jak średnie ruchome, sumy bieżące i zmiany międzyokresowe.
• Kompilowanie: tworzenie złożonych miar przez odwoływanie się do innych miar zamiast ponownego pisania ich logiki.

Na tej stronie przyjęto założenie, że masz znajomość podstawowych zasad modelowania widoku metryki. Zobacz Widoki metryk modelu.

Miary okien

Miary okienne umożliwiają definiowanie miar za pomocą agregacji okiennych, kumulacyjnych lub częściowoaddytywnych w widokach metryk. Obsługują obliczenia, takie jak średnie ruchome, zmiany okresu w okresie i sumy bieżące.

Miarę okna można dodać w edytorze Eksploratora wykazu lub w języku YAML.

Dodawanie miary okna w edytorze

Na karcie UI w edytorze widoku metryki kliknij + Okno podczas edycji miary. + Okno jest dostępne zarówno w trybie Builder, jak i Custom. Opcje okna w edytorze odpowiadają polam YAML opisanym w sekcji Definiowanie miary okna.

Aby uzyskać więcej informacji na temat tworzenia i edytowania miar, zobacz Tworzenie widoku metryki.

Definiowanie miary okna

Miara okna zawiera następujące wymagane pola:

• order: pole określające kolejność okna.

• zakres: definiuje zakres okna. Obsługiwane wartości obejmują current, , cumulative, trailingleading, i all. Zakres trailing lub leading przyjmuje jednostkę czasu w polu daty lub znacznika czasu order, na przykład trailing 7 day, albo nie przyjmuje żadnej jednostki w kolumnie kolejnych liczb całkowitych order, na przykład trailing 3. Aby uzyskać pełną składnię i opisy, zobacz Obsługiwane range wartości. Szczegółowe informacje na temat modyfikatorów inclusive i exclusive dla trailing i leading można znaleźć w sekcji Uwzględnianie lub wykluczanie wiersza kotwicy.

Miara okna czasowego obsługuje także następujące opcjonalne pola:

• semiadditive: określa sposób agregowania miary, gdy pole zamówienia nie jest uwzględnione w kwerendzie GROUP BY. Możliwe wartości: first i last. Wartość domyślna to last.

• offset: Przesuwa ramę okna do tyłu lub do przodu wzdłuż order pola o stałą wartość. Na polu daty lub znacznika czasu order użyj przesunięcia daty, takiego jak -12 month, dla miar porównujących kolejne okresy, takich jak miesiąc do miesiąca lub rok do roku. Użyj numerycznego przesunięcia bez jednostki, na przykład -1, w kolejnej kolumnie liczb całkowitych order, aby porównywać w obrębie okresu biznesowego, który nie jest datą kalendarzową. Aby uzyskać informacje o składni, obsługiwanych jednostkach i ograniczeniach, zobacz Miary okien.

Możesz także odwołać się do parametru całkowitoliczbowego jako wartości range lub offset miary okna, dzięki czemu element wywołujący może przekazać rozmiar okna w momencie wykonywania zapytania. Zobacz Przekazywanie rozmiaru okna jako parametru.

Jak offset przesuwa ramkę okna

Zobacz Dostępność funkcji widoku danych metryk, aby sprawdzić minimalne wymagania dotyczące zasobów obliczeniowych i wersji specyfikacji YAML.

Pole range określa kształt okna względem wiersza kotwicy, a offset przesuwa tę ramkę o określony interwał wzdłuż order. Poniższa tabela przedstawia przedział dla każdej wartości range z i bez wartości offset równej k, względem wiersza zakotwiczenia t:

offset jest niezależny od semiadditive. Opcja first lub last nadal kontroluje sposób zwijania miary, gdy order nie znajduje się w zapytaniu GROUP BY.

Aby uzyskać najlepsze wyniki, dopasuj offset do naturalnego orderziarna . W przypadku danych miesięcznych preferowane jest offset: -12 month zamiast offset: -365 day, ponieważ arytmetyka miesięcy i lat uwzględnia miesiące o różnej długości oraz lata przestępne, podczas gdy arytmetyka day tego nie uwzględnia.

Uwzględnianie lub wykluczanie wiersza zakotwiczenia

Zobacz Dostępność funkcji widoku danych metryk, aby sprawdzić minimalne wymagania dotyczące zasobów obliczeniowych i wersji specyfikacji YAML.

W przypadku zakresów trailing i leading opcjonalne słowo kluczowe inclusive lub exclusive określa, czy wartość okna dla wiersza zakotwiczenia (na przykład dzisiaj) jest częścią okna kroczącego:

Poniższy przykład pokazuje, jak inclusive i exclusive wpływają na okno kroczące dla daty odniesienia 2025-01-05 z użyciem trailing 3 day.

Załóżmy, że dane bazowe mają jeden wiersz dziennie z następującymi wartościami:

Każdy modyfikator wybiera wiersze z trzech dni względem punktu odniesienia i sumuje ich wartości:

leading zakresy działają według tej samej logiki, ale w przeciwnym kierunku.

Przykład miary okna końcowego, ruchomego lub przesuwnego

W poniższym przykładzie obliczana jest 7-dniowa liczba klientów, którzy składali zamówienia. Ta metryka śledzi trendy zaangażowania klientów w czasie, pokazując, ile różnych klientów dokonało zakupów w tygodniu poprzedzającym każdą datę.

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

W tym przykładzie stosowana jest następująca konfiguracja:

• order: date określa, że date pole porządkuje okno.
• range: trailing 7 day definiuje okno jako 7 dni przed każdą datą, z wyłączeniem samej daty.
• Miara pomija semiadditive, więc używa domyślnej last wartości i zwraca ostatnią wartość w 7-dniowym oknie, gdy date nie jest kolumną grupującą.

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
$$

Przykład miary okna okresowego

Poniższy przykład oblicza wzrost sprzedaży w ciągu dnia, porównując dzisiejszy przychód (sumę wszystkich cen zamówień) do wczorajszego przychodu. Ta metryka identyfikuje dzienne trendy sprzedaży i pokazuje procentową zmianę przychodu.

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

W tym przykładzie stosowana jest następująca konfiguracja:

• W przykładzie użyto dwóch miar okiennych: jednej do obliczania łącznej sprzedaży z poprzedniego dnia i jednej dla bieżącego dnia.
• Trzecia miara oblicza zmianę procentową (wzrost) między bieżącymi i poprzednimi dniami.

Przykład miary okna rok do roku przy użyciu offset

Modyfikator offset jest blokiem konstrukcyjnym miar okresowych. Zdefiniuj przesuniętą kopię miary podstawowej, a następnie połącz te dwie miary, aby bezpośrednio w widoku metryki wyrazić różnice, współczynniki lub wskaźniki wzrostu.

Poniższy przykład oblicza wzrost sprzedaży rok do roku, porównując sprzedaż każdego miesiąca z tym samym miesiącem w poprzednim roku. Przesunięta miara używa funkcji offset: -12 month, aby cofnąć się o 12 miesięcy w polu month.

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)

W tym przykładzie stosowana jest następująca konfiguracja:

• monthly_sales to miara podstawowa, sumując sprzedaż w bieżącym miesiącu.
• monthly_sales_py jest tą samą miarą przesuniętą do tyłu o 12 miesięcy za pomocą funkcji offset: -12 month. W styczniu 2025 r. zwraca wartość dla stycznia 2024 r.
• yoy_growth i yoy_growth_pct stanowią dwie wartości służące do wyrażenia zmiany bezwzględnej i zmiany procentowej. Użycie NULLIF metody pozwala uniknąć błędów dzielenia przez zero, gdy wartość poprzedniego roku jest równa zero.

Miary okienkowe na kolumnie indeksu numerycznego

Wymaga Databricks Runtime 19 lub wyższego oraz specyfikacji YAML w wersji 1.1 lub wyższej.

Element opatrzony datą offset, taki jak -12 month kroki w kolumnie daty lub znacznika czasu. Kolumna daty już nie pasuje, gdy oś porównawcza to okres biznesowy, który nie jest datą kalendarzową. Tygodnie fiskalne, tygodnie ISO oraz okresy rozliczeniowe 4-4-5 to przykłady. Zamiast tego uporządkuj miarę okna według kolumny indeksu całkowitego i zastosuj wartość liczbową bez jednostki offset lub range. Przesunięcie numeryczne wykonuje arytmetykę całkowitą na indeksie, czyli offset: -1 oznacza poprzednią pozycję w sekwencji, a range: trailing 3 oznacza trzy ostatnie pozycje.

Numeryczne przesunięcie lub zakres zwraca poprawny wynik tylko wtedy, gdy kolumna order spełnia wszystkie następujące wymagania. Tylko pierwsze wymaganie jest weryfikowane w czasie zapytania. Kolumna, która łamie którąkolwiek z pozostałych dwóch, zwraca błędne liczby, a nie błąd, więc zwerfikuj je samodzielnie:

• Całkowita: Kolumna to TINYINT, SMALLINT, INT lub BIGINT. DATE, TIMESTAMP, DECIMAL, DOUBLE, , oraz STRING kolumny nie są prawidłowymi kolumnami indeksowymi. Aby porównać według daty, użyj zamiast tego wersji z datą offset. Zobacz Jak offset przesuwa ramkę okna.
• Monotoniczna i ciągła (gęsta): Wartość zwiększa się dokładnie o 1 z jednego rzeczywistego okresu na następny, również na granicy roku lub kwartału. Przerwa lub powtarzająca się wartość powoduje, że offset: -1 pomija okres lub zlicza go podwójnie. Surowa etykieta, taka jak taka fiscal_week , która resetuje się do 1 każdego roku, sama w sobie nie jest ważnym indeksem.
• Dopasowane do poziomu porównania: Przesunięcie lub kroki zakresu są zgodne z poziomem indeksu. Na indeksie offset: -1 miesięcznym to poprzedni miesiąc, a range: trailing 3 to ostatnie trzy miesiące. Dla bardziej grubszego porównania, takiego jak rok do roku, należy zamówić osobną miarę na indeksie rocznym lub użyć miary o tej samej pozycji w poprzednim cyklu. Nie używaj ponownie bardziej szczegółowego indeksu (miesięcznego) i nie grupuj. Zobacz Ta sama pozycja w poprzednim cyklu (dwie specyfikacje okna, bez indeksu).

Pobierz kolumnę indeksu

Możesz nazwać wstępnie obliczoną kolumnę indeksu ze źródła lub wyprowadzić ją w widoku metryki. Przepis zależy od kształtu kalendarza:

Wyrównaj wymiary, od których zależy indeks

Nadaj range: all specyfikację kolejności każdemu polu widoku metryki, na podstawie którego obliczany jest indeks, na przykład order_year oraz order_month dla month_index = order_year * 12 + order_month. Dotyczy to niezależnie od tego, czy indeks jest wyprowadzany w widoku metrycznym, czy jest wstępnie obliczany jako goła kolumna. Specyfikacja range: all powoduje, że pola te są ignorowane podczas tworzenia okien, zgodnie z zamierzeniem, gdy zapytanie grupuje według tych pól lub je filtruje.

Te specyfikacje nie są opcjonalne. Bez nich zapytanie, które grupuje według order_year lub order_month, dzieli okno według tych pól, co ogranicza przesuniętą ramkę do jednego okresu, a miara porównawcza zwraca NULL.

Każde inne pole nie ma specyfikacji range: all. Pole niezależne od indeksu, takie jak region, jest grupowane normalnie, a okno jest partycjonowane według wartości.

Kolejne porównanie lub okno przesuwające (indeks plus zakres liczbowy)

Użyj indeksu z przesunięciem liczbowym lub zakresem, gdy masz na myśli „sąsiadujący w sekwencji”, na przykład poprzedni okres, ruchome N okresów lub okres od początku do dziś. Uporządkuj indeks, zastosuj przesunięcie numeryczne lub zakres i dodaj specyfikację range: all dla każdej kolumny kalendarzowej, od której indeks zależy. W poniższym przykładzie indeks zależy od order_year i order_month:

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

W tym przykładzie stosowana jest następująca konfiguracja:

• month_index jest kolejnym wskaźnikiem monotonicznym, który wzrasta o 1 każdego miesiąca w granicach roku.
• monthly_sales porządkuje w indeksie za pomocą range: current i nadaje kolumnom order_year oraz order_month podziału specyfikację range: all, tak aby grupowanie według nich działało.
• monthly_sales_prev dodaje offset: -1 do indeksu, aby cofnąć się o jeden miesiąc, prawidłowo uwzględniając przekroczenie granicy roku.
• sales_trailing_3mo używa zakresu trailing 3 bezjednostkowego do sumowania trzech pozycji indeksowych. Ponieważ indeks jest kolejny, trzy pozycje to trzy miesiące, bez uwzględnienia arytmetyki jednostki czasu. Zakłada to, że każdy miesiąc w danym zakresie ma wiersz źródłowy. Jeśli brakuje miesiąca, okno nie daje się już jednoznacznie przyporządkować do trzech miesięcy kalendarzowych, więc zagęść dane źródłowe do pełnego zestawu okresów, jeśli mogą występować luki. Domyślnie zakres to exclusive, więc obejmuje trzy miesiące przed bieżącym miesiącem. Dodaj inclusive, aby zamiast tego uwzględnić bieżący miesiąc.
• mom_pct_change tworzy miarę bazową i miary przesunięte. Użycie NULLIF unika błędów dzielenia przez zero, gdy wartość poprzednia wynosi zero.

Wykonaj zapytanie względem miary, grupując według dopasowanych kolumn podziału, a nie według surowego indeksu:

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

Ta sama pozycja w poprzednim cyklu (dwie specyfikacje okien, brak indeksu)

Porównanie takie jak "ten sam miesiąc w zeszłym roku" jest wyrównane według pozycji, a nie odległości absolutnej, więc nie wymaga kolumny indeksu. Użyj dwóch specyfikacji okien: jedna przesuwa cykl nadrzędny, a druga utrzymuje pozycję wewnętrzną.

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

W tym przykładzie stosowana jest następująca konfiguracja:

• monthly_sales_py używa dwóch specyfikacji okien. Parametr order_year cofa wartość roku o jeden za pomocą offset: -1, a parametr order_month utrzymuje miesiąc na stałym poziomie za pomocą range: current.
• Porównanie jest dopasowywane według pozycji, więc nie wymaga kolumny indeksowej.
• yoy_pct_change składa dwie miary wyrażające procentową zmianę.

Przykład skumulowanej (bieżącej) miary

Poniższy przykład oblicza skumulowany przychód ze sprzedaży od początku zestawu danych do każdej daty. Ta suma bieżąca pokazuje, ile całkowitego przychodu zostało wygenerowane w czasie, co jest przydatne do śledzenia postępów w kierunku rocznych celów przychodów lub analizowania długoterminowych wzorców wzrostu.

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

W tym przykładzie stosowana jest następująca konfiguracja:

• order: date porządkuje okno chronologicznie.
• range: cumulative Definiuje okno jako wszystkie dane od początku zestawu danych do i włącznie z każdą datą.
• Miara pomija semiadditive, więc używa domyślnej wartości last. Miara zwraca najnowszą wartość skumulowaną, gdy date nie jest uwzględniona w zapytaniu GROUP BY, zamiast sumować dla wszystkich dat.

Przykład miary okres-data

W poniższym przykładzie oblicza się przychód ze sprzedaży od początku roku (YTD). Ta miara pokazuje skumulowany przychód wygenerowany od 1 stycznia każdego roku do bieżącej daty, resetując na początku każdego nowego roku.

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

W tym przykładzie stosowana jest następująca konfiguracja:

• W przykładzie użyto dwóch specyfikacji okna: jednej dla sumy skumulowanej dla pola date, a drugiej, aby ograniczyć sumę do roku current.
• Pole year ogranicza sumę skumulowaną tak, aby była resetowane na początku każdego nowego roku.
• Pola month i year tworzą hierarchię dat w polu zamówienia: każda z nich jest definiowana w date polu datewedług nazwy, a nie w kolumnie bazowejo_orderdate, dzięki czemu zapytania mogą grupować tę miarę według nich. Zobacz Grupowanie według pola hierarchii dat.

Przykład miary semiaddytywnej

W poniższym przykładzie obliczane są salda kont, które nie mogą być sumowane między datami (nie można dodać salda poniedziałkowego do wtorkowego salda w celu uzyskania łącznego salda). Zamiast tego, podczas agregowania danych z wielu dni, metryka zwraca najnowsze saldo. Jednak wskaźnik może być nadal sumowany dla klientów, aby pokazać łączne saldo wszystkich kont w danym dniu.

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

W tym przykładzie stosowana jest następująca konfiguracja:

• order: date porządkuje okno chronologicznie.
• range: current ogranicza okno do jednego dnia, bez agregacji między dniami.
• semiadditive: last Zwraca najnowsze saldo w przypadku agregowania w ciągu wielu dni. last jest wartością domyślną, więc możesz pominąć tę linię. Użyj semiadditive: first, aby wrócić do najwcześniejszego salda.

Zapytanie miary okna

Możesz wykonać zapytanie o widok metryk z miarą okna tak jak o każdy inny widok metryk. Miara okna jest obliczana wzdłuż pola order , więc zapytanie, które dzieli wyniki w czasie, musi odwoływać się do tego pola bezpośrednio lub za pośrednictwem zdefiniowanego pola hierarchii dat. Gdy zapytanie nie odwołuje się do pola order, słowo kluczowe semiadditive określa zwracaną wartość, jak opisano w przykładzie miary semiaddytywnej.

Poniższy przykład grupuje miarę okna według state i według wyrażenia miesiąca w polu datezamówienia:

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

Grupuj według pola hierarchii dat

Hierarchia dat agreguje pole kolejności do mniej szczegółowych poziomów, takich jak tydzień, miesiąc lub rok. Zdefiniuj każdy poziom jako pole w polu zamówienia według nazwy, a nie w bazowej kolumnie źródłowej:

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)

Grupowanie miary okna analitycznego według poziomu hierarchii zwraca miarę na tym poziomie szczegółowości. Przy założeniu, że przykład „okres do daty” został utworzony jako ytd_metric_view, tak jak w przykładzie miary „Okres do daty”, następujące zapytanie zwraca wartość YTD na ostatnią datę w każdym miesiącu:

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

Składalność

Widoki metryk są komponowalne. Możesz tworzyć nowe pola i miary odwołujące się do istniejących, a nie zapisywać logiki od podstaw. Zmniejsza to duplikację i ułatwia utrzymanie złożonych definicji metryk.

Kompozycyjność działa na dwóch poziomach: w obrębie pojedynczego widoku metryki oraz między widokami metryk, gdy jeden widok metryki jest używany jako źródło dla innego widoku.

Komposability obsługuje następujące wzorce referencyjne:

• Poprzednie pola w nowych polach.
• Pola i wcześniejsze miary w nowych miarach.
• Pola z widoków metryk używane jako źródło w nowych polach.
• Pola i miary z widoków metrycznych używane jako źródło w nowych miarach.

Definiowanie miar z komponowalnością

measures W sekcji można odwoływać się do miar z widoku metryki źródłowej lub miar zdefiniowanych wcześniej w tym samym widoku metryki. Takie podejście zwiększa spójność, inspekcję i konserwację warstwy semantycznej.

Przykład: Średnia wartość zamówienia (AOV)

W poniższym przykładzie zdefiniowano średnią wartość zamówienia (AOV) przy użyciu dwóch miar niepodzielnych: total_revenue (suma cen zamówień) i order_count (liczba zamówień). Miara avg_order_value odwołuje się do obu miar atomowych.

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)

total_revenue Jeśli definicja zmieni się (na przykład w celu wykluczenia podatku), avg_order_value automatycznie użyje zaktualizowanej definicji.

Kompozycyjność z logiką warunkową

Komponowanie umożliwia tworzenie złożonych współczynników, wartości procentowych warunkowych i współczynników wzrostu bez polegania na funkcjach okienkowych do prostych obliczeń z okresu na okres.

Przykład: wskaźnik realizacji

W poniższym przykładzie obliczana jest stopa realizacji: procent zamówień ze stanem 'F' (spełniony). Miara dzieli zamówienia spełnione przez łączną liczbę zamówień.

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

Najlepsze rozwiązania dotyczące komponowania

1. Najpierw zdefiniuj miary niepodzielne: ustanów podstawowe miary (SUM, COUNT, AVG) przed zdefiniowaniem miar odwołujących się do nich.
2. Użyj funkcji dla odwołań: użyj MEASURE()MEASURE() funkcji podczas odwoływania się do innej miary w elemencie expr. Nie powtarzaj logiki agregacji ręcznie. Na przykład należy unikać SUM(a) / COUNT(b) , jeśli miary dla obu wartości już istnieją.
3. Określanie priorytetów czytelności: Tworzenie miar przy użyciu przejrzystych formuł matematycznych. Na przykład MEASURE(gross_profit) / MEASURE(total_revenue) jest jaśniejsze niż pojedyncze złożone wyrażenie SQL.
4. Dodawanie metadanych semantycznych: użyj metadanych semantycznych do formatowania miar złożonych (na przykład wartości procentowych lub waluty) dla narzędzi podrzędnych. Zobacz Metadane agenta w widokach metryk.

Dodatkowe zasoby

• Widoki metryk modelu
• Metadane agenta w widokach metryk
• Materializacja widoków metryk
• Dokumentacja składni YAML dla widoku metryk