Рекомендации по оптимизации File Cache при разделении чтения и записи
В архитектуре Apache Doris с разделением вычислений и хранения при развёртывании нескольких вычислительных групп для разделения чтения и записи производительность запросов сильно зависит от доли попаданий в File Cache. При промахе кэша (Cache Miss) вычислительная группа только для чтения вынуждена получать данные из удалённого объектного хранилища, что может значительно увеличить задержку запросов.
В этом документе объясняется, как с помощью прогрева кэша и соответствующих настроек уменьшить число промахов кэша, вызванных Compaction, приёмом данных и Schema Change, и тем самым обеспечить стабильную производительность запросов в кластерах только для чтения.
Основная проблема: инвалидация кэша при появлении новых версий данных (Rowsets)
В Doris операции Compaction, Schema Change и приёма данных создают новые наборы файлов данных (Rowsets). Вычислительная группа только для записи по умолчанию кэширует данные в локальном File Cache во время записи, поэтому производительность запросов в этой вычислительной группе не страдает.
Когда вычислительные группы только для чтения синхронизируют метаданные и узнают о новых Rowsets, соответствующие новые файлы данных отсутствуют в локальном кэше. Если в этот момент запрос обращается к новому Rowset, происходит промах кэша, который приводит к снижению производительности.
Основная идея: заблаговременно или с помощью интеллектуальных механизмов загружать данные в кэш вычислительной группы только для чтения до того, как к ним обратятся запросы.
Обзор механизмов прогрева кэша
Прогрев кэша — это процесс упреждающей загрузки данных из удалённого хранилища в File Cache на узлах BE. Doris предоставляет два основных подхода к прогреву:
| Подход к прогреву | Сценарий применения | Особенности |
|---|---|---|
| Активный инкрементальный прогрев | Большинство сценариев, в которых у пользователя есть права на настройку связей прогрева | Интеллектуальный и автоматизированный; рекомендуется в первую очередь |
| Автоматический прогрев в вычислительной группе только для чтения | Нет прав на настройку связей прогрева или используются таблицы без MoW | Небольшие накладные расходы и простая настройка |
Активный инкрементальный прогрев (рекомендуется)
После настройки связи прогрева между вычислительной группой записи и вычислительной группой только для чтения система при появлении новых Rowsets в результате записи, Compaction или других событий активно уведомляет связанные вычислительные группы только для чтения и запускает в них асинхронный прогрев кэша.
Подробные сведения о настройке см. в разделе Активный инкрементальный прогрев FileCache.
Автоматический прогрев в вычислительной группе только для чтения
После включения этой настройки на узлах BE вычислительной группы только для чтения система автоматически запускает асинхронную задачу прогрева при обнаружении новых Rowsets.
Задайте следующую настройку в be.conf вычислительной группы только для чтения:
enable_warmup_immediately_on_new_rowset = true
Межгрупповое чтение из кэша (резервный механизм)
При чтении холодных данных, не охваченных прогревом, можно использовать чтение из кэша другой группы в качестве резервного механизма: при промахе локального кэша вычислительная группа только для чтения сначала пытается прочитать блок из File Cache узла BE вычислительной группы записи и обращается к объектному хранилищу, только если это не удалось. Если назначить вычислительную группу записи группой заполнения кэша (peer_cache_fill_compute_group_id), она также будет получать недостающие блоки из объектного хранилища по запросу группы только для чтения и сохранять их копии в собственном кэше.
Чтение из кэша другой группы включено по умолчанию. Это пассивное чтение во время выполнения запроса, которое не заменяет прогрев и позволяет запросам только для чтения использовать пропускную способность сети и ресурсы чтения кэша вычислительной группы записи. Отключите этот механизм, если требуется строгая изоляция.
Снижение влияния Compaction и Schema Change на производительность запросов
Фоновая операция Compaction объединяет старые Rowsets и создаёт новые. Если новые Rowsets ещё не прогреты, производительность запросов в вычислительной группе только для чтения может колебаться из-за Cache Miss. Эту проблему решают следующие два варианта.
Вариант 1: активный инкрементальный прогрев + отложенная фиксация (рекомендуется)
Этот вариант полностью исключает обращение вычислительных групп только для чтения к новым, ещё не кэшированным Rowsets, созданным в результате Compaction или Schema Change.
Принцип работы:
- Настройте связь активного инкрементального прогрева между вычислительной группой записи и вычислительной группой только для чтения.
- На узлах BE вычислительной группы записи включите отложенную фиксацию для Compaction и Schema Change.
Задайте следующую настройку в be.conf вычислительной группы записи:
enable_compaction_delay_commit_for_warm_up = true
Последовательность действий:
- Задача Compaction или Schema Change завершается в вычислительной группе записи и создаёт новый Rowset.
- Новый Rowset не фиксируется сразу: он невидим для вычислительных групп только для чтения.
- Система запускает прогрев кэша для нового Rowset в связанных вычислительных группах только для чтения.
- Новый Rowset фиксируется и становится видимым для всех вычислительных групп только после того, как все связанные вычислительные группы только для чтения завершат прогрев.
Преимущества:
- Плавный переход: все результаты Compaction, видимые вычислительным группам только для чтения, уже находятся в кэше, поэтому производительность запросов не колеблется.
- Высокая стабильность: это самый надёжный вариант для обеспечения производительности запросов при разделении чтения и записи.
Вариант 2: автоматический прогрев в вычислительной группе только для чтения + выбор с учётом прогрева при выполнении запросов
Этот вариант использует интеллектуальный выбор на уровне запросов, чтобы по возможности пропускать новые Rowsets, прогрев которых ещё не завершён.
Примечание: для таблиц Unique Key MoW нельзя пропускать Rowsets, созданные в результате Compaction, поскольку это нарушит корректность результатов.
Шаги настройки:
-
Включите автоматический прогрев в
be.confвычислительной группы только для чтения:enable_warmup_immediately_on_new_rowset = true -
Включите стратегию выбора Rowset с учётом прогрева при выполнении запросов с помощью переменной сеанса или свойства пользователя.
Настройка для сеанса запросов:
SET enable_prefer_cached_rowset = true;Или настройка в качестве свойства пользователя:
SET property for "jack" enable_prefer_cached_rowset = true;
Последовательность действий:
- Когда вычислительная группа только для чтения обнаруживает новый Rowset, созданный в результате Compaction, она асинхронно запускает задачу прогрева.
- При включённой настройке
enable_prefer_cached_rowsetисполнитель запросов отдаёт предпочтение уже прогретым версиям Rowset. - Запрос автоматически пропускает новые Rowsets, которые ещё прогреваются, без нарушения согласованности данных и обращается к более старым, уже кэшированным Rowsets.
Ограничения:
Этот вариант работает по принципу максимального использования доступных возможностей, без строгих гарантий. Если старые Rowsets, соответствующие новому Rowset, уже удалены или запрос должен обращаться к последней версии данных, запрос всё равно будет ожидать завершения прогрева либо напрямую читать холодные данные.
Снижение влияния приёма данных на производительность запросов
При частом приёме данных, например с помощью INSERT INTO и Stream Load, постоянно создаются новые небольшие файлы (Rowsets), что вызывает Cache Miss в вычислительной группе только для чтения. Если бизнес допускает задержку данных на уровне секунды или долей секунды, следующая комбинированная стратегия может значительно повысить производительность ценой минимального снижения актуальности данных.
Принцип работы: сочетание автоматического прогрева с настройкой допустимого отставания данных при выполнении запроса позволяет исполнителю запросов интеллектуально пропускать самые новые данные, прогрев которых ещё не завершён, в пределах заданного временного окна.
Шаги настройки:
-
Включите механизм прогрева: включите активный инкрементальный прогрев для вычислительной группы только для чтения или включите автоматический прогрев:
enable_warmup_immediately_on_new_rowset = true -
Задайте допустимое отставание данных для запросов: настройте
query_freshness_tolerance_msв сеансе запросов или свойствах пользователя в вычислительной группе только для чтения.Настройка для сеанса запросов:
-- Allow up to 1000 milliseconds (1 second) of data latency
SET query_freshness_tolerance_ms = 1000;Или настройка в качестве свойства пользователя:
SET property for "jack" query_freshness_tolerance_ms = 1000;
Последовательность действий:
- В начале выполнения запрос проверяет Rowsets, к которым ему необходимо обратиться.
- Если Rowset создан за последние 1000 мс и его прогрев ещё не завершён, исполнитель запросов автоматически пропускает его и обращается к более старым, уже кэшированным данным.
- Подавляющее большинство запросов находит данные в кэше, что позволяет избежать снижения производительности из-за чтения недавно записанных холодных данных.
Поведение при превышении допустимого времени: если прогрев Rowset занимает больше времени, чем задано в query_freshness_tolerance_ms, например более 1000 мс, запрос перестаёт его пропускать и возвращается к стандартному поведению — прямому чтению холодных данных. Это гарантирует, что данные в конечном итоге станут видимыми.
Преимущества:
- Значительное повышение производительности: в сценариях с высокой интенсивностью записи этот подход эффективно устраняет резкие колебания производительности запросов.
- Высокая гибкость: пользователи могут гибко выбирать баланс между актуальностью данных и производительностью запросов в соответствии с требованиями бизнеса.
Сравнение вариантов и рекомендации по выбору
| Вариант | Сценарий применения | Влияние Compaction | Влияние Schema Change | Влияние новых записанных данных |
|---|---|---|---|---|
| Активный инкрементальный прогрев + отложенная фиксация (+ необязательная настройка допустимого отставания данных) | Особо строгие требования к задержке запросов; есть права на настройку связей прогрева | Отсутствует | Отсутствует | Зависит от настройки допустимого отставания данных |
| Автоматический прогрев в вычислительной группе только для чтения + предпочтение кэшированных данных (+ необязательная настройка допустимого отставания данных) | Нет прав на настройку связей прогрева; неэффективен для таблиц MoW с первичным ключом, если допустимое отставание данных не настроено | Отсутствует | Cache Miss | Зависит от настройки допустимого отставания данных |
Оба варианта можно сочетать с межгрупповым чтением из кэша в качестве резервного механизма, который сокращает число обращений к объектному хранилищу при чтении холодных данных, не охваченных прогревом. Описанные выше стратегии прогрева кэша и соответствующие настройки позволяют эффективно управлять поведением кэша в Apache Doris при разделении чтения и записи, минимизировать потери производительности из-за промахов кэша и обеспечить стабильную и эффективную обработку запросов только для чтения.
Часто задаваемые вопросы
Вопрос: можно ли одновременно включить активный инкрементальный прогрев и автоматический прогрев в вычислительной группе только для чтения?
Да. Эти механизмы не исключают друг друга. Включение обоих расширяет охват прогрева. Рекомендуется использовать активный инкрементальный прогрев как основной механизм, а автоматический — как дополнительный.
Вопрос: когда результаты Compaction становятся видимыми после включения отложенной фиксации?
Результаты Compaction фиксируются и становятся видимыми для всех вычислительных групп только после того, как все связанные вычислительные группы только для чтения завершат прогрев. При превышении времени ожидания прогрева система принудительно выполняет фиксацию, чтобы не блокировать выполнение Compaction.
Вопрос: какое значение следует задать для query_freshness_tolerance_ms?
Выберите значение исходя из допустимой для бизнеса задержки данных. Диапазон от 500 до 2000 мс обычно обеспечивает баланс между производительностью и актуальностью данных. Если бизнес предъявляет особо строгие требования к работе в реальном времени, включать эту настройку не рекомендуется.
Вопрос: почему нельзя пропускать Rowsets, созданные в результате Compaction, для таблиц MoW с первичным ключом?
Семантика удаления в таблицах MoW (Merge-on-Write) зависит от версии данных, полученной после Compaction. Пропуск этих Rowsets может привести к некорректным результатам запросов, поэтому система всегда читает последнюю версию Rowset.
Вопрос: производительность запросов в вычислительной группе только для чтения внезапно снизилась. Как быстро определить причину?
- Проверьте показатели доли попаданий в File Cache в системе мониторинга BE, чтобы определить, не возникло ли большое количество Cache Miss.
- Уточните, выполнялись ли в последнее время операции Compaction, Schema Change или приёма данных большими пакетами.
- Убедитесь, что механизм прогрева настроен правильно (
enable_warmup_immediately_on_new_rowsetили активный инкрементальный прогрев). - Проверьте состояние выполнения задач прогрева, чтобы убедиться, что прогрев завершается в штатном режиме.