Crear vistas materializadas

En este documento se describe cómo crear vistas materializadas en BigQuery. Antes de leer este documento, familiarízate con la introducción a las vistas materializadas.

Antes de empezar

Concede roles de gestión de identidades y accesos (IAM) que proporcionen a los usuarios los permisos necesarios para realizar cada tarea de este documento.

Permisos obligatorios

Para crear vistas materializadas, necesitas el permiso de gestión de identidades y accesos bigquery.tables.create.

Cada uno de los siguientes roles de gestión de identidades y accesos predefinidos incluye los permisos que necesitas para crear una vista materializada:

• bigquery.dataEditor
• bigquery.dataOwner
• bigquery.admin

Para obtener más información sobre la gestión de identidades y accesos (IAM) de BigQuery, consulta el artículo sobre el control de acceso con IAM.

Crear vistas materializadas

Para crear una vista materializada, selecciona una de las siguientes opciones:

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 vez que se haya creado correctamente la vista materializada, aparecerá en el panel Explorador de BigQuery en la consola Google Cloud . En el siguiente ejemplo se muestra un esquema de una vista materializada:

A menos que inhabilite la actualización automática, BigQuery iniciará una actualización completa asíncrona de la vista materializada. La consulta finaliza rápidamente, pero la actualización inicial puede seguir ejecutándose.

Control de acceso

Puedes conceder acceso a una vista materializada a nivel de conjunto de datos, vista o columna. También puedes definir el acceso en un nivel superior de la jerarquía de recursos de gestión de identidades y accesos.

Para consultar una vista materializada, se necesita acceso a la vista y a sus tablas base. Para compartir una vista materializada, puedes conceder permisos a las tablas base o configurar una vista materializada como vista autorizada. Para obtener más información, consulta Vistas autorizadas.

Para controlar el acceso a las vistas en BigQuery, consulta Vistas autorizadas.

Compatibilidad con consultas de vistas materializadas

Las vistas materializadas usan una sintaxis de SQL restringida. Las consultas deben usar el siguiente patrón:

[ 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

Limitaciones de las consultas

Las vistas materializadas tienen las siguientes limitaciones.

Requisitos de agregación

Los agregados de la consulta de la vista materializada deben ser resultados. No se admite el cálculo, el filtrado ni la combinación basados en un valor agregado. Por ejemplo, no se puede crear una vista a partir de la siguiente consulta porque produce un valor calculado a partir de un agregado, COUNT(*) / 10 as cnt.

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

Actualmente, solo se admiten las siguientes funciones de agregación:

• ANY_VALUE (pero no más de STRUCT)
• APPROX_COUNT_DISTINCT
• ARRAY_AGG (pero no más de ARRAY o STRUCT)
• AVG
• BIT_AND
• BIT_OR
• BIT_XOR
• COUNT
• COUNTIF
• HLL_COUNT.INIT
• LOGICAL_AND
• LOGICAL_OR
• MAX
• MIN
• MAX_BY (pero no más de STRUCT)
• MIN_BY (pero no más de STRUCT)
• SUM

Funciones de SQL no admitidas

Las siguientes funciones de SQL no se admiten en las vistas materializadas:

• UNION ALL. (Asistencia en la versión science preliminar)
• LEFT OUTER JOIN (asistencia en la versión science preliminar)
• RIGHT/FULL OUTER JOIN.
• Combinaciones automáticas, también conocidas como uso de un JOIN en la misma tabla más de una vez.
• Funciones de ventana.
• ARRAY subconsultas.
• Funciones no deterministas, como RAND(), CURRENT_DATE(), SESSION_USER() o CURRENT_TIME().
• Funciones definidas por el usuario (UDF).
• TABLESAMPLE.
• FOR SYSTEM_TIME AS OF.

Compatibilidad con LEFT OUTER JOIN y UNION ALL

Para solicitar comentarios o asistencia sobre esta función, envía un correo a bq-mv-help @google.com.

Las vistas materializadas incrementales admiten LEFT OUTER JOIN y UNION ALL. Las vistas materializadas con instrucciones LEFT OUTER JOIN y UNION ALL comparten las limitaciones de otras vistas materializadas incrementales. Además, smart tuning no se admite en las vistas materializadas con union all o left outer join.

Ejemplos

En el siguiente ejemplo se crea una vista materializada incremental agregada con LEFT JOIN. Esta vista se actualiza de forma incremental cuando se añaden datos a la tabla de la izquierda.

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

En el siguiente ejemplo se crea una vista materializada incremental agregada con UNION ALL. Esta vista se actualiza de forma incremental cuando se añaden datos a una o a ambas tablas. Para obtener más información sobre las actualizaciones incrementales, consulta Actualizaciones incrementales.

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

Restricciones de control de acceso

• Si la consulta de un usuario sobre una vista materializada incluye columnas de la tabla base a las que no puede acceder debido a la seguridad a nivel de columna, la consulta falla y se muestra el mensaje Access Denied.
• Si un usuario consulta una vista materializada, pero no tiene acceso completo a todas las filas de las tablas base de la vista materializada, BigQuery ejecuta la consulta en las tablas base en lugar de leer los datos de la vista materializada. De esta forma, la consulta respeta todas las restricciones de control de acceso. Esta limitación también se aplica al consultar tablas con columnas enmascaradas.

Cláusula WITH y expresiones de tabla comunes (ETCs)

Las vistas materializadas admiten cláusulas WITH y expresiones de tabla comunes. Las vistas materializadas con cláusulas WITH deben seguir el patrón y las limitaciones de las vistas materializadas sin cláusulas WITH.

Ejemplos

En el siguiente ejemplo se muestra una vista materializada que usa una cláusula 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;

En el siguiente ejemplo se muestra una vista materializada que usa una cláusula WITH que no se admite porque contiene dos cláusulas GROUP BY:

WITH tmp AS (
  SELECT city, COUNT(*) AS population
  FROM mydataset.mytable
  GROUP BY city
)
SELECT population, COUNT(*) AS cnt
GROUP BY population;

Vistas materializadas sobre tablas de BigLake

Para crear vistas materializadas sobre tablas de BigLake, la tabla de BigLake debe tener habilitado el almacenamiento en caché de metadatos sobre los datos de Cloud Storage y la vista materializada debe tener un valor de opción max_staleness mayor que la tabla base. Las vistas materializadas de tablas BigLake admiten el mismo conjunto de consultas que otras vistas materializadas.

Ejemplo

Creación de una vista agregada simple mediante una tabla base de 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;

Para obtener información sobre las limitaciones de las vistas materializadas en tablas de BigLake, consulta Vistas materializadas en tablas de BigLake.

Vistas materializadas sobre tablas externas de Apache Iceberg

Puedes hacer referencia a tablas de Iceberg grandes en vistas materializadas en lugar de migrar esos datos al almacenamiento gestionado por BigQuery.

Crear una vista materializada sobre una tabla de Iceberg

En el siguiente ejemplo se crea una vista materializada alineada con las particiones sobre una tabla Iceberg base con particiones:

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

La tabla Iceberg subyacente myicebergtable debe tener una especificación de partición como la siguiente:

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

Limitaciones

Además de las limitaciones de las tablas Iceberg estándar, las vistas materializadas de las tablas Iceberg tienen las siguientes limitaciones:

• Puedes crear una vista materializada que esté alineada con las particiones de la tabla base. Sin embargo, la vista materializada solo admite la transformación de particiones basada en el tiempo, como YEAR, MONTH, DAY y HOUR.
• La granularidad de la partición de la vista materializada no puede ser más precisa que la granularidad de la partición de la tabla base. Por ejemplo, si particiona la tabla base anualmente mediante la columna birth_date, no se puede crear una vista materializada con PARTITION BY DATE_TRUNC(birth_date, MONTH).
• Si las tablas Iceberg base tienen cambios en más de 4000 particiones, la vista materializada se invalida por completo al actualizarse, aunque esté particionada.
• Se admiten evoluciones de particiones. Sin embargo, si cambias las columnas de partición de una tabla base sin volver a crear la vista materializada, es posible que se invalide por completo y no se pueda solucionar actualizando la vista materializada.
• Debe haber al menos una instantánea en la tabla base.
• La tabla de Iceberg debe ser una tabla de BigLake, por ejemplo, una tabla externa autorizada.
• La consulta de la vista materializada puede fallar si el archivo metadata.json de tu tabla Iceberg está dañado.
• Si Controles de Servicio de VPC está habilitado, las cuentas de servicio de la tabla externa autorizada deben añadirse a tus reglas de entrada. De lo contrario, Controles de Servicio de VPC bloqueará la actualización automática en segundo plano de la vista materializada.

El archivo metadata.json de tu tabla Iceberg debe cumplir las siguientes especificaciones. Sin estas especificaciones, tus consultas analizan la tabla base y no usan el resultado materializado.

• En los metadatos de la tabla:

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

• En instantáneas:

  • parent-snapshot-id (si está disponible)
  • schema-id
  • operation (en el campo summary)

• Partición (para la vista materializada particionada)

Vistas materializadas particionadas

Las vistas materializadas de tablas con particiones se pueden particionar. La partición de una vista materializada es similar a la de una tabla normal, ya que resulta útil cuando las consultas suelen acceder a un subconjunto de las particiones. Además, la partición de una vista materializada puede mejorar el comportamiento de la vista cuando se modifican o eliminan los datos de la tabla o las tablas base. Para obtener más información, consulta Alineación de particiones.

Si la tabla base tiene particiones, puede crear particiones en una vista materializada en la misma columna de partición. En el caso de las particiones basadas en el tiempo, la granularidad debe coincidir (por horas, por días, por meses o por años). En el caso de las particiones de intervalos de números enteros, la especificación del intervalo debe coincidir exactamente. No puedes particionar una vista materializada en una tabla base no particionada.

Si la tabla base tiene particiones por tiempo de ingestión, una vista materializada puede agruparse por la columna _PARTITIONDATE de la tabla base y también crear particiones por ella. Si no especificas explícitamente la partición al crear la vista materializada, esta no se particionará.

Si la tabla base tiene particiones, plantéate crear particiones en la vista materializada para reducir el coste de mantenimiento de las tareas de actualización y el coste de las consultas.

Caducidad de la partición

No se puede definir la caducidad de las particiones en las vistas materializadas. Una vista materializada hereda implícitamente el tiempo de caducidad de la partición de la tabla base. Las particiones de la vista materializada están alineadas con las particiones de la tabla base, por lo que caducan de forma síncrona.

Ejemplo 1

En este ejemplo, la tabla base tiene particiones diarias en la columna transaction_time. La vista materializada tiene particiones en la misma columna y está agrupada en clústeres por la columna 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
);

Ejemplo 2

En este ejemplo, la tabla base se particiona por hora de ingestión con particiones diarias. La vista materializada selecciona la hora de ingestión como una columna llamada date. La vista materializada se agrupa por la columna date y se particiona por la misma columna.

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

Ejemplo 3

En este ejemplo, la tabla base tiene particiones en una columna TIMESTAMP llamada transaction_time, con particiones diarias. La vista materializada define una columna llamada transaction_hour, que usa la función TIMESTAMP_TRUNC para truncar el valor a la hora más próxima. La vista materializada está agrupada por transaction_hour y también particionada por este campo.

Ten en cuenta lo siguiente:

• La función de truncamiento que se aplica a la columna de partición debe ser al menos tan granular como la partición de la tabla base. Por ejemplo, si la tabla base usa particiones diarias, la función de truncamiento no puede usar la granularidad MONTH ni YEAR.

• En la especificación de partición de la vista materializada, la granularidad debe coincidir con la de la tabla 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
);

Agrupar vistas materializadas

Puedes agrupar en clústeres las vistas materializadas por sus columnas de salida, de acuerdo con las limitaciones de las tablas agrupadas en clústeres de BigQuery. Las columnas de salida agregadas no se pueden usar como columnas de clustering. Si añade columnas de agrupación a las vistas materializadas, puede mejorar el rendimiento de las consultas que incluyan filtros en esas columnas.

Hacer referencia a vistas lógicas

Para solicitar comentarios o asistencia sobre esta función, envía un correo a bq-mv-help@google.com.

Las consultas de vistas materializadas pueden hacer referencia a vistas lógicas, pero están sujetas a las siguientes limitaciones:

• Se aplican limitaciones a las vistas materializadas.
• Si la vista lógica cambia, la vista materializada deja de ser válida y debe actualizarse por completo.
• La sintonización inteligente no está disponible.

Consideraciones al crear vistas materializadas

Qué vistas materializadas crear

Cuando crees una vista materializada, asegúrate de que su definición refleje los patrones de consulta de las tablas base. Las vistas materializadas son más eficaces cuando responden a un conjunto amplio de consultas en lugar de a un solo patrón de consulta específico.

Por ejemplo, supongamos que tienes una consulta en una tabla en la que los usuarios suelen filtrar por las columnas user_id o department. Puedes agrupar por estas columnas y, opcionalmente, crear clústeres por ellas en lugar de añadir filtros como user_id = 123 a la vista materializada.

Por ejemplo, puedes usar filtros de fecha deterministas, ya sea por una fecha específica, como WHERE order_date = '2019-10-01', o por un periodo, como WHERE order_date BETWEEN '2019-10-01' AND '2019-10-31'. Añade un filtro de periodo en la vista materializada que abarque los periodos esperados en la consulta:

CREATE MATERIALIZED VIEW ...
  ...
  WHERE date > '2019-01-01'
  GROUP BY date

Uniones

Las siguientes recomendaciones se aplican a las vistas materializadas con JOINs.

Poner primero la tabla que cambia con más frecuencia

Asegúrate de que la tabla más grande o la que cambia con más frecuencia sea la primera o la más a la izquierda de las tablas a las que se hace referencia en la consulta de la vista. Las vistas materializadas con combinaciones admiten consultas incrementales y se actualizan cuando se añade contenido a la primera tabla o a la tabla situada más a la izquierda de la consulta, pero los cambios en otras tablas invalidan por completo la caché de la vista. En los esquemas de estrella o copo de nieve, la primera tabla o la tabla situada más a la izquierda suele ser la tabla de hechos.

Evitar la unión en claves de clustering

Las vistas materializadas con uniones funcionan mejor en los casos en los que los datos están muy agregados o la consulta de unión original es costosa. En el caso de las consultas selectivas, BigQuery suele poder realizar la combinación de forma eficiente y no se necesita ninguna vista materializada. Por ejemplo, considere las siguientes definiciones de vistas materializadas.

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

Supongamos que store_sales está agrupado en ss_store_sk y que suele ejecutar consultas como las siguientes:

SELECT
  SUM(ss_net_paid)
FROM dataset.store_sales
INNER JOIN dataset.store
ON ss_store_sk = s_store_sk
WHERE s_country = 'Germany';

Es posible que la vista materializada no sea tan eficiente como la consulta original. Para obtener los mejores resultados, experimenta con un conjunto representativo de consultas, con y sin la vista materializada.

Usar vistas materializadas con la opción max_staleness

La opción de max_stalenessvista materializada te ayuda a conseguir un rendimiento de las consultas alto y constante con costes controlados al procesar conjuntos de datos grandes que cambian con frecuencia. Con el parámetro max_staleness, puedes reducir el coste y la latencia de tus consultas si estableces un intervalo de tiempo en el que se acepte la obsolescencia de los datos de los resultados de las consultas. Este comportamiento puede ser útil para los paneles de control y los informes en los que no es esencial que los resultados de las consultas estén totalmente actualizados.

Antigüedad de los datos

Cuando consultas una vista materializada con la opción max_staleness definida, BigQuery devuelve el resultado en función del valor de max_staleness y de la hora en la que se produjo la última actualización.

Si la última actualización se produjo en el intervalo max_staleness, BigQuery devuelve los datos directamente desde la vista materializada sin leer las tablas base. Por ejemplo, esto se aplica si el intervalo de max_staleness es de 4 horas y la última actualización se produjo hace 2 horas.

Si la última actualización se produjo fuera del intervalo max_staleness, BigQuery lee los datos de la vista materializada, los combina con los cambios realizados en la tabla base desde la última actualización y devuelve el resultado combinado. Este resultado combinado puede seguir estando obsoleto hasta tu max_staleness intervalo. Por ejemplo, esto se aplica si el intervalo de max_staleness es de 4 horas y la última actualización se produjo hace 7 horas.

Opción Crear con max_staleness

Selecciona una de las opciones siguientes:

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

Aplicar la opción max_staleness

Puedes aplicar este parámetro a las vistas materializadas que ya tengas con la instrucción ALTER MATERIALIZED VIEW. Por ejemplo:

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

Consulta con max_staleness

Puedes consultar vistas materializadas con la opción max_staleness como lo harías con cualquier otra vista materializada, vista lógica o tabla.

Por ejemplo:

SELECT * FROM  project-id.my_dataset.my_mv_table

Esta consulta devuelve los datos de la última actualización si no son anteriores al parámetro max_staleness. Si la vista materializada no se ha actualizado en el intervalo max_staleness, BigQuery combina los resultados de la última actualización disponible con los cambios de la tabla base para devolver los resultados en el intervalo max_staleness.

Streaming de datos y resultados de max_staleness

Si insertas datos en las tablas base de una vista materializada con la opción max_staleness, es posible que la consulta de la vista materializada excluya los registros que se insertaron en sus tablas antes del inicio del intervalo de obsolescencia. Por lo tanto, una vista materializada que incluya datos de varias tablas y la opción max_staleness podría no representar una instantánea de esas tablas en un momento concreto.

Ajuste inteligente y opción max_staleness

El ajuste inteligente reescribe automáticamente las consultas para usar vistas materializadas siempre que sea posible, independientemente de la opción max_staleness, incluso si la consulta no hace referencia a una vista materializada. La opción max_staleness de una vista materializada no afecta a los resultados de la consulta reescrita. La opción max_staleness solo afecta a las consultas que consultan directamente la vista materializada.

Gestionar la obsolescencia y la frecuencia de actualización

Debes definir max_staleness en función de tus requisitos. Para evitar leer datos de las tablas base, configure el intervalo de actualización de forma que la actualización se produzca dentro del intervalo de obsolescencia. Puedes tener en cuenta el tiempo de ejecución medio de la actualización más un margen de crecimiento.

Por ejemplo, si se necesita una hora para actualizar la vista materializada y quieres un margen de una hora para el crecimiento, debes definir el intervalo de actualización en dos horas. De esta forma, la actualización se produce dentro del plazo máximo de cuatro horas de antigüedad de los datos del informe.

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;

Vistas materializadas no incrementales

Las vistas materializadas no incrementales admiten la mayoría de las consultas SQL, incluidas las cláusulas OUTER JOIN, UNION y HAVING, así como las funciones analíticas. Para determinar si se ha usado una vista materializada en tu consulta, comprueba las estimaciones de costes mediante una prueba sin ejecución. En los casos en los que se puede tolerar que los datos no estén actualizados (por ejemplo, en el procesamiento de datos por lotes o en la creación de informes), las vistas materializadas no incrementales pueden mejorar el rendimiento de las consultas y reducir los costes. Si usas la opción max_staleness, puedes crear vistas materializadas complejas y arbitrarias que se mantienen automáticamente y que tienen garantías de obsolescencia integradas.

Usar vistas materializadas no incrementales

Puede crear vistas materializadas no incrementales mediante la opción allow_non_incremental_definition. Esta opción debe ir acompañada de la opción max_staleness. Para asegurarte de que la vista materializada se actualice periódicamente, también debes configurar una política de actualización. Si no hay una política de actualización, debes actualizar manualmente la vista materializada.

La vista materializada siempre representa el estado de las tablas base en el intervalo max_staleness. Si la última actualización es demasiado antigua y no representa las tablas base del intervalo max_staleness, la consulta lee las tablas base. Para obtener más información sobre las posibles implicaciones en el rendimiento, consulta Datos obsoletos.

Crear con allow_non_incremental_definition

Para crear una vista materializada con la opción allow_non_incremental_definition, sigue estos pasos. Una vez que haya creado la vista materializada, no podrá modificar la opción allow_non_incremental_definition. Por ejemplo, no puede cambiar el valor true a false ni quitar la opción allow_non_incremental_definition de la vista materializada.

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

Consulta con allow_non_incremental_definition

Puedes consultar vistas materializadas no incrementales como cualquier otra vista materializada, vista lógica o tabla.

Por ejemplo:

SELECT * FROM  my_project.my_dataset.my_mv_table

Si los datos no son anteriores al parámetro max_staleness, esta consulta devuelve los datos de la última actualización. Para obtener más información sobre la antigüedad y la actualidad de los datos, consulta el artículo Antigüedad de los datos.

Limitaciones específicas de las vistas materializadas no incrementales

Las siguientes limitaciones solo se aplican a las vistas materializadas con la opción allow_non_incremental_definition. A excepción de las limitaciones de la sintaxis de consulta admitida, se aplican todas las limitaciones de las vistas materializadas.

• El ajuste inteligente no se aplica a las vistas materializadas que incluyen la opción allow_non_incremental_definition. La única forma de beneficiarse de las vistas materializadas con la opción allow_non_incremental_definition es consultarlas directamente.
• Las vistas materializadas sin la opción allow_non_incremental_definition pueden actualizar de forma incremental un subconjunto de sus datos. Las vistas materializadas con la opción allow_non_incremental_definition deben actualizarse por completo.
• Las vistas materializadas con la opción max_staleness validan la presencia de las restricciones de seguridad a nivel de columna durante la ejecución de la consulta. Consulta más detalles sobre este tema en el artículo Control de acceso a nivel de columna.

Siguientes pasos

• Gestionar vistas materializadas.
• Usa vistas materializadas.