Обновляемые материализованные представления концептуально похожи на материализованные представления в традиционных OLTP базах данных, сохраняющие результат заданного запроса для быстрого извлечения и уменьшающие необходимость многократного выполнения ресурсоемких запросов. В отличие от инкрементных материализованных представлений ClickHouse, это требует периодического выполнения запроса по всему набору данных - результаты которого сохраняются в целевой таблице для запроса. Этот набор результатов должен, теоретически, быть меньше исходного набора данных, что позволяет последующему запросу выполняться быстрее.
Диаграмма объясняет, как работают обновляемые материализованные представления:
Вы также можете посмотреть следующее видео:
Когда следует использовать обновляемые материализованные представления?
Инкрементные материализованные представления ClickHouse невероятно мощные и, как правило, масштабируются намного лучше, чем метод, используемый обновляемыми материализованными представлениями, особенно в случаях, когда необходимо выполнить агрегацию по одной таблице. Посчитывая агрегацию только для каждого блока данных в момент его вставки и сливая инкрементные состояния в финальную таблицу, запрос выполняется только на подмножестве данных. Этот метод масштабируется до потенциальных петабайтов данных и обычно является предпочтительным методом.
Тем не менее, существуют случаи, когда этот инкрементный процесс не требуется или не применим. Некоторые задачи либо несовместимы с инкрементным подходом, либо не требуют обновлений в реальном времени, и периодическая пересборка оказывается более подходящей. Например, вы можете захотеть регулярно выполнять полное пересчитывание представления по всему набору данных, потому что оно использует сложное соединение, что несовместимо с инкрементным подходом.
Обновляемые материализованные представления могут выполнять пакетные процессы, выполняя такие задачи, как денормализация. Зависимости могут быть созданы между обновляемыми материализованными представлениями так, чтобы одно представление зависело от результатов другого и выполнялось только после его завершения. Это может заменить запланированные рабочие процессы или простые DAG, такие как работа dbt. Чтобы узнать больше о том, как устанавливать зависимости между обновляемыми материализованными представлениями, перейдите к разделу CREATE VIEW, Зависимости.
Как освежить обновляемое материализованное представление?
Обновляемые материализованные представления автоматически обновляются с интервалом, который определяется при создании.
Например, следующее материализованное представление обновляется каждую минуту:
CREATE MATERIALIZED VIEW table_name_mv
REFRESH EVERY 1 MINUTE TO table_name AS
...
Если вы хотите принудительно обновить материализованное представление, вы можете использовать оператор SYSTEM REFRESH VIEW:
Когда последний раз обновлялось обновляемое материализованное представление?
Чтобы узнать, когда последний раз обновлялось обновляемое материализованное представление, вы можете запросить системную таблицу system.view_refreshes, как показано ниже:
Функция APPEND позволяет вам добавлять новые строки в конец таблицы, вместо того чтобы заменять все представление.
Одним из применений этой функции является захват снимков значений в определенный момент времени. Например, предположим, что у нас есть таблица events, заполняемая потоком сообщений из Kafka, Redpanda или другой платформы потоковых данных.
Этот набор данных имеет 4096 значений в колонке uuid. Мы можем написать следующий запрос, чтобы найти те, у которых наибольшее общее количество:
SELECT
uuid,
sum(count) AS count
FROM events
GROUP BY ALL
ORDER BY count DESC
LIMIT 10
┌─uuid─┬───count─┐
│ c6f │ 5676468 │
│ 951 │ 5669731 │
│ 6a6 │ 5664552 │
│ b06 │ 5662036 │
│ 0ca │ 5658580 │
│ 2cd │ 5657182 │
│ 32a │ 5656475 │
│ ffe │ 5653952 │
│ f33 │ 5653783 │
│ c5b │ 5649936 │
└──────┴─────────┘
Допустим, мы хотим захватывать количество для каждого uuid каждые 10 секунд и сохранять это в новой таблице под названием events_snapshot. Схема events_snapshot будет выглядеть так:
CREATE TABLE events_snapshot (
ts DateTime32,
uuid String,
count UInt64
)
ENGINE = MergeTree
ORDER BY uuid;
Затем мы могли бы создать обновляемое материализованное представление для заполнения этой таблицы:
CREATE MATERIALIZED VIEW events_snapshot_mv
REFRESH EVERY 10 SECOND APPEND TO events_snapshot
AS SELECT
now() AS ts,
uuid,
sum(count) AS count
FROM events
GROUP BY ALL;
Затем мы можем запросить events_snapshot, чтобы получить количество с течением времени для конкретного uuid:
Руководство по денормализации данных показывает различные методы денормализации данных с использованием набора данных Stack Overflow. Мы заполняем данные в следующие таблицы: votes, users, badges, posts и postlinks.
В этом руководстве мы показали, как денормализовать набор данных postlinks в таблицу posts с помощью следующего запроса:
SELECT
posts.*,
arrayMap(p -> (p.1, p.2), arrayFilter(p -> p.3 = 'Linked' AND p.2 != 0, Related)) AS LinkedPosts,
arrayMap(p -> (p.1, p.2), arrayFilter(p -> p.3 = 'Duplicate' AND p.2 != 0, Related)) AS DuplicatePosts
FROM posts
LEFT JOIN (
SELECT
PostId,
groupArray((CreationDate, RelatedPostId, LinkTypeId)) AS Related
FROM postlinks
GROUP BY PostId
) AS postlinks ON posts_types_codecs_ordered.Id = postlinks.PostId;
Затем мы показали, как выполнить одноразовую вставку этих данных в таблицу posts_with_links, но в производственной системе мы бы хотели выполнять эту операцию периодически.
Как таблица posts, так и таблица postlinks потенциально могут обновляться. Поэтому, вместо того чтобы пытаться реализовать это соединение с помощью инкрементных материализованных представлений, вполне может быть достаточно просто запланировать выполнение этого запроса через установленный интервал, например, раз в час, сохраняя результаты в таблице post_with_links.
Вот где помогают обновляемые материализованные представления, и мы можем создать одно с помощью следующего запроса:
CREATE MATERIALIZED VIEW posts_with_links_mv
REFRESH EVERY 1 HOUR TO posts_with_links AS
SELECT
posts.*,
arrayMap(p -> (p.1, p.2), arrayFilter(p -> p.3 = 'Linked' AND p.2 != 0, Related)) AS LinkedPosts,
arrayMap(p -> (p.1, p.2), arrayFilter(p -> p.3 = 'Duplicate' AND p.2 != 0, Related)) AS DuplicatePosts
FROM posts
LEFT JOIN (
SELECT
PostId,
groupArray((CreationDate, RelatedPostId, LinkTypeId)) AS Related
FROM postlinks
GROUP BY PostId
) AS postlinks ON posts_types_codecs_ordered.Id = postlinks.PostId;
Представление будет выполняться немедленно и каждый час после этого, как запланировано, чтобы обеспечить отражение обновлений в исходной таблице. Важно, что когда запрос повторно выполняется, набор результатов атомарно и прозрачно обновляется.
примечание
Синтаксис здесь идентичен синтаксису инкрементного материализованного представления, за исключением того, что мы включаем оператор REFRESH:
Затем мы можем написать следующий запрос для вычисления сводки по каждому актеру, упорядоченной по количеству появлений в фильмах.
SELECT
id, any(actor_name) AS name, uniqExact(movie_id) AS movies,
round(avg(rank), 2) AS avg_rank, uniqExact(genre) AS genres,
uniqExact(director_name) AS directors, max(created_at) AS updated_at
FROM (
SELECT
imdb.actors.id AS id,
concat(imdb.actors.first_name, ' ', imdb.actors.last_name) AS actor_name,
imdb.movies.id AS movie_id, imdb.movies.rank AS rank, genre,
concat(imdb.directors.first_name, ' ', imdb.directors.last_name) AS director_name,
created_at
FROM imdb.actors
INNER JOIN imdb.roles ON imdb.roles.actor_id = imdb.actors.id
LEFT JOIN imdb.movies ON imdb.movies.id = imdb.roles.movie_id
LEFT JOIN imdb.genres ON imdb.genres.movie_id = imdb.movies.id
LEFT JOIN imdb.movie_directors ON imdb.movie_directors.movie_id = imdb.movies.id
LEFT JOIN imdb.directors ON imdb.directors.id = imdb.movie_directors.director_id
)
GROUP BY id
ORDER BY movies DESC
LIMIT 5;
Не требуется много времени для возврата результата, но предположим, что мы хотим, чтобы это было еще быстрее и менее ресурсоемко.
Предположим, что этот набор данных также подвергается постоянным обновлениям - фильмы постоянно выходят с новыми актерами и режиссерами.
Пришло время для обновляемого материализованного представления, поэтому сначала создадим целевую таблицу для результатов:
CREATE MATERIALIZED VIEW imdb.actor_summary_mv
REFRESH EVERY 1 MINUTE TO imdb.actor_summary AS
SELECT
id,
any(actor_name) AS name,
uniqExact(movie_id) AS num_movies,
avg(rank) AS avg_rank,
uniqExact(genre) AS unique_genres,
uniqExact(director_name) AS uniq_directors,
max(created_at) AS updated_at
FROM
(
SELECT
imdb.actors.id AS id,
concat(imdb.actors.first_name, ' ', imdb.actors.last_name) AS actor_name,
imdb.movies.id AS movie_id,
imdb.movies.rank AS rank,
genre,
concat(imdb.directors.first_name, ' ', imdb.directors.last_name) AS director_name,
created_at
FROM imdb.actors
INNER JOIN imdb.roles ON imdb.roles.actor_id = imdb.actors.id
LEFT JOIN imdb.movies ON imdb.movies.id = imdb.roles.movie_id
LEFT JOIN imdb.genres ON imdb.genres.movie_id = imdb.movies.id
LEFT JOIN imdb.movie_directors ON imdb.movie_directors.movie_id = imdb.movies.id
LEFT JOIN imdb.directors ON imdb.directors.id = imdb.movie_directors.director_id
)
GROUP BY id
ORDER BY num_movies DESC;
Представление будет выполняться немедленно и каждую минуту после этого, как запланировано, чтобы обеспечить отражение обновлений в исходной таблице. Наш предыдущий запрос для получения сводки по актерам становится синтаксически проще и значительно быстрее!
SELECT *
FROM imdb.actor_summary
ORDER BY num_movies DESC
LIMIT 5
Предположим, мы добавим нового актера, "Clicky McClickHouse" в наши исходные данные, который, как оказалось, снялся во множестве фильмов!
INSERT INTO imdb.actors VALUES (845466, 'Clicky', 'McClickHouse', 'M');
INSERT INTO imdb.roles SELECT
845466 AS actor_id,
id AS movie_id,
'Himself' AS role,
now() AS created_at
FROM imdb.movies
LIMIT 10000, 910;
Менее чем через 60 секунд наша целевая таблица обновляется, чтобы отразить продуктивность актера Clicky:
SELECT *
FROM imdb.actor_summary
ORDER BY num_movies DESC
LIMIT 5;
