Версия: 2.0.x

Конфигурация групп ресурсов на основе audit log

В Selena группы ресурсов (Resource Groups) предоставляют эффективный механизм изоляции ресурсов путем распределения лимитов CPU, памяти и параллелизма на основе классификаторов, таких как идентификатор пользователя и тип запроса. Эта функция необходима для эффективного использования ресурсов в мультитенантных средах.

Традиционная конфигурация групп ресурсов часто основывается на эмпирических оценках. Анализируя исторические данные запросов из таблицы audit log selena_audit_db__.selena_audit_tbl__, администраторы могут вместо этого использовать подход на основе данных для настройки групп ресурсов. Ключевые метрики, такие как время CPU, потребление памяти и параллелизм запросов, дают объективное представление о фактических характеристиках нагрузки.

Этот подход помогает:

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

Эта тема содержит пошаговое руководство о том, как вывести подходящие параметры групп ресурсов на основе паттернов нагрузки, наблюдаемых из audit log.

примечание

Это руководство основано на анализе с использованием плагина AuditLoader, который позволяет выполнять запросы к журналам аудита с помощью SQL-операторов непосредственно в вашем cluster. Подробные инструкции по установке плагина см. в разделе AuditLoader.

Распределение ресурсов CPU

Цель

Определить потребление CPU на пользователя и пропорционально распределить ресурсы CPU, используя cpu_weight или exclusive_cpu_cores.

Анализ

Следующий SQL агрегирует общее время CPU на пользователя (cpuCostNs) за последние 30 дней, преобразует его в секунды и вычисляет процент от общего использования CPU.

SELECT 
    user,
    SUM(cpuCostNs) / 1e9 AS total_cpu_seconds,                  -- Запрос общего времени CPU.
    (
        SUM(cpuCostNs) /
        (
            SELECT SUM(cpuCostNs)
            FROM selena_audit_db__.selena_audit_tbl__
            WHERE state IN ('EOF','OK')
              AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
        )
    ) * 100 AS cpu_usage_percentage                             -- Вычисление процента от общего использования CPU на пользователя.
FROM selena_audit_db__.selena_audit_tbl__
WHERE state IN ('EOF','OK')                                     -- Включить только завершенные запросы.
  AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)    -- Запрос данных за последние 30 дней.
GROUP BY user
ORDER BY total_cpu_seconds DESC
LIMIT 20;                                                       -- Список топ-20 пользователей с наибольшим потреблением ресурсов CPU.

Лучшие практики

Предположим фиксированное количество ядер CPU на BE (например, 64 ядра). Если пользователь составляет 16% (cpu_usage_percentage) от общего времени CPU, выделение приблизительно 64 × 16% ≈ 11 ядер является разумным.

Вы можете настроить лимиты CPU для группы ресурсов следующим образом:

exclusive_cpu_cores:
- Его значение не должно превышать общее количество ядер на одном BE.
- Сумма exclusive_cpu_cores всех групп ресурсов не должна превышать общее количество ядер на одном BE.
cpu_weight:
- Применяется только к группам ресурсов с мягкой изоляцией.
- Определяет относительную долю CPU среди конкурирующих запросов на оставшихся ядрах.
- Не отображается напрямую на фиксированное количество ядер CPU.

Управление памятью

Цель

Определить пользователей с интенсивным использованием памяти и установить соответствующие лимиты памяти и circuit breaker.

Анализ

Следующий SQL вычисляет максимальное использование памяти на пользователя (memCostBytes) для одного запроса за последние 30 дней.

SELECT 
    user,
    MAX(memCostBytes) / (1024 * 1024) AS max_mem_mb            -- Максимальное использование памяти (в MB) на запрос.
FROM selena_audit_db__.selena_audit_tbl__
WHERE state IN ('EOF','OK')                                    -- Включить только завершенные запросы.
  AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)   -- Запрос данных за последние 30 дней.
GROUP BY user
ORDER BY max_mem_mb DESC
LIMIT 20;                                                      -- Список топ-20 пользователей с наибольшим потреблением памяти.

Лучшие практики

max_mem_mb представляет общее использование памяти на всех BE. Вы можете вычислить приблизительное использование памяти на один BE как: max_mem_mb / количество_BE.

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

big_query_mem_limit:
- Защищает cluster от аномально больших запросов.
- Вы можете установить его на относительно высокий порог, чтобы избежать ложного прерывания запросов.
mem_limit:
- В большинстве случаев устанавливайте его на высокое значение (например, 0.9).

Контроль параллелизма

Цель

Определить пиковый параллелизм запросов на пользователя и установить соответствующие значения concurrency_limit.

Анализ

Следующий SQL анализирует поминутный параллелизм запросов за последние 30 дней и извлекает максимальный наблюдаемый параллелизм на пользователя.

WITH UserConcurrency AS (
    SELECT 
        user,
        DATE_FORMAT(timestamp, '%Y-%m-%d %H:%i') AS minute_bucket,
        COUNT(*) AS query_concurrency
    FROM selena_audit_db__.selena_audit_tbl__
    WHERE state IN ('EOF', 'OK')                              -- Включить только завершенные запросы.
      AND timestamp >= DATE_SUB(NOW(), INTERVAL 30 DAY)       -- Запрос данных за последние 30 дней.
      AND LOWER(stmt) LIKE '%select%'                         -- Включить только SELECT-запросы.
    GROUP BY user, minute_bucket
    HAVING query_concurrency > 1                              -- Исключить сценарии, где параллелизм менее одного запроса в минуту.
)
SELECT 
    user,
    minute_bucket,
    query_concurrency / 60.0 AS query_concurrency_per_second  -- Запрос посекундного параллелизма.
FROM (
    SELECT
        user,
        minute_bucket,
        query_concurrency,
        ROW_NUMBER() OVER (
            PARTITION BY user
            ORDER BY query_concurrency DESC
        ) AS rn
    FROM UserConcurrency
) ranked
WHERE rn = 1                                                  -- Сохранить наивысшую запись для каждого пользователя.
ORDER BY query_concurrency_per_second DESC
LIMIT 50;                                                     -- Список топ-50 пользователей с наибольшим параллелизмом.

Лучшие практики

Вышеуказанный анализ выполняется с поминутной детализацией. Фактический посекундный параллелизм может быть выше.

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

concurrency_limit
- Установите его приблизительно на 1.5× от наблюдаемого пика, чтобы обеспечить запас.
- Для пользователей с экстремальными всплесками параллелизма вы можете дополнительно включить очереди запросов (Query Queues), чтобы сгладить пиковую нагрузку и защитить стабильность cluster.

Изоляция ресурсов для асинхронных материализованных представлений

Цель

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

Анализ

Следующий SQL идентифицирует операции обновления материализованных представлений с интенсивным использованием памяти, обычно характеризуемые операторами INSERT OVERWRITE.

SELECT 
    user,
    MAX(memCostBytes) / (1024 * 1024) AS max_mem_mb             -- Максимальное использование памяти (в MB) на запрос.
FROM selena_audit_db__.selena_audit_tbl__
WHERE state IN ('EOF','OK')                                     -- Включить только завершенные запросы.
  AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)    -- Запрос данных за последние 30 дней.
  AND LOWER(stmt) LIKE '%insert overwrite%'                     -- Включить только операции обновления материализованных представлений.
GROUP BY user
ORDER BY max_mem_mb DESC
LIMIT 20;                                                       -- Список топ-20 пользователей с наибольшим потреблением памяти.

Лучшие практики

Selena предоставляет системную группу ресурсов (default_mv_wg) для задач обновления материализованных представлений по умолчанию. Однако настройка выделенной группы ресурсов для задач обновления материализованных представлений строго рекомендуется для обеспечения строгой изоляции и предотвращения деградации производительности запросов переднего плана из-за операций обновления материализованных представлений.

Инструкции по настройке лимитов групп ресурсов см. в разделах Лучшие практики для распределения ресурсов CPU и Лучшие практики для управления памятью.

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

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

CREATE RESOURCE GROUP rg_mv
TO (
    user = 'mv_user',
    query_type IN ('insert', 'select')
)
WITH (
    'cpu_weight' = '32',
    'mem_limit' = '0.9',
    'concurrency_limit' = '10',
    'spill_mem_limit_threshold' = '0.5'
);

Назначьте группу ресурсов материализованному представлению.
- Назначение при создании материализованного представления:
```
CREATE MATERIALIZED VIEW mv_example
REFRESH ASYNC
PROPERTIES (
    'resource_group' = 'rg_mv'
)
AS
SELECT * FROM example_table;
```
- Назначение существующему материализованному представлению:
```
ALTER MATERIALIZED VIEW mv_example SET ("resource_group" = "rg_mv");
```

Распределение ресурсов CPU​

Цель​

Анализ​

Лучшие практики​

Управление памятью​

Цель​

Анализ​

Лучшие практики​

Контроль параллелизма​

Цель​

Анализ​

Лучшие практики​

Изоляция ресурсов для асинхронных материализованных представлений​

Цель​

Анализ​

Лучшие практики​

См. также​

Распределение ресурсов CPU

Цель

Анализ

Лучшие практики

Управление памятью

Цель

Анализ

Лучшие практики

Контроль параллелизма

Цель

Анализ

Лучшие практики

Изоляция ресурсов для асинхронных материализованных представлений

Цель

Анализ

Лучшие практики

См. также