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 Spark de Lakeflow.

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

Para las vistas materializadas definidas mediante canalizaciones declarativas de Spark 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.

Note

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 transaction_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:

Important

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.
• Los orígenes de datos con filtros de fila o máscaras de columna definidos no admiten la actualización incremental. Consulte Filtros de fila y máscaras de columna.

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

Cuando se actualiza una vista materializada, puede especificar una actualización o una actualización completa.

• Una actualización intenta realizar una actualización incremental, pero realizará una recompute completa de los datos si es necesario. La actualización incremental solo está disponible cuando el proceso al que está conectado es sin servidor.
• Una actualización completa siempre vuelve a calcular todas las entradas a la vista materializada y restablece todos los puntos de control.

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

Actualización predeterminada

La actualización predeterminada de una vista materializada en intentos sin servidor de realizar una 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. Si no es posible una actualización incremental o el proceso conectado es clásico en lugar de sin servidor, se realiza una recompute completa.

La salida de una actualización incremental y una recompute completa son las mismas. Azure Databricks ejecuta un análisis de costos para elegir la opción más barata entre una actualización incremental y una recompute completa.

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 vuelven a calcular completamente.

Al crear vistas materializadas con una instancia de SQL Warehouse o canalizaciones declarativas de Spark de Lakeflow sin servidor, Azure Databricks las actualiza incrementalmente si se admiten sus consultas. Si una consulta usa expresiones no admitidas, Azure Databricks ejecuta una recompute completa en su lugar, lo que puede aumentar los costos.

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 borrando la tabla y los puntos de control y reprocesando todos los datos disponibles en el origen.

Para realizar una actualización completa de las vistas materializadas definidas mediante Databricks SQL, use la sintaxis siguiente:

REFRESH MATERIALIZED VIEW mv_name FULL

Para las vistas materializadas definidas en las canalizaciones declarativas de Lakeflow Spark, puede optar por ejecutar una actualización completa sobre los conjuntos de datos seleccionados o sobre todos los conjuntos de datos de la canalización. Consulte Semántica de la actualización de canalización.

Important

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. Esto también puede cambiar el esquema de las columnas que ya no existen en los datos de origen.

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.

Important

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	Yes
WITH	Sí, se admiten expresiones de tabla comunes.
UNION ALL*	Yes
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*	Yes
LEFT OUTER JOIN*	Yes
FULL OUTER JOIN*	Yes
RIGHT OUTER JOIN*	Yes
OVER	Yes. PARTITION_BY Las columnas deben especificarse para incrementar en las funciones de ventana.
QUALIFY	Yes
EXPECTATIONS	Sí, las vistas materializadas que incluyen expectativas se pueden actualizar incrementalmente. Sin embargo, no se admite la actualización incremental para los casos siguientes: Cuando la vista materializada lee de una vista que contiene expectativas. Cuando la vista materializada tiene una DROP expectativa e incluye NOT NULL columnas en su esquema.
Funciones no deterministas	Las funciones de hora no deterministas se admiten en WHERE cláusulas . Esto incluye funciones como current_date(), current_timestamp()y now(). No se admiten otras funciones no deterministas.
Orígenes no delta	No se admiten fuentes como volúmenes externos, ubicaciones externas y catálogos externos.

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:

Technique	¿Actualización incremental?	Description
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	Yes	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 canalizaciones declarativas de Spark 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:

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

Consulte Registro de eventos de canalización.