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)

Risolvi array e mappe nella sorgente

Campi, misure e giunzioni operano tutti su colonne piatte e scalari. Se i dati di origine includono colonne di tipo ARRAY o MAP, risolvile in colonne piatte nella query source prima di farvi riferimento altrove nella vista delle metriche. Ci sono due strategie di trasformazione, a seconda che tu voglia una riga per ogni elemento dell'array o un singolo valore per riga sorgente. Entrambe si applicano sia che l'array sia nella sorgente di primo livello sia in una tabella a cui ti unisci. Vedi Trasformare tipi di dati complessi per l'intero insieme delle funzioni di trasformazione.

Nessun set di dati nel catalogo samples ha una colonna di tipo array, quindi gli esempi in questa sezione utilizzano una vista orders che ha un array line_items di struct. Usa il seguente esempio per creare una vista con un campo che è un array. Sostituisci catalog.schema con il catalogo e lo schema su cui vuoi scrivere. Devi avere i permessi per creare oggetti in quello schema.

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;

Appiattisci un array in più righe

Per analizzare ogni elemento dell'array come una riga a sé stante, usa explode() nella query source per scompattare l'array. Ogni elemento diventa una riga separata, e le altre colonne della riga sorgente si ripetono per ciascun elemento. Vedi Espandere elementi annidati da una mappa o da un array.

Il seguente esempio smonta l'array line_items in modo che ogni elemento diventi una riga:

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)

L'espansione dell'array nell'source moltiplica le righe di origine, quindi un'aggregazione come COUNT(1) conta gli elementi dell'array, non le righe originali. Per misurare anche le righe originali senza fan-out, considera invece la tabella esplosa come un join one_to_many. Consultare join da uno a molti.

Aggregare un array in un unico valore

Per ridurre un array a un valore per riga sorgente senza cambiare il conteggio delle righe, applica una funzione scalare nell'array source , come aggregate(), array_size(), o reduce(). Ogni riga di origine mantiene il proprio livello di granularità e la colonna calcolata è disponibile per i campi e le misure.

Il seguente esempio calcola il numero degli elementi e la quantità totale dell'array line_items per ordine:

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)

Poiché la query di origine riduce l'array prima che la vista delle metriche lo elabori, la query di origine mantiene una riga per ogni ordine e le misure vengono aggregate tra gli ordini come di consueto.

Risolvere un array in una tabella giunta

La stessa regola si applica quando l'array si trova in una tabella a cui vuoi unirti, non nella fonte di primo livello. Un join opera su colonne piatte, quindi espandi l'array nella subquery source della tabella sottoposta a join prima del join. Scrivi la join source come query SQL che espanda o aggreghi l'array, quindi esegui la join sulle colonne risultanti. Vedi Unioni nelle viste metriche.

Il seguente esempio usa customer come sorgente e unisce la orders vista con cardinality: one_to_many. Il join source aggrega l'array line_items di ciascun ordine in uno scalare total_quantity prima del join, così la vista delle metriche può sommarlo per cliente senza duplicare le righe dei clienti:

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)

Per trattare invece ogni elemento dell'array come una riga distinta nella tabella risultante dal join, appiattire l'array con explode() nell'operazione di join source allo stesso modo. Vedi Convertire un array in righe.

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. Un campo supporta i seguenti componenti:

• name: Opzionale su Databricks runtime 19 e superiori. Alias della colonna. Se omesso, Azure Databricks deriva il nome da expr.
• expr:Obbligatorio. Un'espressione SQL che fa riferimento ai dati sorgente o ai campi precedentemente definiti nella vista metrica.

Su Databricks runtime 19 e superiori, expr: source.o_orderstatus produce il nome o_orderstatus. Vedi Derivare nomi di colonne dalle espressioni per regole di denominazione e requisiti.

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. Una misura supporta i seguenti componenti:

• name: Opzionale su Databricks runtime 19 e superiori. L'alias della misura. Se omesso, Azure Databricks deriva il nome da expr.
• expr:Obbligatorio. Un'espressione SQL aggregata che può includere funzioni aggregate SQL.

Su Databricks runtime 19 e superiori, expr: SUM(o_totalprice) produce il nome SUM(o_totalprice). Vedi Derivare nomi di colonne dalle espressioni per regole di denominazione e esempi di query.

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