`, veillez à utiliser le nom de la vue plutôt que celui de la table. Si la liste `DEPENDS ON` contient une table ordinaire, une vue non actualisable ou une faute de frappe, la vue ne sera jamais rafraîchie et affichera l’état `MissingDependencies` dans `system.view_refreshes`. Les dépendances peuvent être modifiées ou supprimées à l’aide de `ALTER` ; voir [Modification des paramètres de rafraîchissement](#changing-refresh-parameters).
#### Utilisation de DEPENDS ON pour une latence de propagation cohérente
Si les deux vues utilisent `REFRESH EVERY` avec la même période, la dépendance s’applique à chaque créneau temporel.
Par exemple, supposons que les vues X et Y utilisent toutes deux `REFRESH EVERY 1 HOUR` et que Y lit les données de la table de sortie de X. Sans dépendance, Y verrait généralement les données du rafraîchissement de l’heure précédente de X. Avec `DEPENDS ON X`, le rafraîchissement de 11:00 de Y ne démarrera qu’une fois celui de 11:00 de X terminé.
```text theme={null}
10:00 11:00 12:00
│ │ │
X: [run]┐ [run]┐ [run]┐
│ │ │
Y: └►[run] └►[run] └►[run]
```
La dépendance comme l’élément dépendant peuvent chacun sauter des créneaux temporels de manière indépendante si les actualisations durent plus longtemps que la période d’actualisation. Rien ne garantit que l’élément dépendant s’actualise exactement une fois pour chaque actualisation de la dépendance.
```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]
```
#### Utilisation de DEPENDS ON pour le traitement de flux par lots
Si `REFRESH EVERY` n’est pas utilisé, la vue dépendante X se rafraîchit si toutes ses dépendances ont été rafraîchies au moins une fois depuis le dernier rafraîchissement de X. `REFRESH AFTER T` ajoute un délai : la vue dépendante commencera à se rafraîchir T unités de temps après qu’une dépendance a terminé un rafraîchissement.
Les dépendances circulaires sont autorisées et utiles. Considérez ce graphe de vues matérialisées actualisables :
1. X prend un lot de lignes d’un flux et les place dans une table.
2. Ensuite, Y et Z lisent tous deux dans cette table, effectuent des agrégations différentes et ajoutent les résultats à d’autres tables.
3. Une fois le lot entièrement traité, X prend le lot suivant, et le cycle se répète.
```text theme={null}
source
│
▼
┌─────────┐
┌───►│ X │◄───┐
│ └──┬───┬──┘ │
DEPENDS │ │ DEPENDS
ON ▼ ▼ ON
│ ┌─┐ ┌─┐ │
└──────┤Y│ │Z├──────┘
└─┘ └─┘
```
Exemple complet :
```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;
```
Les chaînes plus longues fonctionnent également.
Cela ne fonctionne correctement que lorsque la coordination du rafraîchissement est activée, c’est-à-dire lorsque les vues se trouvent dans une base de données Replicated ou Shared database. Sans coordination, le redémarrage du serveur interrompt le cycle, ce qui nécessite un `SYSTEM REFRESH VIEW` manuel après chaque redémarrage, plutôt qu’une seule fois après la création des vues.
### Paramètres de rafraîchissement
Paramètres de rafraîchissement disponibles :
* `refresh_retries` - Nombre de tentatives en cas d’échec de la requête de rafraîchissement avec une exception. Si toutes les tentatives échouent, le système passe à l’heure de rafraîchissement planifiée suivante. 0 signifie aucune nouvelle tentative, -1 signifie un nombre infini de tentatives. Par défaut : 2.
* `refresh_retry_initial_backoff_ms` - Délai avant la première nouvelle tentative, si `refresh_retries` n’est pas égal à zéro. Chaque tentative suivante double le délai, jusqu’à `refresh_retry_max_backoff_ms`. Par défaut : 100 ms.
* `refresh_retry_max_backoff_ms` - Limite de la croissance exponentielle du délai entre les tentatives de rafraîchissement. Par défaut : 60000 ms (1 minute).
* `all_replicas` - Dans une [base de données Replicated](/fr/reference/engines/database-engines/replicated) avec `APPEND`, contrôle si toutes les répliques se rafraîchissent indépendamment ou si une seule réplique se rafraîchit à chaque heure planifiée. Ne peut pas être modifié après la création de la vue. Par défaut : `false`.
### Modification des paramètres de rafraîchissement
Les paramètres de rafraîchissement d’une vue matérialisée actualisable existante peuvent être modifiés à l’aide de [`ALTER TABLE ... MODIFY REFRESH`](/fr/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 planification (`EVERY` ou `AFTER`) est obligatoire : l’instruction remplace toujours *tous* les paramètres de rafraîchissement — la planification, `RANDOMIZE FOR`, `DEPENDS ON` et les paramètres de rafraîchissement — par ceux qui sont spécifiés. Tout élément omis est réinitialisé à sa valeur par défaut (paramètres) ou supprimé (dépendances, randomisation).
* Pour modifier uniquement les paramètres de rafraîchissement (par ex. `refresh_retries`), répétez la planification existante :
```sql theme={null}
ALTER TABLE rmv MODIFY REFRESH EVERY 1 HOUR SETTINGS refresh_retries = 5;
```
* `ALTER TABLE ... MODIFY SETTING refresh_retries = ...` n’est pas pris en charge pour les vues matérialisées ; vous devez passer par `MODIFY REFRESH`.
* L’ajout ou la suppression de `APPEND` n’est pas pris en charge.
* Le paramètre `all_replicas` ne peut pas être modifié après la création.
Exemples :
```sql theme={null}
-- Change the schedule, drop existing settings and dependencies.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE;
-- Change the schedule and tune retry behavior.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE
SETTINGS refresh_retries = 5,
refresh_retry_initial_backoff_ms = 500,
refresh_retry_max_backoff_ms = 60000;
-- Keep the dependency while changing the period.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR DEPENDS ON other_rmv;
-- Drop the dependency by omitting `DEPENDS ON`.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR;
```
### Autres opérations
L’état de toutes les vues matérialisées actualisables est disponible dans la table [`system.view_refreshes`](/fr/reference/system-tables/view_refreshes). Elle contient notamment la progression du rafraîchissement (s’il est en cours), la date et l’heure du dernier et du prochain rafraîchissement, ainsi que le message d’exception si un rafraîchissement a échoué.
Pour arrêter, démarrer, déclencher ou annuler manuellement des rafraîchissements, utilisez [`SYSTEM STOP|START|REFRESH|WAIT|CANCEL VIEW`](/fr/reference/statements/system#managing-refreshable-materialized-views).
Pour attendre la fin d’un rafraîchissement, utilisez [`SYSTEM WAIT VIEW`](/fr/reference/statements/system#wait-view). C’est notamment utile pour attendre le rafraîchissement initial après la création d’une vue.
Fait amusant : la requête de rafraîchissement peut lire dans la vue en cours de rafraîchissement et voir la version des données antérieure au rafraîchissement. Cela signifie que vous pouvez implémenter le jeu de la vie de Conway : [https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==](https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==)
## Window View
Il s'agit d'une fonctionnalité expérimentale qui pourra évoluer de manière non compatible avec les versions antérieures dans les versions ultérieures. Pour utiliser les window views et la requête `WATCH`, activez le paramètre [allow\_experimental\_window\_view](/fr/reference/settings/session-settings#allow_experimental_window_view). Saisissez la commande `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']
```
La window view peut agréger les données par fenêtre temporelle et produire les résultats lorsque la fenêtre est prête à émettre. Elle stocke les résultats d'agrégation partiels dans une table interne (ou spécifiée) afin de réduire la latence, et peut envoyer le résultat du traitement vers une table spécifiée ou des notifications à l'aide de la requête WATCH.
La création d'une window view est similaire à celle d'une `MATERIALIZED VIEW`. Une window view nécessite un moteur de stockage interne pour stocker les données intermédiaires. Le stockage interne peut être spécifié à l'aide de la clause `INNER ENGINE` ; la window view utilisera `AggregatingMergeTree` comme moteur interne par défaut.
Lors de la création d'une window view sans `TO [db].[table]`, vous devez spécifier `ENGINE` – le moteur de table utilisé pour stocker les données.
### Fonctions de fenêtre temporelle
Les [fonctions de fenêtre temporelle](/fr/reference/functions/regular-functions/time-window-functions) servent à obtenir la borne inférieure et la borne supérieure de la fenêtre des enregistrements. La window view doit être utilisée avec une fonction de fenêtre temporelle.
### ATTRIBUTS TEMPORELS
La window view prend en charge le **temps de traitement** et le **temps d’événement**.
Le **temps de traitement** permet à la window view de produire des résultats en fonction de l’heure de la machine locale et est utilisé par défaut. C’est la notion du temps la plus simple, mais elle n’offre pas de déterminisme. L’attribut de temps de traitement peut être défini en affectant à `time_attr` de la fonction de fenêtre temporelle une colonne de table, ou en utilisant la fonction `now()`. La requête suivante crée une window view avec le temps de traitement.
```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
```
**Le temps d’événement** correspond au moment où chaque événement s'est produit sur l'appareil qui l'a généré. Ce temps est généralement intégré aux enregistrements au moment de leur création. Le traitement basé sur le temps d’événement permet d'obtenir des résultats cohérents, même en cas d'événements arrivant dans le désordre ou en retard. Window view prend en charge le traitement basé sur le temps d’événement à l'aide de la syntaxe `WATERMARK`.
Window view propose trois stratégies de watermark :
* `STRICTLY_ASCENDING` : émet un watermark correspondant à l'horodatage maximal observé jusqu'à présent. Les lignes dont l'horodatage est inférieur à l'horodatage maximal ne sont pas considérées comme en retard.
* `ASCENDING` : émet un watermark correspondant à l'horodatage maximal observé jusqu'à présent moins 1. Les lignes dont l'horodatage est égal ou inférieur à l'horodatage maximal ne sont pas considérées comme en retard.
* `BOUNDED` : WATERMARK=INTERVAL. Émet des watermarks correspondant à l'horodatage maximal observé moins le délai spécifié.
Les requêtes suivantes montrent des exemples de création d'une window view avec `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);
```
Par défaut, la fenêtre sera déclenchée à l’arrivée du watermark, et les éléments arrivés après celui-ci seront ignorés. Window View prend en charge le traitement des événements en retard en définissant `ALLOWED_LATENESS=INTERVAL`. Voici un exemple de gestion du retard :
```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;
```
Notez que les éléments émis lors d’un déclenchement tardif doivent être considérés comme des résultats mis à jour d’un calcul précédent. Au lieu de se déclencher à la fin des fenêtres, la window view se déclenche immédiatement à l’arrivée de l’événement tardif. Cela entraîne donc plusieurs résultats pour une même fenêtre. Les utilisateurs doivent tenir compte de ces résultats dupliqués ou les dédupliquer.
Vous pouvez modifier la requête `SELECT` spécifiée dans la window view à l’aide de l’instruction `ALTER TABLE ... MODIFY QUERY`. La structure de données résultant de la nouvelle requête `SELECT` doit être identique à celle de la requête `SELECT` d’origine, avec ou sans la clause `TO [db.]name`. Notez que les données de la fenêtre en cours seront perdues, car l’état intermédiaire ne peut pas être réutilisé.
### Surveillance des nouvelles fenêtres
La window view prend en charge la requête [WATCH](/fr/reference/statements/watch) pour surveiller les modifications, ou vous pouvez utiliser la syntaxe `TO` pour écrire les résultats dans une table.
```sql theme={null}
WATCH [db.]window_view
[EVENTS]
[LIMIT n]
[FORMAT format]
```
Il est possible de spécifier un `LIMIT` pour définir le nombre de mises à jour à recevoir avant de mettre fin à la requête. La clause `EVENTS` permet d'obtenir une forme abrégée de la requête `WATCH` : au lieu du résultat de la requête, vous ne recevrez que son watermark le plus récent.
### Paramètres
* `window_view_clean_interval` : intervalle de nettoyage de la window view, en secondes, pour libérer les données obsolètes. Le système conserve les fenêtres qui n’ont pas encore été entièrement déclenchées en fonction de l’heure système ou de la configuration `WATERMARK`, et supprime les autres données.
* `window_view_heartbeat_interval` : intervalle de heartbeat, en secondes, indiquant que la requête watch est active.
* `wait_for_window_view_fire_signal_timeout` : délai d’attente du signal de déclenchement de la window view lors du traitement en temps d’événement.
### Exemple
Supposons que nous devions compter le nombre de logs de clics toutes les 10 secondes dans une table de logs appelée `data`, dont la structure est la suivante :
```sql theme={null}
CREATE TABLE data ( `id` UInt64, `timestamp` DateTime) ENGINE = Memory;
```
Tout d’abord, nous créons une window view avec une fenêtre fixe de 10 secondes :
```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
```
Ensuite, nous utilisons la requête `WATCH` pour obtenir les résultats.
```sql theme={null}
WATCH wv
```
Lorsque des logs sont insérés dans la table `data`,
```sql theme={null}
INSERT INTO data VALUES(1,now())
```
La requête `WATCH` devrait afficher les résultats comme ceci :
```text theme={null}
┌─count(id)─┬────────window_start─┐
│ 1 │ 2020-01-14 16:56:40 │
└───────────┴─────────────────────┘
```
Sinon, nous pouvons envoyer la sortie vers une autre table à l’aide de la syntaxe `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
```
Vous trouverez d'autres exemples parmi les tests avec état de ClickHouse (ils y sont nommés `*window_view*`).
### Utilisation de Window View
La fonctionnalité window view est utile dans les scénarios suivants :
* **Surveillance** : agréger et calculer les métriques des logs au fil du temps, puis envoyer les résultats vers une table cible. Le tableau de bord peut utiliser la table cible comme table source.
* **Analyse** : agréger et prétraiter automatiquement les données dans la fenêtre temporelle. Cela peut être utile lors de l’analyse d’un grand nombre de logs. Ce prétraitement élimine les calculs répétés dans plusieurs requêtes et réduit la latence des requêtes.
## Contenu associé
* Blog : [Travailler avec des données de séries temporelles dans ClickHouse](https://clickhouse.com/blog/working-with-time-series-data-and-functions-ClickHouse)
* Blog : [Créer une solution d’observabilité avec ClickHouse - Partie 2 - Traces](https://clickhouse.com/blog/storing-traces-and-spans-open-telemetry-in-clickhouse)
## Vues temporaires
ClickHouse prend en charge les **vues temporaires** avec les caractéristiques suivantes (comme pour les tables temporaires, le cas échéant) :
* **Durée de vie de la session**
Une vue temporaire n’existe que pendant la session en cours. Elle est supprimée automatiquement à la fin de la session.
* **Aucune base de données**
Vous **ne pouvez pas** qualifier une vue temporaire avec un nom de base de données. Elle existe en dehors des bases de données (dans l’espace de noms de la session).
* **Non répliqué / pas de ON CLUSTER**
Les objets temporaires sont locaux à la session et **ne peuvent pas** être créés avec `ON CLUSTER`.
* **Résolution des noms**
Si un objet temporaire (table ou vue) porte le même nom qu’un objet persistant et qu’une requête fait référence à ce nom **sans** base de données, c’est l’objet **temporaire** qui est utilisé.
* **Objet logique (pas de stockage)**
Une vue temporaire stocke uniquement son texte `SELECT` (en utilisant le moteur `View` en interne). Elle ne conserve pas les données et n’accepte pas `INSERT`.
* **Clause ENGINE**
Vous **n’avez pas** besoin de spécifier `ENGINE` ; s’il est fourni sous la forme `ENGINE = View`, il est ignoré ou traité comme la même vue logique.
* **Sécurité / privilèges**
La création d’une vue temporaire nécessite le privilège `CREATE TEMPORARY VIEW`, implicitement accordé par `CREATE VIEW`.
* **SHOW CREATE**
Utilisez `SHOW CREATE TEMPORARY VIEW view_name;` pour afficher le DDL d’une vue temporaire.
### Syntaxe
```sql theme={null}
CREATE TEMPORARY VIEW [IF NOT EXISTS] view_name AS
```
`OR REPLACE` n’est **pas** pris en charge pour les vues temporaires (comme pour les tables temporaires). Si vous devez « remplacer » une vue temporaire, supprimez-la, puis recréez-la.
### Exemples
Créez une table source temporaire, ainsi qu’une vue temporaire basée sur celle-ci :
```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;
```
Affichez son DDL :
```sql theme={null}
SHOW CREATE TEMPORARY VIEW tview;
```
Supprimez-la :
```sql theme={null}
DROP TEMPORARY VIEW IF EXISTS tview; -- temporary views are dropped with TEMPORARY TABLE syntax
```
### Restrictions / limites
* `CREATE OR REPLACE TEMPORARY VIEW ...` → **non autorisé** (utilisez `DROP` + `CREATE`).
* `CREATE TEMPORARY MATERIALIZED VIEW ...` / `WINDOW VIEW` → **non autorisé**.
* `CREATE TEMPORARY VIEW db.view AS ...` → **non autorisé** (pas de qualificatif de base de données).
* `CREATE TEMPORARY VIEW view ON CLUSTER 'name' AS ...` → **non autorisé** (les objets temporaires sont locaux à la session).
* `POPULATE`, `REFRESH`, `TO [db.table]`, les moteurs internes et toutes les clauses propres aux MV → **non applicables** aux vues temporaires.
### Remarques sur les requêtes distribuées
Une **vue** temporaire n’est qu’une définition ; il n’y a donc aucune donnée à faire circuler. Si votre vue temporaire fait référence à des **tables** temporaires (par ex., `Memory`), leurs données peuvent être envoyées vers des serveurs distants lors de l’exécution distribuée des requêtes, de la même manière que pour les tables temporaires.
#### Exemple
```sql theme={null}
-- A session-scoped, in-memory table
CREATE TEMPORARY TABLE temp_ids (id UInt64) ENGINE = Memory;
INSERT INTO temp_ids VALUES (1), (5), (42);
-- A session-scoped view over the temp table (purely logical)
CREATE TEMPORARY VIEW v_ids AS
SELECT id FROM temp_ids;
-- Replace 'test' with your cluster name.
-- GLOBAL JOIN forces ClickHouse to *ship* the small join-side (temp_ids via v_ids)
-- to every remote server that executes the left side.
SELECT count()
FROM cluster('test', system.numbers) AS n
GLOBAL ANY INNER JOIN v_ids USING (id)
WHERE n.number < 100;
```