`, asegúrate de usar el nombre de la vista y no el de la tabla. Si la lista de `DEPENDS ON` contiene una tabla normal, una vista no actualizable o un error tipográfico, la vista no se actualizará nunca y mostrará el estado `MissingDependencies` en `system.view_refreshes`. Las dependencias pueden modificarse o eliminarse con `ALTER`; consulta [Cambiar los parámetros de actualización](#changing-refresh-parameters).
#### Uso de DEPENDS ON para una latencia de propagación constante
Si ambas vistas usan `REFRESH EVERY` con el mismo período, la dependencia se aplica en cada franja horaria.
P. ej., supongamos que las vistas X e Y usan `REFRESH EVERY 1 HOUR`, y que Y lee de la tabla de salida de X. Sin dependencias, Y normalmente vería los datos de X de la actualización de la hora anterior. Con `DEPENDS ON X`, la actualización de Y de las 11:00 solo comenzará después de que finalice la actualización de X de las 11:00.
```text theme={null}
10:00 11:00 12:00
│ │ │
X: [run]┐ [run]┐ [run]┐
│ │ │
Y: └►[run] └►[run] └►[run]
```
Tanto la dependencia como la vista dependiente pueden omitir franjas horarias de forma independiente si las actualizaciones tardan más que el período de actualización. No se garantiza que la vista dependiente se actualice exactamente una vez por cada actualización de la dependencia.
```text theme={null}
10:00 11:00 12:00 13:00
│ │ │ |
X: [run]┐ [run]┐ [run]┐ [run]┐
│ └────┐ (Y skips 12:00) └───┐
Y: └►[10:00 ru------un]└►[11:00 ru---------------un]└►[13:00 run]
```
#### Uso de DEPENDS ON para el procesamiento de flujo por lotes
Si no se usa `REFRESH EVERY`, la vista dependiente X se actualiza si todas sus dependencias se han actualizado al menos una vez desde la última actualización de X. `REFRESH AFTER T` añade un retraso: la vista dependiente iniciará la actualización T unidades de tiempo después de que la dependencia complete una actualización.
Se permiten las dependencias circulares y son útiles. Considere este grafo de vistas materializadas actualizables:
1. X toma un lote de filas de un flujo y las coloca en una tabla.
2. Luego, Y y Z leen de esa tabla, realizan agregaciones distintas y añaden los resultados a otras tablas.
3. Una vez que el lote se ha procesado por completo, X toma el siguiente lote y el ciclo se repite.
```text theme={null}
source
│
▼
┌─────────┐
┌───►│ X │◄───┐
│ └──┬───┬──┘ │
DEPENDS │ │ DEPENDS
ON ▼ ▼ ON
│ ┌─┐ ┌─┐ │
└──────┤Y│ │Z├──────┘
└─┘ └─┘
```
Ejemplo completo:
```sql theme={null}
CREATE TABLE current_batch (t UInt64, v Int64) ENGINE ReplicatedMergeTree ORDER BY t;
CREATE TABLE batch_log (max_t UInt64, n Int64, v_sum Int64, processed_at DateTime64) ENGINE ReplicatedMergeTree ORDER BY max_t;
CREATE TABLE stats (h UInt64, n UInt64) ENGINE ReplicatedSummingMergeTree ORDER BY h;
-- (system.numbers stands in for a data source with monotonically increasing timestamps or sequence numbers)
CREATE MATERIALIZED VIEW current_batch_v REFRESH EVERY 10 SECOND DEPENDS ON batch_log_v, stats_v TO current_batch AS SELECT number as t, number * 10 as v FROM system.numbers WHERE number > (SELECT max(max_t) FROM batch_log) LIMIT 100;
CREATE MATERIALIZED VIEW batch_log_v REFRESH DEPENDS ON current_batch_v APPEND TO batch_log AS SELECT max(t) as max_t, count() as n, sum(v) as v_sum, now64() as processed_at FROM current_batch;
CREATE MATERIALIZED VIEW stats_v REFRESH DEPENDS ON current_batch_v APPEND TO stats AS SELECT cityHash64(v) % 20 as h, count() as n FROM current_batch GROUP BY h;
-- Must trigger initial refresh manually.
SYSTEM REFRESH VIEW current_batch_v;
```
Las cadenas más largas también funcionan.
Esto solo funciona bien cuando la coordinación de actualización está habilitada, es decir, cuando las vistas están en una base de datos Replicated o Shared. Sin coordinación, un reinicio del servidor interrumpe el ciclo, por lo que se requiere un `SYSTEM REFRESH VIEW` manual después de cada reinicio, en lugar de solo una vez tras crear las vistas.
### Parámetros de actualización
Parámetros de actualización disponibles:
* `refresh_retries` - Cuántas veces reintentar si la consulta de actualización falla con una excepción. Si fallan todos los reintentos, se pasa a la siguiente hora de actualización programada. 0 significa que no hay reintentos; -1, que los reintentos son infinitos. Predeterminado: 2.
* `refresh_retry_initial_backoff_ms` - Retraso antes del primer reintento, si `refresh_retries` no es cero. Cada reintento posterior duplica el retraso, hasta `refresh_retry_max_backoff_ms`. Predeterminado: 100 ms.
* `refresh_retry_max_backoff_ms` - Límite del crecimiento exponencial del retraso entre intentos de actualización. Predeterminado: 60000 ms (1 minuto).
* `all_replicas` - En una [base de datos Replicated](/es/reference/engines/database-engines/replicated) con `APPEND`, controla si todas las réplicas se actualizan de forma independiente o si solo una réplica se actualiza en cada momento programado. No se puede cambiar después de crear la vista. Predeterminado: `false`.
### Cambiar los parámetros de actualización
Los parámetros de actualización de una vista materializada actualizable existente se modifican mediante [`ALTER TABLE ... MODIFY REFRESH`](/es/reference/statements/alter/view#alter-table--modify-refresh-statement):
```sql theme={null}
ALTER TABLE [db.]name MODIFY REFRESH EVERY|AFTER ... [RANDOMIZE FOR ...] [DEPENDS ON ...] [SETTINGS ...]
```
La programación (`EVERY` o `AFTER`) es obligatoria: la sentencia siempre sustituye *todos* los parámetros de actualización —la programación, `RANDOMIZE FOR`, `DEPENDS ON` y los parámetros de actualización— por los especificados. Todo lo que se omita se restablece a su valor predeterminado (configuración) o se elimina (dependencias, aleatorización).
* Para cambiar solo los parámetros de actualización (por ejemplo, `refresh_retries`), repita la programación actual:
```sql theme={null}
ALTER TABLE rmv MODIFY REFRESH EVERY 1 HOUR SETTINGS refresh_retries = 5;
```
* `ALTER TABLE ... MODIFY SETTING refresh_retries = ...` no es compatible con las vistas materializadas; debe hacerse mediante `MODIFY REFRESH`.
* No se admite añadir ni quitar `APPEND`.
* La configuración `all_replicas` no puede cambiarse después de la creación.
Ejemplos:
```sql theme={null}
-- Cambiar el horario, eliminar la configuración y las dependencias existentes.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE;
-- Cambiar el horario y ajustar el comportamiento de reintentos.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE
SETTINGS refresh_retries = 5,
refresh_retry_initial_backoff_ms = 500,
refresh_retry_max_backoff_ms = 60000;
-- Mantener la dependencia al cambiar el período.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR DEPENDS ON other_rmv;
-- Eliminar la dependencia omitiendo `DEPENDS ON`.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR;
```
### Otras operaciones
El estado de todas las vistas materializadas actualizables está disponible en la tabla [`system.view_refreshes`](/es/reference/system-tables/view_refreshes). En particular, incluye el progreso de la actualización (si está en curso), la hora de la última y de la próxima actualización, y el mensaje de excepción si una actualización falló.
Para detener, iniciar, activar o cancelar actualizaciones manualmente, use [`SYSTEM STOP|START|REFRESH|WAIT|CANCEL VIEW`](/es/reference/statements/system#managing-refreshable-materialized-views).
Para esperar a que se complete una actualización, use [`SYSTEM WAIT VIEW`](/es/reference/statements/system#wait-view). En particular, resulta útil para esperar a que termine la actualización inicial tras crear una vista.
Dato curioso: la consulta de actualización puede leer de la vista que se está actualizando y ver la versión de los datos anterior a la actualización. Esto significa que puede implementar el juego de la vida de Conway: [https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==](https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==)
## Window View
Esta es una función experimental que puede cambiar de forma incompatible con versiones anteriores en futuras versiones. Habilite el uso de las Window View y de la consulta `WATCH` mediante la opción de configuración [allow\_experimental\_window\_view](/es/reference/settings/session-settings#allow_experimental_window_view). Introduzca el comando `set allow_experimental_window_view = 1`.
```sql theme={null}
CREATE WINDOW VIEW [IF NOT EXISTS] [db.]table_name [TO [db.]table_name] [INNER ENGINE engine] [ENGINE engine] [WATERMARK strategy] [ALLOWED_LATENESS interval_function] [POPULATE]
AS SELECT ...
GROUP BY time_window_function
[COMMENT 'comment']
```
Una window view puede agregar datos por ventana de tiempo y generar los resultados cuando la ventana esté lista para dispararse. Almacena los resultados parciales de la agregación en una tabla interna (o especificada) para reducir la latencia, y puede enviar el resultado del procesamiento a una tabla especificada o enviar notificaciones mediante la consulta WATCH.
Crear una window view es similar a crear `MATERIALIZED VIEW`. Una window view necesita un motor de almacenamiento interno para guardar datos intermedios. El almacenamiento interno puede especificarse mediante la cláusula `INNER ENGINE`; la window view usará `AggregatingMergeTree` como motor interno predeterminado.
Al crear una window view sin `TO [db].[table]`, debe especificar `ENGINE`, el motor de tabla para almacenar los datos.
### Funciones de ventana de tiempo
Las [funciones de ventana de tiempo](/es/reference/functions/regular-functions/time-window-functions) se utilizan para obtener los límites inferior y superior de la ventana de los registros. La window view debe usarse con una función de ventana de tiempo.
### ATRIBUTOS DE TIEMPO
Window view admite el uso de **tiempo de procesamiento** y **tiempo de evento**.
El **tiempo de procesamiento** permite que window view genere resultados en función de la hora de la máquina local y se usa de forma predeterminada. Es la noción de tiempo más sencilla, pero no proporciona determinismo. El atributo de tiempo de procesamiento puede definirse estableciendo el valor de `time_attr` de la función de ventana de tiempo en una columna de la tabla o mediante la función `now()`. La siguiente consulta crea una window view con tiempo de procesamiento.
```sql theme={null}
CREATE WINDOW VIEW wv AS SELECT count(number), tumbleStart(w_id) as w_start from date GROUP BY tumble(now(), INTERVAL '5' SECOND) as w_id
```
El **tiempo del evento** es el momento en que ocurrió cada evento individual en el dispositivo que lo produjo. Este tiempo suele estar incluido en los registros cuando se generan. El procesamiento por tiempo del evento permite obtener resultados coherentes incluso en caso de eventos desordenados o tardíos. Window view admite el procesamiento por tiempo del evento mediante la sintaxis `WATERMARK`.
Window view proporciona tres estrategias de watermark:
* `STRICTLY_ASCENDING`: Emite un watermark con la marca temporal máxima observada hasta el momento. Las filas con una marca temporal inferior a la marca temporal máxima no se consideran tardías.
* `ASCENDING`: Emite un watermark con la marca temporal máxima observada hasta el momento menos 1. Las filas con una marca temporal igual o inferior a la marca temporal máxima no se consideran tardías.
* `BOUNDED`: WATERMARK=INTERVAL. Emite watermarks que corresponden a la marca temporal máxima observada menos el retraso especificado.
Las siguientes consultas son ejemplos de creación de una window view con `WATERMARK`:
```sql theme={null}
CREATE WINDOW VIEW wv WATERMARK=STRICTLY_ASCENDING AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
CREATE WINDOW VIEW wv WATERMARK=ASCENDING AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
CREATE WINDOW VIEW wv WATERMARK=INTERVAL '3' SECOND AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
```
De forma predeterminada, la ventana se activará cuando llegue la watermark, y los elementos que lleguen por detrás de la watermark se descartarán. La window view admite el procesamiento de eventos tardíos configurando `ALLOWED_LATENESS=INTERVAL`. Un ejemplo de gestión de la tardanza es:
```sql theme={null}
CREATE WINDOW VIEW test.wv TO test.dst WATERMARK=ASCENDING ALLOWED_LATENESS=INTERVAL '2' SECOND AS SELECT count(a) AS count, tumbleEnd(wid) AS w_end FROM test.mt GROUP BY tumble(timestamp, INTERVAL '5' SECOND) AS wid;
```
Tenga en cuenta que los elementos emitidos por una activación tardía deben tratarse como resultados actualizados de un cálculo anterior. En lugar de activarse al final de las ventanas, la window view se activará inmediatamente cuando llegue el evento tardío. Por lo tanto, generará múltiples salidas para la misma ventana. Los usuarios deben tener en cuenta estos resultados duplicados o deduplicarlos.
Puede modificar la consulta `SELECT` especificada en la window view mediante la sentencia `ALTER TABLE ... MODIFY QUERY`. La estructura de datos resultante de la nueva consulta `SELECT` debe ser la misma que la de la consulta `SELECT` original, con o sin la cláusula `TO [db.]name`. Tenga en cuenta que los datos de la ventana actual se perderán porque el estado intermedio no se puede reutilizar.
### Supervisión de nuevas ventanas
Window view admite la consulta [WATCH](/es/reference/statements/watch) para supervisar los cambios, o use la sintaxis `TO` para enviar los resultados a una tabla.
```sql theme={null}
WATCH [db.]window_view
[EVENTS]
[LIMIT n]
[FORMAT format]
```
Se puede especificar un `LIMIT` para definir el número de actualizaciones que se recibirán antes de finalizar la consulta. La cláusula `EVENTS` puede usarse para obtener una forma abreviada de la consulta `WATCH`, donde, en lugar del resultado de la consulta, solo se obtiene la watermark más reciente de la consulta.
### Configuración
* `window_view_clean_interval`: El intervalo de limpieza de window view, en segundos, para liberar datos obsoletos. El sistema conservará las ventanas que no se hayan activado por completo según la hora del sistema o la configuración de `WATERMARK`, y eliminará el resto de los datos.
* `window_view_heartbeat_interval`: El intervalo de heartbeat, en segundos, para indicar que la consulta watch sigue activa.
* `wait_for_window_view_fire_signal_timeout`: Tiempo de espera para recibir la señal de activación de window view durante el procesamiento por tiempo de evento.
### Ejemplo
Supongamos que necesitamos contar la cantidad de logs de clics por cada 10 segundos en una tabla de logs llamada `data`, cuya estructura es:
```sql theme={null}
CREATE TABLE data ( `id` UInt64, `timestamp` DateTime) ENGINE = Memory;
```
Primero, creamos una window view con una tumble window con un intervalo de 10 segundos:
```sql theme={null}
CREATE WINDOW VIEW wv as select count(id), tumbleStart(w_id) as window_start from data group by tumble(timestamp, INTERVAL '10' SECOND) as w_id
```
A continuación, usamos la consulta `WATCH` para obtener los resultados.
```sql theme={null}
WATCH wv
```
Cuando se insertan logs en la tabla `data`,
```sql theme={null}
INSERT INTO data VALUES(1,now())
```
La consulta `WATCH` debería mostrar los resultados de la siguiente manera:
```text theme={null}
┌─count(id)─┬────────window_start─┐
│ 1 │ 2020-01-14 16:56:40 │
└───────────┴─────────────────────┘
```
Como alternativa, podemos adjuntar la salida a otra tabla mediante la sintaxis `TO`.
```sql theme={null}
CREATE WINDOW VIEW wv TO dst AS SELECT count(id), tumbleStart(w_id) as window_start FROM data GROUP BY tumble(timestamp, INTERVAL '10' SECOND) as w_id
```
Se pueden encontrar ejemplos adicionales en las pruebas con estado de ClickHouse (allí se llaman `*window_view*`).
### Uso de Window View
La window view es útil en los siguientes escenarios:
* **Monitoreo**: Agrega y calcula las métricas de los logs a lo largo del tiempo, y envía los resultados a una tabla de destino. El dashboard puede usar la tabla de destino como tabla de origen.
* **Análisis**: Agrega y preprocesa automáticamente los datos dentro de la ventana de tiempo. Esto puede ser útil al analizar una gran cantidad de logs. El preprocesamiento elimina cálculos repetidos en múltiples consultas y reduce la latencia de las consultas.
## Contenido relacionado
* Blog: [Cómo trabajar con datos de series temporales en ClickHouse](https://clickhouse.com/blog/working-with-time-series-data-and-functions-ClickHouse)
* Blog: [Creación de una solución de observabilidad con ClickHouse - Parte 2 - Trazas](https://clickhouse.com/blog/storing-traces-and-spans-open-telemetry-in-clickhouse)
## Vistas temporales
ClickHouse admite **vistas temporales** con las siguientes características (en línea con las tablas temporales, cuando corresponde):
* **Duración de la sesión**
Una vista temporal existe solo durante la sesión actual. Se elimina automáticamente cuando la sesión finaliza.
* **Sin base de datos**
**No se puede** calificar una vista temporal con un nombre de base de datos. Existe fuera de las bases de datos (en el espacio de nombres de la sesión).
* **No replicadas / sin ON CLUSTER**
Los objetos temporales son locales a la sesión y **no pueden** crearse con `ON CLUSTER`.
* **Resolución de nombres**
Si un objeto temporal (tabla o vista) tiene el mismo nombre que un objeto persistente y una consulta hace referencia a ese nombre **sin** una base de datos, se usa el objeto **temporal**.
* **Objeto lógico (sin almacenamiento)**
Una vista temporal solo almacena su texto `SELECT` (usa internamente el motor `View`). No conserva datos y no admite `INSERT`.
* **Cláusula ENGINE**
**No** es necesario especificar `ENGINE`; si se indica como `ENGINE = View`, se ignora o se trata como la misma vista lógica.
* **Seguridad / privilegios**
Para crear una vista temporal se requiere el privilegio `CREATE TEMPORARY VIEW`, que se concede implícitamente mediante `CREATE VIEW`.
* **SHOW CREATE**
Use `SHOW CREATE TEMPORARY VIEW view_name;` para mostrar el DDL de una vista temporal.
### Sintaxis
```sql theme={null}
CREATE TEMPORARY VIEW [IF NOT EXISTS] view_name AS
```
`OR REPLACE` **no** se admite para las vistas temporales (para mantener la coherencia con las tablas temporales). Si necesita “reemplazar” una vista temporal, elimínela y vuelva a crearla.
### Ejemplos
Cree una tabla fuente temporal y una vista temporal sobre esta:
```sql theme={null}
CREATE TEMPORARY TABLE t_src (id UInt32, val String);
INSERT INTO t_src VALUES (1, 'a'), (2, 'b');
CREATE TEMPORARY VIEW tview AS
SELECT id, upper(val) AS u
FROM t_src
WHERE id <= 2;
SELECT * FROM tview ORDER BY id;
```
Muestra su DDL:
```sql theme={null}
SHOW CREATE TEMPORARY VIEW tview;
```
Elimínela:
```sql theme={null}
DROP TEMPORARY VIEW IF EXISTS tview; -- las vistas temporales se eliminan con la sintaxis TEMPORARY TABLE
```
### No permitidos / limitaciones
* `CREATE OR REPLACE TEMPORARY VIEW ...` → **no permitido** (usa `DROP` + `CREATE`).
* `CREATE TEMPORARY MATERIALIZED VIEW ...` / `WINDOW VIEW` → **no permitido**.
* `CREATE TEMPORARY VIEW db.view AS ...` → **no permitido** (sin calificador de base de datos).
* `CREATE TEMPORARY VIEW view ON CLUSTER 'name' AS ...` → **no permitido** (los objetos temporales son locales a la sesión).
* `POPULATE`, `REFRESH`, `TO [db.table]`, motores internos y todas las cláusulas específicas de las MV → **no aplicables** a las vistas temporales.
### Notas sobre las consultas distribuidas
Una **vista** temporal es solo una definición; no hay datos que transferir. Si la vista temporal hace referencia a **tablas** temporales (p. ej., `Memory`), sus datos pueden enviarse a servidores remotos durante la ejecución de consultas distribuidas, del mismo modo que ocurre con las tablas temporales.
#### Ejemplo
```sql theme={null}
-- Una tabla en memoria con ámbito de sesión
CREATE TEMPORARY TABLE temp_ids (id UInt64) ENGINE = Memory;
INSERT INTO temp_ids VALUES (1), (5), (42);
-- Una vista con ámbito de sesión sobre la tabla temporal (puramente lógica)
CREATE TEMPORARY VIEW v_ids AS
SELECT id FROM temp_ids;
-- Reemplaza 'test' con el nombre de tu cluster.
-- GLOBAL JOIN obliga a ClickHouse a *enviar* el lado pequeño del join (temp_ids a través de v_ids)
-- a cada servidor remoto que ejecuta el lado izquierdo.
SELECT count()
FROM cluster('test', system.numbers) AS n
GLOBAL ANY INNER JOIN v_ids USING (id)
WHERE n.number < 100;
```