Это углубленное введение в возможности изоляции рабочей нагрузки . Но прежде всего, почему и когда вам нужна изоляция рабочей нагрузки? Если вы столкнулись с какой-либо из следующих ситуаций, читайте дальше, и вы найдете решение: Apache Doris У вас есть разные бизнес-отделы или арендаторы, использующие один и тот же кластер, и вы хотите предотвратить взаимодействие рабочих нагрузок. У вас есть задачи запросов с разными уровнями приоритета, и вы хотите отдать приоритет критически важным задачам (таким как анализ данных в реальном времени и онлайн-транзакции) с точки зрения ресурсов и выполнения. Вам нужна изоляция рабочей нагрузки, но также вам нужны высокая рентабельность и коэффициент использования ресурсов. Apache Doris поддерживает изоляцию рабочей нагрузки на основе тега ресурса и группы рабочей нагрузки. Тег ресурса изолирует ресурсы ЦП и памяти для различных рабочих нагрузок на уровне серверных узлов, а механизм группы рабочей нагрузки может дополнительно разделить ресурсы внутри внутреннего узла для более эффективного использования ресурсов. https://www.youtube.com/watch?v=Wd3l5C4k8Ok&embedable=true Изоляция ресурса на основе тега ресурса Начнем с архитектуры Apache Doris. У Doris есть два : внешние (FE) и внутренние (BE). Узлы FE хранят метаданные, управляют кластерами, обрабатывают запросы пользователей и анализируют планы запросов, а узлы BE отвечают за вычисления и хранение данных. Таким образом, узлы BE являются основными потребителями ресурсов. типа узлов Основная идея решения изоляции на основе тегов ресурсов состоит в том, чтобы разделить вычислительные ресурсы на группы путем назначения тегов узлам BE в кластере, где узлы BE с одним и тем же тегом составляют группу ресурсов. Группу ресурсов можно рассматривать как единицу хранения и вычислений данных. Для данных, поступающих в Doris, система будет записывать реплики данных в разные группы ресурсов в соответствии с конфигурациями. Запросы также будут назначены для выполнения соответствующим . группам ресурсов Например, если вы хотите разделить рабочие нагрузки чтения и записи в кластере 3-BE, вы можете выполнить следующие действия: : привяжите 2 BE к тегу «Чтение» и 1 BE к тегу «Запись». Назначьте теги ресурсов узлам BE . Предположим, что в таблице 1 есть 3 реплики, привяжите 2 из них к тегу «Чтение» и 1 к тегу «Запись». Данные, записанные в реплику 3, будут синхронизированы с репликой 1 и репликой 2, а процесс синхронизации данных потребляет мало ресурсов BE 1 и BE2. Назначьте теги ресурсов репликам данных . Запросы, включающие тег «Чтение» в свои SQL-запросы, будут автоматически перенаправляться на узлы, помеченные тегом «Чтение» (в данном случае BE 1 и BE 2). Для задач записи данных вам также необходимо назначить им тег «Запись», чтобы их можно было направить на соответствующий узел (BE 3). Таким образом, между рабочими нагрузками чтения и записи не будет конфликтов за ресурсы, за исключением накладных расходов на синхронизацию данных от реплики 3 к репликам 1 и 2. Назначьте группы рабочей нагрузки тегам ресурсов Resource Tag также обеспечивает в Apache Doris. Например, ресурсы вычислений и хранения, помеченные как «Пользователь А», предназначены только для пользователя А, а ресурсы, помеченные как «Пользователь Б», предназначены исключительно для пользователя Б. Именно так Doris реализует мультиарендную изоляцию ресурсов с помощью тегов ресурсов на стороне BE. . мультитенантность Разделение узлов BE на группы обеспечивает : высокий уровень изоляции ЦП, память и устройства ввода-вывода разных арендаторов физически изолированы. На одного арендатора никогда не повлияют сбои (например, сбои процесса) другого арендатора. Но у него есть несколько минусов: При разделении чтения и записи, когда запись данных прекращается, узлы BE, помеченные как «Запись», становятся бездействующими. Это снижает общее использование кластера. В условиях мультитенантности, если вы хотите дополнительно изолировать различные рабочие нагрузки одного и того же арендатора, назначив каждому из них отдельные узлы BE, вам придется столкнуться со значительными затратами и низким уровнем использования ресурсов. Количество арендаторов привязано к количеству реплик данных. Итак, если у вас 5 арендаторов, вам понадобится 5 реплик данных. Это огромная избыточность хранилища. . Чтобы улучшить эту ситуацию, мы предоставляем решение для изоляции рабочей нагрузки на основе группы рабочей нагрузки в Apache Doris 2.0.0 и усовершенствовали ее в Apache Doris 2.1.0 Изоляция рабочей нагрузки на основе группы рабочей нагрузки Решение на основе реализует более детальное разделение ресурсов. Он дополнительно разделяет ресурсы ЦП и памяти внутри процессов на узлах BE, а это означает, что запросы на одном узле BE могут быть в некоторой степени изолированы друг от друга. Это позволяет избежать конкуренции за ресурсы в процессах BE и оптимизирует использование ресурсов. группы рабочей нагрузки Пользователи могут связывать запросы с группами рабочей нагрузки, тем самым ограничивая процент ресурсов ЦП и памяти, которые может использовать запрос. При высоких нагрузках на кластер Doris может автоматически уничтожать наиболее ресурсоемкие запросы в группе рабочей нагрузки. При низкой нагрузке на кластер Doris может разрешить нескольким группам рабочей нагрузки совместно использовать простаивающие ресурсы. Doris поддерживает как мягкое ограничение ЦП, так и жесткое ограничение ЦП. Мягкое ограничение позволяет группам рабочей нагрузки преодолевать ограничения и использовать простаивающие ресурсы, обеспечивая более эффективное использование. Жесткое ограничение — это жесткая гарантия стабильной производительности, поскольку оно предотвращает взаимное влияние групп рабочей нагрузки. (Мягкое ограничение ЦП и жесткое ограничение ЦП противоречат друг другу. Вы можете выбирать между ними в зависимости от вашего собственного варианта использования.) Его отличия от решения на основе тегов ресурсов включают в себя: Группы рабочей нагрузки формируются внутри процессов. Несколько групп рабочей нагрузки конкурируют за ресурсы в пределах одного узла BE. Распределение реплик данных не рассматривается, поскольку группа рабочей нагрузки — это всего лишь способ управления ресурсами. Мягкий лимит процессора Мягкое ограничение ЦП реализуется параметром , который концептуально аналогичен весам. Группам рабочей нагрузки с более высоким значением будет выделено больше процессорного времени в течение временного интервала. cpu_share cpu_share Например, если группа A настроена с параметром , равным 1, а группа B — 9. В течение 10-секундного интервала, когда и группа A, и группа B полностью загружены, группа A и группа B смогут потреблять 1 с и 9 секунд процессорного времени соответственно. cpu_share В реальных случаях не все рабочие нагрузки в кластере работают на полную мощность. В соответствии с мягким ограничением, если у группы B низкая или нулевая рабочая нагрузка, то группа A сможет использовать все десятки процессорного времени, тем самым увеличивая общую загрузку ЦП в кластере. Мягкое ограничение обеспечивает гибкость и более высокий коэффициент использования ресурсов. С другой стороны, это может вызвать колебания производительности. Жесткий лимит процессора Жесткое ограничение ЦП в Apache Doris 2.1.0 предназначено для пользователей, которым требуется стабильная производительность. Проще говоря, жесткий лимит ЦП определяет, что группа рабочей нагрузки не может использовать больше ресурсов ЦП, чем ее лимит, независимо от того, есть ли свободные ресурсы ЦП или нет. Вот как это работает: Предположим, что для группы A установлено , а для группы B — значение . Если и группа A, и группа B работают с полной нагрузкой, группа A и группа B будут использовать соответственно 10% и 90% общего времени ЦП. Разница заключается в том, когда снижается загруженность группы Б. В таких случаях, независимо от того, насколько высока нагрузка запросов группы A, она не должна использовать более 10% выделенных ей ресурсов ЦП. cpu_hard_limit=10% cpu_hard_limit=90% В отличие от мягкого ограничения, жесткое ограничение гарантирует стабильную производительность системы за счет гибкости и возможности более высокого коэффициента использования ресурсов. Ограничение ресурсов памяти Память узла BE состоит из следующих частей: Зарезервированная память для операционной системы. Память, потребляемая не-запросами, не учитывается в статистике памяти группы рабочей нагрузки. Память потребляется запросами, включая запись данных. Это можно отслеживать и контролировать с помощью группы рабочей нагрузки. Параметр определяет максимальный (%) объем памяти, доступный группе рабочей нагрузки в процессе BE. Это также влияет на приоритет групп ресурсов. memory_limit В исходном состоянии группе ресурсов с высоким приоритетом будет выделено больше памяти. Установив , вы можете разрешить группам ресурсов занимать больше памяти, чем указано в ограничениях, при наличии свободного места. Когда памяти не хватает, Дорис отменит задачи, чтобы освободить выделенные ими ресурсы памяти. В этом случае система сохранит как можно больше ресурсов памяти для групп ресурсов с высоким приоритетом. enable_memory_overcommit Очередь запросов Бывает, что кластер берет на себя больше нагрузок, чем может выдержать. В этом случае отправка новых запросов будет не только бесплодной, но и будет мешать выполнению текущих запросов. Чтобы улучшить эту ситуацию, Apache Doris предоставляет механизм . Пользователи могут установить ограничение на количество запросов, которые могут одновременно выполняться в кластере. Запрос будет отклонен, когда очередь запросов заполнена или по истечении таймаута ожидания, что обеспечивает стабильность системы при высоких нагрузках. очереди запросов Механизм очереди запросов включает в себя три параметра: , . max_concurrency max_queue_size queue_timeout Тесты Чтобы продемонстрировать эффективность мягкого и жесткого ограничения ЦП, мы провели несколько тестов. Окружающая среда: одна машина, 16 ядер, 64 ГБ Развертывание: 1 FE + 1 BE. Набор данных: ClickBench, TPC-H Инструмент нагрузочного тестирования: Apache JMeter. Тест мягкого ограничения процессора Запустите два клиента и непрерывно отправляйте запросы (ClickBench Q23) с использованием групп рабочей нагрузки и без него соответственно. Обратите внимание, что кэш страниц следует отключить, чтобы он не влиял на результаты теста. Сравнивая пропускную способность двух клиентов в обоих тестах, можно сделать вывод, что: два клиента потребляют ресурсы ЦП на равной основе. Без настройки групп рабочей нагрузки и установив для значение 2:1, соотношение пропускной способности двух клиентов составит 2:1. При более высоком значении Клиенту 1 предоставляется более высокая доля ресурсов ЦП и он обеспечивает более высокую пропускную способность. Настроив группы рабочей нагрузки cpu_share cpu_share Тест жесткого ограничения процессора Запустите клиент, установите для группы рабочей нагрузки и запустите ClickBench Q23 в течение 5 минут при уровне параллелизма 1, 2 и 4 соответственно. cpu_hard_limit=50% По мере увеличения параллелизма запросов коэффициент использования ЦП остается на уровне около 800 %, что означает, что используются 8 ядер. На 16-ядерной машине это , что вполне ожидаемо. Кроме того, поскольку наложены жесткие ограничения на ЦП, ожидаемым результатом также является увеличение задержки TP99 по мере увеличения параллелизма. загрузка 50 % Тестирование в моделируемой производственной среде В реальном использовании пользователи особенно обеспокоены задержкой запросов, а не просто пропускной способностью запросов, поскольку задержка более ощутима в пользовательском опыте. Вот почему мы решили проверить эффективность Workload Group в моделируемой производственной среде. Мы выбрали набор SQL, состоящий из запросов, которые должны быть выполнены в течение 1 с (ClickBench Q15, Q17, Q23 и TPC-H Q3, Q7, Q19), включая агрегирование одной таблицы и запросы на соединение. Размер набора данных TPC-H составляет 100 ГБ. Аналогично мы проводим тесты с настройкой групп рабочей нагрузки и без нее. Как показывают результаты: (сравнение тестов 1 и 2): при подключении параллельного соединения с клиентом 2 оба клиента испытывают увеличение задержки запроса в 2–3 раза. Без группы рабочей нагрузки (сравнение тестов 3 и 4). По мере увеличения параллельности клиента 2 колебания производительности клиента 1 становятся намного меньшими, что является доказательством того, насколько эффективно он защищен изоляцией рабочей нагрузки. Настройка группы рабочей нагрузки Рекомендации и планы Решение на основе тегов ресурсов представляет собой тщательный план изоляции рабочей нагрузки. Решение на основе группы рабочей нагрузки обеспечивает лучший баланс между изоляцией и использованием ресурсов и дополняется механизмом очереди запросов для гарантии стабильности. Итак, какой из них выбрать для вашего варианта использования? Вот наша рекомендация: : для случаев использования, когда разные бизнес-подразделения используют один и тот же кластер, поэтому ресурсы и данные физически изолированы для разных арендаторов. Тег ресурса : для случаев использования, когда один кластер выполняет различные рабочие нагрузки запросов для гибкого распределения ресурсов. Группа рабочей нагрузки В будущих выпусках мы продолжим улучшать взаимодействие с пользователем группы рабочей нагрузки и функции очереди запросов: Освобождение памяти путем отмены запросов — жестокий метод. Мы планируем реализовать это путем разделения диска, что повысит стабильность производительности запросов. Поскольку память, потребляемая не-запросами в BE, не включается в статистику памяти группы рабочей нагрузки, пользователи могут наблюдать несоответствие между использованием памяти процессом BE и использованием памяти группой рабочей нагрузки. Мы разберемся в этом вопросе, чтобы избежать путаницы. В механизме очереди запросов нагрузка на кластер контролируется путем установки максимального параллелизма запросов. Мы планируем включить динамический максимальный параллелизм запросов в зависимости от доступности ресурсов на BE. Это создает противодавление на стороне клиента и, таким образом, повышает доступность Doris, когда клиенты продолжают отправлять большие нагрузки. Основная идея Resource Tag — группировать узлы BE, а идея Workload Group — дальнейшее разделение ресурсов одного узла BE. Чтобы понять эти идеи, пользователям сначала необходимо узнать о концепции узлов BE в Doris. Однако с точки зрения эксплуатации пользователям нужно только понимать процент потребления ресурсов каждой из их рабочих нагрузок и какой приоритет они должны иметь, когда нагрузка кластера насыщена. Таким образом, мы попытаемся найти способ сгладить кривую обучения пользователей, например, сохранив концепцию узлов BE в «черном ящике». Для получения дополнительной помощи по изоляции рабочей нагрузки в Apache Doris присоединяйтесь . к сообществу Apache Doris
