Перейти к основному содержанию
Создает новое представление. Представления бывают обычными, материализованными, обновляемыми материализованными и оконными.

​
Обычное представление

Синтаксис: 
CREATE [OR REPLACE] VIEW [IF NOT EXISTS] [db.]table_name [(alias1 [, alias2 ...])] [ON CLUSTER cluster_name]
[DEFINER = { user | CURRENT_USER }] [SQL SECURITY { DEFINER | INVOKER | NONE }]
AS SELECT ...
[COMMENT 'comment']
Обычные представления не хранят данные. При каждом обращении они просто читают их из другой таблицы. Иными словами, обычное представление — это всего лишь сохранённый запрос. При чтении из представления этот сохранённый запрос используется как подзапрос в секции FROM. Например, предположим, что вы создали представление: 
CREATE VIEW view AS SELECT ...
и написали запрос: 
SELECT a, b, c FROM view
Этот запрос полностью эквивалентен использованию такого подзапроса: 
SELECT a, b, c FROM (SELECT ...)

​
Параметризованное представление

Параметризованные представления похожи на обычные представления, но могут создаваться с параметрами, значения которых определяются не сразу. Эти представления можно использовать с табличными функциями: имя представления указывается как имя функции, а значения параметров — как её аргументы. 
CREATE VIEW view AS SELECT * FROM TABLE WHERE Column1={column1:datatype1} and Column2={column2:datatype2} ...
Выше создаётся представление для таблицы, которое можно использовать как табличную функцию, подставив параметры, как показано ниже. 
SELECT * FROM view(column1=value1, column2=value2 ...)

​
Materialized View

CREATE MATERIALIZED VIEW [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster_name] [TO[db.]name [(columns)]] [ENGINE = engine] [POPULATE]
[REFRESH ...]
[DEFINER = { user | CURRENT_USER }] [SQL SECURITY { DEFINER | NONE }]
AS SELECT ...
[COMMENT 'comment']

CREATE OR REPLACE MATERIALIZED VIEW [db.]table_name [ON CLUSTER cluster_name] [TO[db.]name [(columns)]] [ENGINE = engine] [POPULATE]
[REFRESH ...]
[DEFINER = { user | CURRENT_USER }] [SQL SECURITY { DEFINER | NONE }]
AS SELECT ...
[COMMENT 'comment']
OR REPLACE и IF NOT EXISTS являются взаимоисключающими: их совместное использование вызывает синтаксическую ошибку.

​
CREATE OR REPLACE MATERIALIZED VIEW

CREATE OR REPLACE MATERIALIZED VIEW атомарно заменяет существующее materialized view и его внутреннюю таблицу хранения (если она есть). Для выполнения этой операции требуется движок базы данных Atomic или Replicated. 
CREATE OR REPLACE MATERIALIZED VIEW [db.]name [ON CLUSTER cluster]
[TO [db.]target_table]
[ENGINE = engine]
[POPULATE]
[REFRESH ...]
AS SELECT ...
Ключевые особенности:
  • Без предложения TO: старая внутренняя таблица удаляется и создается новая. Существующие данные во внутренней таблице теряются, если не указан POPULATE.
  • С предложением TO: заменяется только определение представления; целевая таблица и ее данные не затрагиваются.
  • Совместимо с REFRESH, ON CLUSTER и любыми параметрами движка. POPULATE поддерживается только в базах данных Atomic — в базах данных Replicated он не допускается (см. примечание о POPULATE ниже).
  • Требуются привилегии CREATE VIEW и DROP VIEW.
CREATE OR REPLACE MATERIALIZED VIEW поддерживается только для движков баз данных Atomic и Replicated. Для движка базы данных Ordinary это не поддерживается.
Примеры: 
-- Создание materialized view со внутренней таблицей
CREATE OR REPLACE MATERIALIZED VIEW mv
    ENGINE = MergeTree ORDER BY x
    AS SELECT x, sum(y) AS total FROM src GROUP BY x;

-- Замена новым определением (данные старой внутренней таблицы будут утеряны)
CREATE OR REPLACE MATERIALIZED VIEW mv
    ENGINE = MergeTree ORDER BY x
    AS SELECT x, count() AS cnt FROM src GROUP BY x;

-- Замена с POPULATE для дозагрузки из существующих исходных данных
CREATE OR REPLACE MATERIALIZED VIEW mv
    ENGINE = MergeTree ORDER BY x
    POPULATE
    AS SELECT x FROM src;

-- Замена MV с внутренней таблицей на MV с TO-таблицей (данные целевой таблицы сохраняются)
CREATE OR REPLACE MATERIALIZED VIEW mv TO target
    AS SELECT x FROM src;
Вот пошаговое руководство по использованию materialized views.
Materialized views хранят данные, преобразованные соответствующим запросом SELECT. При создании materialized view без TO [db].[table] необходимо указать ENGINE — движок таблицы для хранения данных. При создании materialized view с TO [db].[table] нельзя одновременно использовать POPULATE. Materialized view работает следующим образом: при вставке данных в таблицу, указанную в SELECT, часть вставленных данных преобразуется этим запросом SELECT, а результат вставляется в представление.
Materialized views в ClickHouse при вставке в целевую таблицу используют имена столбцов, а не их порядок. Если каких-либо имен столбцов нет в результате запроса SELECT, ClickHouse использует значение по умолчанию, даже если столбец не имеет тип Nullable. Поэтому рекомендуется задавать псевдонимы для каждого столбца при использовании materialized views.Materialized views в ClickHouse по своей сути больше похожи на триггеры вставки. Если в запросе представления есть агрегация, она применяется только к батчу только что вставленных данных. Любые изменения существующих данных в исходной таблице (например, update, delete, drop partition и т. д.) не изменяют materialized view.Поведение materialized views в ClickHouse при ошибках не является детерминированным. Это означает, что блоки, которые уже были записаны, сохранятся в целевой таблице, а все блоки после ошибки — нет.По умолчанию, если отправка в одно из представлений завершается ошибкой, запрос INSERT тоже завершается ошибкой, и некоторые блоки могут не записаться в целевую таблицу. Это поведение можно изменить с помощью настройки materialized_views_ignore_errors (ее следует задавать для запроса INSERT): если установить materialized_views_ignore_errors=true, любые ошибки при отправке в представления будут игнорироваться, и все блоки будут записаны в целевую таблицу.Также обратите внимание, что для таблиц system.*_log значение materialized_views_ignore_errors по умолчанию равно true.
Если указать POPULATE, существующие данные таблицы будут вставлены в представление при его создании, как при выполнении CREATE TABLE ... AS SELECT .... В противном случае запрос будет содержать только данные, вставленные в таблицу после создания представления. Мы не рекомендуем использовать POPULATE, поскольку данные, вставленные в таблицу во время создания представления, не будут вставлены в него.
Поскольку POPULATE работает как CREATE TABLE ... AS SELECT ..., у него есть ограничения:
  • Он не поддерживается для базы данных Replicated
  • Он не поддерживается в ClickHouse Cloud
Вместо этого можно использовать отдельный INSERT ... SELECT.
Запрос SELECT может содержать DISTINCT, GROUP BY, ORDER BY, LIMIT. Обратите внимание, что соответствующие преобразования выполняются независимо для каждого блока вставленных данных. Например, если задан GROUP BY, данные агрегируются во время вставки, но только в пределах одного пакета вставленных данных. Далее данные не агрегируются. Исключение — использование ENGINE, который сам выполняет агрегацию данных, например SummingMergeTree. Если materialized view использует конструкцию TO [db.]name, можно выполнить DETACH представления, запустить ALTER для целевой таблицы, а затем ATTACH ранее отсоединённого (DETACH) представления. Обратите внимание, что на materialized view влияет настройка optimize_on_insert. Данные объединяются перед вставкой в представление. Представления выглядят так же, как обычные таблицы. Например, они отображаются в результате запроса SHOW TABLES. Чтобы удалить представление, используйте DROP VIEW. Хотя DROP TABLE тоже работает для VIEW.

​
Безопасность SQL

DEFINER и SQL SECURITY позволяют указать, от имени какого пользователя ClickHouse выполнять запрос, лежащий в основе представления. SQL SECURITY имеет три допустимых значения: DEFINER, INVOKER или NONE. В секции DEFINER можно указать любого существующего пользователя или CURRENT_USER. В следующей таблице показано, какие права требуются и какому пользователю, чтобы выполнять SELECT из представления. Обратите внимание: независимо от выбранного режима безопасности SQL, в любом случае для чтения из представления по-прежнему требуется GRANT SELECT ON <view>.
Параметр безопасности SQLПредставлениеMaterialized View
DEFINER aliceУ alice должен быть grant SELECT на исходную таблицу представления.У alice должен быть grant SELECT на исходную таблицу представления и grant INSERT на целевую таблицу представления.
INVOKERУ пользователя должен быть grant SELECT на исходную таблицу представления.SQL SECURITY INVOKER нельзя указывать для materialized view.
NONE--
SQL SECURITY NONE — устаревший параметр. Любой пользователь, имеющий права на создание представлений с SQL SECURITY NONE, сможет выполнять любые произвольные запросы. Поэтому для создания представления с этим параметром требуется GRANT ALLOW SQL SECURITY NONE TO <user>.
Если DEFINER/SQL SECURITY не указаны, используются значения по умолчанию: Если представление присоединено без указания DEFINER/SQL SECURITY, по умолчанию используется SQL SECURITY NONE для materialized view и SQL SECURITY INVOKER для обычного представления. Чтобы изменить безопасность SQL для существующего представления, используйте 
ALTER TABLE MODIFY SQL SECURITY { DEFINER | INVOKER | NONE } [DEFINER = { user | CURRENT_USER }]

​
Примеры

CREATE VIEW test_view
DEFINER = alice SQL SECURITY DEFINER
AS SELECT ...

CREATE VIEW test_view
SQL SECURITY INVOKER
AS SELECT ...

​
Live View

Эта возможность объявлена устаревшей и будет удалена в будущем. Для вашего удобства старая документация находится здесь

​
Refreshable Materialized View

CREATE MATERIALIZED VIEW [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
REFRESH EVERY|AFTER interval [OFFSET interval]
[RANDOMIZE FOR interval]
[DEPENDS ON [db.]name [, [db.]name [, ...]]]
[SETTINGS name = value [, name = value [, ...]]]
[APPEND]
[TO[db.]name] [(columns)] [ENGINE = engine]
[EMPTY]
[DEFINER = { user | CURRENT_USER }] [SQL SECURITY { DEFINER | NONE }]
AS SELECT ...
[COMMENT 'comment']
где interval — последовательность простых интервалов: 
number SECOND|MINUTE|HOUR|DAY|WEEK|MONTH|YEAR
Периодически выполняет соответствующий запрос и сохраняет его результат в таблице.
  • Если указано APPEND, при каждом обновлении в таблицу добавляются новые строки без удаления существующих. Вставка не является атомарной, как и в обычном запросе INSERT INTO ... SELECT.
  • В противном случае при каждом обновлении предыдущее содержимое таблицы атомарно заменяется.
Отличия от обычных non-refreshable materialized views:
  • Нет insert trigger. Когда новые данные вставляются в таблицу, указанную в SELECT, они не передаются автоматически в refreshable materialized view. Вместо этого данные вставляются только во время периодических или ручных обновлений.
  • Для запроса SELECT нет ограничений. Допускаются table functions (например, url()), views, UNION, JOIN.
Настройки в части запроса REFRESH ... SETTINGS — это настройки обновления (например, refresh_retries), а не обычные настройки (например, max_threads). Обычные настройки можно указать с помощью SETTINGS в конце запроса.

​
Расписание обновления

Примеры расписаний обновления: 
REFRESH EVERY 1 DAY -- каждый день, в полночь (UTC)
REFRESH EVERY 1 MONTH -- в 1-й день каждого месяца, в полночь
REFRESH EVERY 1 MONTH OFFSET 5 DAY 2 HOUR -- в 6-й день каждого месяца, в 2:00
REFRESH EVERY 2 WEEK OFFSET 5 DAY 15 HOUR 10 MINUTE -- каждую вторую субботу, в 15:10
REFRESH EVERY 30 MINUTE -- в 00:00, 00:30, 01:00, 01:30 и т.д.
REFRESH AFTER 30 MINUTE -- через 30 минут после завершения предыдущего обновления, без привязки к времени суток
-- REFRESH AFTER 1 HOUR OFFSET 1 MINUTE -- синтаксическая ошибка: OFFSET не допускается с AFTER
REFRESH EVERY 1 WEEK 2 DAYS -- каждые 9 дней, без привязки к конкретному дню недели или месяца;
                            -- а именно: когда номер дня (начиная с 1969-12-29) кратен 9
REFRESH EVERY 5 MONTHS -- каждые 5 месяцев, в разные месяцы каждого года (так как 12 не кратно 5);
                       -- а именно: когда номер месяца (начиная с 1970-01) кратен 5
RANDOMIZE FOR случайным образом смещает время каждого обновления, например: 
REFRESH EVERY 1 DAY OFFSET 2 HOUR RANDOMIZE FOR 1 HOUR -- каждый день в случайное время между 01:30 и 02:30
Для одного представления одновременно может выполняться не более одного обновления. Например, если обновление представления с REFRESH EVERY 1 MINUTE занимает 2 минуты, оно будет обновляться раз в 2 минуты. Если затем оно начнёт выполняться быстрее и обновляться за 10 секунд, оно снова вернётся к обновлению раз в минуту. (В частности, оно не будет обновляться каждые 10 секунд, чтобы наверстать пропущенные обновления — никакой очереди таких обновлений не существует.) Кроме того, обновление запускается сразу после создания materialized view, если только в запросе CREATE не указано EMPTY. Если указано EMPTY, первое обновление произойдёт по расписанию.

​
В базе данных Replicated

Если refreshable materialized view находится в базе данных Replicated, реплики координируют работу между собой так, что в каждый запланированный момент обновление выполняет только одна реплика. Для этого требуется движок таблицы ReplicatedMergeTree, чтобы все реплики видели данные, полученные в результате обновления. В режиме APPEND координацию можно отключить с помощью SETTINGS all_replicas = 1. В этом случае реплики выполняют обновления независимо друг от друга. Тогда ReplicatedMergeTree не требуется. В режиме без APPEND поддерживается только координируемое обновление. Для нескоординированного обновления используйте базу данных Atomic и запрос CREATE ... ON CLUSTER, чтобы создать refreshable materialized view на всех репликах. Координация выполняется через Keeper. Путь znode определяется настройкой сервера default_replica_path.

​
Зависимости обновления

DEPENDS ON синхронизирует обновление разных таблиц. Например, предположим, что существует цепочка из двух refreshable materialized view: 
CREATE MATERIALIZED VIEW source REFRESH EVERY 1 DAY AS SELECT * FROM url(...)
CREATE MATERIALIZED VIEW destination REFRESH EVERY 1 DAY AS SELECT ... FROM source
Без DEPENDS ON оба представления начнут обновляться в полночь, и в destination обычно будут попадать вчерашние данные из source. Если добавить зависимость: 
CREATE MATERIALIZED VIEW destination REFRESH EVERY 1 DAY DEPENDS ON source AS SELECT ... FROM source
тогда обновление destination начнется только после того, как в этот день завершится обновление source, поэтому destination будет основан на актуальных данных. Того же результата также можно добиться с помощью: 
CREATE MATERIALIZED VIEW destination REFRESH AFTER 1 HOUR DEPENDS ON source AS SELECT ... FROM source
где 1 HOUR может быть любой длительностью, меньшей, чем период обновления source. Зависимая таблица не будет обновляться чаще, чем любая из её зависимостей. Это корректный способ настроить цепочку refreshable views, не указывая фактический период обновления более одного раза. Ещё несколько примеров:
  • REFRESH EVERY 1 DAY OFFSET 10 MINUTE (destination) зависит от REFRESH EVERY 1 DAY (source)
    Если обновление source занимает больше 10 минут, destination будет его ждать.
  • REFRESH EVERY 1 DAY OFFSET 1 HOUR зависит от REFRESH EVERY 1 DAY OFFSET 23 HOUR
    Аналогично примеру выше, хотя соответствующие обновления происходят в разные календарные дни. Обновление destination в день X+1 будет ждать обновления source в день X (если оно занимает более 2 часов).
  • REFRESH EVERY 2 HOUR зависит от REFRESH EVERY 1 HOUR
    Обновление 2 HOUR выполняется после обновления 1 HOUR через каждый второй час, например после полуночного обновления, затем после обновления в 2 часа ночи и т. д.
  • REFRESH EVERY 1 MINUTE зависит от REFRESH EVERY 2 HOUR
    destination обновляется один раз после каждого обновления source, то есть каждые 2 часа. 1 MINUTE фактически игнорируется.
  • REFRESH AFTER 1 HOUR зависит от REFRESH AFTER 1 HOUR
    В настоящее время это не рекомендуется.
DEPENDS ON работает только между refreshable materialized views. Если указать обычную таблицу в списке DEPENDS ON, view вообще никогда не будет обновляться (зависимости можно удалить с помощью ALTER, см. Изменение параметров обновления).

​
Настройки обновления

Доступные настройки обновления:
  • refresh_retries - Сколько раз повторять попытку, если запрос обновления завершается исключением. Если все повторные попытки завершаются неудачей, обновление пропускается до следующего запланированного времени. 0 означает отсутствие повторных попыток, -1 — бесконечное число повторных попыток. Значение по умолчанию: 2.
  • refresh_retry_initial_backoff_ms - Задержка перед первой повторной попыткой, если refresh_retries не равно нулю. При каждой следующей повторной попытке задержка удваивается, вплоть до refresh_retry_max_backoff_ms. Значение по умолчанию: 100 мс.
  • refresh_retry_max_backoff_ms - Ограничение на экспоненциальный рост задержки между попытками обновления. Значение по умолчанию: 60000 мс (1 минута).
  • all_replicas - В Replicated database с APPEND определяет, будут ли все реплики обновляться независимо или в каждый запланированный момент обновление будет выполнять только одна реплика. Не может быть изменено после создания представления. Значение по умолчанию: false.
  • prefer_dependency_replica - Если у представления есть DEPENDS ON, приоритет на выполнение зависимого обновления получает реплика, выполнившая обновление родительского объекта; остальные реплики откладывают свою попытку на prefer_dependency_replica_delay_ms. Полезно при использовании SharedMergeTree, чтобы избежать ситуаций, когда отставание репликации приводит к отсутствию данных в цепочках зависимых обновлений. Значение по умолчанию: false.
  • prefer_dependency_replica_delay_ms - Как долго неприоритетные реплики ждут перед попыткой выполнить зависимое обновление, когда включен параметр prefer_dependency_replica. Значение по умолчанию: 2000 мс.

​
Изменение параметров обновления

Параметры обновления существующей refreshable materialized view изменяются командой ALTER TABLE ... MODIFY REFRESH: 
ALTER TABLE [db.]name MODIFY REFRESH EVERY|AFTER ... [RANDOMIZE FOR ...] [DEPENDS ON ...] [SETTINGS ...]
Расписание (EVERY или AFTER) обязательно: этот оператор всегда заменяет все параметры обновления — расписание, RANDOMIZE FOR, DEPENDS ON и настройки обновления — на указанные в нём. Всё, что опущено, сбрасывается к значению по умолчанию (настройки) или удаляется (зависимости, рандомизация).
  • Чтобы изменить только настройки обновления (например, refresh_retries), заново укажите текущее расписание: 
    ALTER TABLE rmv MODIFY REFRESH EVERY 1 HOUR SETTINGS refresh_retries = 5;
  • ALTER TABLE ... MODIFY SETTING refresh_retries = ... не поддерживается для materialized view; нужно использовать MODIFY REFRESH.
  • Добавлять или удалять APPEND не поддерживается.
  • Настройку all_replicas нельзя изменить после создания.
Примеры: 
-- Изменить расписание, удалить существующие настройки и зависимости.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE;

-- Изменить расписание и настроить поведение повторных попыток.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE
SETTINGS refresh_retries = 5,
         refresh_retry_initial_backoff_ms = 500,
         refresh_retry_max_backoff_ms = 60000;

-- Сохранить зависимость при изменении периода.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR DEPENDS ON other_rmv;

-- Удалить зависимость, опустив `DEPENDS ON`.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR;

​
Другие операции

Статус всех refreshable materialized view доступен в таблице system.view_refreshes. В частности, в ней содержатся прогресс обновления (если оно выполняется), время последнего и следующего обновления, а также сообщение об исключении, если обновление завершилось ошибкой. Чтобы вручную остановить, запустить, инициировать или отменить обновления, используйте SYSTEM STOP|START|REFRESH|WAIT|CANCEL VIEW. Чтобы дождаться завершения обновления, используйте SYSTEM WAIT VIEW. Это особенно полезно, если нужно дождаться первого обновления после создания представления.
Интересный факт: запросу обновления разрешено читать из обновляемого представления, при этом он видит версию данных до обновления. Это означает, что вы можете реализовать игру «Жизнь» Конвея: https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==

​
Оконное представление

Это экспериментальная возможность, которая в будущих выпусках может измениться обратно несовместимым образом. Чтобы включить использование оконных представлений и запроса WATCH, включите настройку allow_experimental_window_view. Введите команду set allow_experimental_window_view = 1.
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']
Оконное представление может агрегировать данные по временному окну и выводить результаты, когда окно готово выдать их. Оно хранит частичные результаты агрегации во внутренней (или указанной) таблице, чтобы уменьшить задержку, и может записывать результат обработки в указанную таблицу или отправлять уведомления с помощью запроса WATCH. Создание оконного представления похоже на создание MATERIALIZED VIEW. Для хранения промежуточных данных оконному представлению требуется внутреннее хранилище. Его можно указать с помощью предложения INNER ENGINE; по умолчанию оконное представление использует AggregatingMergeTree в качестве внутреннего движка. При создании оконного представления без TO [db].[table] необходимо указать ENGINE — движок таблицы для хранения данных.

​
Функции временных окон

Функции временных окон используются для получения нижней и верхней границ окна для записей. Оконное представление необходимо использовать вместе с функцией временного окна.

​
АТРИБУТЫ ВРЕМЕНИ

Оконное представление поддерживает обработку по времени обработки и времени события. Время обработки позволяет оконному представлению формировать результаты на основе локального времени машины и используется по умолчанию. Это наиболее простое понятие времени, однако оно не обеспечивает детерминированность. Атрибут времени обработки можно задать, установив time_attr функции временного окна в столбец таблицы или используя функцию now(). Следующий запрос создает оконное представление с временем обработки. 
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
Время события — это время, когда каждое отдельное событие произошло на устройстве-источнике. Обычно эта временная метка записывается в запись в момент её создания. Обработка по времени события позволяет получать согласованные результаты даже при нарушении порядка событий или при позднем поступлении событий. Оконное представление поддерживает обработку по времени события с помощью синтаксиса WATERMARK. Оконное представление поддерживает три стратегии водяной метки:
  • STRICTLY_ASCENDING: Выдаёт водяную метку, равную максимальной наблюдаемой на текущий момент временной метке. Строки, у которых временная метка меньше максимальной, не считаются опоздавшими.
  • ASCENDING: Выдаёт водяную метку, равную максимальной наблюдаемой на текущий момент временной метке минус 1. Строки, у которых временная метка равна максимальной или меньше неё, не считаются опоздавшими.
  • BOUNDED: WATERMARK=INTERVAL. Выдаёт водяные метки, равные максимальной наблюдаемой временной метке минус указанная задержка.
Следующие запросы — примеры создания оконного представления с WATERMARK: 
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);
По умолчанию окно срабатывает при поступлении водяной метки, а элементы, поступившие позже водяной метки, отбрасываются. Оконное представление поддерживает обработку опоздавших событий с помощью настройки ALLOWED_LATENESS=INTERVAL. Пример обработки опоздавших событий: 
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;
Обратите внимание, что элементы, выдаваемые при позднем срабатывании, следует рассматривать как обновлённые результаты предыдущего вычисления. Вместо срабатывания в конце окна оконное представление срабатывает сразу при поступлении позднего события. Таким образом, для одного и того же окна будет сформировано несколько результатов. Пользователям нужно учитывать эти дублирующиеся результаты или выполнять их дедупликацию. Вы можете изменить SELECT запрос, указанный в оконном представлении, с помощью оператора ALTER TABLE ... MODIFY QUERY. Структура данных, получающаяся в результате выполнения нового SELECT запроса, должна быть такой же, как у исходного SELECT запроса, как с предложением TO [db.]name, так и без него. Обратите внимание, что данные в текущем окне будут потеряны, поскольку промежуточное состояние нельзя использовать повторно.

​
Мониторинг новых окон

Оконное представление поддерживает запрос WATCH для мониторинга изменений, либо можно использовать синтаксис TO для вывода результатов в таблицу. 
WATCH [db.]window_view
[EVENTS]
[LIMIT n]
[FORMAT format]
Можно указать LIMIT, чтобы задать количество обновлений, которые нужно получить до завершения запроса. Предложение EVENTS позволяет использовать сокращённую форму запроса WATCH: вместо результата запроса вы получите только последнюю водяную метку запроса.

​
Настройки

  • window_view_clean_interval: Интервал очистки оконного представления в секундах для удаления устаревших данных. Система сохраняет окна, которые ещё не были полностью активированы в соответствии с системным временем или конфигурацией WATERMARK, а остальные данные удаляются.
  • window_view_heartbeat_interval: Интервал heartbeat-сигнала в секундах, показывающий, что watch-запрос активен.
  • wait_for_window_view_fire_signal_timeout: Тайм-аут ожидания сигнала срабатывания оконного представления при обработке по времени события.

​
Пример

Предположим, нам нужно подсчитать количество записей о кликах за каждые 10 секунд в таблице журналов data, и структура этой таблицы такова: 
CREATE TABLE data ( `id` UInt64, `timestamp` DateTime) ENGINE = Memory;
Сначала создадим оконное представление с окном tumble с 10-секундным интервалом: 
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
Затем с помощью запроса WATCH получаем результаты. 
WATCH wv
При вставке логов в таблицу data, 
INSERT INTO data VALUES(1,now())
Запрос WATCH должен вывести результаты в следующем виде: 
┌─count(id)─┬────────window_start─┐
│         1 │ 2020-01-14 16:56:40 │
└───────────┴─────────────────────┘
Либо можно направить вывод в другую таблицу, используя синтаксис TO. 
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
Дополнительные примеры можно найти в тестах ClickHouse с сохранением состояния (там они называются *window_view*).

​
Использование оконного представления

Оконное представление полезно в следующих сценариях:
  • Мониторинг: Агрегируйте и вычисляйте метрики по журналам во времени и выводите результаты в целевую таблицу. Панель мониторинга может использовать целевую таблицу в качестве исходной.
  • Анализ: Автоматически агрегируйте и предварительно обрабатывайте данные в пределах временного окна. Это может быть полезно при анализе большого количества журналов. Предварительная обработка устраняет повторяющиеся вычисления в нескольких запросах и уменьшает задержку выполнения запросов.

​
Связанные материалы

​
Временные представления

ClickHouse поддерживает временные представления со следующими характеристиками (где применимо — аналогично временным таблицам):
  • Срок жизни сеанса Временное представление существует только в рамках текущего сеанса. По завершении сеанса оно удаляется автоматически.
  • Без базы данных Для временного представления нельзя указывать имя базы данных. Оно существует вне баз данных (в пространстве имен сеанса).
  • Не реплицируется / без ON CLUSTER Временные объекты локальны для сеанса и не могут создаваться с ON CLUSTER.
  • Разрешение имен Если временный объект (таблица или представление) имеет то же имя, что и постоянный объект, и запрос ссылается на это имя без указания базы данных, используется временный объект.
  • Логический объект (без хранения) Временное представление хранит только текст своего SELECT (внутри используется хранилище View). Оно не сохраняет данные и не поддерживает INSERT.
  • Предложение ENGINE Указывать ENGINE не требуется; если указать ENGINE = View, оно будет проигнорировано / обработано как то же логическое представление.
  • Безопасность / привилегии Для создания временного представления требуется привилегия CREATE TEMPORARY VIEW, которая неявно предоставляется через CREATE VIEW.
  • SHOW CREATE Используйте SHOW CREATE TEMPORARY VIEW view_name;, чтобы вывести DDL временного представления.

​
Синтаксис

CREATE TEMPORARY VIEW [IF NOT EXISTS] view_name AS <select_query>
OR REPLACE не поддерживается для временных представлений (по аналогии с временными таблицами). Если вам нужно «заменить» временное представление, удалите его и создайте заново.

​
Примеры

Создайте временную исходную таблицу и временное представление на её основе: 
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;
Показать DDL: 
SHOW CREATE TEMPORARY VIEW tview;
Удалить её: 
DROP TEMPORARY VIEW IF EXISTS tview;  -- временные представления удаляются с использованием синтаксиса TEMPORARY TABLE

​
Недопустимые варианты / ограничения

  • CREATE OR REPLACE TEMPORARY VIEW ... → не допускается (используйте DROP + CREATE).
  • CREATE TEMPORARY MATERIALIZED VIEW ... / WINDOW VIEW → не допускается.
  • CREATE TEMPORARY VIEW db.view AS ... → не допускается (без указания базы данных).
  • CREATE TEMPORARY VIEW view ON CLUSTER 'name' AS ... → не допускается (временные объекты локальны для сеанса).
  • POPULATE, REFRESH, TO [db.table], внутренние движки и все специфичные для MV секции → не применимы к временным представлениям.

​
Примечания о распределённых запросах

Временное представление — это лишь определение; передавать здесь нечего. Если ваше временное представление ссылается на временные таблицы (например, Memory), их данные могут передаваться на удалённые серверы при выполнении распределённого запроса — так же, как и в случае временных таблиц.

​
Пример

-- Таблица в памяти в рамках сеанса
CREATE TEMPORARY TABLE temp_ids (id UInt64) ENGINE = Memory;

INSERT INTO temp_ids VALUES (1), (5), (42);

-- Представление в рамках сеанса над временной таблицей (исключительно логическое)
CREATE TEMPORARY VIEW v_ids AS
SELECT id FROM temp_ids;

-- Замените 'test' именем вашего кластера.
-- GLOBAL JOIN заставляет ClickHouse *отправлять* небольшую сторону JOIN (temp_ids через v_ids)
-- на каждый удалённый сервер, выполняющий левую часть запроса.
SELECT count()
FROM cluster('test', system.numbers) AS n
GLOBAL ANY INNER JOIN v_ids USING (id)
WHERE n.number < 100;
Последнее изменение 10 июня 2026 г.