Workload management в DWH на собеседовании Data Engineer

Зачем WLM

Workload management (WLM) — управление тем, как хранилище данных распределяет ресурсы между разными типами нагрузки. В любом реальном DWH одновременно работают несколько категорий пользователей и задач, и у каждой свои требования:

• ETL — пакетные (batch) задачи: тяжёлые, долгие, прожорливые до памяти и CPU. Им не важна секундная задержка, важно досчитать до дедлайна.
• Аналитика — интерактивные запросы аналитиков: относительно быстрые, но их важно не заставлять ждать в очереди по десять минут.
• Дашборды — частые и лёгкие запросы от BI-инструмента: их много, они мелкие, но должны отвечать мгновенно.

Без WLM все эти нагрузки конкурируют за один пул ресурсов, и тяжёлый ETL легко забивает всё хранилище — дашборды начинают отваливаться по таймауту как раз в тот момент, когда на них смотрит руководство. WLM нужен, чтобы этого не происходило: он расставляет приоритеты и не даёт одной нагрузке задушить остальные. На собесе DE эту тему поднимают, когда обсуждают эксплуатацию DWH и вопрос «как сделать, чтобы аналитики и ETL не мешали друг другу».

Очереди запросов

Первый механизм WLM — очереди (query queues). Запросы разбивают по категориям и направляют в разные очереди, у каждой из которых свой лимит одновременных запросов и своя доля памяти:

ETL queue:       до 5 одновременных запросов, 50% памяти
Analyst queue:   до 20 одновременных запросов, 30% памяти
Dashboard queue: до 50 одновременных запросов, 20% памяти

Маршрутизация в нужную очередь обычно идёт по роли пользователя (сервисный аккаунт ETL → ETL-очередь), по типу запроса или по явной подсказке (query hint / query group). Идея в том, чтобы тяжёлые ETL-запросы физически не могли занять слоты, отведённые под дашборды: даже если ETL захлебнулся, у дашбордов остаётся своя изолированная ёмкость.

Приоритеты

Второй механизм — приоритеты. Чем выше приоритет запроса, тем больше ресурсов он получает и тем раньше выполняется при конкуренции:

Уровни приоритета: CRITICAL > HIGH > NORMAL > LOW

Дашборды  = HIGH   (интерактивные, ждёт живой пользователь)
ETL       = NORMAL (терпит, лишь бы успел к дедлайну)
Backfill  = LOW    (пересчёт истории, можно и ночью)

При нехватке ресурсов (contention) запросы с высоким приоритетом получают их первыми, а низкоприоритетные притормаживаются или вытесняются. Логика распределения обычно обратна интуиции новичка: интерактивным дашбордам дают высокий приоритет не потому, что они «важнее» ETL, а потому что их ждёт человек в реальном времени, тогда как фоновый пересчёт истории спокойно потерпит.

Лимиты конкурентности

Concurrency limit — максимальное число запросов, которые выполняются одновременно. Это фундаментальный компромисс WLM:

Snowflake warehouse: MAX_CONCURRENCY_LEVEL = 8

Чем выше лимит, тем больше запросов проходит в единицу времени (throughput), но тем сильнее они конкурируют за ресурсы и тем медленнее каждый в отдельности. Чем ниже лимит, тем предсказуемее скорость каждого запроса, но тем длиннее очередь ожидающих. Правильного универсального числа нет — его подбирают под профиль нагрузки. В Redshift этот механизм реализован через слоты WLM (queue slots): каждая очередь получает фиксированное число слотов, и запрос занимает один или несколько.

Изоляция ресурсов

Самый жёсткий способ развести нагрузки — дать им разные вычислительные ресурсы, а не делить один. Тогда всплеск в одной нагрузке физически не может затронуть другую.

Snowflake. В одном аккаунте поднимают несколько виртуальных складов (warehouses), каждый под свою нагрузку, с авто-остановкой (auto-suspend) и авто-запуском (auto-resume), чтобы не платить за простой:

WH_ETL     — большой склад под пакетные задачи
WH_ANALYST — маленький, запускается по запросу аналитиков
WH_DASH    — с авто-остановкой после простоя

Поскольку склады не делят compute, тяжёлый ETL на WH_ETL вообще не касается дашбордов на WH_DASH — это самая надёжная изоляция.

ClickHouse / Greenplum. Здесь роль изоляции играют пулы ресурсов (resource pools) и очереди: каждой группе пользователей выделяют квоту по памяти и потокам, чтобы один тяжёлый запрос не отъедал ресурсы у всех остальных.

Как это спрашивают на собесе

«Тяжёлый ETL кладёт дашборды — что делать?» Это классический сценарий, ради которого и придуман WLM. Хороший ответ идёт по нарастающей: сначала развести нагрузки по очередям с разной долей ресурсов, затем расставить приоритеты (дашбордам — выше), а в пределе — вынести ETL и дашборды на отдельные warehouse/кластеры, чтобы изолировать их полностью.

«В чём разница между приоритетом и лимитом конкурентности?» Приоритет решает, кому достанутся ресурсы при конкуренции, а лимит конкурентности — сколько запросов вообще может идти одновременно. Приоритет перераспределяет, лимит ограничивает. Часто их настраивают вместе.

«Как изолировать нагрузки в Snowflake?» Через отдельные виртуальные склады под каждую нагрузку с auto-suspend и auto-resume. Это отличает Snowflake от классического Redshift, где изоляция строится на очередях и слотах WLM внутри одного кластера. Разобрать такие вопросы по DWH с готовыми ответами можно в Карьернике.

Частые ошибки

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

Слишком высокий лимит конкурентности. Кажется, что больше одновременных запросов — всегда лучше, но за порогом ресурсов они начинают мешать друг другу, и каждый выполняется медленнее. Иногда снизить конкурентность полезнее, чем повысить.

Неверные приоритеты. Дать ETL высокий приоритет «потому что он важный» — ошибка. Высокий приоритет нужен тому, кого ждёт живой человек (дашборды, интерактивная аналитика), а фоновый пересчёт вполне переживёт низкий.

Изоляция без учёта стоимости. Развести всё по отдельным warehouse — надёжно, но за каждый склад платят. Без auto-suspend простаивающие ресурсы жгут бюджет впустую, поэтому изоляцию всегда обсуждают вместе с оптимизацией затрат.

Связанные темы

• DWH cost optimization для DE
• Capacity planning для SA
• Snowflake vs BigQuery для DE
• DWH ClickHouse для DE
• Подготовка к собесу Data Engineer

FAQ

Чем очереди отличаются от приоритетов?

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

Как WLM реализован в Snowflake против Redshift?

В Redshift WLM встроен в кластер: настраиваются очереди и слоты внутри одного вычислительного ресурса. В Snowflake compute и storage разделены, поэтому изоляцию делают через отдельные виртуальные склады — каждая нагрузка получает свой warehouse. Плюс Snowflake — склады масштабируются и останавливаются независимо, минус — за каждый активный склад платят отдельно.

Как выбрать лимит конкурентности?

Отталкивайтесь от профиля нагрузки, а не от «чем больше, тем лучше». Много мелких быстрых запросов (дашборды) выигрывают от высокого лимита. Несколько тяжёлых ETL-запросов — наоборот: высокий лимит заставит их конкурировать за память и замедлит все. Подбирают итеративно, глядя на время ожидания в очереди и время выполнения.

Что такое resource pool в ClickHouse?

Это механизм квотирования: группе пользователей выделяется ограничение по памяти, числу потоков и одновременных запросов. Он играет ту же роль, что очереди WLM в Redshift, — не даёт одному тяжёлому запросу или одной команде отъесть ресурсы у остальных.

Это официальная информация?

Нет. Статья основана на документации Snowflake, Amazon Redshift, ClickHouse и Greenplum, а также на опыте кандидатов. Конкретные механизмы и их названия зависят от версии и конфигурации хранилища.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.