В аналитической платформе отчёты пользователей и регулярные пакетные расчёты конкурируют за одни ресурсы. Как изолировать эти нагрузки, чтобы запуск расчёта не ухудшал интерактивные запросы?
Используйте изоляцию рабочих нагрузок: разделите интерактивные запросы и пакетные расчёты по вычислительным ресурсам, очередям или пулам с отдельными лимитами. Тогда каждая категория получает гарантированную долю ресурсов, а тяжёлая пакетная задача не может полностью вытеснить пользовательские запросы.
Одной настройки приоритета обычно недостаточно: она управляет порядком выполнения, но не всегда ограничивает уже выполняющиеся запросы. Надёжная изоляция сочетает отдельные ресурсы, квоты, ограничения параллелизма и контроль длительности запросов.
Изначально аналитические системы часто запускали все запросы на одном наборе вычислительных узлов. Это упрощало эксплуатацию, но интерактивные запросы, построение витрин и периодические пересчёты начинали конкурировать за процессор, память, дисковый ввод-вывод и сетевую пропускную способность.
По мере роста числа пользователей возникла потребность отделить требования к задержке от требований к пропускной способности. Так появились очереди, классы обслуживания и отдельные вычислительные пулы, позволяющие управлять нагрузками независимо от самого хранилища данных.
Пакетный расчёт может одновременно запускать множество тяжёлых операций чтения, соединений и агрегаций. Если он использует общие ресурсы с интерактивными запросами, возрастает их задержка, появляются тайм-ауты и нестабильное время ответа.
Простое повышение приоритета пользовательских запросов не решает проблему полностью. Высокоприоритетные запросы всё равно могут исчерпать память, вызвать конкуренцию за диски или перегрузить управляющие узлы. Обратная крайность — жёсткое резервирование ресурсов — может привести к их простою, когда одна нагрузка временно отсутствует.
Сначала нагрузки классифицируют по требованиям: интерактивные запросы, пакетные преобразования, загрузка данных и фоновые задачи. Для каждого класса задают отдельную очередь или вычислительный пул, максимальное число одновременно выполняющихся задач, лимиты памяти и допустимую продолжительность.
Интерактивному классу обычно резервируют ресурсы и ограничивают максимальную сложность запроса. Пакетный класс получает больше параллелизма, но может быть ограничен по доле процессора, памяти или времени запуска. Фоновые задачи выполняются с наименьшим приоритетом и не должны блокировать критичные нагрузки.
Изоляция бывает логической и физической. Логическая использует общие узлы, но разделяет очереди и квоты; она экономичнее, однако конкуренция за общие диски, сеть или память может сохраниться. Физическая изоляция выделяет отдельные узлы или вычислительные кластеры; она лучше защищает задержку, но увеличивает стоимость и риск неэффективного использования ресурсов.
Важно отделять вычислительные ресурсы от данных, если используемая платформа это поддерживает. Несколько независимых вычислительных групп могут читать один набор данных, не дублируя его, но необходимо проверить конкуренцию за хранилище, кэш, сеть и метаданные.
Политика должна включать защиту от плохо сформированных запросов: ограничение максимального объёма результата, времени выполнения, числа параллельных соединений и операций без фильтра по крупным таблицам. При этом ограничения не заменяют оптимизацию моделей данных и запросов — они только предотвращают отказ всей платформы из-за отдельной задачи.
Контроль эффективности ведут по задержке запросов, очереди ожидания, доле отказов, использованию ресурсов и времени завершения пакетных окон. Если интерактивные запросы стабильно укладываются в целевой показатель, а пакетные расчёты завершаются в допустимое окно, границы пулов выбраны приемлемо.
Главный компромисс — между гарантией задержки и общей утилизацией. Чем жёстче резервирование, тем надёжнее изоляция, но тем больше вероятность простоя; эластическое выделение ресурсов повышает эффективность, но требует контроля пиков и корректного планирования квот.
В компании отчёты аналитиков выполнялись днём, а пересчёт нескольких крупных витрин запускался каждый час. Все задачи использовали один вычислительный кластер. Во время пересчёта интерактивные запросы иногда выполнялись несколько минут вместо нескольких секунд.
Рассматривались три варианта. Увеличение кластера давало запас производительности, но не устраняло конкуренцию и повышало стоимость. Полный запрет пакетных расчётов в рабочее время сокращал влияние на пользователей, но увеличивал задержку обновления данных. Только повышение приоритета отчётов не защищало память и дисковый ввод-вывод.
Выбрали два вычислительных пула поверх общего хранилища. Для интерактивного пула закрепили минимальную долю ресурсов и ограничили число тяжёлых запросов, а для пакетного — отдельную квоту и контролируемый параллелизм. Дополнительно ввели автоматическое перемещение фоновых задач в периоды высокой пользовательской нагрузки.
В результате задержка интерактивных запросов стала предсказуемой, а пакетные расчёты сохранили требуемое окно завершения. При этом мониторинг показал узкое место в общей сети, поэтому для отдельных периодов пришлось ограничить скорость чтения пакетного пула.
1. Достаточно ли разделить нагрузки по приоритетам?
Нет. Приоритет определяет, какая задача получит ресурс следующей, но не гарантирует, что уже выполняющийся запрос не займёт большую часть памяти, каналов ввода-вывода или сетевой пропускной способности. Для предсказуемой задержки нужны квоты, ограничение параллелизма и, при необходимости, отдельные вычислительные ресурсы.
2. Можно ли полностью устранить взаимное влияние при общем хранилище?
Нет, физическое разделение вычислений не гарантирует полной независимости. Нагрузки могут конкурировать за диски, сеть, кэш, контроллеры и операции с метаданными. Поэтому после разделения пулов нужно измерять общие компоненты и при необходимости ограничивать скорость чтения, менять размещение данных или выделять отдельные ресурсы хранения.
3. Как не превратить изоляцию в дорогостоящий простой ресурсов?
Следует резервировать только минимально необходимую гарантированную долю, а свободные ресурсы разрешать временно заимствовать другим пулам. При этом заимствование должно быть вытесняемым: интерактивная нагрузка получает ресурс обратно при росте спроса. Границы пулов нужно пересматривать по фактическим метрикам, иначе фиксированное резервирование приведёт либо к дефициту, либо к постоянному простою.