Materializzazione per le visualizzazioni delle metriche

La materializzazione per le visualizzazioni delle metriche accelera le query usando viste materializzate per pre-calcolare le aggregazioni. Le pipeline di Lakeflow orchestrano le viste materializzate definite dall'utente per una determinata visualizzazione delle metriche. In fase di esecuzione della query, l’ottimizzatore delle query indirizza le query alla vista materializzata più adatta utilizzando la corrispondenza automatica delle query basata sugli aggregati (riscrittura delle query). È possibile eseguire una query sulla visualizzazione delle metriche come di consueto, senza ulteriori operazioni manuali. Databricks aggiorna le materializzazioni per mantenerle aggiornate. Sceglie anche quale materializzazione interrogare per query più rapide a costi inferiori.

Funzionamento della materializzazione

La materializzazione per le visualizzazioni delle metriche prevede due fasi: la definizione della materializzazione e l'esecuzione di query su di essa.

Fase di definizione

Quando si definisce una visualizzazione delle metriche con materializzazione, si specificano i campi, le misure e la pianificazione dell'aggiornamento nella visualizzazione delle metriche YAML. Da tale definizione, Databricks crea una pipeline Lakeflow gestita che compila e gestisce le viste materializzate.

In questo modo la definizione della metrica viene separata dalla modalità di archiviazione:

• La visualizzazione delle metriche è un oggetto Catalogo Unity che definisce i campi, le misure e i join della metrica, insieme alla configurazione della materializzazione (pianificazione e granularità). È l'unica fonte di verità per ciò che significa la metrica.
• La pipeline materializza tale definizione in una o più viste materializzate, ognuna calcolata in base a una granularità specifica. Databricks sceglie quale leggere al momento della query.

Esecuzione della query

Quando si esegue SELECT ... FROM <metric_view>, Query Optimizer usa la riscrittura delle query con riconoscimento dell'aggregazione per ottimizzare le prestazioni:

• Percorso veloce: legge da viste materializzate pre-calcolate quando è disponibile una materializzazione adeguata.
• Percorso di fallback: legge direttamente dai dati di origine quando non è disponibile alcuna materializzazione appropriata.

Query Optimizer bilancia automaticamente le prestazioni e l'aggiornamento scegliendo tra dati materializzati e di origine. I risultati vengono visualizzati in modo trasparente indipendentemente dal percorso usato dall'ottimizzatore. Per ulteriori informazioni su come eseguire query sulle viste delle metriche, consulta Eseguire query sulle viste delle metriche.

Requisiti

Per usare la materializzazione per le visualizzazioni delle metriche:

• L'area di lavoro deve avere il calcolo serverless abilitato. Questo è necessario per eseguire le pipeline Lakeflow.
• Una risorsa di calcolo o di sql warehouse che esegue Databricks Runtime 17.3 o versione successiva.

Informazioni di riferimento sulla configurazione

La materializzazione viene configurata in un campo di primo livello materialization nella definizione YAML della visualizzazione delle metriche. Questo campo imposta la riscrittura mode della query (sempre relaxed), un aggiornamento schedulefacoltativo e un elenco di materialized_views da gestire. Ogni vista materializzata è aggregated, che esegue il pre-calcolo di dimensioni e misure specifiche o unaggregated, che materializza il modello di dati completo.

Per la specifica completa campo per campo, inclusi i campi obbligatori e facoltativi, i valori consentiti e le restrizioni della clausola schedule, consulta Materializzazione.

Definizione di esempio

L'esempio seguente definisce una visualizzazione delle metriche con una materializzazione non raggruppata e due materializzazioni aggregate:

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

La materializzazione revenue_breakdown utilizza cluster_by e partition_by per controllare come i dati materializzati sono disposti fisicamente, allo stesso modo delle clausole CLUSTER BY e PARTITION BY su una vista materializzata. Per la specifica completa del campo, vedere Materializzazione.

CREATE OR REPLACE VIEW catalog.schema.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - name: category
      expr: substring(category, 5)

    - name: color
      expr: color

  measures:
    - name: total_revenue
      expr: SUM(revenue)

    - name: number_of_suppliers
      expr: COUNT(DISTINCT supplier_id)

  materialization:
    schedule: every 6 hours
    mode: relaxed

    materialized_views:
      - name: baseline
        type: unaggregated

      - name: revenue_breakdown
        type: aggregated
        dimensions:
          - category
          - color
        measures:
          - total_revenue

      - name: suppliers_by_category
        type: aggregated
        dimensions:
          - category
        measures:
          - number_of_suppliers
$$

Modalità riscrittura query

Nella modalità relaxed, la riscrittura automatica delle query verifica solo se le viste materializzate candidate dispongono dei campi e delle misure necessari per soddisfare la query.

I controlli seguenti vengono ignorati:

• Aggiornamento: non verifica che la materializzazione sia aggiornata.
• Impostazioni SQL: non verifica che le impostazioni, TIMEZONE ad esempio o ANSI_MODE corrispondano.
• Determinismo: non verifica che i risultati materializzati siano completamente deterministici.

Le query che corrispondono a una materializzazione utilizzano l'ultimo aggiornamento. Le query che non trovano corrispondenza ricorrono alla fonte e restituiscono dati in tempo reale. Di conseguenza, la freschezza dei dati può variare a seconda che una query possa essere riscritta. Per garantire la coerenza, allinea la pianificazione dell'aggiornamento della materializzazione alla pipeline di origine. Ad esempio, se i dati di origine si aggiornano ogni giorno con una pipeline batch, pianifica gli aggiornamenti della materializzazione in modo che vengano eseguiti dopo il completamento della pipeline. In alternativa, utilizzare una materializzazione non aggregata per garantire che tutte le query leggano dallo stesso snapshot.

Non è possibile creare una materializzazione quando viene usata la visualizzazione metrica o una delle relative tabelle di origine:

• Sicurezza a livello di riga (RLS), mascheramento a livello di colonna (CLM) o criteri ABAC. I risultati pre-calcolati possono ignorare i controlli di accesso per utente che devono essere applicati in fase di query.
• Espressioni dipendenti dal invoker, il cui risultato cambia in base all'utente che esegue la query (ad esempio, current_user() o is_member()). Una materializzazione viene pre-calcolata una volta e condivisa, quindi la gestione a un utente diverso restituirà risultati non corretti o non sicuri.

Databricks convalida questa restrizione quando si crea, si modifica o si aggiorna una materializzazione. Queste operazioni hanno esito negativo con la condizione METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED di errore (SQLSTATE 42K0E). Vedere METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Tipi di materializzazioni per le visualizzazioni delle metriche

Le sezioni seguenti illustrano i tipi di viste materializzate disponibili per le visualizzazioni delle metriche e forniscono indicazioni sulla selezione della configurazione appropriata per le origini dati e i modelli di query.

Tipo aggregato

Questo tipo pre-calcola le aggregazioni per le combinazioni di misure e campi specificate per la copertura mirata.

Utilizzare un tipo aggregato quando sono presenti combinazioni di dimensioni e misure specifiche su cui viene eseguita una query di frequente. Con le materializzazioni aggregate, si applicano sia strategie di corrispondenza esatta che di corrispondenza cumulativa , offrendo le migliori prestazioni delle query per tali modelli.

Per le aggregazioni ottimali:

• Includere le dimensioni più usate nelle GROUP BY clausole.
• Includere eventuali colonne di filtro potenziali (colonne usate in WHERE in fase di query).
• Materializza al livello di dettaglio più elevato richiesto dalle tue query. Ad esempio, una materializzazione in (region, sku, event_day) può soddisfare tutto quanto segue:
  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku con WHERE region = 'US'
• Evita dimensioni così granulari da produrre gruppi composti per lo più da una sola riga, ad esempio un timestamp grezzo con precisione al millisecondo. Questo non ha alcun vantaggio e gonfia lo spazio di archiviazione.
• Prestare attenzione alle misure non additive. Le misure non additivi non possono essere riaggregate dai risultati parziali (ad esempio, COUNT(DISTINCT), MEDIANe percentili) e richiedono una corrispondenza esatta con una materializzazione.

Una singola aggregazione può soddisfare solo query che corrispondono esattamente alle sue dimensioni specifiche (corrispondenza esatta) oppure a un sottoinsieme delle sue dimensioni (corrispondenza rollup). Databricks consiglia di creare più materializzazioni aggregate per forme di query diverse.

Tipo non raggruppato

Questo tipo materializza l'intero modello di dati non aggregato (i campi source, joins, filter e fields) per una copertura più ampia con un impatto minore sulle prestazioni rispetto al tipo aggregato.

Usare un tipo non raggruppato quando si verifica una delle condizioni seguenti:

• La vista delle metriche comporta trasformazioni o join costosi sui dati di origine.
• I modelli di query sono imprevedibili o vari.
• Tutti gli utenti che eseguono query sulla visualizzazione delle metriche devono visualizzare la coerenza all'interno dei dati.

Con materializzazioni non raggruppate, le viste di origine costose e i join vengono calcolati una sola volta all'aggiornamento anziché in ogni query. Quando esistono materializzazioni aggregate e non aggregate, Databricks calcola le materializzazioni aggregate da quella non raggruppata. Ciò fornisce un'istantanea coerente ed evita il ricalcolo ridondante della sorgente. Una corrispondenza non aggregata è sempre ammissibile, a prescindere dalla struttura della query, fatte salve le limitazioni descritte in Modalità di riscrittura della query.

Una materializzazione non raggruppata non è utile quando l'origine è un riferimento diretto alla tabella senza un filtro selettivo. In tal caso, non offre alcun vantaggio rispetto a interrogare direttamente la fonte.

Per altre indicazioni su come e quando usare questi tipi di materializzazione, vedere Scegliere un tipo di materializzazione per le visualizzazioni delle metriche.

Riscrittura automatica delle query

Quando esegui una query su una vista metrica, la riscrittura delle query indirizza automaticamente la query verso la migliore materializzazione disponibile. Usa tre strategie di riscrittura delle query: corrispondenza esatta, corrispondenza rollup e corrispondenza non raggruppata.

La query viene eseguita automaticamente sulla materializzazione migliore anziché sulle tabelle di base usando questo algoritmo:

1. In primo luogo, Query Optimizer tenta una corrispondenza esatta.
2. Se non esiste una corrispondenza esatta, l'ottimizzatore di query tenta una corrispondenza aggregata.
3. Se non esiste alcuna corrispondenza di rollup e esiste una materializzazione non raggruppata, Query Optimizer prova una corrispondenza non raggruppata.
4. Se non è presente alcuna corrispondenza non raggruppata, la query legge direttamente dalle tabelle di origine.

Le sezioni seguenti illustrano il funzionamento di ogni strategia.

Corrispondenza esatta

La query richiede esattamente ciò che è stato precalcolato nella materializzazione. La riscrittura della query legge il risultato archiviato senza lavoro aggiuntivo, consentendo risultati rapidi.

Per qualificarsi per la corrispondenza esatta:

• Le espressioni della GROUP BY query devono corrispondere esattamente alle dimensioni di materializzazione.
• Le misure della query devono essere un sottoinsieme delle misure della materializzazione.

Ad esempio, una materializzazione ha dimensioni [region, order_date] e misure [total_revenue, order_count]. Una query che raggruppa per region e order_date e richiede total_revenue corrisponde esattamente, perché le dimensioni sono le stesse e la misura è stata precalcolata.

Corrispondenza rollup

La query richiede un riepilogo a un livello più grossolano rispetto a quello già calcolato. L'ottimizzatore legge il risultato precalcolato e lo aggrega nuovamente fino al livello richiesto dalla query.

Per qualificarsi per la partita di rollup:

• Granularità più grossolana: la query raggruppa per un numero inferiore di dimensioni o per una granularità temporale più ampia rispetto alla materializzazione.
• Tutte le misure sono additivi: ogni misura richiesta dalla query deve essere una che può essere ricompiuta correttamente combinando risultati parziali (ad esempio, SUM di SUMo MAX di MAXes). MEDIAN non può essere aggregato perché dipende dalla distribuzione del gruppo.
• Tutti i filtri partecipanti devono essere espressioni deterministiche: se la query ha una WHERE clausola , il filtro deve sempre produrre lo stesso risultato per lo stesso input. Ad esempio, WHERE region = 'US' è deterministico, ma le espressioni come rand() o uuid() no.

La corrispondenza rollup non è applicabile alle misure non additive, poiché non possono essere riaggregate correttamente a partire da risultati parziali. Vedere Misure additive.

Ad esempio, usando la stessa materializzazione con dimensioni [region, order_date] e misure [total_revenue, order_count], una query che raggruppa solo per region e richiede total_revenue costituisce una corrispondenza rollup. La query richiede meno dimensioni rispetto a quelle materializzate, quindi il motore aggrega i totali giornalieri in totali a livello di regione.

Misure aggregabili

Una misura è aggiuntiva se il risultato aggregato può essere ricalcolate correttamente aggregando le materializzazioni aggregate esistenti. Questo è il requisito fondamentale per l'abbinamento dei rollup.

Qualsiasi aggregazione che utilizza DISTINCT (ad esempio, COUNT(DISTINCT), SUM(DISTINCT)) non è additiva e non può essere aggregata.

Le funzioni seguenti sono additive:

• SUM
• COUNT
• MIN
• MAX
• BIT_AND
• BIT_OR
• BIT_XOR
• BOOL_AND
• BOOL_OR

Le restrizioni aggiuntive si applicano alle misure aggiuntive:

• La definizione della misura deve contenere esattamente una funzione di aggregazione. Una misura la cui definizione combina più aggregazioni (ad esempio, sum(cost) + min(revenue)) non è idonea per la corrispondenza di rollup.
• Se la definizione della misura include una FILTER clausola , deve essere deterministica.
• La misura non può essere una misura basata su finestra, ad esempio un totale mobile su 7 giorni o un confronto anno su anno definito con un blocco finestra.

Corrispondenza non raggruppata

La query non corrisponde ad alcuna aggregazione pre-calcolata, ma il lavoro di preparazione costoso (join e filtri) è già stato eseguito. La riscrittura della query inizia dal set di dati preparato della materializzazione non raggruppata anziché tornare alle tabelle di origine.

Se esiste una materializzazione non raggruppata, questa strategia è sempre idonea come fallback prima di passare all'origine. Qualsiasi struttura della query può usarla, nel rispetto delle restrizioni descritte in Modalità di riscrittura delle query.

Ad esempio, la query viene raggruppata per category e richiede unique_customers, ma nessuna materializzazione aggregata include tali campi e misure. Tuttavia, esiste una materializzazione non aggregata con il set di dati unito e filtrato già pronto. L'ottimizzatore di query legge da quel set di dati preparato ed esegue GROUP BY category, COUNT(DISTINCT customer_id) al momento della query, invece di eseguire nuovamente da zero il join delle tabelle non elaborate.

Verificare se una query utilizza viste materializzate

Esistono due modi per verificare se una query usa una vista materializzata:

• Esegui EXPLAIN EXTENDED sulla query per visualizzare il piano di esecuzione della query. Se è stata utilizzata la materializzazione, il nodo foglia include __materialization_mat_<pipeline ID>___metric_view_mat_ e il nome della materializzazione presente nel file YAML.
• Osserva il profilo della query, come illustrato di seguito.

Ciclo di vita della materializzazione

In questa sezione viene illustrato come vengono create, gestite e aggiornate le materializzazioni durante il ciclo di vita.

Creare e modificare

Quando si crea o si modifica una visualizzazione metrica (usando CREATE, ALTERo Esplora cataloghi), la visualizzazione delle metriche viene aggiornata immediatamente. Le viste materializzate vengono aggiornate in modo asincrono in background usando una pipeline gestita.

Per definire una nuova materializzazione nell'editor di Catalog Explorer:

1. Fare clic su Materializzazioni.
2. Fare clic su Pianifica per impostare una pianificazione. È possibile selezionare un periodo di intervallo o impostare la materializzazione da eseguire in un momento specifico.
3. Selezionare un tipo. Per visualizzazione metrica è consentita una sola materializzazione non raggruppata. Per altre informazioni, vedere Tipi di materializzazioni per le visualizzazioni delle metriche.
4. Usare l'elenco a discesa Campi per selezionare i campi da includere nella materializzazione.
5. Usare l'elenco a discesa Misure per selezionare le misure da includere.

Quando si crea una visualizzazione delle metriche, Databricks crea una pipeline Lakeflow e pianifica immediatamente un aggiornamento iniziale se sono presenti viste materializzate specificate. La vista metrica rimane interrogabile senza materializzazioni ricorrendo all'interrogazione sui dati di origine.

Quando si modifica una visualizzazione delle metriche, Databricks non pianifica nuovi aggiornamenti, a meno che non si abiliti la materializzazione per la prima volta. Le viste materializzate non vengono usate per la riscrittura automatica delle query fino al completamento dell'aggiornamento pianificato successivo.

La modifica della pianificazione della materializzazione non attiva un aggiornamento.

Senza una pianificazione, la pipeline esegue un aggiornamento iniziale al momento della creazione, ma gli aggiornamenti successivi devono essere avviati manualmente, altrimenti i dati diventano obsoleti. Databricks consiglia sempre di definire una pianificazione in modo che i dati rimangano aggiornati, a meno che non si eseguano test o prototipi.

Vedere Aggiornamento manuale per un controllo più corretto sul comportamento di aggiornamento.

Esaminare la pipeline sottostante

La materializzazione per le viste metriche è implementata tramite le pipeline Lakeflow. È possibile accedere alla pipeline in due modi:

• In Esplora cataloghi: la scheda Panoramica per la visualizzazione delle metriche include un collegamento diretto sotto l'intestazione Pianificazione aggiornamenti . Per informazioni su come accedere a Esplora cataloghi, vedere Informazioni su Esplora cataloghi.
• Uso di SQL: eseguire DESCRIBE EXTENDED. La sezione Aggiorna informazioni contiene il collegamento alla pipeline e lo stato di aggiornamento corrente.

DESCRIBE EXTENDED my_metric_view;

Output di esempio:

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

Aggiornamento manuale

Dal collegamento alla pagina della pipeline Lakeflow è possibile avviare manualmente un aggiornamento della pipeline per aggiornare le materializzazioni. È anche possibile attivare un aggiornamento manuale usando il comando SQL seguente:

REFRESH MATERIALIZED VIEW <metric-view-name>

Aggiornamento incrementale

Le viste materializzate usano l'aggiornamento incrementale quando possibile e presentano le stesse limitazioni delle viste materializzate standard relative alle origini dati e alla struttura del piano.

Per informazioni dettagliate sui prerequisiti e sulle restrizioni, vedere Aggiornamento incrementale per le viste materializzate.

Billing

L'aggiornamento delle viste materializzate comporta costi di utilizzo per le pipeline Lakeflow. Per trovare il consumo DBU della pipeline, vedere Qual è il consumo DBU di una pipeline serverless?.

Restrizioni note

Le restrizioni seguenti si applicano alla materializzazione per le visualizzazioni delle metriche:

• Non è possibile materializzare una visualizzazione metrica che definisce i parametri.
• Dopo aver creato una materializzazione per una visualizzazione metrica, non è possibile modificare il proprietario.
• Databricks non supporta la proprietà del gruppo delle visualizzazioni metriche materializzate.
• Solo la strategia di corrispondenza esatta è idonea per le visualizzazioni delle metriche con join uno-a-molti.