Crea viste materializzate
Questo documento descrive come creare viste materializzate in BigQuery. Prima di leggere questo documento, acquisisci familiarità con l'Introduzione alle viste materializzate.
Prima di iniziare
Concedi i ruoli IAM (Identity and Access Management) che forniscono agli utenti le autorizzazioni necessarie per eseguire ogni attività in questo documento.
Autorizzazioni obbligatorie
Per creare viste materializzate, devi disporre dell'autorizzazione IAM bigquery.tables.create.
Ciascuno dei seguenti ruoli IAM predefiniti include le autorizzazioni necessarie per creare una vista materializzata:
bigquery.dataEditorbigquery.dataOwnerbigquery.admin
Per saperne di più su Identity and Access Management (IAM) di BigQuery, consulta Controllo degli accessi con IAM.
Crea viste materializzate
Per creare una vista materializzata, seleziona una delle seguenti opzioni:
SQL
Utilizza l'istruzione CREATE MATERIALIZED VIEW.
L'esempio seguente crea una vista materializzata per il numero di clic per ogni ID prodotto:
Nella console Google Cloud , vai alla pagina BigQuery.
Nell'editor di query, inserisci la seguente istruzione:
CREATE MATERIALIZED VIEW PROJECT_ID.DATASET.MATERIALIZED_VIEW_NAME AS ( QUERY_EXPRESSION );
Sostituisci quanto segue:
PROJECT_ID: il nome del progetto in cui vuoi creare la vista materializzata, ad esempiomyproject.DATASET: il nome del set di dati BigQuery in cui vuoi creare la vista materializzata, ad esempiomydataset. Se stai creando una vista materializzata su una tabella BigLake di Amazon Simple Storage Service (Amazon S3) (anteprima), assicurati che il set di dati si trovi in una regione supportata.MATERIALIZED_VIEW_NAME: il nome della vista materializzata che vuoi creare, ad esempiomy_mv.QUERY_EXPRESSION: l'espressione di query GoogleSQL che definisce la vista materializzata, ad esempioSELECT product_id, SUM(clicks) AS sum_clicks FROM mydataset.my_source_table.
Fai clic su Esegui.
Per saperne di più su come eseguire le query, consulta Esegui una query interattiva.
Esempio
L'esempio seguente crea una vista materializzata per il numero di clic per ogni ID prodotto:
CREATE MATERIALIZED VIEW myproject.mydataset.my_mv_table AS ( SELECT product_id, SUM(clicks) AS sum_clicks FROM myproject.mydataset.my_base_table GROUP BY product_id );
Terraform
Utilizza la risorsa google_bigquery_table.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configura l'autenticazione per le librerie client.
L'esempio seguente crea una visualizzazione denominata my_materialized_view:
Per applicare la configurazione Terraform in un progetto Google Cloud , completa i passaggi descritti nelle sezioni seguenti.
Prepara Cloud Shell
- Avvia Cloud Shell.
-
Imposta il progetto Google Cloud predefinito in cui vuoi applicare le configurazioni Terraform.
Devi eseguire questo comando una sola volta per progetto e puoi eseguirlo in qualsiasi directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Le variabili di ambiente vengono sostituite se imposti valori espliciti nel file di configurazione Terraform.
Prepara la directory
Ogni file di configurazione Terraform deve avere la propria directory (chiamata anche modulo principale).
-
In Cloud Shell, crea una directory e un nuovo file al suo interno. Il nome file deve avere l'estensione
.tf, ad esempiomain.tf. In questo tutorial, il file è denominatomain.tf.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
Se stai seguendo un tutorial, puoi copiare il codice campione in ogni sezione o passaggio.
Copia il codice campione nel file
main.tfappena creato.Facoltativamente, copia il codice da GitHub. Questa opzione è consigliata quando lo snippet Terraform fa parte di una soluzione end-to-end.
- Esamina e modifica i parametri di esempio da applicare al tuo ambiente.
- Salva le modifiche.
-
Inizializza Terraform. Devi eseguire questa operazione una sola volta per directory.
terraform init
Facoltativamente, per utilizzare l'ultima versione del provider Google, includi l'opzione
-upgrade:terraform init -upgrade
Applica le modifiche
-
Esamina la configurazione e verifica che le risorse che Terraform creerà o aggiornerà corrispondano alle tue aspettative:
terraform plan
Apporta le correzioni necessarie alla configurazione.
-
Applica la configurazione Terraform eseguendo il comando seguente e inserendo
yesal prompt:terraform apply
Attendi che Terraform visualizzi il messaggio "Apply complete!".
- Apri il tuo progetto Google Cloud per visualizzare i risultati. Nella console Google Cloud , vai alle risorse nell'interfaccia utente per assicurarti che Terraform le abbia create o aggiornate.
API
Chiama il metodo tables.insert e trasmetti una risorsa Table con un campo materializedView definito:
{ "kind": "bigquery#table", "tableReference": { "projectId": "PROJECT_ID", "datasetId": "DATASET", "tableId": "MATERIALIZED_VIEW_NAME" }, "materializedView": { "query": "QUERY_EXPRESSION" } }
Sostituisci quanto segue:
PROJECT_ID: il nome del progetto in cui vuoi creare la vista materializzata, ad esempiomyproject.DATASET: il nome del set di dati BigQuery in cui vuoi creare la vista materializzata, ad esempiomydataset. Se stai creando una vista materializzata su una tabella BigLake di Amazon Simple Storage Service (Amazon S3) (anteprima), assicurati che il set di dati si trovi in una regione supportata.MATERIALIZED_VIEW_NAME: il nome della vista materializzata che vuoi creare, ad esempiomy_mv.QUERY_EXPRESSION: l'espressione di query GoogleSQL che definisce la vista materializzata, ad esempioSELECT product_id, SUM(clicks) AS sum_clicks FROM mydataset.my_source_table.
Esempio
L'esempio seguente crea una vista materializzata per il numero di clic per ogni ID prodotto:
{ "kind": "bigquery#table", "tableReference": { "projectId": "myproject", "datasetId": "mydataset", "tableId": "my_mv" }, "materializedView": { "query": "select product_id,sum(clicks) as sum_clicks from myproject.mydataset.my_source_table group by 1" } }
Java
Prima di provare questo esempio, segui le istruzioni di configurazione di Java nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery Java.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configura l'autenticazione per le librerie client.
Dopo aver creato la vista materializzata, questa viene visualizzata nel riquadro Explorer di BigQuery nella console Google Cloud . L'esempio seguente mostra lo schema di una vista materializzata:
A meno che non disattivi l'aggiornamento automatico, BigQuery avvia un aggiornamento completo asincrono per la vista materializzata. La query termina rapidamente, ma l'aggiornamento iniziale potrebbe continuare a essere eseguito.
Controllo degli accessi
Puoi concedere l'accesso a una vista materializzata a livello di set di dati, a livello di vista o a livello di colonna. Puoi anche impostare l'accesso a un livello superiore nella gerarchia delle risorse IAM.
Per eseguire query su una vista materializzata, è necessario l'accesso alla vista e alle relative tabelle di base. Per condividere una vista materializzata, puoi concedere le autorizzazioni alle tabelle di base o configurare una vista materializzata come vista autorizzata. Per saperne di più, consulta Visualizzazioni autorizzate.
Limitazioni del controllo degli accessi
Se la query di un utente su una vista materializzata include colonne della tabella di base a cui non può accedere a causa della sicurezza a livello di colonna, la query non va a buon fine e viene visualizzato il messaggio
Access Denied.Se un utente esegue una query su una vista materializzata, ma non ha accesso completo a tutte le righe delle tabelle di base della vista materializzata, BigQuery esegue la query sulle tabelle di base anziché leggere i dati della vista materializzata. In questo modo, la query rispetta tutti i vincoli di controllo dell'accesso. Questa limitazione si applica anche quando si eseguono query su tabelle con colonne con mascheramento dei dati.
Supporto delle query sulle viste materializzate
Le viste materializzate utilizzano una sintassi SQL limitata. Le query devono utilizzare il seguente pattern:
[ WITH cte [, …]] SELECT [{ ALL | DISTINCT }] expression [ [ AS ] alias ] [, ...] FROM from_item [, ...] [ WHERE bool_expression ] [ GROUP BY expression [, ...] ] from_item: { table_name [ as_alias ] | { join_operation | ( join_operation ) } | field_path | unnest_operator | cte_name [ as_alias ] } as_alias: [ AS ] alias
Limitazioni delle query
Le viste materializzate incrementali presentano le seguenti limitazioni.
Requisiti di aggregazione
Le aggregazioni nella query della vista materializzata devono essere output. Il calcolo, il filtro o l'unione in base a un valore aggregato non sono supportati. Ad esempio, la creazione di una vista dalla seguente query non è supportata perché produce un valore calcolato da un aggregato, COUNT(*) / 10 as cnt.
SELECT TIMESTAMP_TRUNC(ts, HOUR) AS ts_hour, COUNT(*) / 10 AS cnt FROM mydataset.mytable GROUP BY ts_hour;
Sono supportate solo le seguenti funzioni di aggregazione:
ANY_VALUE(ma non oltreSTRUCT)APPROX_COUNT_DISTINCTARRAY_AGG(ma non oltreARRAYoSTRUCT)AVGBIT_ANDBIT_ORBIT_XORCOUNTCOUNTIFHLL_COUNT.INITLOGICAL_ANDLOGICAL_ORMAXMINMAX_BY(ma non oltreSTRUCT)MIN_BY(ma non oltreSTRUCT)SUM
Funzionalità SQL non supportate
Le seguenti funzionalità SQL non sono supportate nelle viste materializzate:
UNION ALL. (Supporto in anteprima di )LEFT OUTER JOIN(supporto in anteprima per )RIGHT/FULL OUTER JOIN.- Self-join, ovvero l'utilizzo di un
JOINsulla stessa tabella più di una volta. - Funzioni finestra.
ARRAYdi subquery.- Funzioni non deterministiche come
RAND(),CURRENT_DATE(),SESSION_USER()oCURRENT_TIME(). - Funzioni definite dall'utente (UDF).
TABLESAMPLE.FOR SYSTEM_TIME AS OF.- Funzioni AI generative.
Supporto di LEFT OUTER JOIN e UNION ALL
Per richiedere feedback o assistenza per questa funzionalità, invia un'email all'indirizzo bq-mv-help@google.com.
Le viste materializzate incrementali supportano LEFT OUTER JOIN e UNION ALL.
Le viste materializzate con istruzioni LEFT OUTER JOIN e UNION ALL condividono le limitazioni di altre viste materializzate incrementali. Inoltre, l'ottimizzazione intelligente non è supportata per le viste materializzate con UNION ALL o LEFT OUTER JOIN.
Per le viste materializzate incrementali partizionate che utilizzano UNION ALL, tutte le tabelle di base devono avere le stesse impostazioni della data di scadenza della partizione (TTL) per mantenere l'allineamento delle partizioni.
Se le tabelle di base hanno date di scadenza delle partizioni diverse, gli aggiornamenti incrementali non vanno a buon fine.
Esempi
L'esempio seguente crea una vista materializzata incrementale aggregata con
un LEFT JOIN. Questa vista viene aggiornata in modo incrementale quando i dati vengono aggiunti alla tabella
di sinistra.
CREATE MATERIALIZED VIEW dataset.mv AS ( SELECT s_store_sk, s_country, s_zip, SUM(ss_net_paid) AS sum_sales, FROM dataset.store_sales LEFT JOIN dataset.store ON ss_store_sk = s_store_sk GROUP BY 1, 2, 3 );
L'esempio seguente crea una vista materializzata incrementale aggregata con
un UNION ALL. Questa vista viene aggiornata in modo incrementale quando i dati vengono aggiunti a una o entrambe le tabelle. Per ulteriori informazioni sugli aggiornamenti incrementali, consulta
Aggiornamenti incrementali.
CREATE MATERIALIZED VIEW dataset.mv PARTITION BY DATE(ts_hour) AS ( SELECT SELECT TIMESTAMP_TRUNC(ts, HOUR) AS ts_hour, SUM(sales) sum_sales FROM (SELECT ts, sales from dataset.table1 UNION ALL SELECT ts, sales from dataset.table2) GROUP BY 1 );
Clausola WITH ed espressioni di tabella comuni (CTE)
Le viste materializzate supportano le clausole WITH e le espressioni di tabella comuni.
Le viste materializzate con clausole WITH devono comunque seguire il pattern e le limitazioni delle viste materializzate senza clausole WITH.
Esempi
L'esempio seguente mostra una vista materializzata che utilizza una clausola WITH:
WITH tmp AS ( SELECT TIMESTAMP_TRUNC(ts, HOUR) AS ts_hour, * FROM mydataset.mytable ) SELECT ts_hour, COUNT(*) AS cnt FROM tmp GROUP BY ts_hour;
L'esempio seguente mostra una vista materializzata che utilizza una clausola WITH non supportata perché contiene due clausole GROUP BY:
WITH tmp AS ( SELECT city, COUNT(*) AS population FROM mydataset.mytable GROUP BY city ) SELECT population, COUNT(*) AS cnt GROUP BY population;
Viste materializzate su tabelle BigLake
Per creare viste materializzate su tabelle BigLake, la tabella BigLake deve avere la memorizzazione nella cache dei metadati abilitata sui dati di Cloud Storage e la vista materializzata deve avere un valore dell'opzione max_staleness maggiore della tabella di base.
Le viste materializzate sulle tabelle BigLake supportano lo stesso insieme di query di altre viste materializzate.
Esempio
Creazione di una vista aggregata utilizzando una tabella di base BigLake:
CREATE MATERIALIZED VIEW sample_dataset.sample_mv OPTIONS (max_staleness=INTERVAL "0:30:0" HOUR TO SECOND) AS SELECT COUNT(*) cnt FROM dataset.biglake_base_table;
Per informazioni dettagliate sulle limitazioni delle viste materializzate sulle tabelle BigLake, consulta Viste materializzate sulle tabelle BigLake.
Viste materializzate su tabelle esterne Apache Iceberg
Puoi fare riferimento a tabelle Iceberg di grandi dimensioni nelle viste materializzate anziché eseguire la migrazione dei dati allo spazio di archiviazione gestito da BigQuery.
Crea una vista materializzata su una tabella Iceberg
L'esempio seguente crea una vista materializzata con partizioni allineate su una tabella Iceberg di base partizionata:
CREATE MATERIALIZED VIEW mydataset.myicebergmv PARTITION BY DATE_TRUNC(birth_month, MONTH) AS SELECT * FROM mydataset.myicebergtable;
La tabella Iceberg di base sottostante myicebergtable deve avere una specifica di partizione come la seguente:
"partition-specs" : [ {
"spec-id" : 0,
"fields" : [ {
"name" : "birth_month",
"transform" : "month",
"source-id" : 3,
"field-id" : 1000
} ]
} ]
Limitazioni
Oltre alle limitazioni delle tabelle Iceberg standard, le viste materializzate sulle tabelle Iceberg presentano le seguenti limitazioni:
- Puoi creare una vista materializzata con allineamento delle partizioni alla tabella di base. Tuttavia, la vista materializzata supporta solo la trasformazione della partizione basata sul tempo, ad esempio
YEAR,MONTH,DAYeHOUR. - La granularità della partizione della vista materializzata non può essere più precisa della granularità della partizione della tabella di base. Ad esempio, se partizioni la tabella di base annualmente utilizzando la colonna
birth_date, la creazione di una vista materializzata conPARTITION BY DATE_TRUNC(birth_date, MONTH)non è supportata. - Se le tabelle Iceberg di base presentano modifiche in più di 4000 partizioni, la vista materializzata viene completamente invalidata al momento dell'aggiornamento, anche se è partizionata.
- Sono supportate le evoluzioni delle partizioni. Tuttavia, la modifica delle colonne di partizionamento di una tabella di base senza ricreare la vista materializzata potrebbe comportare un'invalidazione completa che non può essere corretta aggiornando la vista materializzata.
- Nella tabella di base deve essere presente almeno uno snapshot.
- La tabella Iceberg deve essere una tabella BigLake, ad esempio una tabella esterna autorizzata.
- La query sulla vista materializzata potrebbe non riuscire se il file
metadata.jsondella tabella Iceberg è danneggiato. - Se i Controlli di servizio VPC sono abilitati, i service account della tabella esterna autorizzata devono essere aggiunti alle regole in entrata, altrimenti i Controlli di servizio VPC bloccano l'aggiornamento automatico in background per la vista materializzata.
Il file metadata.json della tabella Iceberg deve avere
le seguenti specifiche. Senza queste specifiche, le query eseguono la scansione della tabella di base, senza utilizzare il risultato materializzato.
-
current-snapshot-idcurrent-schema-idsnapshotssnapshot-log
In snapshots:
parent-snapshot-id(se disponibile)schema-idoperation(nel camposummary)
Partizionamento (per la vista materializzata partizionata)
Viste materializzate partizionate
Le viste materializzate sulle tabelle partizionate possono essere partizionate. Il partizionamento di una vista materializzata è simile al partizionamento di una tabella normale, in quanto offre vantaggi quando le query accedono spesso a un sottoinsieme delle partizioni. Inoltre, il partizionamento di una vista materializzata può migliorare il comportamento della vista quando i dati nella tabella o nelle tabelle di base vengono modificati o eliminati. Per saperne di più, consulta Allineamento delle partizioni.
Se la tabella di base è partizionata, puoi partizionare una vista materializzata sulla stessa colonna di partizionamento. Per le partizioni basate sul tempo, la granularità deve corrispondere (oraria, giornaliera, mensile o annuale). Per le partizioni con intervallo di numeri interi, la specifica dell'intervallo deve corrispondere esattamente. Non puoi partizionare una vista materializzata su una tabella di base non partizionata.
Se la tabella di base è partizionata in base al tempo di importazione, una vista materializzata può essere raggruppata in base alla colonna _PARTITIONDATE della tabella di base e anche partizionata in base a questa colonna.
Se non specifichi esplicitamente il partizionamento quando crei la vista materializzata, questa non viene partizionata.
Se la tabella di base è partizionata, valuta la possibilità di partizionare anche la vista materializzata per ridurre i costi di manutenzione dei job di aggiornamento e i costi delle query.
Scadenza partizione
La scadenza della partizione non può essere impostata sulle viste materializzate. Una vista materializzata eredita implicitamente la scadenza della partizione dalla tabella di base. Le partizioni della vista materializzata sono allineate alle partizioni della tabella di base, quindi scadono in modo sincrono.
Esempio 1
In questo esempio, la tabella di base è partizionata in base alla colonna transaction_time con partizioni giornaliere. La vista materializzata è partizionata sulla stessa colonna e raggruppata in cluster sulla colonna employee_id.
CREATE TABLE my_project.my_dataset.my_base_table( employee_id INT64, transaction_time TIMESTAMP) PARTITION BY DATE(transaction_time) OPTIONS (partition_expiration_days = 2); CREATE MATERIALIZED VIEW my_project.my_dataset.my_mv_table PARTITION BY DATE(transaction_time) CLUSTER BY employee_id AS ( SELECT employee_id, transaction_time, COUNT(employee_id) AS cnt FROM my_dataset.my_base_table GROUP BY employee_id, transaction_time );
Esempio 2
In questo esempio, la tabella di base è partizionata per data di importazione con partizioni giornaliere. La vista materializzata seleziona l'ora di importazione come colonna denominata date. La vista materializzata è raggruppata in base alla colonna date e partizionata in base alla stessa colonna.
CREATE MATERIALIZED VIEW my_project.my_dataset.my_mv_table PARTITION BY date CLUSTER BY employee_id AS ( SELECT employee_id, _PARTITIONDATE AS date, COUNT(1) AS count FROM my_dataset.my_base_table GROUP BY employee_id, date );
Esempio 3
In questo esempio, la tabella di base è partizionata in base a una colonna TIMESTAMP denominata transaction_time, con partizioni giornaliere. La vista materializzata definisce una colonna denominata transaction_hour, utilizzando la funzione TIMESTAMP_TRUNC per troncare il valore all'ora più vicina. La vista materializzata è raggruppata per transaction_hour e anche partizionata per questo valore.
Tieni presente quanto segue:
La funzione di troncamento applicata alla colonna di partizionamento deve essere granulare almeno quanto il partizionamento della tabella di base. Ad esempio, se la tabella di base utilizza partizioni giornaliere, la funzione di troncamento non può utilizzare la granularità
MONTHoYEAR.Nella specifica della partizione della vista materializzata, la granularità deve corrispondere alla tabella di base.
CREATE TABLE my_project.my_dataset.my_base_table ( employee_id INT64, transaction_time TIMESTAMP) PARTITION BY DATE(transaction_time); CREATE MATERIALIZED VIEW my_project.my_dataset.my_mv_table PARTITION BY DATE(transaction_hour) AS ( SELECT employee_id, TIMESTAMP_TRUNC(transaction_time, HOUR) AS transaction_hour, COUNT(employee_id) AS cnt FROM my_dataset.my_base_table GROUP BY employee_id, transaction_hour );
Viste materializzate del cluster
Puoi raggruppare le viste materializzate in base alle colonne di output, nel rispetto delle limitazioni delle tabelle in cluster di BigQuery. Le colonne di output aggregate non possono essere utilizzate come colonne di clustering. L'aggiunta di colonne di clustering alle viste materializzate può migliorare le prestazioni delle query che includono filtri su queste colonne.
Viste logiche di riferimento
Per richiedere feedback o assistenza per questa funzionalità, invia un'email all'indirizzo bq-mv-help@google.com.
Le query sulle viste materializzate possono fare riferimento a viste logiche, ma sono soggette alle seguenti limitazioni:
- Si applicano le limitazioni delle viste materializzate.
- Se la vista logica cambia, la vista materializzata non è più valida e deve essere aggiornata completamente.
- L'ottimizzazione intelligente non è supportata.
Best practice per la creazione di viste materializzate
Quando crei viste materializzate, tieni presente le seguenti best practice.
Quali viste materializzate creare
Quando crei una vista materializzata, assicurati che la relativa definizione rifletta i pattern di query sulle tabelle di base. Le viste materializzate sono più efficaci quando gestiscono un ampio insieme di query anziché un solo pattern di query specifico.
Ad esempio, considera una query su una tabella in cui gli utenti filtrano spesso in base alle colonne user_id o department. Puoi raggruppare in base a queste colonne e, facoltativamente, raggrupparle in cluster, anziché aggiungere filtri come user_id = 123 alla vista materializzata.
Un altro esempio è l'utilizzo di filtri di date deterministici, per data specifica, ad esempio WHERE order_date = '2019-10-01', o per intervallo di date, ad esempio WHERE order_date BETWEEN '2019-10-01' AND '2019-10-31'. Aggiungi un filtro dell'intervallo di date nella vista materializzata che copra gli intervalli di date previsti nella query:
CREATE MATERIALIZED VIEW ... ... WHERE date > '2019-01-01' GROUP BY date
Join nelle viste materializzate
I seguenti suggerimenti si applicano alle viste materializzate con istruzioni JOIN.
Posiziona per prima la tabella che cambia più di frequente
Assicurati che la tabella più grande o che cambia più di frequente sia la prima o la tabella più a sinistra a cui viene fatto riferimento nella query della vista. Le viste materializzate con join supportano le query incrementali e l'aggiornamento quando viene aggiunta la prima tabella o quella più a sinistra nella query, ma le modifiche ad altre tabelle invalidano completamente la cache della vista. Negli schemi a stella o a fiocco di neve, la prima tabella o quella più a sinistra deve essere generalmente la tabella dei fatti.
Evita i join sulle chiavi di clustering
Le viste materializzate con join funzionano meglio nei casi in cui i dati sono fortemente aggregati o la query di join originale è costosa. Per le query selettive, BigQuery è spesso già in grado di eseguire il join in modo efficiente e non è necessaria alcuna vista materializzata. Ad esempio, considera le seguenti definizioni di vista materializzata.
CREATE MATERIALIZED VIEW dataset.mv CLUSTER BY s_market_id AS ( SELECT s_market_id, s_country, SUM(ss_net_paid) AS sum_sales, COUNT(*) AS cnt_sales FROM dataset.store_sales INNER JOIN dataset.store ON ss_store_sk = s_store_sk GROUP BY s_market_id, s_country );
Supponiamo che store_sales sia raggruppato in cluster su ss_store_sk e che tu esegua spesso query come la seguente:
SELECT SUM(ss_net_paid) FROM dataset.store_sales INNER JOIN dataset.store ON ss_store_sk = s_store_sk WHERE s_country = 'Germany';
La vista materializzata potrebbe non essere efficiente quanto la query originale. Per ottenere i risultati migliori, sperimenta con un insieme rappresentativo di query, con e senza la vista materializzata.
Utilizza le viste materializzate con l'opzione max_staleness
L'opzione di vista materializzata max_staleness ti aiuta a ottenere prestazioni delle query costantemente elevate con costi controllati durante l'elaborazione di set di dati di grandi dimensioni che cambiano di frequente. Con il parametro max_staleness, puoi ridurre i costi e la latenza delle query impostando un intervallo di tempo in cui l'obsolescenza dei dati dei risultati delle query è accettabile. Questo comportamento può essere utile per dashboard e report per i quali non sono essenziali risultati di query completamente aggiornati.
Aggiornamento dei dati
Quando esegui una query su una vista materializzata con l'opzione max_staleness impostata, BigQuery restituisce il risultato in base al valore max_staleness e all'ora dell'ultimo aggiornamento.
Se l'ultimo aggiornamento è avvenuto entro l'intervallo max_staleness, BigQuery restituisce i dati direttamente dalla vista materializzata senza leggere le tabelle di base. Ad esempio, se l'intervallo di max_staleness è di 4 ore e l'ultimo aggiornamento è avvenuto 2 ore fa.
Se l'ultimo aggiornamento è avvenuto al di fuori dell'intervallo max_staleness, BigQuery legge i dati dalla vista materializzata, li combina con le modifiche alla tabella di base dall'ultimo aggiornamento e restituisce il risultato combinato. Questo risultato combinato potrebbe essere ancora obsoleto, fino all'intervallo max_staleness. Ad esempio, se l'intervallo max_staleness è di 4 ore e l'ultimo aggiornamento è avvenuto 7 ore fa,
Opzione Crea con max_staleness
Seleziona una delle seguenti opzioni:
SQL
Per creare una vista materializzata con l'opzione max_staleness, aggiungi una clausola OPTIONS all'istruzione DDL quando crei la vista materializzata:
Nella console Google Cloud , vai alla pagina BigQuery.
Nell'editor di query, inserisci la seguente istruzione:
CREATE MATERIALIZED VIEW
project-id.my_dataset.my_mv_tableOPTIONS (enable_refresh = true, refresh_interval_minutes = 60, max_staleness = INTERVAL "4:0:0" HOUR TO SECOND) AS SELECT employee_id, DATE(transaction_time), COUNT(1) AS count FROMmy_dataset.my_base_tableGROUP BY 1, 2;Sostituisci quanto segue:
- project-id è l'ID progetto.
- my_dataset è l'ID di un set di dati nel tuo progetto.
- my_mv_table è l'ID della vista materializzata che stai creando.
- my_base_table è l'ID di una tabella nel set di dati che funge da tabella di base per la vista materializzata.
Fai clic su Esegui.
Per saperne di più su come eseguire le query, consulta Esegui una query interattiva.
API
Chiama il metodo tables.insert con una risorsa materializedView definita come parte della richiesta API. La risorsa materializedView contiene un campo query. Ad esempio:
{ "kind": "bigquery#table", "tableReference": { "projectId": "project-id", "datasetId": "my_dataset", "tableId": "my_mv_table" }, "materializedView": { "query": "select product_id,sum(clicks) as sum_clicks from project-id.my_dataset.my_base_table group by 1" } "maxStaleness": "4:0:0" }
Sostituisci quanto segue:
- project-id è l'ID progetto.
- my_dataset è l'ID di un set di dati nel tuo progetto.
- my_mv_table è l'ID della vista materializzata che stai creando.
- my_base_table è l'ID di una tabella nel set di dati che funge da tabella di base per la vista materializzata.
product_idè una colonna della tabella di base.clicksè una colonna della tabella di base.sum_clicksè una colonna nella vista materializzata che stai creando.
Applica l'opzione max_staleness
Puoi applicare questo parametro alle viste materializzate esistenti utilizzando l'istruzione ALTER
MATERIALIZED VIEW. Ad esempio:
ALTER MATERIALIZED VIEW project-id.my_dataset.my_mv_table SET OPTIONS (enable_refresh = true, refresh_interval_minutes = 120, max_staleness = INTERVAL "8:0:0" HOUR TO SECOND);
Query con max_staleness
Puoi eseguire query sulle viste materializzate con l'opzione max_staleness come faresti per qualsiasi altra vista materializzata, vista logica o tabella.
Ad esempio:
SELECT * FROM project-id.my_dataset.my_mv_table
Questa query restituisce i dati dell'ultimo aggiornamento se non sono più vecchi del parametro max_staleness. Se la vista materializzata non è stata aggiornata entro l'intervallo max_staleness, BigQuery unisce i risultati dell'ultimo aggiornamento disponibile con le modifiche alla tabella di base per restituire i risultati entro l'intervallo max_staleness.
Streaming di dati e risultati di max_staleness
Se trasmetti dati in streaming nelle tabelle di base di una vista materializzata con l'opzione max_staleness, la query della vista materializzata potrebbe escludere i record che sono stati trasmessi in streaming nelle sue tabelle prima dell'inizio dell'intervallo di inattività. Di conseguenza, una vista materializzata che include dati di più tabelle e l'opzione max_staleness potrebbe non rappresentare uno snapshot point-in-time di queste tabelle.
Limitazioni relative ai flussi di dati e ai viaggi nel tempo
Sebbene i set di dati BigQuery abbiano una finestra di viaggio nel tempo predefinita di 7 giorni, il buffer di archiviazione in streaming conserva i dati solo per 3 giorni. Questo crea la seguente limitazione per le viste materializzate:
Errore di query: se una vista materializzata utilizza l'opzione
max_stalenesse non è stata aggiornata per più di 3 giorni, le query sulla vista non vanno a buon fine e viene visualizzato il messaggio di erroreStreaming data from <materialized_view_name> is temporarily unavailable.Causa: l'errore si verifica perché il processo di riscrittura della query tenta di leggere le modifiche incrementali (delta) dal buffer di archiviazione in modalità flusso. Se i dati richiesti sono più vecchi del periodo di conservazione di 3 giorni, il sistema non può recuperare i delta necessari per la riscrittura incrementale.
Per evitare questi errori, assicurati che la policy di aggiornamento aggiorni la vista materializzata almeno una volta ogni 3 giorni.
Ottimizzazione intelligente e opzione max_staleness
L'ottimizzazione intelligente riscrive automaticamente le query per utilizzare le viste materializzate ogni volta che è possibile, indipendentemente dall'opzione max_staleness, anche se la query non fa riferimento a una vista materializzata. L'opzione max_staleness su una vista materializzata non influisce sui risultati della query riscritta. L'opzione max_staleness influisce solo sulle query che eseguono query direttamente sulla vista materializzata.
Gestisci l'obsolescenza e la frequenza di aggiornamento
Devi impostare max_staleness in base ai tuoi requisiti. Per evitare di leggere i dati dalle tabelle di base, configura l'intervallo di aggiornamento in modo che l'aggiornamento avvenga entro l'intervallo di inattività. Puoi tenere conto del tempo di esecuzione medio dell'aggiornamento più un margine di crescita.
Ad esempio, se è necessaria un'ora per aggiornare la vista materializzata e vuoi un buffer di un'ora per la crescita, devi impostare l'intervallo di aggiornamento su due ore. Questa configurazione garantisce che l'aggiornamento avvenga entro il limite massimo di quattro ore di inattività del report.
CREATE MATERIALIZED VIEW project-id.my_dataset.my_mv_table OPTIONS (enable_refresh = true, refresh_interval_minutes = 120, max_staleness = INTERVAL "4:0:0" HOUR TO SECOND) AS SELECT employee_id, DATE(transaction_time), COUNT(1) AS cnt FROM my_dataset.my_base_table GROUP BY 1, 2;
Viste materializzate non incrementali
Le viste materializzate non incrementali supportano la maggior parte delle query SQL, incluse le clausole OUTER
JOIN, UNION e HAVING e le funzioni analitiche. Per determinare se una vista materializzata è stata utilizzata nella query, controlla le stime dei costi utilizzando un dry run.
In scenari in cui l'obsolescenza dei dati è accettabile, ad esempio per il trattamento dati o la generazione di report in batch, le viste materializzate non incrementali possono migliorare le prestazioni delle query e ridurre i costi. Utilizzando l'opzione max_staleness, puoi creare viste materializzate complesse e arbitrarie che vengono gestite automaticamente e hanno limiti di inattività integrati.
Utilizza viste materializzate non incrementali
Puoi creare viste materializzate non incrementali utilizzando l'opzione allow_non_incremental_definition. Questa opzione deve essere accompagnata dall'opzione max_staleness. Per garantire un aggiornamento periodico della vista materializzata, devi anche configurare una policy di aggiornamento.
Senza una policy di aggiornamento, devi aggiornare manualmente la vista materializzata.
La vista materializzata rappresenta sempre lo stato delle tabelle di base nell'intervallo max_staleness. Se l'ultimo aggiornamento è troppo obsoleto e non rappresenta le tabelle di base nell'intervallo max_staleness, la query legge le tabelle di base. Per scoprire di più sulle possibili implicazioni sul rendimento, consulta Inattività dei dati.
Crea con allow_non_incremental_definition
Per creare una vista materializzata con l'opzione allow_non_incremental_definition, segui questi passaggi. Dopo aver creato la vista materializzata, non puoi modificare l'opzione allow_non_incremental_definition. Ad esempio, non puoi modificare il valore true in false o rimuovere l'opzione allow_non_incremental_definition dalla vista materializzata.
SQL
Aggiungi una clausola OPTIONS all'istruzione DDL quando crei la vista materializzata:
Nella console Google Cloud , vai alla pagina BigQuery.
Nell'editor di query, inserisci la seguente istruzione:
CREATE MATERIALIZED VIEW my_project.my_dataset.my_mv_table OPTIONS ( enable_refresh = true, refresh_interval_minutes = 60, max_staleness = INTERVAL "4" HOUR, allow_non_incremental_definition = true) AS
SELECTs_store_sk, SUM(ss_net_paid) AS sum_sales, APPROX_QUANTILES(ss_net_paid, 2)[safe_offset(1)] median FROM my_project.my_dataset.store LEFT OUTER JOIN my_project.my_dataset.store_sales ON ss_store_sk = s_store_sk GROUP BY s_store_sk HAVING median < 40 OR median is NULL ;Sostituisci quanto segue:
- my_project è l'ID progetto.
- my_dataset è l'ID di un set di dati nel tuo progetto.
- my_mv_table è l'ID della vista materializzata che stai creando.
- my_dataset.store e my_dataset.store_sales sono gli ID delle tabelle nel set di dati che fungono da tabelle di base per la vista materializzata.
Fai clic su Esegui.
Per saperne di più su come eseguire le query, consulta Esegui una query interattiva.
API
Chiama il metodo tables.insert con una risorsa materializedView definita come parte della richiesta API. La risorsa materializedView contiene un campo query. Ad esempio:
{ "kind": "bigquery#table", "tableReference": { "projectId": "my_project", "datasetId": "my_dataset", "tableId": "my_mv_table" }, "materializedView": { "query": "`SELECT` s_store_sk, SUM(ss_net_paid) AS sum_sales, APPROX_QUANTILES(ss_net_paid, 2)[safe_offset(1)] median FROM my_project.my_dataset.store LEFT OUTER JOIN my_project.my_dataset.store_sales ON ss_store_sk = s_store_sk GROUP BY s_store_sk HAVING median < 40 OR median is NULL`", "allowNonIncrementalDefinition": true } "maxStaleness": "4:0:0" }
Sostituisci quanto segue:
- my_project è l'ID progetto.
- my_dataset è l'ID di un set di dati nel tuo progetto.
- my_mv_table è l'ID della vista materializzata che stai creando.
- my_dataset.store e my_dataset.store_sales sono gli ID delle tabelle nel set di dati che fungono da tabelle di base per la vista materializzata.
Crea viste materializzate su set di dati esterni di Spanner
Prima di procedere, devi creare il set di dati esterno Spanner sottostante utilizzando una connessione CLOUD_RESOURCE.
Puoi creare viste materializzate non incrementali che fanno riferimento alle tabelle dei set di dati esterni di Spanner utilizzando l'opzione allow_non_incremental_definition.
L'esempio seguente utilizza una tabella di set di dati esterni Spanner di base:
/* You must create the spanner_external_dataset with a CLOUD_RESOURCE connection. */ CREATE MATERIALIZED VIEW sample_dataset.sample_spanner_mv OPTIONS ( enable_refresh = true, refresh_interval_minutes = 60, max_staleness = INTERVAL "24" HOUR, allow_non_incremental_definition = true) AS SELECT COUNT(*) cnt FROM spanner_external_dataset.spanner_table;
Query con allow_non_incremental_definition
Puoi eseguire query su viste materializzate non incrementali come faresti su qualsiasi altra vista materializzata, vista logica o tabella.
Ad esempio:
SELECT * FROM my_project.my_dataset.my_mv_table
Se i dati non sono più vecchi del parametro max_staleness, questa query restituisce i dati dell'ultimo aggiornamento. Per informazioni dettagliate sull'obsolescenza e sull'aggiornamento dei dati, consulta Obsolescenza dei dati.
Limitazioni specifiche per le viste materializzate non incrementali
Le seguenti limitazioni si applicano solo alle viste materializzate con l'opzione allow_non_incremental_definition. Ad eccezione delle limitazioni relative alla sintassi delle query supportata, si applicano comunque tutte le limitazioni delle viste materializzate.
- L'ottimizzazione intelligente non viene applicata alle viste materializzate che includono l'opzione
allow_non_incremental_definition. L'unico modo per trarre vantaggio dalle viste materializzate con l'opzioneallow_non_incremental_definitionè eseguire query direttamente su di esse. - Le viste materializzate senza l'opzione
allow_non_incremental_definitionpossono aggiornare in modo incrementale un sottoinsieme dei propri dati. Le viste materializzate con l'opzioneallow_non_incremental_definitiondevono essere aggiornate nella loro interezza. - Le viste materializzate con l'opzione
max_stalenessconvalidano la presenza dei vincoli di sicurezza a livello di colonna durante l'esecuzione delle query. Per saperne di più, consulta Controllo dell'accesso a livello di colonna. - Per le viste materializzate sulle tabelle dei set di dati esterni di Spanner, se l'ultimo aggiornamento di una vista materializzata non incrementale è avvenuto al di fuori dell'intervallo
max_staleness, le query leggono le tabelle dei set di dati esterni di Spanner di base, anche se la tabella di base non è cambiata. Ad esempio, se l'intervallomax_stalenessè di 4 ore e l'ultimo aggiornamento è avvenuto 7 ore fa, la query leggerà le tabelle del set di dati esterno Spanner di base.
Passaggi successivi
- Gestisci le viste materializzate.
- Utilizza le viste materializzate.
- Risolvi i problemi relativi alle viste materializzate.