Visualizzazioni delle metriche del modello

Le visualizzazioni delle metriche creano un livello semantico per i dati, trasformando tabelle e viste in metriche aziendali standardizzate. Definiscono cosa misurare, come aggregarlo e come segmentarlo. Di conseguenza, ogni utente dell'organizzazione segnala lo stesso valore per lo stesso indicatore KPI, eliminando la creazione di report incoerenti e abilitando l'analisi flessibile in tutti i campi.

I componenti principali definiti sono origini, join, filtri, campi e misure.

Per un esempio completo con join, campi, misure e metadati dell'agente, vedere Esercitazione: creare una visualizzazione delle metriche con join e modellazione dei dati.

Componenti di base

Una visualizzazione metrica è costituita dagli elementi seguenti:

Definire un'origine

È possibile usare un asset simile a una tabella o una query SQL come origine per la visualizzazione delle metriche. Devi avere almeno SELECT privilegi su qualsiasi asset a cui si fa riferimento.

Un asset simile a una tabella è qualsiasi oggetto di Unity Catalog che espone uno schema tabulare e supporta SELECT query, incluse tabelle, viste, viste materializzate, tabelle di streaming, tabelle esterne, tabelle di sistema e viste metriche.

Usare un asset simile a una tabella come origine

Per usare un asset simile a una tabella come origine, specificare il nome completo. Ad esempio: samples.tpch.orders.

Usare una visualizzazione metrica come origine

È possibile usare una visualizzazione metrica esistente come origine per una nuova visualizzazione metrica:

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

Quando si usa una visualizzazione metrica come origine, si applicano le stesse regole di componibilità per i campi e le misure di riferimento. Vedere Componibilità.

Usare una query SQL come origine

Per usare una query SQL, scrivere il testo della query direttamente in 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)

Campi

I campi, detti anche dimensioni, sono colonne della vista metrica che è possibile usare nelle clausole SELECT, WHERE e GROUP BY in fase di esecuzione della query. Un campo può essere una colonna categorica, ad esempio area o stato, o una colonna numerica non raggruppata, ad esempio prezzo o quantità, che è possibile aggregare in fase di query. Ogni espressione di campo deve restituire un valore scalare. Può fare riferimento a colonne dai dati o dai campi di origine definiti in precedenza nella visualizzazione metrica. Ogni campo è costituito da due componenti:

• name: alias della colonna
• expr: espressione SQL che fa riferimento ai dati di origine o ai campi definiti in precedenza nella visualizzazione metrica

Misure

Le misure sono espressioni che producono risultati senza un livello di aggregazione predeterminato. Devono essere espressi usando funzioni di aggregazione. Per fare riferimento a una misura in una query, usa MEASURE. Le misure possono fare riferimento a colonne di base nei dati di origine, nei campi definiti in precedenza o in misure definite in precedenza. Ogni misura è costituita dai componenti seguenti:

• name: l'alias della misura
• expr: espressione SQL aggregata che può includere funzioni di aggregazione SQL

Nell'esempio seguente vengono illustrati i modelli di misura comuni per l'analisi dei dati relativi a ordini e ricavi. Questi esempi usano la tabella TPC-H orders, che contiene i dati delle transazioni di vendita, inclusi i prezzi degli ordini (o_totalprice), gli identificatori dei clienti (), le chiavi ordine (o_custkeyo_orderkey), le date dell'ordine (o_orderdate) e i livelli di priorità (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))

Vedere Funzioni di aggregazione per un elenco di funzioni di aggregazione.

Applicare filtri

Un filtro si applica a tutte le query che fanno riferimento alla visualizzazione metrica. Per definire un filtro nell'interfaccia utente, vedere Passaggio 3: Definire un filtro.

Per definire un filtro nella definizione YAML, scrivere un'espressione booleana. L'esempio seguente mostra modelli di filtro comuni:

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

Lavorare con i join

Le visualizzazioni delle metriche supportano join per arricchire i dati di origine con attributi di tabelle correlate. È possibile modellare schemi a stella (tabella dei fatti unita a tabelle delle dimensioni), schemi a fiocco di neve (join tra dimensioni su più livelli) e relazioni uno-a-molti (espansione della tabella dei fatti a partire da una fonte dimensionale). Per informazioni dettagliate su tipi di join, cardinalità, modelli di schema e restrizioni, vedere Join nelle visualizzazioni delle metriche.

Per definire i join nell'interfaccia utente, vedere Passaggio 2: Aggiungere un join. Per definire join nella definizione YAML, usare i modelli nelle sezioni seguenti.

Schemi stella modello

In uno schema a stella, source è la tabella dei fatti e si collega a una o più tabelle delle dimensioni utilizzando un LEFT OUTER JOIN. Le visualizzazioni delle metriche si uniscono alle tabelle dei fatti e delle dimensioni necessarie per la query specifica, in base ai campi e alle misure selezionati.

Specificare le colonne join usando una on clausola (espressione booleana) o una using clausola (nomi di colonna condivisa). Il join deve basarsi su una relazione da molti a uno. In caso di molti-a-molti, il motore seleziona la prima riga corrispondente dalla tabella delle dimensioni unita.

L'esempio seguente unisce orders (tabella dei fatti) a customer (tabella delle dimensioni) ed espone gli attributi del cliente come campi. L'impostazione rely.at_most_one_match: true dichiara che il join è molti a uno (ogni ordine ha esattamente un cliente), consentendo al motore di ottimizzare le query che applicano filtri ai campi della tabella oggetto del join.

Vedi Ottimizzare i join con 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)

Sintassi e formattazione YAML

Le definizioni di visualizzazione delle metriche seguono la sintassi di notazione YAML standard. Vedere Informazioni di riferimento sulla sintassi YAML per la visualizzazione delle metriche per la sintassi e la formattazione necessarie.

Procedure consigliate

Usare le linee guida seguenti per la modellazione delle visualizzazioni delle metriche:

• Misure atomiche del modello: iniziare definendo prima le misure più semplici (ad esempio SUM(revenue), COUNT(DISTINCT customer_id)). Creare misure complesse usando la componibilità.
• Standardizzare i valori dei campi: utilizzare trasformazioni (ad esempio, le istruzioni CASE) per convertire i codici del database in denominazioni aziendali chiare (ad esempio, convertire lo stato dell'ordine 'O' in 'Open' e 'F' in 'Fulfilled').
• Definire l'ambito con i filtri: se una visualizzazione delle metriche deve includere solo gli ordini completati, definire tale filtro nella visualizzazione delle metriche in modo che gli utenti non possano includere accidentalmente dati incompleti.
• Usare la denominazione chiara: i nomi delle metriche devono essere riconoscibili per gli utenti aziendali (ad esempio, "Customer Lifetime Value" invece di cltv_agg_measure).
• Campi ora separati: includere campi ora granulari (ad esempio "Data ordine") e campi di ora troncati (ad esempio "Mese ordine" o "Settimana ordine") per abilitare sia l'analisi a livello di dettaglio che di tendenza.

Risorse aggiuntive

• Join nelle visualizzazioni delle metriche
• Tecniche avanzate per le visualizzazioni delle metriche
• Metadati dell'agente nelle visualizzazioni delle metriche
• Materializzazione per le visualizzazioni delle metriche
• Informazioni di riferimento sulla sintassi YAML per la visualizzazione delle metriche