Resource Group: физическая изоляция и управление группами ресурсов для узлов BE
Resource Group представляет собой механизм физической изоляции различных рабочих нагрузок в архитектуре с совмещением хранения и вычислений. С помощью тегов узлы BE разделяются на несколько групп ресурсов, а реплики таблиц распределяются между этими группами. Таким образом, разные пользователи или направления бизнеса получают доступ к собственным выделенным вычислительным ресурсам и ресурсам хранения, не мешая друг другу.
Принцип работы
По сути, Resource Group представляет собой политику размещения реплик таблиц. Основной механизм работает следующим образом:
- Теги разделяют узлы BE на группы, каждая из которых определяется именем тега, например
group_aилиgroup_b. - Разные реплики таблицы размещаются в разных группах ресурсов. Например, все 3 реплики table1 находятся в group_a, а из 4 реплик table2 2 находятся в group_a и ещё 2 в group_b.
- При выполнении запроса привязанная к пользователю группа ресурсов ограничивает его доступ репликами и вычислительными ресурсами узлов этой группы.
Преимущества и ограничения:
| Аспект | Описание |
|---|---|
| Изоляция сбоев | Разные группы ресурсов используют независимые узлы BE. Отказ узла BE в одной группе не влияет на запросы в других группах |
| Ограничения загрузки | Для загрузки требуется успешная запись в несколько реплик. Если оставшиеся реплики не обеспечивают выполнение требования Quorum, загрузка всё равно завершается ошибкой |
| Затраты на хранение | Каждой группе ресурсов нужна как минимум одна реплика таблицы. Чем больше групп ресурсов, тем больше реплик хранится |
Типичные сценарии использования
| Сценарий | Описание |
|---|---|
| Изоляция чтения и записи | Разделите кластер на две группы ресурсов: Online и Offline. Online обрабатывает большое число параллельных запросов с низкой задержкой, а Offline выполняет задания ETL. Данные хранятся в 3 репликах: 2 в группе Online и 1 в группе Offline |
| Изоляция направлений бизнеса | Несколько направлений бизнеса не используют общие данные. Выделите каждому направлению независимую группу ресурсов. Это равнозначно объединению нескольких физических кластеров в один большой кластер с единым управлением |
| Изоляция пользователей | Несколько пользователей работают с одной и той же таблицей бизнес-данных, но получают независимые группы ресурсов, чтобы избежать конкуренции за ресурсы. Создайте несколько реплик таблицы, разместите каждую в соответствующей группе ресурсов и привяжите каждого пользователя к его собственной группе |
Настройка группы ресурсов
Предварительные требования
- Кластер Doris, развёрнутый в режиме с совмещением хранения и вычислений и содержащий несколько узлов BE.
- Привилегия
ALTER SYSTEM, которой обычно обладает пользователь admin.
Общий порядок действий
- Назначьте узлам BE теги, чтобы разделить их на группы ресурсов.
- При создании или изменении таблицы задайте политику распределения реплик между группами ресурсов.
- Привяжите пользователей к группам ресурсов, чтобы ограничить область выполнения их запросов.
Шаг 1: назначение тегов узлам BE
Предположим, что текущий кластер содержит 6 узлов BE (от host1 до host6). Изначально все узлы принадлежат группе ресурсов по умолчанию (Default).
Разделите эти 6 узлов на 3 группы ресурсов:
alter system modify backend "host1:9050" set ("tag.location" = "group_a");
alter system modify backend "host2:9050" set ("tag.location" = "group_a");
alter system modify backend "host3:9050" set ("tag.location" = "group_b");
alter system modify backend "host4:9050" set ("tag.location" = "group_b");
alter system modify backend "host5:9050" set ("tag.location" = "group_c");
alter system modify backend "host6:9050" set ("tag.location" = "group_c");
После выполнения команд узлы host[1-2] принадлежат group_a, узлы host[3-4] принадлежат group_b, а узлы host[5-6] принадлежат group_c.
Примечание: узел BE может принадлежать только одной группе ресурсов.
Шаг 2: распределение реплик по группам ресурсов
После определения групп ресурсов укажите, сколько реплик будет храниться в каждой группе, задав свойство replication_allocation при создании таблицы.
Пример: разместите 3 реплики UserTable в 3 разных группах ресурсов:
create table UserTable
(k1 int, k2 int)
distributed by hash(k1) buckets 1
properties(
"replication_allocation"="tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"
)
После выполнения команды данные UserTable хранятся в виде 3 реплик на узлах групп group_a, group_b и group_c соответственно.
Текущее разделение узлов и распределение данных выглядит следующим образом:
┌────────────────────────────────────────────────────┐
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ host1 │ │ host2 │ │
│ │ ┌─────────────┐ │ │ │ │
│ group_a │ │ replica1 │ │ │ │ │
│ │ └─────────────┘ │ │ │ │
│ │ │ │ │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
├────────────────────────────────────────────────────┤
├────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ host3 │ │ host4 │ │
│ │ │ │ ┌─────────────┐ │ │
│ group_b │ │ │ │ replica2 │ │ │
│ │ │ │ └─────────────┘ │ │
│ │ │ │ │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
├────────────────────────────────────────────────────┤
├────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ host5 │ │ host6 │ │
│ │ │ │ ┌─────────────┐ │ │
│ group_c │ │ │ │ replica3 │ │ │
│ │ │ │ └─────────────┘ │ │
│ │ │ │ │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
└────────────────────────────────────────────────────┘
Настройка единой политики размещения реплик на уровне базы данных
Если база данных содержит много таблиц, изменять политику размещения реплик для каждой таблицы по отдельности неудобно. Doris позволяет задать единую политику распределения реплик на уровне базы данных. Настройки таблицы имеют приоритет над настройками базы данных.
Пример: db1 содержит 4 таблицы, причём для table1 нужна отдельная политика размещения реплик, а остальные 3 таблицы используют политику базы данных по умолчанию.
Создайте db1 с политикой размещения реплик по умолчанию group_c:1, group_b:2:
CREATE DATABASE db1 PROPERTIES (
"replication_allocation" = "tag.location.group_c:1, tag.location.group_b:2"
)
Создайте table1 и переопределите политику, указав group_a:1, group_b:2:
CREATE TABLE table1
(k1 int, k2 int)
distributed by hash(k1) buckets 1
properties(
"replication_allocation"="tag.location.group_a:1, tag.location.group_b:2"
)
В операторах CREATE TABLE для table2, table3 и table4 не нужно указывать replication_allocation: они автоматически наследуют политику db1.
Изменение политики распределения реплик базы данных не влияет на существующие таблицы.
Шаг 3: привязка пользователей к группам ресурсов
Используйте оператор set property, чтобы разрешить пользователю выполнять запросы только на узлах указанных групп ресурсов:
set property for 'user1' 'resource_tags.location' = 'group_a';
set property for 'user2' 'resource_tags.location' = 'group_b';
set property for 'user3' 'resource_tags.location' = 'group_a, group_b, group_c';
После такой настройки пользователь user1 при запросах к UserTable обращается только к репликам на узлах group_a и использует только вычислительные ресурсы group_a; пользователь user3 может использовать реплики и вычислительные ресурсы любой группы ресурсов.
Различия между версиями:
| Версия | Поведение по умолчанию |
|---|---|
| 2.0.2 и более ранние | Если свойство пользователя resource_tags.location пусто, ограничения по тегам на него не распространяются и он может использовать любую группу ресурсов |
| 2.0.3 и более поздние | Обычные пользователи по умолчанию могут использовать только группу ресурсов default; пользователи root и admin могут использовать любую группу ресурсов |
После изменения свойства resource_tags.location пользователю необходимо переподключиться, чтобы изменение вступило в силу.
Назначение групп ресурсов для заданий загрузки
Ресурсы, используемые заданиями загрузки (включая INSERT, Broker Load, Routine Load, Stream Load и другие), делятся на две категории:
| Тип ресурсов | Назначение | Ограничиваются группой ресурсов |
|---|---|---|
| Вычислительные ресурсы | Чтение данных из источников, преобразование и распределение данных | Да. Resource Group ограничивает набор используемых вычислительных ресурсов |
| Ресурсы записи | Кодирование, сжатие и запись данных на диск | Нет. Ресурсы записи определяются узлами, на которых находятся реплики, и не могут быть ограничены |
Поскольку запись должна выполняться на узлах, где находятся реплики данных, а вычислительные ресурсы можно выбирать на любых узлах, Resource Group может ограничивать только вычислительную часть задания загрузки.