Обзор асинхронных материализованных представлений
Асинхронное материализованное представление — это решение для ускорения запросов, сочетающее гибкость представления с высокой производительностью физической таблицы. Благодаря предварительному вычислению и сохранению результатов последующие запросы могут напрямую обращаться к материализованному набору результатов, избегая затрат на повторное выполнение сложных SQL-запросов.
Краткий обзор
Прежде чем использовать асинхронные материализованные представления, уточните следующее:
- Требуется ли для ваших задач ускорение запросов, упрощение ETL, ускорение запросов к внешним таблицам в архитектуре lakehouse или оптимизация записи?
- Соответствует ли запрос шаблону SPJG (SELECT-PROJECT-JOIN-GROUP-BY)?
- Допустима ли согласованность данных в конечном счёте (синхронизация не в реальном времени)?
- Относится ли Catalog базовой таблицы к поддерживаемым типам (Internal/Hive/Iceberg/Paimon/Hudi/JDBC/ES)?
- Нужно ли инкрементальное обновление по партициям для снижения затрат на обновление?
Сценарии использования
Асинхронные материализованные представления предназначены прежде всего для следующих четырёх сценариев:
| Сценарий | Преимущества |
|---|---|
| Ускорение запросов и увеличение числа одновременно выполняемых запросов | Существенно повышает скорость запросов, позволяет выполнять больше запросов одновременно и снижает потребление ресурсов |
| Упрощение процесса ETL | Упрощает процесс извлечения, преобразования и загрузки данных (ETL) и повышает эффективность разработки |
| Ускорение запросов к внешним таблицам в архитектуре lakehouse | Существенно повышает скорость запросов к внешним источникам данных в архитектуре lakehouse |
| Повышение эффективности записи | Снижает конкуренцию за ресурсы, оптимизирует процесс записи данных и обеспечивает согласованность и целостность |
Ограничения
Прежде чем использовать асинхронные материализованные представления, ознакомьтесь со следующими ограничениями:
- Согласованность данных: асинхронное материализованное представление обеспечивает согласованность с базовой таблицей в конечном счёте, но не может синхронизироваться в реальном времени и не гарантирует согласованность в реальном времени.
- Оконные функции: в настоящее время прозрачное переписывание запросов, содержащих оконные функции, в запросы на основе материализованных представлений не поддерживается.
- Сценарии с несколькими таблицами: если материализованное представление объединяет больше таблиц, чем используется в запросе (например, запрос использует только t1 и t2, а материализованное представление содержит t1, t2 и t3), прозрачное переписывание в настоящее время не поддерживается.
- Операторы, не поддерживаемые прозрачным переписыванием: если материализованное представление содержит
UNION ALL,LIMIT,ORDER BYилиCROSS JOIN, его по-прежнему можно создать обычным способом, но использовать для прозрачного переписывания нельзя. - Ограничения типов данных: создание материализованного представления с типом
VARBINARYв настоящее время не поддерживается.
Принципы работы
Асинхронное материализованное представление по сути является внутренней таблицей типа MTMV. При создании материализованного представления система также регистрирует задачу обновления. При выполнении эта задача записывает актуальные данные в материализованное представление с помощью оператора INSERT OVERWRITE.
Механизм обновления
В отличие от синхронных материализованных представлений, которые обновляются инкрементально в реальном времени, асинхронные материализованные представления предлагают более гибкие варианты обновления:
| Режим обновления | Описание | Сценарии применения |
|---|---|---|
| Полное обновление | Заново вычисляет все данные, на которые ссылается SQL-определение материализованного представления, и полностью записывает результат в материализованное представление | Небольшой объём данных или необходимость обеспечить согласованность всех данных |
| Инкрементальное обновление по партициям | Автоматически определяет изменения данных в партициях базовой таблицы и обновляет только затронутые партиции | Большой объём данных, изменения в котором сосредоточены в отдельных партициях |
- Полное обновление: обеспечивает полную согласованность данных материализованного представления с базовой таблицей, но может требовать больше вычислительных ресурсов и времени.
- Инкрементальное обновление по партициям: существенно сокращает затраты ресурсов и времени на обновление, обеспечивая при этом согласованность в конечном счёте.
Прозрачное переписывание запросов
Прозрачное переписывание запросов — важный механизм оптимизации производительности запросов в базе данных. При обработке пользовательского запроса система автоматически переписывает 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 обновляться автоматически?
Оно не может обнаруживать изменения в базовой таблице и подходит только для сценариев с ручным обновлением по мере необходимости.
См. также
- Создание, запросы и обслуживание асинхронных материализованных представлений: Создание, запросы и обслуживание асинхронных материализованных представлений
- Руководство пользователя: Руководство пользователя
- Часто задаваемые вопросы: Часто задаваемые вопросы