Перейти к содержимому
Последнее обновление

Руководство по настройке прогрева File Cache при разделении чтения и записи и использовании основного и резервного кластеров

Предпосылки и сценарии применения​

В архитектуре Apache Doris с разделением вычислений и хранения несколько вычислительных групп могут совместно использовать одни и те же данные в удалённом хранилище. Вычислительная группа записи выполняет загрузку данных, Compaction или Schema Change, а вычислительные группы запросов обслуживают оперативные запросы. Если после создания нового Rowset соответствующие файлы ещё не загружены в локальный File Cache вычислительной группы запросов, первый запрос должен обратиться к объектному хранилищу или HDFS, что может вызвать колебания задержки запросов.

Активный инкрементальный прогрев File Cache предварительно загружает соответствующие файлы Segment и индексов в локальный кеш целевой вычислительной группы после появления новых данных на стороне записи. Он предназначен прежде всего для следующих сценариев:

СценарийОписаниеПреимущество
Разделение чтения и записиВычислительная группа записи непрерывно загружает данные, а вычислительная группа запросов только обслуживает запросыУменьшает число Cache Miss при чтении новых данных вычислительной группой запросов
Высокая доступность с основным и резервным кластерамиРезервная вычислительная группа непрерывно синхронизирует активно используемые данные с основной вычислительной группойСокращает время восстановления прогретого кеша после переключения при сбое
Многопользовательское или многоуровневое хранилище данныхРазные вычислительные группы запросов обращаются только к части бизнес-таблицФильтрация на уровне таблиц сокращает ненужный прогрев и использование кеша
Оптимизация затратВ исходной вычислительной группе много таблиц, но частые запросы обращаются лишь к небольшой их частиСокращает чтение из удалённого хранилища и передачу данных по сети
Информация о версиях

В этом документе описаны активный инкрементальный прогрев File Cache и возможность фильтрации на уровне таблиц с помощью ON TABLES. Точные сведения о поддержке в конкретной версии см. в примечаниях к выпуску и документации по синтаксису SQL соответствующей версии.

Обзор возможностей​

Активный прогрев File Cache поддерживает три режима синхронизации:

Режим синхронизацииЗначение свойстваСценарий применения
Однократная синхронизацияonceРучной запуск начального прогрева при вводе новой вычислительной группы в эксплуатацию
Периодическая синхронизацияperiodicСинхронизация активно используемых данных через заданный интервал для постоянного поддержания кеша в прогретом состоянии
Синхронизация по событиямevent_drivenАвтоматический прогрев данных, создаваемых при Load, Compaction и Schema Change

Синхронизация по событиям может применяться на двух уровнях:

УровеньФорма синтаксисаОписание
Прогрев по событиям на уровне вычислительной группыБез ON TABLESНовые данные, созданные соответствующими событиями в исходной вычислительной группе, запускают прогрев
Прогрев по событиям на уровне таблицС ON TABLES (...)Прогрев запускают только новые данные из таблиц, соответствующих правилам

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

Создание заданий прогрева​

Однократная синхронизация​

Однократная синхронизация подходит для начального прогрева при вводе новой вычислительной группы в эксплуатацию:

WARM UP COMPUTE GROUP <target_compute_group> WITH COMPUTE GROUP <source_compute_group>;

Периодическая синхронизация​

Периодическая синхронизация подходит для непрерывного поддержания синхронизации активно используемых данных:

WARM UP COMPUTE GROUP <target_compute_group> WITH COMPUTE GROUP <source_compute_group>
PROPERTIES (
    "sync_mode" = "periodic",
    "sync_interval_sec" = "600"
);

sync_interval_sec задаёт интервал синхронизации в секундах. Значение по умолчанию: 600.

Прогрев по событиям на уровне вычислительной группы​

Прогрев по событиям на уровне вычислительной группы подходит для сценариев с разделением чтения и записи. Он отслеживает события записи в исходной вычислительной группе и предварительно загружает данные, создаваемые при Load, Compaction и Schema Change, в целевую вычислительную группу:

WARM UP COMPUTE GROUP <target_compute_group> WITH COMPUTE GROUP <source_compute_group>
PROPERTIES (
    "sync_mode" = "event_driven",
    "sync_event" = "load"
);
  • sync_event: при создании задания прогрева по событиям задайте этому параметру значение load.

Прогрев по событиям на уровне таблиц​

Прогрев по событиям на уровне таблиц добавляет к прогреву по событиям на уровне вычислительной группы предложение ON TABLES, определяющее набор таблиц для прогрева:

WARM UP COMPUTE GROUP <target_compute_group> WITH COMPUTE GROUP <source_compute_group>
ON TABLES (
    INCLUDE '<database_pattern>.<table_pattern>'
    [, INCLUDE '<database_pattern>.<table_pattern>' ...]
    [, EXCLUDE '<database_pattern>.<table_pattern>' ...]
)
PROPERTIES (
    "sync_mode" = "event_driven",
    "sync_event" = "load"
);

Описание параметров:

ПараметрОбязательныйОписание
<target_compute_group>ДаИмя целевой вычислительной группы. Новые данные из соответствующих правилам таблиц предварительно загружаются в локальный File Cache этой вычислительной группы
<source_compute_group>ДаИмя исходной вычислительной группы. Doris отслеживает события записи в этой вычислительной группе
ON TABLESНетПравила фильтрации на уровне таблиц. Если не указаны, задание выполняет прогрев по событиям на уровне вычислительной группы
INCLUDEОбязателен при использовании ON TABLESЗадаёт шаблоны таблиц, включаемых в область прогрева. Требуется хотя бы одно правило INCLUDE
EXCLUDEНетИсключает таблицы по шаблонам из результата INCLUDE
sync_modeДаДля прогрева по событиям на уровне таблиц используется event_driven
sync_eventДаДля прогрева по событиям на уровне таблиц в настоящее время используется событие load
Примечание

Не настраивайте одновременно прогрев по событию load на уровне вычислительной группы и прогрев по событиям на уровне таблиц с ON TABLES для одной и той же пары исходной и целевой вычислительных групп. Их семантика пересекается, поэтому Doris отклоняет конфликтующие конфигурации при создании задания. Чтобы перейти от прогрева на уровне вычислительной группы к прогреву на уровне таблиц, сначала отмените старое задание, а затем создайте новое задание с ON TABLES.

Правила сопоставления ON TABLES​

Формат шаблона​

Шаблоны в ON TABLES должны иметь формат 'database.table' и заключаться в одинарные кавычки. Поддерживаются следующие подстановочные знаки:

Подстановочный знакЗначениеПример
*Соответствует любому количеству произвольных символов, включая отсутствие символов'ods.*' соответствует всем таблицам в базе данных ods
?Соответствует ровно одному произвольному символу'logs.access_202?' соответствует таблицам от logs.access_2020 до logs.access_2029

Без подстановочных знаков шаблон задаёт точное совпадение. Например, 'sales.orders' соответствует только таблице orders в базе данных sales.

Примеры распространённых шаблонов:

ШаблонЗначение
'mydb.*'Соответствует всем таблицам в базе данных mydb
'*.orders'Соответствует таблицам с именем orders во всех базах данных
'dw.fact_*'Соответствует таблицам, имена которых начинаются с fact_, в базе данных dw
'*.*_bak'Соответствует таблицам, имена которых заканчиваются на _bak, во всех базах данных
'sales.orders'Точно соответствует sales.orders

INCLUDE и EXCLUDE​

Doris вычисляет итоговую область прогрева следующим образом:

Final warm-up scope = tables matched by all INCLUDE rules - tables matched by all EXCLUDE rules

Правила:

  • Порядок правил INCLUDE и EXCLUDE не влияет на итоговый результат.
  • Требуется хотя бы одно правило INCLUDE. Нельзя указать только EXCLUDE.
  • Результаты нескольких правил INCLUDE объединяются.
  • Несколько правил EXCLUDE удаляют соответствующие им таблицы из набора кандидатов.
  • Сопоставление выполняется согласно правилам именования баз данных и таблиц Doris. Используйте тот же регистр букв, что и в фактических именах баз данных и таблиц.

Пример:

WARM UP COMPUTE GROUP analytics_cg WITH COMPUTE GROUP write_cg
ON TABLES (
    INCLUDE 'ods.*',
    INCLUDE 'dw.fact_*',
    INCLUDE 'dw.dim_*',
    EXCLUDE 'ods.tmp_*',
    EXCLUDE '*.*_bak'
)
PROPERTIES (
    "sync_mode" = "event_driven",
    "sync_event" = "load"
);

В этом примере прогрев охватывает:

  • Таблицы в базе данных ods, кроме тех, имена которых начинаются с tmp_.
  • Таблицы в базе данных dw, имена которых начинаются с fact_ или dim_.
  • Резервные таблицы, имена которых заканчиваются на _bak, исключены во всех базах данных.

Материализованные представления​

Правила ON TABLES сопоставляются как с обычными таблицами, так и с асинхронными материализованными представлениями. Асинхронное материализованное представление существует как независимая таблица в пространстве имён базы данных и сопоставляется по имени с помощью правил INCLUDE и EXCLUDE.

Синхронное материализованное представление (Rollup) является внутренним индексом базовой таблицы, а не независимой таблицей. При прогреве базовой таблицы данные, связанные с её синхронными материализованными представлениями, обрабатываются вместе с ней и не требуют отдельного правила.

Примеры​

Прогрев определённых таблиц​

WARM UP COMPUTE GROUP report_cg WITH COMPUTE GROUP business_cg
ON TABLES (
    INCLUDE 'sales.orders',
    INCLUDE 'sales.customers',
    INCLUDE 'inventory.stock_level'
)
PROPERTIES (
    "sync_mode" = "event_driven",
    "sync_event" = "load"
);

Прогрев всей базы данных​

WARM UP COMPUTE GROUP analytics_cg WITH COMPUTE GROUP load_cg
ON TABLES (
    INCLUDE 'analytics_db.*'
)
PROPERTIES (
    "sync_mode" = "event_driven",
    "sync_event" = "load"
);

Прогрев нескольких баз данных с исключением временных таблиц​

WARM UP COMPUTE GROUP query_cg WITH COMPUTE GROUP etl_cg
ON TABLES (
    INCLUDE 'ods.*',
    INCLUDE 'dwd.*',
    INCLUDE 'dws.*',
    EXCLUDE '*.tmp_*',
    EXCLUDE '*.*_backup'
)
PROPERTIES (
    "sync_mode" = "event_driven",
    "sync_event" = "load"
);

Прогрев одной таблицы в нескольких целевых вычислительных группах​

Если одна и та же таблица должна обслуживать несколько вычислительных групп запросов, создайте отдельное задание для каждой целевой вычислительной группы:

WARM UP COMPUTE GROUP realtime_cg WITH COMPUTE GROUP write_cg
ON TABLES (INCLUDE 'sales.orders')
PROPERTIES ("sync_mode" = "event_driven", "sync_event" = "load");

WARM UP COMPUTE GROUP batch_cg WITH COMPUTE GROUP write_cg
ON TABLES (INCLUDE 'sales.orders')
PROPERTIES ("sync_mode" = "event_driven", "sync_event" = "load");

Управление заданиями прогрева​

Просмотр заданий​

Просмотр всех заданий прогрева:

SHOW WARM UP JOB;

Просмотр определённого задания:

SHOW WARM UP JOB WHERE id = <job_id>;

Описание полей:

ПолеОписание
JobIdУникальный ID задания прогрева
SrcComputeGroupИмя исходной вычислительной группы
DstComputeGroupИмя целевой вычислительной группы
StatusСостояние задания, например PENDING, RUNNING, FINISHED или CANCELLED
TypeОбласть прогрева. CLUSTER означает уровень вычислительной группы, TABLE означает явно указанные таблицы, а TABLES означает таблицы, соответствующие правилам ON TABLES
SyncModeРежим синхронизации, например ONCE, PERIODIC(interval_sec) или EVENT_DRIVEN(event)
CreateTimeВремя создания задания
StartTimeВремя последнего запуска
FinishBatchКоличество завершённых пакетов
AllBatchОбщее количество пакетов
FinishTimeВремя последнего завершения. Задания по событиям обычно продолжают работать
ErrMsgПоследнее сообщение об ошибке. Пустое, если ошибок нет
TablesЯвно заданный список таблиц, используемый преимущественно для однократного или периодического прогрева на уровне таблиц
TableFilterКаноническое представление правил ON TABLES. Пустое для заданий на уровне вычислительной группы
MatchedTablesТекущий список имён таблиц, соответствующих правилам. Периодическое обновление отражает создание, удаление и переименование таблиц
SyncStatsХод синхронизации заданий по событиям. Запрос списка показывает сводку; запрос по ID показывает подробный JSON

SHOW WARM UP JOB подходит для ежедневной проверки. Чтобы список не был слишком широким, SyncStats показывает сводку за последние 30 минут:

{
  "window": "30m",
  "src_size": "58.2mb",
  "dst_size": "57.5mb",
  "gap_size": "716kb",
  "trigger_gap_ms": 1200
}

При запросе по ID задания SyncStats показывает подробные метрики за окна длительностью 5 минут, 30 минут и 1 час:

SHOW WARM UP JOB WHERE id = <job_id>;

Пример SyncStats:

{
  "seg_num": {
    "requested_5m": 42,
    "finish_5m": 40,
    "gap_5m": 2,
    "fail_5m": 0,
    "requested_30m": 180,
    "finish_30m": 178,
    "gap_30m": 2,
    "fail_30m": 0,
    "requested_1h": 320,
    "finish_1h": 318,
    "gap_1h": 2,
    "fail_1h": 0
  },
  "seg_size": {
    "requested_5m": "12.5mb",
    "finish_5m": "11.8mb",
    "gap_5m": "716kb",
    "fail_5m": "0b",
    "requested_30m": "58.2mb",
    "finish_30m": "57.5mb",
    "gap_30m": "716kb",
    "fail_30m": "0b",
    "requested_1h": "102.3mb",
    "finish_1h": "101.6mb",
    "gap_1h": "716kb",
    "fail_1h": "0b"
  },
  "idx_num": {
    "requested_5m": 10,
    "finish_5m": 10,
    "gap_5m": 0,
    "fail_5m": 0
  },
  "idx_size": {
    "requested_5m": "2.1mb",
    "finish_5m": "2.1mb",
    "gap_5m": "0b",
    "fail_5m": "0b"
  },
  "last_trigger_ts": "2026-08-11 14:32:15",
  "last_finish_ts": "2026-08-11 14:32:18",
  "progress_trigger_ts": "2026-08-11 14:32:14",
  "trigger_gap_ms": 1000
}

Обратите внимание на следующие поля:

ПолеОписание
requested_*Объём запросов прогрева, отправленных исходной вычислительной группой
finish_*Объём прогрева, выполненного целевой вычислительной группой
gap_*Разница, указывающая на ещё не выполненный объём
fail_*Объём прогрева, завершившегося ошибкой в целевой вычислительной группе
last_trigger_tsВремя последнего запуска прогрева
progress_trigger_tsВремя запуска на исходной стороне, соответствующее текущему прогрессу в целевой вычислительной группе
last_finish_tsВремя последнего завершения прогрева
trigger_gap_msРазница между временем последнего запуска на исходной стороне и временной отметкой прогресса на целевой стороне, в миллисекундах
Примечание к версии (4.0.8)

Начиная с версии 4.0.8, формат трёх полей временных отметок last_trigger_ts, last_finish_ts и progress_trigger_ts изменён с HH:mm:ss на yyyy-MM-dd HH:mm:ss, поэтому теперь они содержат дату. Ранее отображалось только время суток, из-за чего при переходе через границу суток дата была неоднозначной.

Перед обновлением до 4.0.8 скорректируйте все скрипты, которые разбирают эти поля с использованием фиксированного формата.

Отмена задания​

CANCEL WARM UP JOB WHERE id = <job_id>;

После отмены Doris прекращает отслеживать события и запускать прогрев для этого задания. Данные, уже записанные в File Cache целевой вычислительной группы, не удаляются принудительно и освобождаются согласно обычной политике вытеснения из кеша.

В текущей версии нельзя напрямую изменять правила ON TABLES существующего задания. Чтобы скорректировать область прогрева, сначала отмените старое задание, а затем создайте новое.

Обновление сопоставлений и особенности поведения​

Создание, удаление и переименование таблиц​

Правила ON TABLES проверяются при создании задания и периодически проверяются повторно во время его работы. Интервал обновления по умолчанию составляет 60 секунд.

Это означает следующее:

  • Если после создания задания появляется новая таблица, имя которой соответствует правилам, она автоматически включается в область прогрева в одном из последующих циклов обновления.
  • После удаления таблицы, соответствующей правилам, она удаляется из MatchedTables в одном из последующих циклов обновления.
  • После переименования таблицы, соответствующей правилам, продолжение её прогрева зависит от того, соответствует ли новое имя правилам.

Между созданием новой таблицы и следующим обновлением правил возможна задержка до 60 секунд. Запись в новую таблицу в течение этой задержки не запускает данное задание на уровне таблиц. Запись после обновления запускает прогрев в обычном порядке.

Отсутствие подходящих таблиц при создании задания​

При создании задания прогрева по событиям на уровне таблиц правила ON TABLES должны соответствовать хотя бы одной существующей таблице. Если подходящих таблиц нет, создание задания завершается ошибкой. Проверьте имя базы данных, имя таблицы и шаблоны с подстановочными знаками.

Если вы хотите заранее настроить связь для прогрева, перед созданием задания прогрева создайте хотя бы одну таблицу, соответствующую правилам.

Schema Change​

ON TABLES определяет только набор таблиц и не меняет семантику запуска для самого типа события. Для типов событий, настроенных в текущем задании и поддерживаемых текущей версией, вновь созданные данные обрабатываются согласно результату сопоставления таблиц. Если в задании настроено sync_event = "load", оно отслеживает только соответствующее событие загрузки.

Принцип работы​

Порядок выполнения периодической синхронизации​

  1. FE регистрирует задание и сохраняет интервал синхронизации.
  2. FE периодически проверяет, наступило ли время запуска.
  3. Когда наступает время запуска, FE преобразует целевые таблицы или разделы в соответствующие Tablets и отправляет задачи на выполнение.
  4. BE читает файлы из удалённого хранилища и записывает их в File Cache целевой вычислительной группы.

Порядок выполнения синхронизации по событиям​

  1. Пользователь создаёт задание по событиям, и FE сохраняет связь синхронизации.
  2. FE передаёт конфигурацию синхронизации по событиям в BE исходной вычислительной группы.
  3. BE исходной вычислительной группы запускает прогрев после фиксации события записи.
  4. Для заданий по событиям на уровне таблиц исходный BE обрабатывает только Rowsets, принадлежащие текущему набору таблиц, соответствующих правилам.
  5. BE целевой вычислительной группы скачивает соответствующие файлы Segment и индексов и записывает их в локальный File Cache.
  6. FE предоставляет состояние задания и ход синхронизации через SHOW WARM UP JOB и метрики FE.

Мониторинг метрик​

Наблюдение с помощью SQL​

Самый прямой способ наблюдать за ходом прогрева — использовать SHOW WARM UP JOB:

SHOW WARM UP JOB;
SHOW WARM UP JOB WHERE id = <job_id>;

Рекомендации по использованию:

  • Если gap_size или подробные показатели gap_* устойчиво приближаются к 0, целевая вычислительная группа в целом успевает за скоростью записи исходной вычислительной группы.
  • Если trigger_gap_ms приближается к 0, целевая вычислительная группа обработала данные вплоть до последнего события запуска из исходной вычислительной группы.
  • Если fail_* больше 0, проверьте логи BE на наличие проблем с дисковым пространством, сбоев доступа к удалённому хранилищу или сетевых ошибок.
  • Окно длительностью 5 минут полезно для отслеживания текущих колебаний, а окна длительностью 30 минут и 1 час — для наблюдения за устойчивыми тенденциями.

Метрики BE Bvar​

Помимо SHOW WARM UP JOB и FE /metrics, для проверки метрик выполнения прогрева на отдельном BE можно использовать страницу BE Bvar:

curl http://<be_host>:<brpc_port>/vars

Метрики на стороне BE для периодических заданий:

Имя метрикиЗначение
file_cache_once_or_periodic_warm_up_submitted_segment_sizeРазмер данных сегментов, переданных на обработку
file_cache_once_or_periodic_warm_up_finished_segment_sizeРазмер обработанных данных сегментов
file_cache_once_or_periodic_warm_up_submitted_index_numКоличество индексов, переданных на обработку
file_cache_once_or_periodic_warm_up_finished_index_numКоличество обработанных индексов

Метрики исходного BE для заданий по событиям:

Имя метрикиЗначение
file_cache_event_driven_warm_up_requested_segment_sizeРазмер данных сегментов, запрошенных для синхронизации
file_cache_event_driven_warm_up_requested_index_numКоличество индексов, запрошенных для синхронизации
file_cache_warm_up_rowset_last_call_unix_tsВременная отметка последнего отправленного запроса синхронизации

Метрики целевого BE для заданий по событиям:

Имя метрикиЗначение
file_cache_event_driven_warm_up_submitted_segment_numКоличество полученных сегментов
file_cache_event_driven_warm_up_finished_segment_numКоличество сегментов, для которых завершён прогрев
file_cache_warm_up_rowset_last_handle_unix_tsВременная отметка последнего обработанного запроса синхронизации

Эти метрики отражают выполнение на отдельном BE и помогают проверить, получил ли BE запросы прогрева, завершил ли скачивание и отправлял или обрабатывал ли запросы в последнее время. Для агрегирования на уровне задания по нескольким BE предпочтительно использовать SHOW WARM UP JOB WHERE id = <job_id> или метрики FE Prometheus.

Метрики FE Prometheus​

В облачном режиме FE периодически получает от BE данные о ходе прогрева по событиям и агрегирует их. Интервал обновления по умолчанию составляет 15 секунд. Он управляется параметром конфигурации FE cloud_warm_up_sync_stats_refresh_interval_ms, значение которого по умолчанию составляет 15000 миллисекунд.

Через FE /metrics можно собирать следующие метрики:

Имя метрикиОписание
doris_fe_file_cache_warm_up_sync_job_infoМетаданные задания. Значение всегда равно 1. Метки включают job_id, job_type, sync_mode, sync_event, job_state, а также исходную и целевую вычислительные группы
doris_fe_file_cache_warm_up_sync_job_size_bytesОбщий объём прогрева, отправленный исходной стороной и выполненный целевой стороной, в байтах. Содержит метки side и window
doris_fe_file_cache_warm_up_sync_job_trigger_gap_msРазница между временем последнего запуска на исходной стороне и временной отметкой прогресса на целевой стороне, в миллисекундах

Примеры распространённых запросов PromQL:

# Total warm-up size submitted by the source side in the last 5 minutes for each job
doris_fe_file_cache_warm_up_sync_job_size_bytes{side="src",window="5m"}

# Total warm-up size completed by the target side in the last 5 minutes for each job
doris_fe_file_cache_warm_up_sync_job_size_bytes{side="dst",window="5m"}

# Sync size gap in the last 5 minutes for each job
doris_fe_file_cache_warm_up_sync_job_size_bytes{side="src",window="5m"}
  - ignoring(side)
doris_fe_file_cache_warm_up_sync_job_size_bytes{side="dst",window="5m"}

# Trigger progress time gap for each job
doris_fe_file_cache_warm_up_sync_job_trigger_gap_ms

ignoring(side) указывает Prometheus игнорировать метку side при вычитании рядов объёма на исходной и целевой сторонах, чтобы ряды src и dst с одинаковыми заданием и окном можно было сопоставить.

Полная последовательность действий​

  1. Просмотрите текущие вычислительные группы и проверьте имена исходной и целевой вычислительных групп:

    SHOW COMPUTE GROUPS;

  2. Уточните набор таблиц, которым нужен прогрев:

    SHOW TABLES FROM ods;
    SHOW TABLES FROM dw;

  3. Создайте задание прогрева по событиям на уровне таблиц:

    WARM UP COMPUTE GROUP read_cg WITH COMPUTE GROUP write_cg
    ON TABLES (
        INCLUDE 'ods.*',
        INCLUDE 'dw.fact_*',
        EXCLUDE 'ods.tmp_*'
    )
    PROPERTIES (
        "sync_mode" = "event_driven",
        "sync_event" = "load"
    );

  4. Проверьте состояние задания и таблицы, соответствующие правилам:

    SHOW WARM UP JOB;

  5. После записи данных проверьте ход синхронизации:

    SHOW WARM UP JOB WHERE id = <job_id>;

  6. Чтобы скорректировать правила, отмените старое задание и создайте новое:

    CANCEL WARM UP JOB WHERE id = <job_id>;

Рекомендации​

  • Если вычислительная группа запросов обращается лишь к небольшому набору основных таблиц, предпочтительно использовать прогрев по событиям на уровне таблиц, чтобы избежать чрезмерного использования кеша при прогреве на уровне вычислительной группы.
  • В хранилищах данных с чёткими соглашениями об именовании таблиц проще поддерживать такие правила, как INCLUDE 'dws.*', INCLUDE 'ads.*' и EXCLUDE '*.tmp_*'.
  • Избегайте ситуаций, когда несколько заданий охватывают одни и те же активно используемые таблицы. Хотя целевая сторона по возможности избегает повторного скачивания, управление заданиями и интерпретация метрик усложняются.
  • Чтобы изменить область прогрева, отмените и заново создайте задание. Не рассчитывайте, что старое задание автоматически изменит свои правила.
  • Используйте SHOW WARM UP JOB для получения сведений об отдельном задании, а метрики FE Prometheus в Grafana — для мониторинга долгосрочных тенденций.

Часто задаваемые вопросы​

Вопрос: Отменяет ли сбой синхронизации в одном цикле всё задание?

Нет. Сбой синхронизации в текущем цикле приводит только к пропуску этого выполнения. Состояние задания не меняется, и в последующих циклах попытки повторяются. Выполните SHOW WARM UP JOB WHERE id = <job_id>, чтобы проверить ErrMsg и счётчики сбоев в SyncStats, а затем изучите логи BE для поиска причины.

Вопрос: Что происходит при превышении времени ожидания выполнения периодического задания?

После превышения времени ожидания система пропускает текущий цикл. Само задание не удаляется, и следующий цикл запускается в обычном порядке. Чтобы оценить последнее выполнение, проверьте StartTime, FinishTime, FinishBatch и AllBatch в SHOW WARM UP JOB.

Вопрос: Поддерживается ли синхронизация из нескольких исходных вычислительных групп в одну целевую?

Да. Например, вычислительные группы A и C могут обе синхронизироваться с вычислительной группой B (связи A -> B и C -> B могут существовать одновременно). Если несколько заданий охватывают одни и те же таблицы, управление заданиями и интерпретация метрик усложняются.

Вопрос: Когда следует использовать прогрев по событиям на уровне таблиц?

Используйте прогрев по событиям на уровне таблиц, если целевая вычислительная группа запрашивает только часть таблиц или если в исходной вычислительной группе много таблиц, но активно используется лишь небольшая их часть. Это сокращает ненужный прогрев и заполнение кеша редко используемыми данными.

Вопрос: Что происходит, если не использовать ON TABLES?

Без ON TABLES задание выполняет прогрев по событиям на уровне вычислительной группы. Новые данные, созданные соответствующими событиями в исходной вычислительной группе, запускают прогрев.

Вопрос: Важен ли порядок INCLUDE и EXCLUDE?

Нет. Doris сначала объединяет результаты всех правил INCLUDE, а затем удаляет все таблицы, соответствующие правилам EXCLUDE.

Вопрос: Если таблица, соответствующая правилам, создана после создания задания, будет ли она прогреваться автоматически?

Да. Doris периодически повторно проверяет правила. Если новая таблица соответствует правилам, она включается в область прогрева в одном из последующих циклов обновления. Интервал обновления по умолчанию составляет 60 секунд.

Вопрос: Продолжится ли прогрев таблицы после её переименования?

Это зависит от того, соответствует ли новое имя таблицы правилам ON TABLES. Если соответствует, прогрев продолжается. Если нет, прогрев прекращается в одном из последующих циклов обновления.

Вопрос: Можно ли прогревать только один раздел таблицы?

Прогрев по событиям на уровне таблиц выполняет фильтрацию с точностью до таблицы и не поддерживает указание разделов в ON TABLES. Новые данные из таблицы, соответствующей правилам, обрабатываются согласно правилам уровня таблиц.

Вопрос: Как проверить, что прогрев работает?

Это можно проверить следующим образом:

  1. Выполните SHOW WARM UP JOB WHERE id = <job_id> и проверьте, имеет ли Status значение RUNNING или FINISHED.
  2. Для прогрева по событиям на уровне таблиц проверьте, соответствует ли MatchedTables вашим ожиданиям.
  3. Сравните FinishBatch с AllBatch, чтобы проверить ход выполнения однократных или периодических заданий.
  4. Проверьте SyncStats и убедитесь, что gap_size или подробные показатели gap_* приближаются к 0, а trigger_gap_ms не растёт непрерывно.
  5. Наблюдайте за метриками BE Bvar целевой вычислительной группы и убедитесь, что счётчики завершения, такие как file_cache_event_driven_warm_up_finished_segment_num, продолжают увеличиваться.
  6. Выполните запросы к соответствующим таблицам в целевой вычислительной группе и с помощью доли попаданий в File Cache, метрик FE и логов BE проверьте, остаётся ли количество чтений из удалённого хранилища высоким.

Вопрос: Как изменить конфигурацию задания синхронизации, например интервал синхронизации или правила ON TABLES?

В текущей версии прямое изменение не поддерживается. Сначала выполните CANCEL WARM UP JOB WHERE id = <job_id>, чтобы отменить старое задание, а затем создайте новое.

Report issue
На этой странице