Обзор асинхронных материализованных представлений
Асинхронное материализованное представление представляет собой решение для ускорения запросов, которое сочетает гибкость представления с высокой производительностью физической таблицы. Благодаря предварительному вычислению и сохранению результатов последующие запросы могут обращаться непосредственно к материализованному набору результатов, избегая затрат на повторное выполнение сложного SQL.
Краткий обзор
Прежде чем использовать асинхронные материализованные представления, уточните следующее:
- Требуются ли бизнесу ускорение запросов, упрощение ETL, ускорение работы с внешними таблицами в архитектуре lakehouse или оптимизация записи?
- Соответствует ли запрос шаблону SPJG (SELECT-PROJECT-JOIN-GROUP-BY)?
- Допустима ли для данных согласованность в конечном счёте (без синхронизации в реальном времени)?
- Входит ли Catalog базовой таблицы в число поддерживаемых (Internal/Hive/Iceberg/Paimon/Hudi/JDBC/ES)?
- Если изменения сосредоточены в нескольких разделах, требуется ли инкрементальное обновление по разделам для снижения затрат на обновление?
- Если в базовых таблицах часто выполняются вставки, обновления и удаления, но изменяется мало строк, подходит ли инкрементальное обслуживание представлений (IVM)?
Сценарии использования
Асинхронные материализованные представления предназначены главным образом для следующих четырёх сценариев:
| Сценарий | Преимущества |
|---|---|
| Ускорение запросов и повышение параллелизма | Значительно ускоряет запросы, повышает параллелизм и снижает потребление ресурсов |
| Упрощение процесса ETL | Упрощает процесс извлечения, преобразования и загрузки данных (ETL) и повышает эффективность разработки |
| Ускорение запросов к внешним таблицам в архитектуре lakehouse | Значительно ускоряет запросы к внешним источникам данных в архитектуре lakehouse |
| Повышение эффективности записи | Снижает конкуренцию за ресурсы, оптимизирует процесс записи данных и обеспечивает согласованность и целостность |
Ограничения
Прежде чем использовать асинхронные материализованные представления, ознакомьтесь со следующими ограничениями:
- Согласованность данных: Асинхронное материализованное представление обеспечивает согласованность с базовой таблицей в конечном счёте, но не может синхронизироваться в реальном времени и не гарантирует согласованность в реальном времени.
- Оконные функции: В настоящее время прозрачное переписывание запросов с оконными функциями для использования материализованных представлений не поддерживается.
- Сценарии с несколькими таблицами: Если в материализованном представлении соединяется больше таблиц, чем участвует в запросе (например, запрос использует только t1 и t2, а материализованное представление содержит t1, t2 и t3), прозрачное переписывание в настоящее время не поддерживается.
- Операторы, не поддерживаемые прозрачным переписыванием: Если материализованное представление содержит
UNION ALL,LIMIT,ORDER BYилиCROSS JOIN, его можно создать обычным способом, но использовать для прозрачного переписывания нельзя. - Ограничения типов данных: При создании материализованного представления тип
VARBINARYв настоящее время не поддерживается.
Принципы работы
Асинхронное материализованное представление по сути является внутренней таблицей типа MTMV. При создании материализованного представления система также регистрирует задачу обновления. Во время выполнения задача записывает актуальные данные в материализованное представление с помощью оператора INSERT OVERWRITE.
Механизм обновления
В отличие от инкрементального обновления синхронных материализованных представлений в реальном времени, асинхронные материализованные представления предоставляют четыре варианта детализации вычислений:
| Способ обновления | Описание | Подходящие сценарии |
|---|---|---|
COMPLETE | Повторно вычисляет все данные, на которые ссылается SQL-запрос в определении материализованного представления | Небольшой объём данных, первоначальное формирование или восстановление базового состояния |
PARTITIONS | Выявляет изменения разделов базовой таблицы и повторно вычисляет каждый затронутый раздел материализованного представления | Большой объём данных, изменения в которых сосредоточены в нескольких разделах |
INCREMENTAL | Использует IVM для вычисления изменений на уровне строк между двумя обновлениями и применяет их к материализованному представлению | Число изменённых строк значительно меньше числа строк во всей таблице или затронутых разделах |
AUTO | Doris автоматически выбирает доступный способ обновления | Требуется, чтобы система выбирала между IVM, обновлением по разделам и полным обновлением |
INCREMENTAL и PARTITIONS выполняют инкрементальное обновление, но с разной детализацией. Первый способ обрабатывает только изменения на уровне строк, а второй полностью пересчитывает затронутые разделы. IVM доступен начиная с Doris 5.0.0 и в настоящее время является экспериментальной возможностью. Требования и ограничения описаны в разделе Инкрементальное обслуживание представлений (IVM).
Прозрачное переписывание
Прозрачное переписывание является важным механизмом оптимизации производительности запросов в базе данных. При обработке пользовательского запроса система автоматически переписывает SQL так, чтобы использовать подходящее материализованное представление, повышая эффективность выполнения и снижая затраты на вычисления. Весь процесс прозрачен для пользователя и не требует его вмешательства.
Асинхронные материализованные представления Doris используют алгоритм прозрачного переписывания на основе шаблона SPJG (SELECT-PROJECT-JOIN-GROUP-BY):
- Выполняется глубокий анализ структуры SQL.
- Автоматически находится и выбирается подходящее материализованное представление для прозрачного переписывания.
- Если существует несколько подходящих материализованных представлений, для выполнения запроса выбирается оптимальное на основе таких стратегий, как модель стоимости, что дополнительно повышает производительность.
Создание асинхронного материализованного представления на озере данных
Синтаксис создания асинхронного материализованного представления на озере данных совпадает с синтаксисом его создания на внутренней таблице, но следует учитывать следующее:
- Источник метаданных: Версия раздела и другая информация, необходимая для обновления материализованного представления, поступают из кеша метаданных озера данных, а не непосредственно из внешней среды. Поэтому после завершения обновления данные согласованы с результатом запроса к озеру данных через Doris, но могут отличаться от результатов других движков в зависимости от того, как обновлялся кеш.
- Обнаружение внешних изменений: Если данные Hive изменяются внешним процессом, не контролируемым Doris (например, заданием Spark, Hive или Flink), но метаданные не меняются (например, при выполнении
insert overwrite), материализованное представление будет ошибочно считаться согласованным с базовой таблицей, однако результаты запросов будут отличаться от результатов запросов к озеру данных через Doris. Эту проблему можно решить принудительным обновлением материализованного представления вручную. - Ограничения Iceberg: При создании материализованного представления с разделами на Iceberg поддерживаются только таблицы Iceberg с одним столбцом разбиения на разделы, а эволюция разбиения на разделы поддерживается с ограничениями. Например, поддерживается изменение временного диапазона раздела по времени; если изменится само поле разбиения на разделы, обновление материализованного представления завершится ошибкой.
- Ограничения Hudi: При создании материализованного представления на Hudi система не может определить, изменились ли данные базовой таблицы. После обновления материализованного представления (или некоторых его разделов) оно считается синхронизированным с базовой таблицей. Поэтому создание материализованного представления на Hudi подходит только для сценариев обновления вручную по требованию.
Поддержка обновления материализованных представлений на озёрах данных
В следующей таблице показана поддержка обновления для различных типов таблиц и Catalog:
| Тип таблицы | Тип Catalog | Способ обновления | Запуск обновления | |
|---|---|---|---|---|
| Полное обновление | Обновление по разделам | Автоматический запуск | ||
| Внутренняя таблица | Internal | Поддерживается с 2.1 | Поддерживается с 2.1 | Поддерживается с 2.1.4 |
| Hive | Hive | Поддерживается с 2.1 | Поддерживается с 2.1 | Не поддерживается |
| Iceberg | Iceberg | Поддерживается с 2.1 | Поддерживается с 3.1 | Не поддерживается |
| Paimon | Paimon | Поддерживается с 2.1 | Поддерживается с 3.1 | Не поддерживается |
| Hudi | Hudi | Поддерживается с 2.1 | Поддерживается с 3.1 | Не поддерживается |
| JDBC | JDBC | Поддерживается с 2.1 | Не поддерживается | Не поддерживается |
| ES | ES | Поддерживается с 2.1 | Не поддерживается | Не поддерживается |
Поддержка прозрачного переписывания на озёрах данных
Прозрачное переписывание с использованием асинхронных материализованных представлений в настоящее время поддерживает следующие типы таблиц и Catalog.
Обнаружение изменений данных базовой таблицы в реальном времени: Это означает, что при изменении данных базовой таблицы, используемых материализованным представлением, оно может обнаружить изменение в реальном времени и использовать актуальные данные в запросах.
| Тип таблицы | Тип Catalog | Поддержка прозрачного переписывания | Обнаружение изменений данных базовой таблицы в реальном времени |
|---|---|---|---|
| Внутренняя таблица | Internal | Поддерживается | Поддерживается |
| Hive | Hive | Поддерживается | Поддерживается с 3.1 |
| Iceberg | Iceberg | Поддерживается | Поддерживается с 3.1 |
| Paimon | Paimon | Поддерживается | Поддерживается с 3.1 |
| Hudi | Hudi | Поддерживается | Не поддерживается |
| JDBC | JDBC | Поддерживается | Не поддерживается |
| ES | ES | Поддерживается | Не поддерживается |
Включение прозрачного переписывания для материализованных представлений на внешних таблицах
Если материализованное представление использует внешние таблицы, по умолчанию оно не участвует в прозрачном переписывании. Чтобы включить его участие, выполните:
SET materialized_view_rewrite_enable_contain_external_table = true;
Оптимизация производительности прозрачного переписывания для внешних таблиц
Начиная с 2.1.11, в Doris оптимизирована производительность прозрачного переписывания для внешних таблиц, главным образом за счёт ускорения получения доступных материализованных представлений, содержащих внешние таблицы.
Если прозрачное переписывание с использованием материализованного представления с разделами, содержащего внешние таблицы, работает медленно, можно настроить следующие параметры в fe.conf:
| Параметр | Значение по умолчанию | Описание | Версия |
|---|---|---|---|
max_hive_partition_cache_num | 10000 | Максимальное число кешей разделов на уровне таблиц в Hive Metastore. Если внешняя таблица Hive содержит много разделов, установите значение 20000 или выше | - |
external_cache_expire_time_minutes_after_access | 10 минут | Срок действия кешированного объекта после последнего обращения к нему. При необходимости его можно увеличить (применяется как к кешу схем внешних таблиц, так и к кешу метаданных Hive) | - |
external_cache_refresh_time_minutes | 10 минут | Интервал автоматического обновления объектов кеша метаданных внешних таблиц. При необходимости его можно увеличить | 3.1+ |
Дополнительные сведения о настройке кеша метаданных внешних таблиц см. в разделе Кеш метаданных.
Связь материализованных представлений с внутренними таблицами OLAP
Модель базовой таблицы, используемой в SQL-определении асинхронного материализованного представления, не ограничена. Это может быть модель Duplicate, модель Unique (merge-on-write или merge-on-read), модель Aggregate и так далее.
Само материализованное представление реализовано на основе таблицы OLAP с моделью Duplicate и теоретически может поддерживать все основные возможности этой модели. Однако для стабильного и эффективного выполнения задач обновления данных на его функциональность накладывается ряд необходимых ограничений:
- Операции с разделами: Разделы материализованного представления автоматически создаются и обслуживаются на основе его базовых таблиц. Пользователи не могут выполнять операции с разделами материализованного представления.
- Удаление и переименование: С материализованным представлением связаны задания (JOB), поэтому для работы с ним нельзя использовать команды
DROP TABLEилиRENAME TABLE. Для выполнения соответствующих операций используйте собственные команды материализованного представления. - Типы данных столбцов: Типы данных столбцов материализованного представления автоматически выводятся из запроса, указанного при создании, и не могут быть изменены, иначе задача обновления может завершиться ошибкой.
- Изменение свойств: У материализованного представления есть свойства, которых нет у таблицы Duplicate. Их необходимо изменять с помощью команд материализованного представления. Остальные общие свойства изменяются командой
ALTER TABLE.
Часто задаваемые вопросы
Вопрос 1: Может ли асинхронное материализованное представление гарантировать согласованность данных с базовой таблицей в реальном времени?
Нет. Асинхронное материализованное представление обеспечивает согласованность с базовой таблицей в конечном счёте, но не может синхронизироваться в реальном времени. Если требуется согласованность в реальном времени, рассмотрите возможность использования синхронного материализованного представления.
Вопрос 2: Почему запрос с оконными функциями нельзя переписать?
Текущий алгоритм прозрачного переписывания пока не поддерживает оконные функции. Запросы с оконными функциями не переписываются для использования материализованных представлений.
Вопрос 3: Почему при переписывании запросов не используется материализованное представление на основе внешней таблицы?
Материализованные представления на основе внешних таблиц по умолчанию не участвуют в прозрачном переписывании. Установите materialized_view_rewrite_enable_contain_external_table = true, чтобы разрешить их участие в переписывании.
Вопрос 4: Почему после изменения данных внешней таблицы Hive внешним процессом результаты запросов к материализованному представлению становятся несогласованными?
Если данные Hive изменяются внешним процессом, например Spark, Hive или Flink, но метаданные не меняются (например, при выполнении insert overwrite), материализованное представление не может обнаружить изменение. Эту проблему можно решить принудительным обновлением материализованного представления вручную.
Вопрос 5: Может ли материализованное представление на основе Hudi обновляться автоматически?
Оно не может обнаруживать изменения в базовой таблице и подходит только для сценариев обновления вручную по требованию.
См. также
- Создание, запросы и обслуживание асинхронных материализованных представлений: Создание, запросы и обслуживание асинхронных материализованных представлений
- Поддержание актуальности на уровне строк: Инкрементальное обслуживание представлений (IVM)
- Руководство пользователя: Руководство пользователя
- Часто задаваемые вопросы: Часто задаваемые вопросы