Actualización incremental para obtener vistas materializadas

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 actualizaciones se ejecutan en un proceso sin servidor

Las operaciones de actualización se ejecutan en canalizaciones sin servidor, independientemente de si la operación se definió en Databricks SQL o con canalizaciones declarativas de Lakeflow.

En el caso de las vistas materializadas definidas mediante Databricks SQL, no es necesario habilitar el área de trabajo para las canalizaciones declarativas de Lakeflow sin servidor. La actualización se realizará automáticamente mediante una canalización sin servidor.

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

¿Cuál es 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 agregada.

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 REPLACE 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 estaría prohibida debido al costo, use tablas de streaming para garantizar el procesamiento exactamente una vez. Entre los ejemplos se incluyen tablas muy grandes.
• No defina una vista materializada contra 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 necesita conservar la información en las tablas posteriores. Por ejemplo, una tabla particionada por 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 Unity Catalog y las tablas externas basadas en Delta Lake.
  • Vistas materializadas.
  • Tablas de streaming, incluidos los destinos de las operaciones AUTO CDC ... INTO.
• 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 es compatible con las tablas Delta, que incluyen vistas materializadas, tablas de streaming y tablas administradas del Unity Catalog. 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:

• Vectores de eliminación
• Seguimiento de filas
• Cambio de fuente de distribución de datos

Estas características se pueden establecer durante la creación o más tarde con la instrucción ALTER TABLE. Por ejemplo:

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

Tipos de actualización para las vistas materializadas

Las actualizaciones de las 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 Canalizaciones declarativas de Lakeflow, puede optar por ejecutar una actualización completa en los conjuntos de datos seleccionados o en todos los conjuntos de datos de una canalización. Consulte Semántica de la actualización de canalización.

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:

Puede deshabilitar opcionalmente las actualizaciones completas en una tabla estableciendo la propiedad de la tabla en pipelines.reset.allowedfalse.

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 un almacén de datos SQL o las canalizaciones declarativas de Lakeflow sin servidor, se actualizan de forma incremental si sus consultas son compatibles. 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 vistas materializadas

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.
Funciones no deterministas	No. No se admiten funciones no deterministas, por ejemplo CURRENT_DATE, .
Orígenes no delta	No se admiten volúmenes, ubicaciones externas y catálogos extranjeros.

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.
Cualquiera de: ROW_BASED PARTITION_OVERWRITE WINDOW_FUNCTION APPEND_ONLY GROUP_AGGREGATE GENERIC_AGGREGATE	Sí	La vista materializada se actualizó de forma incremental mediante la técnica especificada.

Para determinar la técnica utilizada, consulte el registro de eventos de canalizaciones declarativas de Lakeflow donde 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.

Salida de ejemplo para este comando:

• • marca de tiempo
  • Mensaje
• • 2025-03-21T22:23:16.497+00:00
  • Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.

Ver ¿Qué es el registro de eventos de canalizaciones declarativas de Lakeflow?.