Введение
При каждом импорте данных в StarRocks создаётся новая версия данных. Чтобы получить корректные результаты запроса, необходимо объединять все версии. По мере накопления исторических версий увеличивается количество файлов, которые нужно объединять, что заметно снижает эффективность запросов. Для решения этой проблемы StarRocks периодически запускает фоновые задачи, объединяющие исторические версии и устраняющие дубликаты записей. Этот процесс называется Compaction.
Например, после Compaction над файлами данных версии 1 и версии 2 из версии 1 были устранены устаревшие записи (id = 2, value = 11; id = 5, value = 30), и в итоге создан новый файл данных версии 3. Из примера видно, что Compaction — это процесс объединения файлов разных версий в более крупные, направленный на сокращение числа мелких файлов в системе и, как следствие, на повышение эффективности запросов.
По сравнению с таблицами со совмещёнными хранением и вычислениями, в StarRocks режим разделения хранения и вычислений использует новый механизм диспетчеризации Compaction со следующими особенностями:
Планирование Compaction инициируется узлом FE (Frontend), выполнение — на узлах BE (Backend). FE запускает задачи Compaction на уровне разделов (Partition).
Каждая операция Compaction создаёт новую версию и проходит полный конвейер импорта: запись данных, фиксация (commit) и публикация версии (publish version).
Цель этой статьи — описать базовые принципы реализации Compaction для таблиц с разделением хранения и вычислений в StarRocks и помочь разработчикам/инженерам эксплуатации правильно настраивать связанные параметры, чтобы добиться оптимальной производительности на практике.
Механизм обновления версий данных
Каждый импорт в FE создаёт новую версию, помеченную на уровне раздела (Partition). После успешного commit транзакции импорта обновляется номер видимой версии (visible version) раздела; номера версий монотонно возрастают.
Внутри одного Partition может быть несколько Tablet — они разделяют один и тот же номер версии данных. Даже если импорт задействует лишь часть Tablet, после успешного commit версии всех Tablet в этом Partition также повышаются.
Например, в Partition X содержатся Tablet 1…N; текущая видимая версия — 12. После новой транзакции импорта (New Load Txn) и её успешной фиксации видимая версия Partition X станет 13.
Базовая архитектура
Compaction в режиме разделения хранения и вычислений состоит из двух ролей:
планировщик Compaction (Scheduler) — FE;
исполнитель Compaction (Executor) — BE или CN (Compute Node).
Планировщик через RPC формирует задания Compaction (Compaction Job), исполнители их выполняют. На каждом исполнителе есть выделенный пул потоков для выполнения задач Compaction (Compaction Task).
Диспетчеризация Compaction (Scheduler)
На FE работает периодический поток Compaction Scheduler, который планирует и инициирует все задачи Compaction. Базовая единица планирования — Partition.
FE хранит Compaction Score для каждого Partition — показатель приоритета необходимости Compaction; чем выше значение, тем срочнее требуется объединение в разделе. При каждом проходе Scheduler выбирает Partition с максимальным Compaction Score и формирует для них задачи, ограничивая максимальное число задач, запускаемых за один цикл.
Формирование задач происходит так: для каждого Partition планировщик получает список всех Tablet, группирует их по вычислительным узлам (CN) и для каждого CN формирует отдельную Compaction Task со списком Tablet, которые нужно компактизировать на этом CN. Затем задачи отправляются на соответствующие узлы CN.
Пример:
Partition X: четыре Tablet (1–4). Scheduler обнаруживает, что Tablet‑2 и Tablet‑4 находятся на CN‑1, а Tablet‑1 и Tablet‑3 — на CN‑2, и формирует две задачи (Task‑1 для CN‑1 с Tablet‑2 и Tablet‑4; Task‑2 для CN‑2 с Tablet‑1 и Tablet‑3).
Partition Y: три Tablet (5–7). Tablet‑5 и Tablet‑7 на CN‑1, Tablet‑6 — на CN‑2. Формируются Task‑3 (CN‑1: Tablet‑5 и Tablet‑7) и Task‑4 (CN‑2: Tablet‑6).
На каждом CN есть специализированный пул потоков для обработки этих задач; количество потоков настраивается (в ближайших версиях поддерживается динамическая настройка). Каждый поток извлекает из очереди Compaction Task следующую задачу к исполнению.
Очистка данных после Compaction
Таблицы в режиме разделения хранения и вычислений используют многоверсионность. Рассмотрим три последовательные транзакции импорта:
Load Txn 1: при записи транзакции созданы файлы данных file‑1 и file‑2; после commit сформирован Tablet Meta V1 со списком видимых файлов {file‑1, file‑2}.
Load Txn 2: при записи созданы file‑3 и file‑4; при commit на основе V1 и новых файлов сформирован Tablet Meta V2 со списком {file‑1, file‑2, file‑3, file‑4}.
Load Txn 3: при записи создан file‑5; при commit на основе V2 и file‑5 сформирован Tablet Meta V3 со списком {file‑1, file‑2, file‑3, file‑4, file‑5}.
Помимо пользовательских импортов, фоновые задачи Compaction также создают новые версии. Их цели:
объединить множество мелких файлов версий в крупные, сократив количество случайных I/O при запросах;
устранить дубликаты, уменьшив общий объём данных.
Предположим, после Txn 3 выполняется Compaction (Txn 4), который объединяет file‑1…file‑4 в новый file‑6. При commit формируется Tablet Meta V4 со списком {file‑5, file‑6}.
Если Compaction не выполнять, файлы данных нельзя было бы удалять: даже при удалении метаданных старых версий сами файлы оставались бы референсируемыми более новой версией Tablet Meta. С Compaction ситуация меняется: поскольку содержимое file‑1…file‑4 уже включено в file‑6, после того как версии V1, V2 и V3 перестают быть видимыми/используемыми, файлы file‑1…file‑4 можно безопасно удалить.
Критерий безопасного удаления файла данных: файл не должен референсироваться ни одним Tablet Meta.
Руководство по тюнингу Compaction
Просмотр Compaction Score раздела (Partition)
Внимание: команды ниже нужно выполнять, подключившись к Leader FE.
StarRocks поддерживает Compaction Score для каждого Partition — показатель состояния объединения файлов: чем выше значение, тем хуже состояние (слишком много мелких версий). FE использует это значение как один из критериев запуска задач Compaction; пользователи могут ориентироваться на него для диагностики.
Способ 1:
MySQL [(none)]> show proc '/dbs/load_benchmark/store_sales/partitions';
+-------------+---------------+----------------+----------------+-------------+--------+--------------+-------+------------------------------+---------+----------+-----------+----------+------------+-------+-------+-------+
| PartitionId | PartitionName | CompactVersion | VisibleVersion | NextVersion | State | PartitionKey | Range | DistributionKey | Buckets | DataSize | RowCount | CacheTTL | AsyncWrite | AvgCS | P50CS | MaxCS |
+-------------+---------------+----------------+----------------+-------------+--------+--------------+-------+------------------------------+---------+----------+-----------+----------+------------+-------+-------+-------+
| 38028 | store_sales | 913 | 921 | 923 | NORMAL | | | ss_item_sk, ss_ticket_number | 64 | 15.6GB | 273857126 | 2592000 | false | 10.00 | 10.00 | 10.00 |
+-------------+---------------+----------------+----------------+-------------+--------+--------------+-------+------------------------------+---------+----------+-----------+----------+------------+-------+-------+-------+
1 row in set (0.20 sec)
Способ 2 (с версий 3.1.9 и 3.2.4 имеется системная таблица partitions_meta):
mysql> select * from information_schema.partitions_meta order by Max_CS;
+--------------+----------------------------+----------------------------+--------------+-----------------+-----------------+----------------------+--------------+---------------+-----------------+-----------------------------------------+---------+-----------------+----------------+---------------------+-----------------------------+--------------+---------+-----------+------------+------------------+----------+--------+--------+--------------------------------------------------------------------------------------------------------+
| DB_NAME | TABLE_NAME | PARTITION_NAME | PARTITION_ID | COMPACT_VERSION | VISIBLE_VERSION | VISIBLE_VERSION_TIME | NEXT_VERSION | PARTITION_KEY | PARTITION_VALUE | DISTRIBUTION_KEY | BUCKETS | REPLICATION_NUM | STORAGE_MEDIUM | COOLDOWN_TIME | LAST_CONSISTENCY_CHECK_TIME | IS_IN_MEMORY | IS_TEMP | DATA_SIZE | ROW_COUNT | ENABLE_DATACACHE | AVG_CS | P50_CS | MAX_CS | STORAGE_PATH |
+--------------+----------------------------+----------------------------+--------------+-----------------+-----------------+----------------------+--------------+---------------+-----------------+-----------------------------------------+---------+-----------------+----------------+---------------------+-----------------------------+--------------+---------+-----------+------------+------------------+----------+--------+--------+--------------------------------------------------------------------------------------------------------+
| tpcds_1t | call_center | call_center | 11905 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | cc_call_center_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 12.3KB | 42 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11906/11905 |
| tpcds_1t | web_returns | web_returns | 12030 | 3 | 3 | 2024-03-17 08:40:48 | 4 | | | wr_item_sk, wr_order_number | 16 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 3.5GB | 71997522 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/12031/12030 |
| tpcds_1t | warehouse | warehouse | 11847 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | w_warehouse_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 4.2KB | 20 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11848/11847 |
| tpcds_1t | ship_mode | ship_mode | 11851 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | sm_ship_mode_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 1.7KB | 20 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11852/11851 |
| tpcds_1t | customer_address | customer_address | 11790 | 0 | 2 | 2024-03-17 08:32:19 | 3 | | | ca_address_sk | 16 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 120.9MB | 6000000 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11791/11790 |
| tpcds_1t | time_dim | time_dim | 11855 | 0 | 2 | 2024-03-17 08:30:48 | 3 | | | t_time_sk | 16 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 864.7KB | 86400 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11856/11855 |
| tpcds_1t | web_sales | web_sales | 12049 | 3 | 3 | 2024-03-17 10:14:20 | 4 | | | ws_item_sk, ws_order_number | 128 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 47.7GB | 720000376 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/12050/12049 |
| tpcds_1t | store | store | 11901 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | s_store_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 95.6KB | 1002 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11902/11901 |
| tpcds_1t | web_site | web_site | 11928 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | web_site_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 13.4KB | 54 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11929/11928 |
| tpcds_1t | household_demographics | household_demographics | 11932 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | hd_demo_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 2.1KB | 7200 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11933/11932 |
| tpcds_1t | web_page | web_page | 11936 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | wp_web_page_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 43.5KB | 3000 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11937/11936 |
| tpcds_1t | customer_demographics | customer_demographics | 11809 | 0 | 2 | 2024-03-17 08:30:49 | 3 | | | cd_demo_sk | 16 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 2.7MB | 1920800 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11810/11809 |
| tpcds_1t | reason | reason | 11874 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | r_reason_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 1.9KB | 65 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11875/11874 |
| tpcds_1t | promotion | promotion | 11940 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | p_promo_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 69.6KB | 1500 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11941/11940 |
| tpcds_1t | income_band | income_band | 11878 | 0 | 2 | 2024-03-17 08:30:48 | 3 | | | ib_income_band_sk | 1 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 727B | 20 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11879/11878 |
| tpcds_1t | catalog_page | catalog_page | 11944 | 0 | 2 | 2024-03-17 08:30:52 | 3 | | | cp_catalog_page_sk | 16 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 1.8MB | 30000 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11945/11944 |
| tpcds_1t | item | item | 11882 | 0 | 2 | 2024-03-17 08:30:51 | 3 | | | i_item_sk | 16 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 37.1MB | 300000 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11883/11882 |
| tpcds_1t | store_returns | store_returns | 11755 | 3 | 3 | 2024-03-17 09:02:48 | 4 | | | sr_item_sk, sr_ticket_number | 32 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 11.3GB | 287999764 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11756/11755 |
| tpcds_1t | date_dim | date_dim | 11828 | 0 | 2 | 2024-03-17 08:30:47 | 3 | | | d_date_sk | 16 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 1.5MB | 73049 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/11829/11828 |
| tpcds_1t | catalog_sales | catalog_sales | 12215 | 3 | 3 | 2024-03-17 11:44:37 | 4 | | | cs_item_sk, cs_order_number | 256 | 1 | HDD | 9999-12-31 23:59:59 | NULL | 0 | 0 | 94.7GB | 1439982416 | 0 | 0 | 0 | 0 | s3://starrocks-cloud-data-zhangjiakou/dingkai/536a3c77-52c3-485a-8217-781734a970b1/db10328/12216/12215 |
28 rows in set (0.04 sec)
Ключевые поля:
AvgCS: средний Compaction Score всех Tablet в текущем Partition.MaxCS: максимальный Compaction Score среди всех Tablet в текущем Partition.
Просмотр задач Compaction
С ростом числа импортов система постоянно планирует и исполняет задачи Compaction на вычислительных узлах CN. Доступны команды для наблюдения за состоянием выполнения.
Общая сводка всех задач:
MySQL [(none)]> show proc '/compactions';
+----------------------------------------------------+--------+---------------------+------------+---------------------+----------------------------------------------+
| Partition | TxnID | StartTime | CommitTime | FinishTime | Error |
+----------------------------------------------------+--------+---------------------+------------+---------------------+----------------------------------------------+
| load_benchmark.store_sales.store_sales | 197562 | 2023-05-24 15:50:33 | 2023-05-24 15:51:00 | 2023-05-24 15:51:02 | NULL |
+----------------------------------------------------+--------+---------------------+------------+---------------------+----------------------------------------------+
1 rows in set (0.21 sec)
Пояснение полей:
Partition: раздел, для которого выполняется задача Compaction.TxnID: ID транзакции, назначенный FE для этой задачи.StartTime: время начала задачи.CommitTime: время фиксации (commit).FinishTime: время завершения.Error: сведения об ошибке (если нет —NULL).
Детализация по подзадачам на уровне Tablet:
MySQL [(none)]> select * from information_schema.be_cloud_native_compactions where TXN_ID = 197562;
+-------+--------+-----------+---------+---------+------+---------------------+---------------------+----------+--------+
| BE_ID | TXN_ID | TABLET_ID | VERSION | SKIPPED | RUNS | START_TIME | FINISH_TIME | PROGRESS | STATUS |
+-------+--------+-----------+---------+---------+------+---------------------+---------------------+----------+--------+
| 36027 | 197562 | 38033 | 365 | 0 | 1 | 2023-05-24 15:50:34 | 2023-05-24 15:50:38 | 100 | OK |
| 10004 | 197562 | 38064 | 365 | 0 | 1 | 2023-05-24 15:50:42 | 2023-05-24 15:50:47 | 100 | OK |
| 10004 | 197562 | 38065 | 365 | 0 | 1 | 2023-05-24 15:50:46 | NULL | 99 | OK |
| 10004 | 197562 | 38067 | 365 | 0 | 1 | 2023-05-24 15:50:46 | NULL | 92 | OK |
| 10004 | 197562 | 38068 | 365 | 0 | 1 | 2023-05-24 15:50:47 | NULL | 87 | OK |
| 10004 | 197562 | 38072 | 365 | 0 | 1 | 2023-05-24 15:50:47 | NULL | 89 | OK |
| 10004 | 197562 | 38076 | 365 | 0 | 0 | NULL | NULL | 0 | OK |
| ...
64 rows in set (0.22 sec)
Ключевые поля:
PROGRESS: прогресс Compaction по Tablet (в процентах).STATUS: состояние подзадачи; при ошибках содержит подробности.
Отмена задачи Compaction
Отменить конкретную задачу Compaction можно так (выполнять на Leader FE):
CANCEL COMPACTION WHERE TXN_ID = 123;
Параметры настройки
Параметры, управляющие Compaction в режиме разделения хранения и вычислений:
Параметры FE:
# Минимальный Compaction Score: для Partition ниже порога задачи Compaction не запускаются
lake_compaction_score_selector_min_score = 10.0
# Максимальное число задач Compaction, одновременно инициируемых FE
# -1 — FE рассчитает автоматически на основе числа BE
# 0 — FE не будет инициировать задачи Compaction
lake_compaction_max_tasks = -1
# Число записей в истории show proc '/compactions' (по умолчанию 12)
lake_compaction_history_size = 12
lake_compaction_fail_history_size = 12
Параметры FE можно менять динамически:
ADMIN SET FRONTEND CONFIG ("lake_compaction_max_tasks" = "0");
Параметры BE / CN:
# Число потоков одновременного выполнения Compaction на BE/CN (по умолчанию 4)
compact_threads = 4
# Размер очереди задач Compaction на BE (максимум задач от FE), по умолчанию 100
compact_thread_pool_queue_size = 100
# Максимум файлов данных, объединяемых за одну задачу Compaction (по умолчанию 1000)
# На практике рекомендуется 100, чтобы ускорить завершение задач и снизить ресурсопотребление
max_cumulative_compaction_num_singleton_deltas = 100
Параметры BE поддерживают динамическое изменение:
UPDATE information_schema.be_configs SET value = 8 WHERE name = "compact_threads";
Лучшие практики
Отслеживайте Compaction Score и настраивайте оповещения по соответствующим метрикам. Шаблоны Grafana, поставляемые со StarRocks, уже включают эти метрики (см. примечание ниже).
Контролируйте ресурсы, потребляемые Compaction, особенно использование памяти. В станд
артных шаблонах Grafana предусмотрены релевантные панели.
В периоды низкой нагрузки увеличивайте число параллельных рабочих потоков Compaction на вычислительных узлах, чтобы ускорить завершение фоновых объединений.
Примечание. О мониторинге и оповещениях с использованием Prometheus и Grafana см. официальное руководство:
https://docs.starrocks.io/zh/docs/administration/management/monitoring/Monitor_and_Alert/