--- metadata: - name: generator content: Diplodoc Platform v5.50.6 alternate: - https://ytsaurus.tech/docs/en/user-guide/data-processing/operations/chunk-merger.md - https://ytsaurus.tech/docs/ru/user-guide/data-processing/operations/chunk-merger.md --- > **Documentation Index:** Fetch the complete configuration index at https://ytsaurus.tech/docs/ru/llms.txt # Автоматическое укрупнение чанков Для статических таблиц YTsaurus поддерживает возможность автоматического укрупнения чанков на стороне мастер-сервера. В отличие от операции [Merge](https://ytsaurus.tech/docs/ru/user-guide/data-processing/operations/merge.md), данный способ не использует вычислительные ресурсы пула. Для того чтобы включить автоматическое укрупнение чанков, достаточно выставить у таблицы атрибут `@chunk_merger_mode` в одно из значений ниже: - **shallow** — объединение чанков на уровне метаданных, без распаковки. Такой подход работает, только если чанки достаточно «похожи» (в плане сортированности, колонок, compression-кодека и т. д.). Также в какой-то момент у результирующего чанка может стать слишком много [блоков](https://ytsaurus.tech/docs/ru/user-guide/storage/chunks.md#chunk-size). - **deep** — объединение чанков с полным пережатием (путём вычитывания всех входных чанков и записи в новый). Этот режим существенно более дорогой, чем предыдущий, но позволяет объединить чанки с разными характеристиками, которые оказались в одной таблице. Этот режим можно также использовать, чтобы избавиться от мелких блоков или чанков в старых форматах. - **auto** (рекомендуется) — объединение чанков в shallow режиме с откатом в deep в случае неудачи. - **none** - отключает объединение чанков. По умолчанию рекомендуется использовать `auto` (другие режимы тоже разрешены, но переключаться на них стоит, только хорошо понимая, зачем): ```bash $ yt set //home/dir_with_tables/table_i_want_to_merge/@chunk_merger_mode auto ``` Если необходимо мержить все таблицы в определённом поддереве, атрибут можно выставить на всю директорию: ```bash $ yt set //home/dir_with_tables/@chunk_merger_mode auto ``` Если необходимо мержить все таблицы в определённом поддереве за исключением некоторых директорий, можно на эти директории выставить `chunk_merger_mode = none`: ```bash $ yt set //home/dir_with_tables/@chunk_merger_mode auto $ yt set //home/dir_with_tables/subdir/@chunk_merger_mode none ``` {% note info "Примечание" %} Данный механизм работает только для статических таблиц. Динамические таблицы имеют собственные механизмы укрупнения чанков. Выставление атрибута `chunk_merger_mode` для них ни к чему не приведёт. {% endnote %} Следует заметить, что `chunk_merger_mode` — это [наследуемый атрибут](https://ytsaurus.tech/docs/ru/user-guide/storage/chunks.md#common). Это означает, что после его установки его значение будут наследовать все новые таблицы в директории, но для старых ничего не поменяется, поэтому в момент включения следует дополнительно пройтись по всем таблицам. Укрупнение чанков инициируется в момент установки атрибута и каждый раз при записи в таблицу (при этом, в случае дозаписи в качестве оптимизации система попытается перемержить лишь хвост таблицы). ## Атрибуты укрупнения на аккаунте Каждый аккаунт содержит атрибуты, позволяющие управлять механизмом укрупнения чанков: - `allow_using_chunk_merger` — разрешено ли мержить чанки для таблиц этого аккаунта; - `chunk_merger_node_traversal_concurrency` — количество таблиц, для которых можно одновременно запланировать мерж-джобы; - `merge_job_rate_limit` — количество джобов, которое можно планировать в секунду. По умолчанию эти настройки выставлены так, что автоматическое укрупнение чанков для каждого аккаунта будет включено. ## Про диагностику У таблиц есть несколько системных атрибутов, позволяющих узнать о текущем статусе укрупнения чанков. Эти атрибуты не отображаются в веб-интерфейсе — чтобы посмотреть их, следует запросить их через CLI. - `@chunk_merger_status` — статус таблицы в пайплайне мержа, может принимать значения `not_in_merge_pipeline`, `awaiting_merge` и `in_merge_pipeline`. С момента срабатывания триггера для укрупнения чанков и до момента, когда мержер перестанет с таблицей что-либо делать, может пройти существенное количество времени. Если вы выставили `chunk_merger_mode` на таблицу, но чанки в ней всё ещё мелки, то стоит посмотреть на `chunk_merger_status` и дождаться, пока он станет `not_in_merge_pipeline`. - `@chunk_merger_traversal_info/chunk_count` — количество уже обработанных мержером чанков, укрупнять которые больше не планируется. Может быть полезно для понимания, какие чанки уже не помержатся. Пусть для некоторой таблицы было включено автоматическое укрупнение, после которого в ней осталась 1000 чанков, а теперь необходимо дописывать данные в конец таблицы. Рассматривать чанки с самого начала после каждой записи в таблицу нет смысла — если их не объединили до этого, то скорее всего, это не потребуется и сейчас. При этом может понадобиться склеить свежедобавленный чанк с некоторым количеством последних из старых. Так, если `@chunk_merger_traversal_info/chunk_count` равен, к примеру, 980, то в дальнейшем будут рассматриваться лишь последние 20 чанков, и именно их имеет смысл пытаться перемержить с новыми при будущих дозаписях. Автоматическое укрупнение чанков не берёт локи на таблицы, поэтому перемерживание должно быть полностью незаметно и не мешать остальным процессам. Однако, у этого есть неприятное следствие: иногда такие мержи могут завершаться неудачей (например, если за время выполнения мержа таблица была полностью перезаписана новыми данными). Система автоматически ретраит неудавшиеся мержи в случае, если это возможно (это может быть невозможно, если таблица была удалена или стала динамической). Однако, если таблица часто перезаписывается новыми данными, такой процесс может сходиться долго. ## Метрики в Prometheus Для сбора метрик по укрупнению чанков в Prometheus используются следующие временные ряды: - `yt.chunk_server.chunk_merger_account_queue_size` — поаккаунтные очереди на укрупнение чанков. Если очередь аккаунта пуста, стоит убедиться, что выставлен правильный атрибут для всех нужных таблиц. Также следует убедиться, что настройки аккаунта позволяют мержить таблицы: атрибут `allow_using_chunk_merger` переключен в `true`, а в атрибутах `chunk_merger_node_traversal_concurrency` и `merge_job_rate_limit` не выставлен 0. - `yt.chunk_server.chunk_merger_chunk_replacements_succeeded` — количество успешных мержей. - `yt.chunk_server.chunk_merger_chunk_replacements_failed` — количество неудавшихся мержей. Наличие определённого количества неудавшихся мержей — это нормально и полностью избавиться от них не получится, но если оно превышает количество успешных, то стоит обратить на это внимание. Возможно, мерж включен для таблиц, которые постоянно перезаписываются с нуля новыми данными, или очень недолгоживущих таблиц. В таком случае, автоматическое укрупнение для них лучше отключить.