Uso de vistas materializadas en Databricks SQL

En este artículo se describe cómo crear y actualizar vistas materializadas en Databricks SQL para mejorar el rendimiento y reducir el costo de las cargas de trabajo de procesamiento y análisis de datos.

¿Qué son las vistas materializadas?

En Databricks SQL, las vistas materializadas son tablas administradas por el catálogo de Unity que almacenan físicamente los resultados de una consulta. A diferencia de las vistas estándar, que calculan los resultados a petición, las vistas materializadas almacenan en caché los resultados y los actualizan a medida que cambian las tablas de origen subyacentes, ya sea según una programación o automáticamente.

Las vistas materializadas son adecuadas para cargas de trabajo de procesamiento de datos, como el procesamiento de extracción, transformación y carga (ETL). Las vistas materializadas proporcionan una manera simple y declarativa de procesar datos de cumplimiento, correcciones, agregaciones o captura de datos modificados (CDC) generales. Las vistas materializadas también permiten transformaciones fáciles de usar mediante la limpieza, el enriquecimiento y la desnormalización de las tablas base. Al calcular previamente consultas costosas o usadas con frecuencia, las vistas materializadas reducen la latencia de consulta y el consumo de recursos. En muchos casos, pueden calcular incrementalmente los cambios de las tablas de origen, mejorando aún más la eficacia y la experiencia del usuario final.

A continuación se muestran casos de uso comunes para vistas materializadas:

Mantener actualizado un panel de BI con una latencia mínima de consultas de usuario final.
Reducción de la orquestación ETL compleja con lógica SQL simple.
Creación de transformaciones complejas y superpuestas.
Los casos de uso que exigen un rendimiento coherente con información actualizada.

Al crear una vista materializada en una instancia de Databricks SQL Warehouse, se crea una canalización sin servidor para procesar la creación y actualización de la vista materializada. Puede supervisar el estado de las operaciones de actualización en el Explorador de catálogos. Consulte Ver detalles con DESCRIBE EXTENDED.

Requisitos

Las vistas materializadas creadas en Databricks SQL están respaldadas por una canalización sin servidor. El área de trabajo debe admitir canalizaciones sin servidor para usar esta funcionalidad.

Requisitos para crear o actualizar vistas materializadas:

Debe utilizar un almacén pro o SQL sin servidor habilitado para Unity Catalog.
Para actualizar una vista materializada, debe estar en el área de trabajo que la creó.
Para actualizar incrementalmente una vista materializada de tablas Delta, las tablas de origen deben tener habilitado el seguimiento de filas.
El propietario (el usuario que crea la vista materializada) debe tener los permisos siguientes:
- Privilegio SELECT en las tablas base a las que hace referencia la vista materializada.
- Privilegios USE CATALOG y USE SCHEMA en el catálogo y el esquema que contiene las tablas de origen para la vista materializada.
- Privilegios USE CATALOG y USE SCHEMA en el esquema y catálogo de destino de la vista materializada.
- Privilegios CREATE TABLE y CREATE MATERIALIZED VIEW en el esquema que contiene la vista materializada.
Para actualizar una vista materializada, debe tener el privilegio REFRESH en la vista materializada.

El área de trabajo debe estar en una región que admita almacenes de SQL sin servidor.

Requisitos para consultar vistas materializadas:

Debe ser el propietario de la vista materializada o tener SELECT en la vista materializada, junto con USE SCHEMA y USE CATALOG en sus elementos primarios.
Debe usar uno de los siguientes recursos de proceso:
- Almacén de SQL
- Interfaces de canalizaciones declarativas de Spark de Lakeflow
- Proceso del modo de acceso estándar (anteriormente modo de acceso compartido)
- Modo de acceso dedicado (anteriormente modo de acceso de usuario único) en Databricks Runtime 15.4 y versiones posteriores, siempre y cuando el área de trabajo esté habilitada para el proceso sin servidor. Consulte Control de acceso detallado en la computación dedicada.
  
  Si es el propietario de la vista materializada puede usar un recurso de proceso en modo de acceso dedicado que ejecuta Databricks Runtime entre 14.3 y versiones posteriores.

Para obtener información sobre otras restricciones sobre el uso de vistas materializadas, consulte Limitaciones.

Crear una vista materializada

Las operaciones CREATE de la vista materializada de Databricks SQL usan un almacén de Databricks SQL para crear y cargar datos en la vista materializada. La creación de una vista materializada es una operación sincrónica, lo que significa que el comando CREATE MATERIALIZED VIEW se bloquea hasta que se crea la vista materializada y finaliza la carga de datos inicial. Se crea automáticamente una canalización sin servidor para cada vista materializada de Databricks SQL. Cuando se actualiza la vista materializada, la canalización procesa la actualización.

Para crear una vista materializada, use la instrucción CREATE MATERIALIZED VIEW. Para enviar una instrucción crear, use el editor de SQL en la interfaz de usuario de Azure Databricks, la CLI de SQL de Databrickso la API de SQL de Databricks.

El usuario que crea una vista materializada es el propietario de la vista materializada.

En el ejemplo siguiente se crea la vista materializada mv1 a partir de la tabla base base_table1:

-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Al crear una vista materializada mediante la instrucción CREATE OR REPLACE MATERIALIZED VIEW, la actualización inicial de datos y el recopilación comienzan inmediatamente. Esto no consume recursos computacionales de la SQL Warehouse. En su lugar, se usa una canalización sin servidor para la creación y las actualizaciones posteriores.

Los comentarios de columna en una tabla base se propagan automáticamente a la nueva vista materializada solo en la creación. Para agregar una programación, restricciones de tabla u otras propiedades, modifique la definición de vista materializada (la consulta SQL).

La misma instrucción SQL actualizará una vista materializada si se ejecuta nuevamente o según un horario establecido. Una actualización realizada de esta manera actúa como cualquier otra actualización. Para obtener más información, consulte Actualizar una vista materializada.

Para más información sobre cómo configurar una vista materializada, consulte Configuración de vistas materializadas en Databricks SQL. Para obtener información sobre la sintaxis completa para crear una vista materializada, consulte CREATE MATERIALIZED VIEW. Para obtener información sobre cómo cargar datos en diferentes formatos y desde diferentes lugares, consulte Carga de datos en canalizaciones.

Carga de datos desde sistemas externos

Las vistas materializadas se pueden crear en datos externos utilizando la federación de Lakehouse para orígenes de datos admitidos. Para obtener información sobre cómo cargar datos de orígenes no admitidos por la federación de Lakehouse, consulte Opciones de formato de datos. Para obtener información general sobre cómo cargar datos, incluidos ejemplos, consulte Carga de datos en canalizaciones.

Ocultar datos confidenciales

Puede usar vistas materializadas para ocultar datos confidenciales de los usuarios que acceden a la tabla. Una manera de hacerlo es crear la consulta para que no incluya esos datos en primer lugar. Pero también puede enmascarar columnas o filtrar filas en función de los permisos del usuario que realiza la consulta. Por ejemplo, podría ocultar la tax_id columna para los usuarios que no están en el grupo HumanResourcesDept. Para ello, use las sintaxis ROW FILTER y MASK durante la creación de la vista materializada. Para obtener más información, consulte Filtros de fila y máscaras de columna.

Actualizar una vista materializada

Actualizar una vista materializada actualiza la vista para reflejar los cambios más recientes en la tabla base en el momento de la actualización.

Al definir una vista materializada, la CREATE OR REPLACE MATERIALIZED VIEW instrucción se usa para crear la vista y para actualizarla para las actualizaciones programadas. También puede usar la REFRESH MATERIALIZED VIEW instrucción para actualizar la vista materializada sin necesidad de volver a proporcionar la consulta. Consulte REFRESH (MATERIALIZED VIEW o STREAMING TABLE) para obtener más información sobre la sintaxis y los parámetros de SQL para este comando. Para obtener más información sobre los tipos de vistas materializadas que se pueden actualizar incrementalmente, consulte Actualización incremental para vistas materializadas.

Para enviar una instrucción de actualización, use el editor de SQL en la interfaz de usuario de Azure Databricks, un cuaderno asociado a un almacenamiento de SQL, el CLI de SQL de Databrickso la API de SQL de Databricks.

El propietario y cualquier usuario al que se le haya concedido el privilegio REFRESH en la tabla, puede actualizar la vista materializada.

En el ejemplo siguiente se actualiza la vista materializada mv1:

REFRESH MATERIALIZED VIEW mv1;

La operación es sincrónica de forma predeterminada, lo que significa que el comando se bloquea hasta que se complete la operación de actualización. Para actualizar de forma asincrónica, puede agregar la ASYNC palabra clave :

REFRESH MATERIALIZED VIEW mv1 ASYNC;

¿Cómo se actualizan las vistas materializadas de Databricks SQL?

Las vistas materializadas crean y usan automáticamente canalizaciones sin servidor para procesar las operaciones de actualización. La canalización administra la actualización y Databricks SQL Warehouse supervisa la actualización para crear la vista materializada. Las vistas materializadas se pueden actualizar mediante una canalización que se ejecuta según una programación. Las vistas materializadas creadas por Databricks SQL siempre se ejecutan en modo desencadenado. Consulte Desencadenado frente al modo de canalización continua.

Las vistas materializadas se actualizan mediante uno de los dos métodos.

Actualización incremental : el sistema evalúa la consulta de la vista para identificar los cambios que se produjeron después de la última actualización y combina solo los datos nuevos o modificados.
Actualización completa : si no se puede realizar una actualización incremental o no es rentable, el sistema ejecuta toda la consulta y reemplaza los datos existentes en la vista materializada por los nuevos resultados.

La estructura de la consulta y el tipo de datos de origen determinan si se admite la actualización incremental. Para admitir la actualización incremental, los datos de origen deben almacenarse en tablas Delta, con el seguimiento de filas y la fuente de distribución de datos de cambios habilitada. Para ver si una consulta es incrementalizable, use la instrucción SQL EXPLAIN CREATE MATERIALIZED VIEW de Databricks. Después de crear una vista materializada, puede supervisar su comportamiento de actualización para comprobar si se actualiza incrementalmente o a través de una actualización completa.

De forma predeterminada, Azure Databricks usa un modelo de costo para elegir la opción más rentable entre la actualización completa e incremental. Puede invalidar este comportamiento para preferir las actualizaciones incrementales o completas estableciendo una REFRESH POLICY en la definición de SQL de la vista materializada.

Para obtener más información sobre los tipos de actualización y cómo optimizar las actualizaciones incrementales, consulte Actualización incremental para vistas materializadas.

Actualizaciones asincrónicas

De forma predeterminada, las operaciones de actualización se realizan de forma sincrónica. También puede establecer una operación de actualización para que se produzca de forma asincrónica. Esto se puede establecer mediante el comando refresh con la ASYNC palabra clave . Consulta REFRESH (MATERIALIZED VIEW o STREAMING TABLE). El comportamiento asociado a cada enfoque es el siguiente:

Sincrónico: una actualización sincrónica impide que otras operaciones continúen hasta que se complete la actualización. Si el resultado es necesario para el siguiente paso, como al secuenciar operaciones de actualización en herramientas de orquestación como Trabajos de Lakeflow, use una actualización sincrónica. Para organizar vistas materializadas con un trabajo, use el tipo de tarea SQL. Consulte Trabajos de Lakeflow.
Asincrónico: una actualización asincrónica inicia un trabajo en segundo plano en computación sin servidor cuando comienza una actualización de vista materializada, lo que permite que el comando se complete antes de que la carga de datos se finalice. Este tipo de actualización puede ahorrar costos porque la operación no necesariamente requiere capacidad de cómputo en el almacén donde se inicia el comando. Si la actualización se vuelve inactiva y no se está ejecutando ninguna otra tarea, el almacenamiento puede apagarse mientras la actualización usa otro proceso disponible. Además, las actualizaciones asincrónicas admiten iniciar varias operaciones en paralelo.

Actualización de la vista materializada de programación

Puede configurar una vista materializada de Databricks SQL para actualizarse automáticamente en función de una programación definida o desencadenarse cuando se cambian los datos ascendentes. En la tabla siguiente se muestran las distintas opciones para programar actualizaciones.

Método	Description	Ejemplo de caso de uso
Manual	Actualización a petición mediante una instrucción SQL `REFRESH` o a través de la interfaz de usuario del área de trabajo.	Desarrollo, pruebas, actualizaciones ad hoc.
`TRIGGER ON UPDATE`	Defina la vista materializada para actualizar automáticamente cuando cambian los datos ascendentes.	Cargas de trabajo de producción con SLA de frescura de datos o períodos de actualización impredecibles.
`SCHEDULE`	Defina la vista materializada para actualizar en intervalos de tiempo definidos.	Requisitos de actualización predecibles y basados en tiempo.
Tarea SQL en un trabajo	La actualización se orquesta a través de Lakeflow Jobs.	Canalizaciones complejas con dependencias entre sistemas.

Actualización manual

Para actualizar manualmente una vista materializada, puede realizar una actualización desde Databricks SQL o usar la interfaz de usuario del área de trabajo.

Instrucción REFRESH

Para actualizar una canalización mediante Databricks SQL:

En el Editor de SQL, ejecute la instrucción siguiente:
```
REFRESH MATERIALIZED VIEW <mv-name>;
```

Para obtener más información, vea REFRESH (MATERIALIZED VIEW o STREAMING TABLE).

Interfaz de usuario del área de trabajo

Para refrescar una canalización en la interfaz de usuario del área de trabajo:

En el área de trabajo de Azure Databricks, haga clic en Trabajos y canalizaciones.
Seleccione la canalización que desea actualizar en la lista.
Haga clic en el botón de Inicio.

A medida que se actualiza la canalización, verá actualizaciones en la interfaz de usuario.

Desencadenador al actualizar

La TRIGGER ON UPDATE cláusula actualiza automáticamente una vista materializada cuando cambian los datos de origen. Esto elimina la necesidad de coordinar las programaciones entre canalizaciones. La vista materializada permanece actualizada sin necesidad de que el usuario sepa cuándo finalizan los trabajos ascendentes o mantienen una lógica de programación compleja.

Este es el enfoque recomendado para las cargas de trabajo de producción, especialmente cuando las dependencias ascendentes no se ejecutan en programaciones predecibles. Una vez configurada, la vista materializada supervisa sus tablas de origen y se actualiza automáticamente cuando se detectan cambios en cualquiera de los orígenes ascendentes.

Limitaciones

Límites de dependencia ascendente: una vista materializada puede supervisar un máximo de 10 tablas ascendentes y 30 vistas ascendentes. Para obtener más dependencias, divida la lógica entre varias vistas materializadas.
Límites del área de trabajo: puede existir un máximo de 1,000 vistas materializadas con TRIGGER ON UPDATE por área de trabajo. Póngase en contacto con el soporte técnico de Databricks si se necesitan más de 1000 vistas materializadas.
Intervalo mínimo: el intervalo de activación mínimo es de 1 minuto.

En los ejemplos siguientes se muestra cómo establecer un desencadenador al actualizar al definir una vista materializada.

Creación de una vista materializada con desencadenador al actualizar

Para crear una vista materializada que se actualice automáticamente cuando cambien los datos de origen, incluya la TRIGGER ON UPDATE cláusula en la CREATE MATERIALIZED VIEW instrucción .

En el ejemplo siguiente se crea una vista materializada que agrega pedidos de clientes y se actualiza cada vez que se actualizan el origen customers o las tablas orders.

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Limitación de la frecuencia de actualización

Si los datos ascendentes se actualizan con frecuencia, use AT MOST EVERY para limitar la frecuencia con la que la vista se actualiza y limita los costos de proceso. Esto es útil cuando las tablas de origen se actualizan con frecuencia, pero los consumidores finales no necesitan datos en tiempo real. La palabra clave INTERVAL es obligatoria antes del valor de tiempo.

En el ejemplo siguiente se limita la vista materializada para actualizarse como máximo cada 5 minutos, aunque los datos de origen cambien con más frecuencia:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Actualización programada

Las programaciones de actualización se pueden definir directamente en la definición de vista materializada para actualizar la vista en intervalos de tiempo fijos. Este enfoque es útil cuando se conoce la cadencia de actualización de datos y se desea un tiempo de actualización predecible.

Cuando hay una programación de actualización, puede seguir ejecutando una actualización manual en cualquier momento si necesita datos actualizados.

Databricks admite dos sintaxis de programación: SCHEDULE EVERY para intervalos simples y SCHEDULE CRON para programación precisa. Las SCHEDULE palabras clave y SCHEDULE REFRESH son semánticamente equivalentes.

Para obtener más información sobre la sintaxis y el uso de la SCHEDULE cláusula , vea CREATE MATERIALIZED VIEW cláusula SCHEDULE.

Cuando se crea una programación, se configura automáticamente un nuevo trabajo de Databricks para procesar la actualización.

Para ver la programación, realice una de las siguientes acciones:

Ejecute la instrucción DESCRIBE EXTENDED desde el editor de SQL en la interfaz de usuario de Azure Databricks. Consulte DESCRIBE TABLE.
Utiliza el Explorador de Catálogos para ver la vista materializada. La programación aparece en la pestaña Información general, en Estado de actualización. Consulte ¿Qué es el Explorador de catálogos?.

En los ejemplos siguientes se muestra cómo crear una vista materializada con una programación:

Programar cada intervalo de tiempo

En este ejemplo se programa una actualización una vez cada hora:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
  SCHEDULE EVERY 1 HOUR
AS SELECT
    date_trunc('hour', event_time) AS hour,
    count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;

Programación mediante cron

En este ejemplo se programa una actualización cada 15 minutos, en la hora trimestral de la zona horaria UTC:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    date_trunc('minute', event_time) AS minute,
    count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;

Tarea SQL en un trabajo

Los refrescos de vistas materializadas se pueden orquestar a través de trabajos de Databricks creando tareas SQL que incluyan comandos REFRESH MATERIALIZED VIEW. Este enfoque integra las actualizaciones de vistas materializadas en los flujos de trabajo de orquestación de trabajos existentes.

Hay dos maneras de crear un trabajo para actualizar vistas materializadas:

En el Editor de SQL: escriba el REFRESH MATERIALIZED VIEW comando y haga clic en el botón Programar para crear un trabajo directamente desde la consulta.
En la interfaz de usuario de trabajos: cree un nuevo trabajo, agregue un tipo de tarea SQL y adjunte una consulta SQL o un cuaderno con el REFRESH MATERIALIZED VIEW comando .

En el ejemplo siguiente se muestra la instrucción SQL dentro de una tarea SQL que actualiza una vista materializada:

REFRESH MATERIALIZED VIEW catalog.schema.daily_sales_summary;

Este enfoque es adecuado cuando:

Las canalizaciones complejas de varios pasos tienen dependencias entre sistemas.
Se requiere la integración con la orquestación de trabajos existente.
Se requieren alertas y supervisión a nivel de tarea.

Las tareas de SQL usan el SQL Warehouse adjunto al trabajo y el cómputo sin servidor que ejecuta el refresco. Si el uso de la programación basada en definiciones de vistas materializadas cumple los requisitos, cambiar a TRIGGER ON UPDATE o SCHEDULE puede simplificar el flujo de trabajo.

Agregar una programación a una vista materializada existente

Para establecer la programación después de la creación, use la sentencia ALTER MATERIALIZED VIEW.

-- Alters the schedule to refresh the materialized view when its upstream data
-- gets updated.
ALTER MATERIALIZED VIEW sales
  ADD TRIGGER ON UPDATE;

Modificación de una programación o desencadenador existente

Si una vista materializada ya tiene asociada una programación o un desencadenador, use ALTER SCHEDULE o ALTER TRIGGER ON UPDATE para cambiar la configuración de actualización. Esto se aplica si cambia de una programación a otra, un desencadenador a otro o si cambia entre una programación y un desencadenador.

En el ejemplo siguiente se cambia una programación existente para actualizarse cada 4 horas:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  ALTER SCHEDULE EVERY 4 HOURS;

Eliminar una programación o un disparador

Para quitar una programación, use ALTER ... DROP:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  DROP SCHEDULE;

Detener una actualización activa

Para detener una actualización activa en la interfaz de usuario de Azure Databricks, en la página Detalles de la canalización , haga clic en Detener para detener la actualización de la canalización. También puede detener la actualización con el CLI de Databricks o con la operación POST /api/2.0/pipelines/{pipeline_id}/stop en la API de Pipelines.

Tiempos de espera para las actualizaciones

Las actualizaciones de vistas materializadas se ejecutan con un tiempo de espera que limita cuánto tiempo pueden ejecutarse. En el caso de las vistas materializadas creadas o actualizadas el 14 de agosto de 2025 o después, el tiempo de espera se captura al actualizar mediante la ejecución de CREATE OR REFRESH.

Si se establece un STATEMENT_TIMEOUT, se usa ese valor. Consulte STATEMENT_TIMEOUT.
De lo contrario, se utiliza el tiempo de espera del almacén SQL para ejecutar el comando.
Si el almacén no tiene configurado un tiempo de espera, se aplica un valor predeterminado de 2 días.

El tiempo de espera se usa en la creación inicial, pero también en las actualizaciones programadas siguientes.

Para las vistas materializadas que se actualizaron por última vez antes del 14 de agosto de 2025, el tiempo de espera se establece en 2 días.

Ejemplo: Establecimiento de un tiempo de espera para una actualización de vista materializada Puede controlar explícitamente cuánto tiempo se permite ejecutar una actualización de vista materializada estableciendo un tiempo de espera de nivel de instrucción al crear o actualizar la vista:

SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH MATERIALIZED VIEW my_catalog.my_schema.my_mv
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

Esto configura la vista materializada que se actualizará cada 12 horas y, si una actualización tarda más de 6 horas, agota el tiempo de espera y espera la siguiente actualización programada.

Cómo controlan los tiempos de espera de las actualizaciones programadas

Los tiempos de espera solo se sincronizan cuando explícitamente se ejecuta CREATE OR REFRESH.

Las actualizaciones programadas continúan usando el tiempo límite capturado durante la última ejecución CREATE OR REFRESH.
El cambio del tiempo de espera de almacenamiento por sí solo no afecta a las actualizaciones programadas existentes.

Importante

Después de cambiar un tiempo de espera de almacenamiento, vuelva a ejecutar CREATE OR REFRESH para aplicar el nuevo tiempo de espera a futuras actualizaciones programadas.

Eliminar permanentemente registros de una vista materializada con vectores de eliminación habilitados

Importante

La compatibilidad con la instrucción REORG con vistas materializadas está en versión preliminar pública.

Nota:

El uso de una instrucción REORG con una vista materializada requiere Databricks Runtime 15.4 y versiones posteriores.
Aunque puede usar la sentencia REORG con cualquier vista materializada, solo es necesario al eliminar registros de una vista materializada que tiene los vectores de eliminación habilitados. El comando no tiene ningún efecto cuando se usa con una vista materializada sin vectores de eliminación habilitados.

Para eliminar físicamente los registros del almacenamiento subyacente para una vista materializada con vectores de eliminación habilitados, como para el cumplimiento del RGPD, se deben realizar pasos adicionales para garantizar que una VACUUM operación se ejecute en los datos de la vista materializada.

Para eliminar físicamente los registros:

Ejecute una instrucción REORG en la vista materializada y especifique el parámetro APPLY (PURGE). Por ejemplo, REORG TABLE <materialized-view-name> APPLY (PURGE);. Consulte REORG TABLE.
Espere a que pase el período de retención de datos de la vista materializada. El período de retención de datos predeterminado es siete días, pero se puede configurar con la propiedad delta.deletedFileRetentionDuration tabla. Consulte Configurar la retención de datos para consultas de viajes en el tiempo.
REFRESH la vista materializada. Consulte Actualizar una vista materializada. En un plazo de 24 horas a partir de la REFRESH operación, las tareas de mantenimiento de canalización, incluida la VACUUM operación necesaria para asegurarse de que los registros se eliminan permanentemente, se ejecutan automáticamente.

Quitar una vista materializada

Nota:

Para enviar el comando para quitar una vista materializada, debe ser el propietario de esa vista materializada o tener el privilegio MANAGE en la vista materializada.

Para quitar una vista materializada, use la instrucción DROP VIEW. Para enviar una instrucción DROP, puede usar el editor de SQL en la interfaz de usuario de Azure Databricks, la CLI de SQL de Databrickso la API de SQL de Databricks. En el ejemplo siguiente se anula la vista materializada mv1:

DROP MATERIALIZED VIEW mv1;

También puede usar el Explorador de Catálogos para colocar una vista materializada.

Haga clic en Catálogo en la barra lateral.
En el árbol del Explorador de catálogos de la izquierda, abra el catálogo y seleccione el esquema donde se encuentra la vista materializada.
Abra el elemento Tablas en el esquema seleccionado y haga clic en la vista materializada.
En el , seleccione Eliminar.

Entender los costos de una vista materializada

Dado que una vista materializada se ejecuta en un cómputo sin servidor, fuera del cómputo que configuró para un cuaderno o trabajo, puede preguntarse cómo comprender los costos asociados a la vista materializada. El uso de la vista materializada se rastrea mediante el consumo de DBU. Para más información, consulte ¿Qué es el consumo de DBU de una vista materializada o una tabla de streaming?

Habilitar el seguimiento de filas

Para admitir actualizaciones incrementales de tablas Delta, el seguimiento de filas debe estar habilitado para esas tablas de origen. Si vuelve a crear una tabla de origen, debe volver a habilitar el seguimiento de filas.

En el ejemplo siguiente se muestra cómo habilitar el seguimiento de filas en una tabla:

ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

Para más información, consulte Seguimiento de filas en Databricks.

Limitaciones

Para conocer los requisitos de proceso y área de trabajo, consulte Requisitos.
Para conocer los requisitos de actualización incremental, consulte Actualización incremental para vistas materializadas.
Las vistas materializadas no admiten columnas de identidad ni claves suplentes.
Si una vista materializada usa un agregado de suma en una columna que se puede establecer en NULL y solo los valores NULL permanecen en esa columna, el valor agregado resultante de las vistas materializadas es cero en lugar de NULL.
No se puede leer un fuente de distribución de datos modificados desde una vista materializada.
Las consultas de viaje de tiempo no se admiten en vistas materializadas.
Los archivos subyacentes que admiten vistas materializadas pueden incluir datos de tablas ascendentes (incluida la posible información de identificación personal) que no aparecen en la definición de vista materializada. Estos datos se agregan automáticamente al almacenamiento subyacente para admitir la actualización incremental de las vistas materializadas. Dado que los archivos subyacentes de una vista materializada podrían arriesgarse a exponer datos de tablas ascendentes que no forman parte del esquema de la vista materializada, Databricks recomienda no compartir el almacenamiento subyacente con consumidores descendentes que no son de confianza. Por ejemplo, supongamos que la definición de una vista materializada incluye una cláusula COUNT(DISTINCT field_a). Aunque la definición de la vista materializada solo incluye la cláusula de agregado COUNT DISTINCT, los archivos subyacentes contendrán una lista de los valores reales de field_a.
Puede incurrir en algunos cargos de computación sin servidor, incluso cuando utiliza estas características en un entorno de computación dedicado.

Si necesita usar una conexión de Azure Private Link con su vista materializada, póngase en contacto con su representante de Databricks.

Acceso a vistas materializadas desde clientes externos

Para obtener acceso a vistas materializadas desde clientes externos de Delta Lake o Iceberg que no admiten API abiertas, puede usar el modo de compatibilidad. El modo de compatibilidad crea una versión de solo lectura de la vista materializada a la que puede acceder cualquier cliente Delta Lake o Iceberg.

Comentarios

¿Le resultó útil esta página?

Last updated on 2026-02-04