Очистка данных в архитектуре с разделением вычислений и хранения (Recycler): принципы, конфигурация и настройка

В архитектуре Doris с разделением вычислений и хранения для очистки данных используется стратегия пометки на удаление. Выделенный компонент Recycler периодически сканирует помеченные записи метаданных и пакетно удаляет соответствующие объектные файлы, обеспечивая оптимальный баланс между производительностью, безопасностью и использованием ресурсов.

Сравнение стратегий очистки данных

У каждой из трёх распространённых стратегий очистки данных есть свои преимущества и недостатки. В архитектуре Doris с разделением вычислений и хранения используется пометка на удаление:

Стратегия	Условие запуска	Преимущества	Недостатки
Синхронное удаление	Метаданные и файлы удаляются немедленно при выполнении команды удаления	Простота реализации	Медленный отклик, высокий риск, отсутствие буферного периода
Удаление по результатам сверки (обратное)	Периодически сканируются все файлы, выявляются файлы без ссылок и удаляются пакетами	Позволяет удалять файлы без ссылок	Требует обхода всех файлов; высокие затраты на I/O
Пометка на удаление (прямое)	При удалении помечаются только метаданные; фоновый процесс периодически сканирует пометки и удаляет файлы	Быстрый отклик, наличие буферного периода, высокая эффективность	Временная избыточность хранимых данных

Преимущества пометки на удаление

По сравнению с другими подходами пометка на удаление даёт следующие преимущества:

• Быстрый отклик: DROP TABLE лишь помечает KV метаданных как удалённую, не дожидаясь файловых операций I/O. Пользователь сразу получает ответ, а удаление больших таблиц не блокирует работу.
• Эффективная пакетная обработка: фоновый процесс периодически удаляет файлы пакетами, сокращая число системных вызовов и повышая общую эффективность I/O.
• Защита от ошибочных действий: перед фактическим удалением файлов предусмотрен буферный период. В течение этого периода можно восстановить случайно удалённые таблицы, что существенно снижает риск потери данных из-за человеческой ошибки.
• Транзакционная безопасность: пометка представляет собой небольшое изменение метаданных. Атомарность такой операции проще гарантировать, что снижает риск нарушения согласованности данных при системных сбоях.
• Балансировка нагрузки: файлы можно удалять в периоды низкой активности системы, избегая интенсивного потребления ресурсов I/O в часы пиковой рабочей нагрузки.

Как работает Recycler

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

Процесс пометки на удаление

При выполнении команды DROP или появлении ненужных данных в системе, например rowset, объединённых в ходе compaction, соответствующая KV метаданных помечается статусом recycled. Recycler периодически сканирует KV очистки в экземплярах и выполняет следующие действия:

1. Удаляет соответствующие объектные файлы (файлы сегментов и т. д.).
2. Удаляет KV очистки.

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

Иерархическая структура очистки

Очистка данных выполняется иерархически, сверху вниз. Рассмотрим пример с DROP TABLE:

Table
 └─ Partition (delete recycle partition KV)
     └─ Tablet (delete recycle tablet KV)
         └─ Rowset (delete recycle rowset KV)
             └─ Segment files (actual object files, the final deletion unit)

Во время очистки параллельно выполняются задачи нескольких типов, включая recycle_indexes, recycle_partition, recycle_compacted_rowsets, recycle_txn и другие. KV очистки на определённом уровне удаляется только после успешного удаления всех дочерних элементов этого уровня.

Защита за счёт срока хранения

Каждая KV объекта, ожидающего очистки, содержит сведения о сроке хранения. При сканировании Recycler проверяет этот срок и не удаляет объекты, срок хранения которых ещё не истёк.

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

Гарантии надёжности

Поэтапное удаление: сначала удаляются файлы данных, затем метаданные и, наконец, KV индексов или разделов. Это обеспечивает безопасный порядок удаления.

Механизм защиты с помощью lease: перед началом очистки каждый Recycler должен получить lease, который фоновый поток периодически продлевает. Другой Recycler может взять очистку на себя только после истечения lease или перехода в статус IDLE. Это гарантирует, что каждый экземпляр в любой момент времени очищает только один Recycler, и предотвращает нарушения согласованности данных из-за параллельной очистки.

Многоуровневый механизм проверки (Checker)

В Recycler реализован многоуровневый механизм взаимной проверки (checker) метаданных FE, KV в MS и объектных файлов. В фоновом режиме checker выполняет двунаправленные проверки всех KV Recycler, объектных файлов и метаданных в памяти FE.

Рассмотрим проверку KV файлов сегментов и объектных файлов:

Направление проверки	Содержание проверки
Прямая проверка	Сканирует все KV и проверяет, существуют ли соответствующие файлы сегментов и присутствуют ли сведения об этих сегментах в памяти FE
Обратная проверка	Сканирует все файлы сегментов и проверяет, есть ли для каждого из них соответствующая KV и присутствуют ли сведения об этих сегментах в памяти FE

Если какие-либо данные остались неудалёнными или были удалены ошибочно, checker фиксирует соответствующую информацию. На основе отчёта checker специалисты по эксплуатации могут вручную удалить оставшиеся ненужные файлы или восстановить случайно удалённые файлы с помощью версионирования объектов.

В настоящее время поддерживаются прямые и обратные проверки файлов сегментов, файлов idx и метаданных delete bitmap. В дальнейшем планируется охватить проверками все метаданные.

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

Все метрики мониторинга доступны в реальном времени на панели мониторинга MS.

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

Вопрос	Соответствующая метрика
Сколько байт удаляется в секунду и сколько объектов каждого типа удаляется в секунду	recycler_instance_recycle_bytes_per_ms, recycler_instance_recycle_time_per_resource
Какой объём данных удаляется за цикл очистки и сколько времени занимает цикл	recycler_instance_last_round_recycled_bytes, recycler_instance_last_round_recycle_elpased_ts
Сколько объектов удалено и сколько ожидает удаления	recycler_instance_last_round_recycled_num, recycler_instance_last_round_to_recycle_num
В каком состоянии находится очистка каждого бэкенда хранилища	recycler_vault_recycle_status
Когда произошла последняя успешная или неудачная очистка	recycler_instance_recycle_last_success_ts, recycler_instance_recycle_end_ts
Когда ожидается следующая очистка	recycler_instance_next_ts

Полный список метрик

Имя переменной	Имя метрики	Измерения / метки	Описание
g_bvar_recycler_vault_recycle_status	recycler_vault_recycle_status	instance_id, resource_id, status	Статистика состояний операций очистки vault по ID экземпляра, ID ресурса и состоянию
g_bvar_recycler_vault_recycle_task_concurrency	recycler_vault_recycle_task_concurrency	instance_id, resource_id	Число параллельно выполняемых задач очистки файлов vault по ID экземпляра и ID ресурса
g_bvar_recycler_instance_last_round_recycled_num	recycler_instance_last_round_recycled_num	instance_id, resource_type	Число объектов, удалённых за последний цикл
g_bvar_recycler_instance_last_round_to_recycle_num	recycler_instance_last_round_to_recycle_num	instance_id, resource_type	Число объектов, подлежащих удалению в последнем цикле
g_bvar_recycler_instance_last_round_recycled_bytes	recycler_instance_last_round_recycled_bytes	instance_id, resource_type	Объём данных, удалённых за последний цикл (в байтах)
g_bvar_recycler_instance_last_round_to_recycle_bytes	recycler_instance_last_round_to_recycle_bytes	instance_id, resource_type	Объём данных, подлежащих удалению в последнем цикле (в байтах)
g_bvar_recycler_instance_last_round_recycle_elpased_ts	recycler_instance_last_round_recycle_elpased_ts	instance_id, resource_type	Время, затраченное на последнюю операцию очистки (мс)
g_bvar_recycler_instance_recycle_round	recycler_instance_recycle_round	instance_id, resource_type	Номер цикла очистки
g_bvar_recycler_instance_recycle_time_per_resource	recycler_instance_recycle_time_per_resource	instance_id, resource_type	Время, необходимое для очистки каждого ресурса (мс); -1 означает, что очистка не выполнялась
g_bvar_recycler_instance_recycle_bytes_per_ms	recycler_instance_recycle_bytes_per_ms	instance_id, resource_type	Число байт, удаляемых за миллисекунду; -1 означает, что очистка не выполнялась
g_bvar_recycler_instance_recycle_total_num_since_started	recycler_instance_recycle_total_num_since_started	instance_id, resource_type	Общее число объектов, удалённых с момента запуска Recycler
g_bvar_recycler_instance_recycle_total_bytes_since_started	recycler_instance_recycle_total_bytes_since_started	instance_id, resource_type	Общий объём данных, удалённых с момента запуска Recycler (в байтах)
g_bvar_recycler_instance_running_counter	recycler_instance_running_counter	—	Текущее число экземпляров, для которых выполняется очистка
g_bvar_recycler_instance_last_round_recycle_duration	recycler_instance_last_round_recycle_duration	instance_id	Общая продолжительность последнего цикла очистки
g_bvar_recycler_instance_next_ts	recycler_instance_next_ts	instance_id	Ожидаемое время следующей очистки, рассчитанное на основе recycle_interval_seconds
g_bvar_recycler_instance_recycle_st_ts	recycler_instance_recycle_start_ts	instance_id	Время начала всего процесса очистки
g_bvar_recycler_instance_recycle_ed_ts	recycler_instance_recycle_end_ts	instance_id	Время завершения всего процесса очистки
g_bvar_recycler_instance_recycle_last_success_ts	recycler_instance_recycle_last_success_ts	instance_id	Время последней успешной очистки

Параметры конфигурации

Ниже приведены часто используемые параметры конфигурации Recycler:

Параметр	Значение по умолчанию	Описание
recycle_interval_seconds	3600	Интервал между циклами очистки (секунды)
retention_seconds	259200 (3 дня)	Общий срок хранения для всех объектов, которым не задан индивидуальный срок хранения
recycle_concurrency	16	Максимальное число экземпляров, которые один Recycler может очищать одновременно
compacted_rowset_retention_seconds	1800	Срок хранения rowset, объединённых в ходе compaction (секунды)
dropped_index_retention_seconds	10800	Срок хранения удалённых индексов (секунды)
dropped_partition_retention_seconds	10800	Срок хранения удалённых разделов (секунды)
recycle_whitelist	""	Белый список очистки; укажите ID экземпляров через запятую; если список пуст, очищаются все экземпляры
recycle_blacklist	""	Чёрный список очистки; укажите ID экземпляров через запятую; если список пуст, очищаются все экземпляры
instance_recycler_worker_pool_size	32	Число параллельных операций I/O с объектами (list, delete и т. д.)
recycle_pool_parallelism	40	Число параллельных задач очистки (recycle_tablet, recycle_rowset и т. д.)
enable_checker	false	Включает прямую проверку
enable_inverted_check	false	Включает обратную проверку
check_object_interval_seconds	43200 (12 часов)	Интервал запуска checker (секунды)
enable_recycler_stats_metrics	false	Включает метрики наблюдаемости Recycler
recycler_storage_vault_white_list	""	Белый список бэкендов хранилища; укажите имена vault через запятую; если список пуст, очищаются все vault
enable_mark_delete_rowset_before_recycle	false	Определяет, нужно ли помечать метаданные rowset как подлежащие очистке до фактического удаления данных, чтобы удалить данные и KV при следующем сканировании. Поддерживает динамическое изменение. Начиная с версии 4.0.8 значение по умолчанию изменено с true на false
enable_abort_txn_and_job_for_delete_rowset_before_recycle	false	Определяет, нужно ли прерывать транзакции и задания, связанные с rowset, перед его удалением. Поддерживает динамическое изменение. Начиная с версии 4.0.8 значение по умолчанию изменено с true на false

Изменение поведения (4.0.8)

В версии 4.0.8 значения по умолчанию для enable_mark_delete_rowset_before_recycle и enable_abort_txn_and_job_for_delete_rowset_before_recycle изменены с true на false.

Оба параметра включают дополнительные защитные действия перед удалением rowset. Однако текущая реализация создаёт заметные накладные расходы и замедляет очистку, поэтому по умолчанию эти действия больше не выполняются. Чтобы сохранить защиту, явно установите для обоих параметров значение true.

Распространённые сценарии настройки

Очистка выполняется слишком медленно

Цель: ускорить удаление ненужных данных и освободить место в хранилище.

Рекомендации по настройке:

1. Увеличьте параллелизм:
   • recycle_concurrency (по умолчанию 16): увеличьте число одновременно очищаемых экземпляров.
   • instance_recycler_worker_pool_size (по умолчанию 32): увеличьте число параллельных операций I/O с объектами.
   • recycle_pool_parallelism (по умолчанию 40): увеличьте число параллельных задач очистки.
2. Сократите интервал между циклами очистки: уменьшите recycle_interval_seconds со значения по умолчанию 3600 секунд, например до 1800 секунд.
3. Используйте белый список: задайте recycle_whitelist, чтобы в первую очередь очищать важные экземпляры.

Нагрузка от очистки мешает рабочим процессам

Цель: снизить влияние Recycler на рабочие процессы.

Рекомендации по настройке:

1. Уменьшите параллелизм: соответственно снизьте значения recycle_concurrency, instance_recycler_worker_pool_size и recycle_pool_parallelism.
2. Увеличьте интервал между циклами очистки: повысьте recycle_interval_seconds, например до 7200 секунд.
3. Используйте чёрный список: задайте recycle_blacklist, чтобы временно исключить экземпляры с высокой нагрузкой.

Недостаточно места в хранилище, и очистку нужно ускорить

Цель: как можно быстрее освободить место в хранилище.

Рекомендации по настройке:

1. Сократите общий срок хранения: уменьшите retention_seconds со значения по умолчанию 259200 секунд (3 дня).
2. Сократите срок хранения для отдельных типов объектов:
   • compacted_rowset_retention_seconds (по умолчанию 1800 секунд) можно уменьшить до подходящего значения.
   • dropped_index_retention_seconds и dropped_partition_retention_seconds (по умолчанию 10800 секунд) можно скорректировать по необходимости.
3. Выбирайте бэкенды хранилища для очистки: используйте recycler_storage_vault_white_list, чтобы в первую очередь очищать определённые vault.

Нужно увеличить срок хранения для защиты от случайного удаления

Цель: продлить буферный период для восстановления после ошибочных действий.

Рекомендации по настройке:

1. Увеличьте retention_seconds, например до 604800 секунд (7 дней).
2. Настройте такие параметры, как dropped_partition_retention_seconds, отдельно для каждого типа объектов с учётом его важности.

Включение мониторинга и проверок согласованности

Цель: улучшить наблюдаемость и выявить возможные проблемы с согласованностью данных.

Рекомендации по настройке:

1. Включите метрики наблюдаемости: установите enable_recycler_stats_metrics = true.
2. Включите механизмы проверки:
   • enable_checker = true (прямая проверка)
   • enable_inverted_check = true (обратная проверка)
3. Настройте check_object_interval_seconds (по умолчанию 43200 секунд), чтобы проверки выполнялись с подходящей частотой.

Очистка отдельных экземпляров работает некорректно

Цель: временно изолировать проблемные экземпляры, чтобы они не мешали очистке остальных.

Рекомендации по настройке:

1. Добавьте ID проблемного экземпляра в recycle_blacklist, чтобы временно пропускать его.
2. Добавьте ID экземпляров, требующих приоритетной обработки, в recycle_whitelist.
3. Используйте recycler_storage_vault_white_list для выборочной очистки определённых бэкендов хранилища.

Удаление большой таблицы приводит к накоплению задач очистки

Цель: быстро обработать накопившуюся очередь задач очистки.

Рекомендации по настройке:

1. Временно увеличьте параметры параллелизма (recycle_concurrency, recycle_pool_parallelism), чтобы обработать очередь.
2. Используйте белый список, чтобы в первую очередь обрабатывать экземпляры с большой очередью задач.
3. При необходимости разверните несколько экземпляров Recycler, чтобы распределить нагрузку.

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

Длительные запросы завершаются с ошибкой «404 File Not Found»

Симптом: запрос выполняется долго. За это время tablet проходит compaction, а объединённые rowset удаляются Recycler. При обращении к этим rowset запрос выдаёт ошибку 404 file not found.

Причина: значение compacted_rowset_retention_seconds по умолчанию составляет 1800 секунд (30 минут). Если запрос выполняется дольше, необходимые ему файлы rowset могут быть уже удалены.

Решение: увеличьте compacted_rowset_retention_seconds с учётом времени выполнения самых длительных запросов в кластере. Для сценариев с длительными запросами рекомендуется установить значение 7200 секунд или больше.

Как убедиться, что очистка данных работает нормально

Порядок действий:

1. Включите enable_recycler_stats_metrics = true и проверьте метрики recycler_instance_last_round_recycle_duration и recycler_instance_recycle_last_success_ts на панели мониторинга MS.
2. Если recycler_instance_recycle_last_success_ts долго не обновляется, возможно, очистка зависла. Изучите журналы.

Как исследовать возможные проблемы с согласованностью данных

Порядок действий:

1. Убедитесь, что установлены enable_checker = true и enable_inverted_check = true.
2. При необходимости уменьшите check_object_interval_seconds, чтобы повысить частоту проверок.
3. Отслеживайте аномалии, обнаруженные checker, на панели мониторинга MS.
4. Вручную обработайте оставшиеся ненужные файлы на основе отчёта checker или восстановите случайно удалённые файлы с помощью версионирования объектов.

---

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