Compartir a través de

Actualización incremental para vistas materializadas

  • Artículo

En este artículo se describe la semántica y los requisitos para las actualizaciones incrementales en vistas materializadas e identifica las operaciones, palabras clave y cláusulas SQL que admiten la actualización incremental. Incluye la explicación de las diferencias entre las actualizaciones incrementales y completas, e incluye recomendaciones para elegir entre vistas materializadas y tablas de streaming.

Al ejecutar actualizaciones en vistas materializadas mediante canalizaciones sin servidor, se pueden actualizar incrementalmente muchas consultas. Las actualizaciones incrementales ahorran costos de proceso mediante la detección de cambios en los orígenes de datos usados para definir la vista materializada y calcular incrementalmente el resultado.

Las canalizaciones sin servidor son necesarias para la actualización incremental

La actualización incremental para las vistas materializadas requiere canalizaciones sin servidor.

Las operaciones de actualización para vistas materializadas definidas en Databricks SQL siempre se ejecutan mediante canalizaciones sin servidor.

Para las vistas materializadas definidas mediante canalizaciones de Delta Live Tables, debe configurar la canalización para que use sin servidor. Consulte Configuración de una canalización de Delta Live Tables sin servidor.

¿Cuáles son la semántica de actualización para las vistas materializadas?

Las vistas materializadas garantizan resultados equivalentes a las consultas por lotes. Por ejemplo, considere la siguiente consulta de agregado:

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Al ejecutar esta consulta mediante cualquier producto de Azure Databricks, el resultado se calcula mediante la semántica por lotes para agregar todos los registros del origen transactions_table, lo que significa que todos los datos de origen se examinan y agregan en una sola operación.

Nota:

Algunos productos de Azure Databricks almacenan en caché los resultados automáticamente dentro o entre sesiones si los orígenes de datos no han cambiado después de que se haya ejecutado la última consulta. Los comportamientos de almacenamiento en caché automático difieren de las vistas materializadas.

En el ejemplo siguiente se convierte esta consulta por lotes en una vista materializada:

CREATE OR REFRESH MATERIALIZED VIEW transation_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Al actualizar una vista materializada, el resultado calculado es idéntico a la semántica de consulta por lotes. Esta consulta es un ejemplo de una vista materializada que se puede actualizar incrementalmente, lo que significa que la operación de actualización realiza un mejor intento de procesar solo los datos nuevos o modificados en el transactions_table origen para calcular los resultados.

Consideraciones sobre orígenes de datos para vistas materializadas

Aunque puede definir una vista materializada en cualquier origen de datos, no todos los orígenes de datos son adecuados para las vistas materializadas. Tenga en cuenta las siguientes advertencias y recomendaciones:

Importante

Las vistas materializadas realizan un mejor intento de actualizar los resultados incrementalmente para las operaciones admitidas. Algunos cambios en los orígenes de datos requieren una actualización completa.

Todos los orígenes de datos para vistas materializadas deben ser sólidos para la semántica de actualización completa, incluso si la consulta que define la vista materializada admite la actualización incremental.

  • En el caso de las consultas en las que una actualización completa sería prohibitiva, use tablas de streaming para garantizar el procesamiento exactamente una vez. Entre los ejemplos se incluyen tablas muy grandes.
  • No defina una vista materializada en un origen de datos si los registros solo se deben procesar una vez. En su lugar, use tablas de streaming. Entre los ejemplos se incluyen los siguientes:
    • Orígenes de datos que no conservan el historial de datos, como Kafka.
    • Operaciones de ingesta, como las consultas que usan Auto Loader para ingerir datos del almacenamiento de objetos en la nube.
    • Cualquier origen de datos en el que planee eliminar o archivar los datos después del procesamiento, pero debe conservar la información en las tablas de bajada. Por ejemplo, una tabla con particiones de fecha en la que planea eliminar registros anteriores a un umbral determinado.
  • No todos los orígenes de datos admiten actualizaciones incrementales. Los orígenes de datos siguientes admiten la actualización incremental:
    • Tablas delta, incluidas las tablas administradas por el catálogo de Unity y las tablas externas respaldadas por Delta Lake.
    • Vistas materializadas.
    • Tablas de streaming, incluidos los destinos de APPLY CHANGES INTO las operaciones.
  • Algunas operaciones de actualización incremental requieren que el seguimiento de filas esté habilitado en los orígenes de datos consultados. El seguimiento de filas es una característica de Delta Lake que solo admite las tablas delta, que incluyen vistas materializadas, tablas de streaming y tablas administradas del catálogo de Unity. Ver Usar seguimiento de filas para tablas Delta.

Optimización de vistas materializadas

Para obtener el mejor rendimiento, Databricks recomienda habilitar las siguientes características en todas las tablas de origen de vistas materializadas:

Tipos de actualización para vistas materializadas

Las actualizaciones a vistas materializadas son completas o incrementales. Para todas las operaciones, los resultados de una actualización incremental y la actualización completa son los mismos. Azure Databricks ejecuta un análisis de costos para identificar si los cambios en los orígenes de datos requieren una actualización completa.

Para determinar qué tipo de actualización se usa, consulte Determinar el tipo de actualización de una actualización.

Actualización completa

Una actualización completa sobrescribe los resultados en la vista materializada mediante el reprocesamiento de todos los datos disponibles en el origen. Todas las vistas materializadas pueden actualizarse completamente en cualquier actualización determinada, en función de cómo hayan cambiado los orígenes de datos.

Opcionalmente, puede forzar una actualización completa. Para las vistas materializadas definidas mediante Databricks SQL, use la sintaxis siguiente:

REFRESH MATERIALIZED VIEW mv_name FULL

Para las vistas materializadas definidas en una canalización de Delta Live Tables, puede optar por ejecutar una actualización completa en conjuntos de datos seleccionados o en todos los conjuntos de datos de una canalización. Consulte How Delta Live Tables updates tables and views (Cómo delta Live Tables actualiza las tablas y vistas).

Importante

Cuando se ejecuta una actualización completa en un origen de datos donde se han quitado los registros debido al umbral de retención de datos o a la eliminación manual, los registros eliminados no se reflejan en los resultados calculados. Es posible que no pueda recuperar datos antiguos si los datos ya no están disponibles en el origen.

Nota:

Opcionalmente, puede deshabilitar las actualizaciones completas en una tabla estableciendo la propiedad pipelines.reset.allowed falsetable en .

Actualización incremental

Una actualización incremental procesa los cambios en los datos subyacentes después de la última actualización y, a continuación, anexa esos datos a la tabla. Según las tablas base y las operaciones incluidas, solo se pueden actualizar incrementalmente determinados tipos de vistas materializadas.

Solo las vistas materializadas actualizadas mediante canalizaciones sin servidor pueden usar la actualización incremental. Las vistas materializadas que no usan canalizaciones sin servidor siempre se actualizan completamente.

Cuando se crean vistas materializadas mediante una canalización de SQL Warehouse o Delta Live Tables sin servidor, se actualizan de forma incremental automáticamente si se admiten sus consultas. Si una consulta incluye expresiones no admitidas para una actualización incremental, se realiza una actualización completa, lo que podría provocar costos adicionales.

Compatibilidad con la actualización incremental de vista materializada

En la tabla siguiente, se muestra la compatibilidad con la actualización incremental por palabra clave o cláusula SQL.

Importante

Algunas palabras clave y cláusulas requieren que el seguimiento de filas esté habilitado en los orígenes de datos consultados. Ver Usar seguimiento de filas para tablas Delta.

Estas palabras clave y cláusulas se marcan con una estrella (*) en la tabla siguiente.

Palabra clave o cláusula SQL Compatibilidad con la actualización incremental
Expresiones* SELECT Sí, se admiten expresiones que incluyen funciones integradas deterministas e inmutables funciones definidas por el usuario (UDF).
GROUP BY Sí
WITH Sí, se admiten expresiones de tabla comunes.
UNION ALL* Sí
FROM Las tablas base admitidas incluyen tablas Delta, vistas materializadas y tablas de streaming.
WHERE, HAVING* Se admiten cláusulas de filtro como WHERE y HAVING.
INNER JOIN* Sí
LEFT OUTER JOIN* Sí
FULL OUTER JOIN* Sí
RIGHT OUTER JOIN* Sí
OVER Sí. PARTITION_BY Las columnas deben especificarse para incrementar en las funciones de ventana.
QUALIFY Sí
EXPECTATIONS No. Las vistas materializadas que usan expectativas siempre se actualizan completamente.

Nota:

No se admiten funciones no deterministas, por ejemplo, CURRENT_TIMESTAMP.

Determinar el tipo de actualización de una actualización

Para optimizar el rendimiento de las actualizaciones de las vistas materializadas, Azure Databricks usa un modelo de costo para seleccionar la técnica utilizada para la actualización. En la tabla siguiente se describen estas técnicas:

Técnica ¿Actualización incremental? Descripción
FULL_RECOMPUTE No La vista materializada se volvió a calcular completamente
NO_OP No aplicable La vista materializada no se actualizó porque no se detectaron cambios en la tabla base.
ROW_BASED o PARTITION_OVERWRITE Sí La vista materializada se actualizó de manera incremental mediante la técnica especificada.

Para determinar la técnica utilizada, consulte el registro de eventos de Delta Live Tables donde el event_type es planning_information:

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

Reemplace <fully-qualified-table-name> por el nombre completo de la vista materializada, incluido el catálogo y el esquema.

Consulte ¿Qué es el registro de eventos de Delta Live Tables?.