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

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

Синтаксис:
Обычные представления не хранят данные. При каждом обращении они просто читают их из другой таблицы. Иными словами, обычное представление — это всего лишь сохранённый запрос. При чтении из представления этот сохранённый запрос используется как подзапрос в секции FROM. Например, предположим, что вы создали представление:
и написали запрос:
Этот запрос полностью эквивалентен использованию такого подзапроса:

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

Параметризованные представления похожи на обычные представления, но могут создаваться с параметрами, значения которых определяются не сразу. Эти представления можно использовать с табличными функциями: имя представления указывается как имя функции, а значения параметров — как её аргументы.
Выше создаётся представление для таблицы, которое можно использовать как табличную функцию, подставив параметры, как показано ниже.

Materialized View

OR REPLACE и IF NOT EXISTS являются взаимоисключающими: их совместное использование вызывает синтаксическую ошибку.

CREATE OR REPLACE MATERIALIZED VIEW

CREATE OR REPLACE MATERIALIZED VIEW атомарно заменяет существующее materialized view и его внутреннюю таблицу хранения (если она есть). Для выполнения этой операции требуется движок базы данных Atomic или Replicated.
Ключевые особенности:
  • Без предложения TO: старая внутренняя таблица удаляется и создается новая. Существующие данные во внутренней таблице теряются, если не указан POPULATE.
  • С предложением TO: заменяется только определение представления; целевая таблица и ее данные не затрагиваются.
  • Совместимо с REFRESH, ON CLUSTER и любыми параметрами движка. POPULATE поддерживается только в базах данных Atomic — в базах данных Replicated он не допускается (см. примечание о POPULATE ниже).
  • Требуются привилегии CREATE VIEW и DROP VIEW.
CREATE OR REPLACE MATERIALIZED VIEW поддерживается только для движков баз данных Atomic и Replicated. Для движка базы данных Ordinary это не поддерживается.
Примеры:
Вот пошаговое руководство по использованию materialized views.
Materialized views хранят данные, преобразованные соответствующим запросом SELECT. При создании materialized view без TO [db].[table] необходимо указать ENGINE — движок таблицы для хранения данных. При создании materialized view с TO [db].[table] нельзя одновременно использовать POPULATE. Materialized view работает следующим образом: при вставке данных в таблицу, указанную в SELECT, часть вставленных данных преобразуется этим запросом SELECT, а результат вставляется в представление.
В ClickHouse materialized view при вставке в целевую таблицу используют имена столбцов, а не их порядок. Если каких-то имён столбцов нет в результате запроса SELECT, ClickHouse использует значение по умолчанию, даже если столбец не является Nullable. Надёжнее всего указывать псевдонимы для каждого столбца при использовании materialized view.В ClickHouse materialized view реализованы скорее как триггеры вставки. Если в запросе представления есть агрегация, она применяется только к пакету только что вставленных данных. Любые изменения существующих данных в исходной таблице (например, update, delete, drop partition и т. д.) не изменяют materialized view.В ClickHouse у materialized view нет детерминированного поведения в случае ошибок. Это означает, что блоки, которые уже были записаны, сохранятся в целевой таблице, а все блоки после ошибки — нет.По умолчанию, если запись в одно из представлений приводит к исключению, запрос INSERT завершается ошибкой. При этом нет гарантии, что к этому моменту блок уже попал в исходную таблицу — это зависит от момента срабатывания конвейера вставки, а не от ошибки представления. Повторите неудавшийся INSERT с дедупликацией вставки (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views), чтобы получить доставку exactly-once в исходную таблицу и все зависимые представления.Установка materialized_views_ignore_errors=true в запросе INSERT изменяет только отчётность об ошибках: каждая ошибка представления записывается как предупреждение, а запрос INSERT завершается успешно. Доставка в пункт назначения представления, завершившегося с ошибкой, будет частичной — блоки, обработанные до исключения, сохраняются, а проблемный блок и все последующие блоки отбрасываются из этого представления. Представления ниже по цепочке от этого пункта назначения видят только те блоки, которые действительно поступили, поэтому их доставка тоже частична. Соседние представления (и их нисходящие цепочки), которые не сгенерировали исключение, записываются полностью, а запись в исходную таблицу происходит как обычно. Поскольку INSERT сообщает об успехе, клиент не получает сигнала о сбое и автоматический повтор не запускается; используйте эту настройку только тогда, когда запись в исходную таблицу не должна блокироваться из-за проблем на стороне представлений (например, для таблиц system.*_log).Для таблиц 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 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 для существующего представления, используйте

Примеры

Live View

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

Refreshable Materialized View

где interval — последовательность простых интервалов:
В части REFRESH должно быть указано как минимум одно из EVERY, AFTER или DEPENDS ON. Просто REFRESH (без них) не допускается. REFRESH DEPENDS ON ... без EVERY/AFTER — это сокращение для REFRESH AFTER 0 SECOND DEPENDS ON ...; см. ниже раздел Refresh Dependencies. Периодически выполняет соответствующий запрос и сохраняет его результат в таблице.
  • Если указано APPEND, при каждом обновлении в таблицу добавляются новые строки без удаления существующих. Вставка не является атомарной, как и в обычном запросе INSERT INTO ... SELECT.
  • В противном случае при каждом обновлении предыдущее содержимое таблицы атомарно заменяется.
Отличия от обычных non-refreshable materialized views:
  • Нет insert trigger. Когда новые данные вставляются в таблицу, указанную в SELECT, они не передаются автоматически в refreshable materialized view. Вместо этого данные вставляются только во время периодических или ручных обновлений.
  • Для запроса SELECT нет ограничений. Допускаются табличные функции (например, url()), просмотры, UNION, JOIN.
Настройки в части запроса REFRESH ... SETTINGS — это настройки обновления (например, refresh_retries), а не обычные настройки (например, max_threads). Обычные настройки можно указать с помощью SETTINGS в конце запроса.

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

Примеры расписаний обновления:
RANDOMIZE FOR случайным образом смещает время каждого обновления, например:
Для одного представления одновременно может выполняться не более одного обновления. Например, если обновление представления с REFRESH EVERY 1 MINUTE занимает 2 минуты, оно будет обновляться раз в 2 минуты. Если затем оно начнёт выполняться быстрее и обновляться за 10 секунд, оно снова вернётся к обновлению раз в минуту. (В частности, оно не будет обновляться каждые 10 секунд, чтобы наверстать пропущенные обновления — никакой очереди таких обновлений не существует.) Обычно первое обновление запускается сразу после создания materialized view: время с момента последнего обновления равно бесконечности, поэтому по любому расписанию обновление должно начаться прямо сейчас. Если указано EMPTY, это начальное обновление пропускается, а первое обновление произойдёт в следующий момент по расписанию; например, для EVERY 1 HOUR первое обновление произойдёт в конце текущего часа.

В базе данных 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 синхронизирует обновление разных таблиц:
Обновление зависимого представления начнется только после того, как завершится обновление всех представлений, от которых оно зависит. Чтобы запускать обновление сразу после обновления другого представления:
Или, что то же самое:
DEPENDS ON работает только между refreshable materialized view. В частности, если представление-зависимость использует TO <table>, обязательно указывайте имя представления, а не таблицы. Если список DEPENDS ON содержит обычную таблицу, не-refreshable представление или опечатку, представление никогда не будет обновляться и в system.view_refreshes будет иметь состояние MissingDependencies. Зависимости можно изменить или удалить с помощью ALTER, см. Изменение параметров обновления.

Использование DEPENDS ON для согласованной задержки распространения

Если оба представления используют REFRESH EVERY с одинаковым периодом, зависимость действует в каждом временном интервале. Например, предположим, что представления X и Y используют REFRESH EVERY 1 HOUR, а Y читает из выходной таблицы X. Без зависимостей Y обычно будет видеть данные X из обновления за предыдущий час. С DEPENDS ON X обновление Y в 11:00 начнется только после завершения обновления X в 11:00.
И зависимость, и зависящий от неё объект могут независимо пропускать временные интервалы, если обновление занимает больше времени, чем период обновления. Нет гарантии, что зависимый объект будет обновляться ровно один раз на каждое обновление зависимости.

Использование DEPENDS ON для батчевой потоковой обработки

Если REFRESH EVERY не используется, зависимое представление X обновляется, когда все его зависимости обновились хотя бы один раз с момента последнего обновления X. REFRESH AFTER T добавляет задержку: зависимое представление начнет обновляться через T после завершения обновления зависимости. Циклические зависимости допустимы и полезны. Рассмотрим такой граф refreshable materialized views:
  1. X берет батч строк из некоторого потока и помещает их в таблицу.
  2. Затем Y и Z читают из этой таблицы, выполняют разные агрегации и добавляют результаты в другие таблицы.
  3. После полной обработки батча X берет следующий батч, и цикл повторяется.
Полный пример:
Более длинные цепочки тоже работают. Однако это работает хорошо только при включенной координации обновления, то есть когда представления находятся в базе данных Replicated или Shared. Без координации перезапуск сервера прерывает цикл, и после каждого перезапуска приходится вручную выполнять SYSTEM REFRESH VIEW, а не только один раз после создания представлений.

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

Доступные настройки обновления:
  • 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.

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

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

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

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

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

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

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

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

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

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

Настройки

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

Пример

Предположим, нам нужно подсчитать количество записей о кликах за каждые 10 секунд в таблице журналов data, и структура этой таблицы такова:
Сначала создадим оконное представление с окном tumble с 10-секундным интервалом:
Затем с помощью запроса WATCH получаем результаты.
При вставке логов в таблицу data,
Запрос WATCH должен вывести результаты в следующем виде:
Либо можно направить вывод в другую таблицу, используя синтаксис TO.
Дополнительные примеры можно найти в тестах 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 временного представления.

Синтаксис

OR REPLACE не поддерживается для временных представлений (по аналогии с временными таблицами). Если вам нужно «заменить» временное представление, удалите его и создайте заново.

Примеры

Создайте временную исходную таблицу и временное представление на её основе:
Показать DDL:
Удалить её:

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

  • 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), их данные могут передаваться на удалённые серверы при выполнении распределённого запроса — так же, как и в случае временных таблиц.

Пример

Последнее изменение 2 июля 2026 г.