Widoki metryk modelu

Widoki metryk tworzą semantyczną warstwę dla danych, przekształcając tabele i widoki w ustandaryzowane metryki biznesowe. Definiują, co należy mierzyć, jak je agregować i jak go segmentować. W związku z tym każdy użytkownik w organizacji raportuje tę samą wartość dla tego samego kluczowego wskaźnika wydajności, co eliminuje niespójne raportowanie i umożliwia elastyczną analizę we wszystkich polach.

Zdefiniowane składniki to źródła, sprzężenia, filtry, pola i miary.

Aby zapoznać się z pełnym przykładem sprzężeń, pól, miar i metadanych agenta, zobacz Samouczek: tworzenie widoku metryk z sprzężeniami i modelowaniem danych.

Podstawowe składniki

Widok metryki składa się z następujących elementów:

Składnik	Description	Example
Source	Tabela podstawowa, widok lub zapytanie SQL zawierające dane.	samples.tpch.orders
łączy się z	Relacje między tabelami, widokami i widokami metryk w celu wzbogacania danych.	Łączenie orders tabeli z tabelą customers na customer_key
Filtry	Warunki zastosowane do danych źródłowych w celu zdefiniowania zakresu.	status = 'completed' order_date > '2024-01-01'
Fields	Kolumny używane do grupowania, filtrowania i agregowania metryk. Zawiera kolumny podzielone na kategorie i nieagregowane kolumny liczbowe. Nazywane także wymiarami.	Kategoria produktu, Miesiąc zamówienia, Cena jednostkowa
Środki	Agregacje kolumn, które generują metryki.	COUNT(o_orderkey) as Order Count (Liczba zamówień) SUM(o_totalprice) jako Total Revenue (Łączny przychód)

Definiowanie źródła

Możesz użyć elementu zawartości podobnej do tabeli lub zapytania SQL jako źródła widoku metryki. Musisz mieć co najmniej SELECT uprawnienia do dowolnego elementu zawartości, do którego odwołuje się odwołanie.

Zasób podobny do tabeli to dowolny obiekt Unity Catalog, który udostępnia schemat tabelaryczny i obsługuje SELECT zapytania, w tym tabele, widoki, widoki zmaterializowane, tabele przesyłania strumieniowego, tabele zewnętrzne, tabele systemowe i widoki miar.

Używanie elementu zawartości podobnej do tabeli jako źródła

Aby użyć elementu zawartości podobnej do tabeli jako źródła, określ w pełni kwalifikowaną nazwę. Przykład: samples.tpch.orders.

Używanie widoku metryki jako źródła

Możesz użyć istniejącego widoku metryki jako źródła dla nowego widoku metryki:

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`))"

W przypadku używania widoku metryk jako źródła obowiązują te same zasady kompozycji dotyczące odwołań do pól i miar. Zobacz Kompozycyjność.

Używanie zapytania SQL jako źródła

Aby użyć zapytania SQL, napisz tekst zapytania bezpośrednio w pliku 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)

Note

W przypadku używania zapytania SQL jako źródła z klauzulą JOIN, ustaw ograniczenia klucza podstawowego i obcego na tabelach bazowych i użyj opcji RELY dla optymalnej wydajności zapytań. Zobacz Deklarowanie klucza podstawowego, klucza obcego i unikatowych ograniczeń oraz Optymalizacja zapytań przy użyciu klucza podstawowego i unikatowych ograniczeń.

Rozwiązuj tablice i mapy w źródle

Pola, miary i łączenia działają na płaskich, skalarnych kolumnach. Jeśli twoje dane źródłowe mają lub zawierają ARRAY kolumny typu lub MAP są w nich kolumny, rozwiąż je do płaskich kolumn w zapytaniu source przed odniesieniem się do nich gdzie indziej w widoku metryki. Istnieją dwie strategie transformacji, w zależności od tego, czy chcesz mieć jeden wiersz na element tablicy, czy jedną wartość na wiersz źródłowy. Oba mają zastosowanie niezależnie od tego, czy tablica znajduje się w obrocie źródłowym na najwyższym poziomie, czy w tabeli, do której się łączy. Zobacz Transform złożonych typów danych dla pełnego zestawu funkcji transformacji.

Żaden zbiór danych w katalogu samples nie ma kolumny tablicy, więc przykłady w tej sekcji używają widoku orders zawierającego tablicę line_items struktur. Użyj poniższego przykładu, aby stworzyć widok z polem będącym tablicą. Zamień catalog.schema katalog i schemat, do którego chcesz pisać. Musisz mieć uprawnienia do tworzenia obiektów w tym schemiacie.

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;

Spłaszcz tablicę na wiersze

Aby przeanalizować każdy element tablicy jako osobny wiersz, użyj explode() w zapytaniu source do rozpakowania tablicy. Każdy element staje się osobnym wierszem, a pozostałe kolumny wiersza źródłowego powtarzają się dla każdego elementu. Zobacz Exploduj zagnieżdżone elementy z mapy lub tablicy.

Poniższy przykład rozkłada tablicę line_items tak, że każdy element staje się wierszem:

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)

Eksplodowanie tablicy w mnoży source wiersze źródłowe, więc agregacja taka jak liczy COUNT(1) elementy tablicy, a nie oryginalne wiersze. Aby również zmierzyć oryginalne wiersze bez rozlewania się, zamodeluj wybuchniętą tabelę jako połączenie one_to_many . Zobacz sprzężenia jeden do wielu.

Zagreguj tablicę do jednej wartości

Aby zredukować tablicę do jednej wartości na wiersz źródłowy bez zmiany liczby wierszy, zastosuj w zapytaniu source funkcję tablicy skalarnej, taką jak aggregate(), array_size(), lub reduce(). Każdy wiersz źródłowy zachowuje swoje ziarno, a obliczona kolumna jest dostępna dla pól i miar.

Poniższy przykład oblicza liczbę elementów i całkowitą ilość tablicy line_items na zamówienie:

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)

Ponieważ zapytanie źródłowe zmniejsza tablicę zanim widok metryczny ją przetworzy, źródło zachowuje jeden wiersz na każde zamówienie i mierzy agregację między zamówieniami jak zwykle.

Rozwiązuj tablicę w połączonej tabeli

Ta sama zasada dotyczy tabeli, do której chcesz dołączyć, a nie w kodzie najwyższego poziomu. Łączenie działa na płaskich kolumnach, więc rozwiązuje tablicę w podzapytaniu połączonej tabeli source przed połączeniem. Zapisz join source jako zapytanie SQL, które spłaszcza lub agreguje tablicę, a następnie łącz na uzyskanych kolumnach. Zobacz Połączenia w widokach metrycznych.

Poniższy przykład używa customer jako źródła i łączy orders widok z .cardinality: one_to_many Join source agreguje tablicę każdego zamówienia line_items do skalaru total_quantity przed połączeniem, dzięki czemu widok metryki może sumować ją dla każdego klienta bez dublowania wierszy klienta:

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)

Aby zamiast tego traktować każdy element tablicy jako osobny wiersz w tablicy połączonej, spłaszcz tablicę z w explode() połączeniu source w ten sam sposób. Zobacz Spłaszcz tablicę na wiersze.

Pola

Pola, nazywane również wymiarami, to kolumny w widoku metryk, których można używać w klauzulach SELECT, WHERE i GROUP BY podczas wykonywania zapytania. Pole może być kolumną kategorii, taką jak region lub stan, albo nieagregowana kolumna liczbowa, taka jak cena lub ilość, którą można agregować w czasie zapytania. Każde wyrażenie pola musi zwracać wartość skalarną. Może odwoływać się do kolumn z danych źródłowych lub pól zdefiniowanych wcześniej w widoku metryki. Każde pole składa się z dwóch składników:

• name: alias kolumny
• expr: Wyrażenie SQL, które odwołuje się do danych źródłowych lub wcześniej zdefiniowanych pól w widoku metryki

Warning

Pola widoku metryk typu ciąg znaków są zawsze STRING, nawet jeśli kolumna źródłowa ma typ CHAR lub VARCHAR. Ponieważ CHAR(n) wypełnienie spacji jest utracone, porównania mogą zwracać różne wyniki. Na przykład column = 'COLLEGE' odpowiada wartości CHAR(10) w tabeli źródłowej (która jest dopełniona spacjami), ale nie w polu widoku danych.

Środki

Miary to wyrażenia, które generują wyniki bez wstępnie określonego poziomu agregacji. Muszą być wyrażane przy użyciu funkcji agregujących. Aby odwołać się do miary w zapytaniu, użyj MEASURE funkcji . Miary mogą odwoływać się do kolumn bazowych w danych źródłowych, wcześniej zdefiniowanych polach lub wcześniej zdefiniowanych miarach. Każda miara składa się z następujących składników:

• name: alias miary
• expr: agregujące wyrażenie SQL, które może zawierać funkcje agregujące SQL

W poniższym przykładzie przedstawiono typowe wzorce miar do analizowania danych zamówień i przychodów. W tych przykładach użyto tabeli zamówień TPC-H, która zawiera dane transakcji sprzedaży, w tym ceny zamówień (), identyfikatory klientów (o_totalprice), klucze zamówień (o_custkeyo_orderkey), daty zamówienia (o_orderdate) i poziomy priorytetów (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))

Zobacz Funkcje agregujące , aby uzyskać listę funkcji agregujących.

Stosowanie filtrów

Filtr dotyczy wszystkich zapytań odwołujących się do widoku metryki. Aby zdefiniować filtr w interfejsie użytkownika, zobacz Krok 3. Definiowanie filtru.

Aby zdefiniować filtr w definicji YAML, napisz wyrażenie logiczne. W poniższym przykładzie przedstawiono typowe wzorce filtrów:

# 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'

Praca z sprzężeniami

Widoki metryk obsługują łączenia, aby wzbogacić dane źródłowe o atrybuty z powiązanych tabel. Można modelować schematy gwiazdy (tabela faktów połączona z tabelami wymiarów), schematy śnieżynki (wielopoziomowe połączenia tabel wymiarów) oraz relacje jeden do wielu (rozszerzanie tabeli faktów na podstawie źródła wymiarowego). Aby uzyskać szczegółowe informacje na temat typów sprzężeń, kardynalności, wzorców schematu i ograniczeń, zobacz Sprzężenia w widokach metryk.

Aby zdefiniować sprzężenia w interfejsie użytkownika, zobacz Krok 2: Dodawanie sprzężenia. Aby zdefiniować sprzężenia w definicji YAML, użyj wzorców w poniższych sekcjach.

Note

Połączone tabele nie mogą zawierać ARRAY ani MAP typować kolumn. Aby rozwiązywać tablice lub mapy na płaskie kolumny przed połączeniem, zobacz Resolve arrays and maps in the source.

Modele schematów gwiazdy

W schemacie gwiazdy tabela faktów source łączy się z jedną lub więcej tabel wymiarów przy użyciu LEFT OUTER JOIN. Widoki metryk łączą tabele faktów i wymiarów potrzebne dla określonego zapytania na podstawie wybranych pól i miar.

Określ kolumny łączenia za pomocą klauzuli on (wyrażenie logiczne) lub klauzuli using (wspólne nazwy kolumn). Złączenie musi odpowiadać relacji wiele do jednego. W przypadku relacji wiele do wielu silnik wybiera pierwszy pasujący wiersz z połączonej tabeli wymiarów.

Poniższy przykład łączy (tabelę faktów orders ) z customer (tabelą wymiarów) i uwidacznia atrybuty klienta jako pola. Ustawienie rely.at_most_one_match: true określa, że połączenie jest relacją wiele do jednego (każde zamówienie ma dokładnie jednego klienta), co umożliwia silnikowi optymalizację zapytań filtrujących według pól z dołączonej tabeli.

Warning

Ustaw at_most_one_match: true tylko wtedy, gdy relacja jest typu wiele do jednego. Ta właściwość nie jest weryfikowana w czasie wykonywania. Jeśli sprzężenia generuje fan-out, miary zwracają nieprawidłowe wyniki.

Zobacz Optymalizacja sprzężeń za pomocą 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)

Składnia i formatowanie YAML

Definicje widoku metryki są zgodne ze standardową składnią notacji YAML. Aby uzyskać wymaganą składnię i formatowanie, zobacz Dokumentację składni YAML widoku metryk .

Najlepsze rozwiązania

Podczas modelowania widoków metryk użyj następujących wytycznych:

• Podstawowe miary modelu: najpierw zdefiniuj najprostsze miary (na przykład SUM(revenue), COUNT(DISTINCT customer_id)). Tworzenie złożonych miar przy użyciu możliwości kompilowania.
• Ustandaryzuj wartości pól: użyj przekształceń (takich jak CASE instrukcje), aby przekonwertować kody bazy danych na jasne nazwy biznesowe (na przykład przekonwertować stan zamówienia "O" na "Otwarte" i "F" na "Spełnione").
• Zdefiniuj zakres z filtrami: jeśli widok metryki powinien zawierać tylko ukończone zamówienia, zdefiniuj ten filtr w widoku metryki, aby użytkownicy nie mogli przypadkowo uwzględnić niekompletnych danych.
• Użyj jasnego nazewnictwa: nazwy metryk powinny być rozpoznawalne dla użytkowników biznesowych (na przykład "Wartość okresu istnienia klienta" zamiast cltv_agg_measure).
• Oddzielne pola czasu: uwzględnij szczegółowe pola czasu (takie jak "Data zamówienia") i obcięte pola czasu (takie jak "Miesiąc zamówienia" lub "Tydzień zamówienia"), aby włączyć zarówno szczegółowe analizy na poziomie szczegółowości, jak i analizy trendów.

Dodatkowe zasoby

• Złączenia w widokach metryk
• Zaawansowane techniki widoków metryk
• Metadane agenta w widokach metryk
• Materializacja widoków metryk
• Dokumentacja składni YAML dla widoku metryk