Creare viste materializzate

Questo documento descrive come creare visualizzazioni materializzate in BigQuery. Prima di leggere questo documento, familiarizza con l'introduzione alle visualizzazioni con dati memorizzati.

Prima di iniziare

Concedi i ruoli IAM (Identity and Access Management) che concedono 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.dataEditor
• bigquery.dataOwner
• bigquery.admin

Per ulteriori informazioni su Identity and Access Management (IAM) di BigQuery, consulta Controllo dell'accesso con IAM.

Creare viste materializzate

Per creare una vista materializzata, seleziona una delle seguenti opzioni:

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
);

resource "google_bigquery_dataset" "default" {
  dataset_id                      = "mydataset"
  default_partition_expiration_ms = 2592000000  # 30 days
  default_table_expiration_ms     = 31536000000 # 365 days
  description                     = "dataset description"
  location                        = "US"
  max_time_travel_hours           = 96 # 4 days

  labels = {
    billing_group = "accounting",
    pii           = "sensitive"
  }
}

resource "google_bigquery_table" "default" {
  dataset_id          = google_bigquery_dataset.default.dataset_id
  table_id            = "my_materialized_view"
  deletion_protection = false # set to "true" in production

  materialized_view {
    query                            = "SELECT ID, description, date_created FROM `myproject.orders.items`"
    enable_refresh                   = "true"
    refresh_interval_ms              = 172800000 # 2 days
    allow_non_incremental_definition = "false"
  }

}

{
  "kind": "bigquery#table",
  "tableReference": {
    "projectId": "PROJECT_ID",
    "datasetId": "DATASET",
    "tableId": "MATERIALIZED_VIEW_NAME"
  },
  "materializedView": {
    "query": "QUERY_EXPRESSION"
  }
}

{
  "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"
  }
}

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.MaterializedViewDefinition;
import com.google.cloud.bigquery.TableId;
import com.google.cloud.bigquery.TableInfo;

// Sample to create materialized view
public class CreateMaterializedView {

  public static void main(String[] args) {
    // TODO(developer): Replace these variables before running the sample.
    String datasetName = "MY_DATASET_NAME";
    String tableName = "MY_TABLE_NAME";
    String materializedViewName = "MY_MATERIALIZED_VIEW_NAME";
    String query =
        String.format(
            "SELECT MAX(TimestampField) AS TimestampField, StringField, "
                + "MAX(BooleanField) AS BooleanField "
                + "FROM %s.%s GROUP BY StringField",
            datasetName, tableName);
    createMaterializedView(datasetName, materializedViewName, query);
  }

  public static void createMaterializedView(
      String datasetName, String materializedViewName, String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      TableId tableId = TableId.of(datasetName, materializedViewName);

      MaterializedViewDefinition materializedViewDefinition =
          MaterializedViewDefinition.newBuilder(query).build();

      bigquery.create(TableInfo.of(tableId, materializedViewDefinition));
      System.out.println("Materialized view created successfully");
    } catch (BigQueryException e) {
      System.out.println("Materialized view was not created. \n" + e.toString());
    }
  }
}

Una volta creata, la vista materializzata viene visualizzata nel riquadro Explorer di BigQuery nella console Google Cloud. L'esempio seguente mostra uno schema di 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, livello di vista o livello di colonna. Puoi anche impostare l'accesso a un livello superiore nella gerarchia delle risorse IAM.

L'esecuzione di query su una vista materializzata richiede 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 ulteriori informazioni, consulta Visualizzazioni autorizzate.

Per controllare l'accesso alle visualizzazioni in BigQuery, consulta Visualizzazioni autorizzate.

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 per le query

Le viste materializzate presentano i seguenti limiti.

Requisiti aggregati

Gli aggregati nella query della vista materializzata devono essere output. Il calcolo, il filtraggio o l'unione in base a un valore aggregato non è supportato. Ad esempio, la creazione di una visualizzazione dalla seguente query non è supportata perché produce un valore calcolato da un valore aggregato, COUNT(*) / 10 as cnt.

SELECT TIMESTAMP_TRUNC(ts, HOUR) AS ts_hour, COUNT(*) / 10 AS cnt
FROM mydataset.mytable
GROUP BY ts_hour;

Al momento sono supportate solo le seguenti funzioni di aggregazione:

• ANY_VALUE (ma non più di STRUCT)
• APPROX_COUNT_DISTINCT
• ARRAY_AGG (ma non superiore a ARRAY o STRUCT)
• AVG
• BIT_AND
• BIT_OR
• BIT_XOR
• COUNT
• COUNTIF
• HLL_COUNT.INIT
• LOGICAL_AND
• LOGICAL_OR
• MAX
• MIN
• MAX_BY (ma non più di STRUCT)
• MIN_BY (ma non più di STRUCT)
• SUM

Funzionalità SQL non supportate

Le seguenti funzionalità SQL non sono supportate nelle viste materializzate:

• UNION ALL. (Supporto in science Anteprima)
• LEFT OUTER JOIN (supporto in science Anteprima)
• RIGHT/FULL OUTER JOIN.
• Self-join, noto anche come utilizzo di un JOIN nella stessa tabella più di una volta.
• Funzioni finestra.
• ARRAY sottoquery.
• Funzioni non deterministiche come RAND(), CURRENT_DATE(), SESSION_USER() o CURRENT_TIME().
• Funzioni definite dall'utente (UDF).
• TABLESAMPLE.
• FOR SYSTEM_TIME AS OF.

Assistenza 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 visualizzazioni materializzate con istruzioni LEFT OUTER JOIN e UNION ALL condividono le limitazioni di altre visualizzazioni materializzate incrementali. Inoltre, l'ottimizzazione intelligente non è supportata per le visualizzazioni con dati materiali con union all o join esterno sinistro.

Esempi

L'esempio seguente crea una vista materializzata incrementale aggregata con un LEFT JOIN. Questa visualizzazione 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 visualizzazione viene aggiornata in modo incrementale quando i dati vengono aggiunti a una o a 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
);

Restrizioni del controllo degli accessi

• Se la query di un utente di 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 con 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 delle viste materializzate, BigQuery esegue la query sulle tabelle di base anziché leggere i dati delle viste materializzate. In questo modo, la query rispetterà tutti i vincoli di controllo dell'accesso. Questa limitazione si applica anche quando si eseguono query sulle tabelle con colonne con mascheramento dei dati.

Clausola WITH ed espressioni di tabella comuni (CTE)

Le viste materializzate supportano le clausole WITH e le espressioni di tabelle 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 sulle tabelle BigLake

Per creare visualizzazioni materializzate sulle tabelle BigLake, la tabella BigLake deve avere la memorizzazione nella cache dei metadati attivata 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 delle altre viste materializzate.

Esempio

Creazione di una semplice 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 sulle tabelle Apache Iceberg

Per richiedere feedback o assistenza per questa funzionalità, invia un'email all'indirizzo bq-mv-help@google.com.

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.

Creare una vista materializzata in una tabella Iceberg

Per creare una vista materializzata su un'iceberg, segui questi passaggi:

1. Ottieni una tabella Iceberg utilizzando uno dei seguenti metodi:

   • Crea una tabella Iceberg con il file di metadati JSON.
   • Crea una tabella Iceberg utilizzando BigLake Metastore.
   • Scopri di più nei set di dati federati di AWS Glue.

   Esempio

   CREATE EXTERNAL TABLE mydataset.myicebergtable
     WITH CONNECTION `myproject.us.myconnection`
     OPTIONS (
           format = 'ICEBERG',
           uris = ["gs://mybucket/mydata/mytable/metadata/iceberg.metadata.json"]
     )
   

2. Fai riferimento alla tabella Iceberg con le seguenti specifiche di partizione:

   "partition-specs" : [ {
      "spec-id" : 0,
      "fields" : [ {
       "name" : "birth_month",
       "transform" : "month",
       "source-id" : 3,
       "field-id" : 1000
   } ]
   

3. Crea una vista materializzata allineata alle partizioni:

   CREATE MATERIALIZED VIEW mydataset.myicebergmv
     PARTITION BY DATE_TRUNC(birth_month, MONTH)
   AS
     SELECT * FROM mydataset.myicebergtable;
   

Limitazioni

Oltre alle limitazioni delle tabelle Iceberg standard, le visualizzazioni materializzate sulle tabelle Iceberg presentano i seguenti limiti:

• Puoi creare una vista materializzata allineata alla partizione con la tabella di base. Tuttavia, la vista materializzata supporta solo la trasformazione delle partizioni in base al tempo, ad esempio YEAR, MONTH, DAY e HOUR.
• La granularità della partizione della vista materializzata non può essere più fine 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 con PARTITION BY DATE_TRUNC(birth_date, MONTH) non funziona.
• Qualsiasi modifica dello schema invalida la vista materializzata.
• Le evoluzioni delle partizioni sono supportate. Tuttavia, la modifica delle colonne di partizione di una tabella di base senza ricreare la vista materializzata potrebbe comportare un'invalidazione completa che non può essere corretta con l'aggiornamento.
• Nella tabella di base deve essere presente almeno uno snapshot.
• La tabella Iceberg deve essere una tabella BigLake, ad esempio una tabella esterna autorizzata.
• Se Controlli di servizio VPC è attivato, gli account di servizio della tabella esterna autorizzata devono essere aggiunti alle regole di ingresso, altrimenti Controlli di servizio VPC blocca l'aggiornamento automatico in background della 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.

• Nei metadati della tabella:

  • current-snapshot-id
  • current-schema-id
  • snapshots
  • snapshot-log

• In Istantanee:

  • parent-snapshot-id (se disponibile)
  • schema-id
  • operation (nel campo summary)

• Partizionamento (per la vista materializzata partizionata)

Viste materializzate partizionate

Le viste materializzate nelle tabelle partizionate possono essere partizionate. La suddivisione di una vista materializzata è simile alla suddivisione di una tabella normale, in quanto offre un vantaggio quando le query accedono spesso a un sottoinsieme delle partizioni. Inoltre, la suddivisione in parti 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 ulteriori informazioni, 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 essere uguale (ora, giorno, mese o anno). Per le partizioni con intervalli 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 per data di importazione, una vista materializzata può eseguire il raggruppamento in base alla colonna _PARTITIONDATE della tabella di base e anche eseguire il partizionamento in base a questa colonna. Se non specifichi esplicitamente la partizione quando crei la vista materializzata, la vista materializzata non è partizionata.

Se la tabella di base è partizionata, valuta la possibilità di partizionare anche la vista materializzata per ridurre i costi di manutenzione del job di aggiornamento e di query.

Scadenza partizione

La scadenza della partizione non può essere impostata sulle visualizzazioni materializzate. Una vista materializzata eredita implicitamente la data di scadenza della partizione dalla tabella di base. Le partizioni delle viste materializzate 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 partizionate 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 è agrupata per transaction_hour e partizionata in base a questo attributo.

Tieni presente quanto segue:

• La funzione di troncamento applicata alla colonna di partizionamento deve essere almeno granulare quanto la partizione della tabella di base. Ad esempio, se la tabella di base utilizza partizioni giornaliere, la funzione di troncamento non può utilizzare la granularità MONTH o YEAR.

• 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 in cluster

Puoi raggruppare le viste materializzate in base alle colonne di output, rispettando le limitazioni delle tabelle clusterizzate 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.

Visualizzazioni 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 alle viste logiche, ma sono soggette alle seguenti limitazioni:

• Si applicano le limitazioni delle viste materializzate.
• Se la visualizzazione logica cambia, la vista materializzata diventa non valida e deve essere aggiornata completamente.
• La ottimizzazione intelligente non è supportata.

Considerazioni per la creazione di viste materializzate

Quali viste materializzate creare

Quando crei una vista materializzata, assicurati che la definizione della vista materializzata rifletta i pattern di query sulle tabelle di base. Le viste tabelle sono più efficaci quando vengono utilizzate per un ampio insieme di query anziché per un solo pattern di query specifico.

Ad esempio, prendi in considerazione una query su una tabella in cui gli utenti filtrano spesso in base alle colonneuser_id o department. Puoi raggruppare in base a queste colonne e, facoltativamente, raggrupparle in base a queste colonne, anziché aggiungere filtri come user_id = 123 alla visualizzazione materializzata.

Come altro esempio, gli utenti utilizzano spesso i filtri della data, in base a una data specifica, come WHERE order_date = CURRENT_DATE(), o a un intervallo di date, come 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

Unioni

I seguenti consigli si applicano alle viste materializzate con JOIN.

Inserisci per prima la tabella che cambia più di frequente

Assicurati che la tabella più grande o che cambia più di frequente sia la prima/più a sinistra indicata nella query della vista. Le viste con memorizzazione sotto insistenza con join supportano le query incrementali e l'aggiornamento quando viene aggiunta la prima tabella o la tabella più a sinistra della query, ma le modifiche ad altre tabelle rendono completamente non valida la cache della vista. Negli schemi a stella o a fiocco di neve, in genere la prima tabella o quella più a sinistra deve essere la tabella dei fatti.

Evitare l'unione in base alle chiavi di clustering

Le visualizzazioni con dati materiali con join funzionano meglio nei casi in cui i dati sono molto aggregati o la query di join originale è costosa. Per le query selettive, spesso BigQuery è già in grado di eseguire l'unione 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 ed esegui 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 risultati ottimali, esegui esperimenti con un insieme rappresentativo di query, con e senza la vista materializzata.

Utilizzare le viste materializzate con l'opzione max_staleness

L'opzione max_staleness delle vista materializzata ti consente di ottenere un rendimento costante delle query con costi controllati durante l'elaborazione di set di dati di grandi dimensioni e in continua evoluzione. 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 le dashboard e i report per i quali i risultati delle query completamente aggiornati non sono essenziali.

Inattività 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 nell'intervallo max_staleness, BigQuery restituisce i dati direttamente dalla vista materializzata senza leggere le tabelle di base. Ad esempio, questo vale se l'intervallomax_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 inattivo, fino all'intervallo max_staleness. Ad esempio, questo vale 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:

{
  "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"
}

Applica 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);

Esegui una query con max_staleness

Puoi eseguire query sulle viste materializzate con l'opzione max_staleness come faresti con 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 precedenti al parametro max_staleness. Se la vista materializzata non è stata aggiornata in un intervallo max_staleness, BigQuery unisce i risultati dell'ultimo aggiornamento disponibile con le modifiche alla tabella di base per restituire risultati nell'intervallomax_staleness.

Streaming di dati e risultati max_staleness

Se carichi i dati nelle tabelle di base di una vista materializzata con l'opzione max_staleness, la query della vista materializzata potrebbe escludere i record caricati nelle tabelle prima dell'inizio dell'intervallo di inattività. Di conseguenza, una vista materializzata che include i dati di più tabelle e l'opzione max_staleness potrebbe non rappresentare uno snapshot istantataneo di queste tabelle.

Ottimizzazione intelligente e opzione max_staleness

La regolazione intelligente riscrive automaticamente le query per utilizzare le viste materializzate, ove possibile, indipendentemente dall'opzione max_staleness, anche se la query non fa riferimento a una vista materializzata. L'opzione max_staleness in una vista materializzata non influisce sui risultati della query riscritta. L'opzione max_staleness si applica solo alle query che eseguono query direttamente sulla vista materializzata.

Gestire la frequenza di aggiornamento e l'obsolescenza

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 venga eseguito 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 venga eseguito entro il periodo 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;

Visualizzazioni materializzate non incrementali

Le viste materializzate non incrementali supportano la maggior parte delle query SQL, tra cui le clausole OUTER JOIN, UNION e HAVING e le funzioni di analisi. Per determinare se nella query è stata utilizzata una vista materializzata, controlla le stime dei costi utilizzando un simulacro. Negli scenari in cui l'obsolescenza dei dati è accettabile, ad esempio per l'elaborazione o la generazione di report dei dati 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 mantenute automaticamente e dispongono di garanzie di sfasamento integrate.

Utilizzare viste materializzate non incrementali

Puoi creare viste materializzate non incrementali utilizzando l'opzioneallow_non_incremental_definition. Questa opzione deve essere accompagnata dall'opzione max_staleness. Per garantire un aggiornamento periodico della vista materializzata, devi anche configurare un criterio di aggiornamento. Senza un criterio di aggiornamento, devi aggiornare manualmente la vista materializzata.

La vista materializzata rappresenta sempre lo stato delle tabelle di base all'interno dell'intervallo max_staleness. Se l'ultimo aggiornamento è troppo in ritardo 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 Inattualità 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 cambiare il valore true in false o rimuovere l'opzione allow_non_incremental_definition dalla vista materializzata.

{
  "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"
}

Esegui una query con allow_non_incremental_definition

Puoi eseguire query sulle viste materializzate non incrementali come faresti con qualsiasi altra tabella, vista logica o vista materializzata.

Ad esempio:

SELECT * FROM  my_project.my_dataset.my_mv_table

Se i dati non sono precedenti al parametro max_staleness, questa query restituisce i dati dell'ultimo aggiornamento. Per informazioni dettagliate sull'obsolescenza e sull'aggiornamento dei dati, vedi Obsolescenza dei dati.

Limitazioni specifiche per le viste materializzate non incrementali

I seguenti limiti si applicano solo alle visualizzazioni materializzate con l'opzione allow_non_incremental_definition. Ad eccezione delle limitazioni alla sintassi delle query supportate, continuano a essere valide tutte le limitazioni delle visualizzazioni materializzate.

• La regolazione intelligente non viene applicata alle visualizzazioni materializzate che includono l'opzione allow_non_incremental_definition. L'unico modo per usufruire delle viste materializzate con l'opzione allow_non_incremental_definition è eseguire query direttamente su di esse.
• Le viste con dati materiali senza l'opzione allow_non_incremental_definition possono aggiornare in modo incrementale un sottoinsieme dei dati. Le viste materializzate con l'opzione allow_non_incremental_definition devono essere aggiornate interamente.
• Le visualizzazioni con dati materiali con l'opzione max_staleness convalidano la presenza dei vincoli di sicurezza a livello di colonna durante l'esecuzione delle query. Per ulteriori dettagli, consulta la sezione Controllo dell'accesso a livello di colonna.

Passaggi successivi

• Gestisci le viste materializzate.
• Utilizza le viste materializzate.