Эластичный вычислительный узел

Эластичные вычислительные узлы — это особый тип узлов BE, которые не хранят данные и отвечают только за вычисления. Поэтому вычислительные узлы можно рассматривать как узлы BE без состояния, которые легко добавлять и удалять.

В сценариях анализа данных lakehouse эластичные вычислительные узлы можно использовать для запросов к внешним источникам данных, таким как Hive, Iceberg, Hudi, Paimon, JDBC и другим. Doris не отвечает за хранение данных внешних источников, поэтому эластичные вычислительные узлы позволяют легко наращивать вычислительные мощности для работы с ними. Кроме того, для вычислительных узлов можно настроить каталоги кеша, чтобы кешировать часто используемые данные из внешних источников и дополнительно ускорять чтение.

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

• Режим совмещения хранения и вычислений: по умолчанию узлы BE имеют тип mix и отвечают как за хранение, так и за вычисления. Можно развернуть отдельную группу узлов BE типа computation, предназначенных для запросов к внешним таблицам, и эластично увеличивать или уменьшать их количество, не затрагивая хранение данных внутренних таблиц.
• Режим разделения хранения и вычислений: узлы BE уже не имеют состояния, и их количество можно легко увеличивать или уменьшать. При этом части узлов BE можно назначить тип computation, чтобы выделить их для запросов к озеру данных (внешним таблицам) и изолировать эту нагрузку от узлов BE, обслуживающих запросы к внутренним таблицам.

Важно

• Узлы BE типа computation обслуживают только запросы к озеру данных (внешним таблицам); они НЕ обслуживают запросы к внутренним таблицам. Если всем узлам BE в кластере назначен тип computation, запросы к внутренним таблицам завершатся с ошибкой has no queryable replicas. Убедитесь, что в кластере сохранён хотя бы один узел BE типа mix для обслуживания запросов к внутренним таблицам.
• В режиме разделения хранения и вычислений столбец NodeRole в выводе SHOW BACKENDS всегда содержит mix, независимо от значения be_node_role в файле конфигурации BE. Это известная особенность отображения; фактическая роль узла по-прежнему определяется значением be_node_role в be.conf.

Использование вычислительных узлов

Типы узлов BE

В режиме совмещения хранения и вычислений узлы BE делятся на два типа:

• Mix

  Смешанные узлы. Это тип узлов BE по умолчанию. Такие узлы участвуют как в вычислениях, так и в хранении данных внутренних таблиц Doris.

• Computation

  Эластичные вычислительные узлы. Они не хранят данные и отвечают только за вычисления.

Добавление вычислительных узлов

Добавьте следующую настройку в файл конфигурации BE be.conf:

be_node_role=computation

Затем запустите узел BE, и он будет работать как узел типа Computation.

После этого можно подключиться к Doris и выполнить:

ALTER SYSTEM ADD BACKEND

чтобы добавить этот узел BE. После успешного добавления тип узла будет указан как computation в столбце NodeRole в выводе SHOW BACKENDS.

Использование вычислительных узлов

Чтобы включить использование вычислительных узлов и управлять их поведением, настройте следующие параметры в файле конфигурации FE fe.conf:

Имя параметра	Описание
prefer_compute_node_for_external_table	Значение по умолчанию — false. Если установлено true, запросы к внешним таблицам будут преимущественно назначаться вычислительным узлам. Если установлено false, запросы к внешним таблицам будут назначаться любым узлам BE. Если в кластере нет вычислительных узлов, этот параметр ни на что не влияет.
min_backend_num_for_external_table	Действует, только если для prefer_compute_node_for_external_table установлено true. Если количество вычислительных узлов в кластере меньше этого значения, при распределении запросов к внешним таблицам система попытается дополнительно задействовать смешанные узлы, чтобы общее количество узлов достигло указанного значения. Если количество вычислительных узлов в кластере больше этого значения, запросы к внешним таблицам будут назначаться только вычислительным узлам. До версии 2.0 включительно значение этого параметра по умолчанию составляло 3. После версии 2.1 значение по умолчанию — -1, что означает использование только имеющихся вычислительных узлов.

Дополнительное пояснение к min_backend_num_for_external_table:

Предположим, что в кластере есть 3 вычислительных узла и 5 смешанных узлов.

Если для min_backend_num_for_external_table установлено значение, меньшее или равное 3, запросы к внешним таблицам будут использовать только 3 вычислительных узла. Если установлено значение больше 3, например 6, то для выполнения запросов к внешним таблицам будут использоваться 3 вычислительных узла и ещё 3 смешанных узла.

Таким образом, этот параметр в основном задаёт минимальное количество узлов BE, которые могут участвовать в вычислениях для внешних таблиц, причём предпочтение отдаётся вычислительным узлам. Увеличение значения параметра позволяет задействовать больше узлов BE, включая смешанные узлы, в обработке запросов к внешним таблицам; уменьшение значения позволяет ограничить количество узлов BE, участвующих в обработке таких запросов.

Примечание:

1. После версии 2.1 для min_backend_num_for_external_table можно установить -1. В предыдущих версиях значение этого параметра должно быть положительным числом. Параметр действует только при prefer_compute_node_for_external_table = true.

2. Если значение min_backend_num_for_external_table превышает общее количество узлов BE, будут выбраны все доступные узлы BE.

3. Указанные выше параметры можно изменять динамически с помощью команды ADMIN SET FRONTEND CONFIG, без перезапуска узла FE. Настройку необходимо выполнить на всех узлах FE. Другой вариант — добавить настройки в fe.conf и перезапустить узел FE.

Рекомендации по использованию

Изоляция ресурсов и эластичное масштабирование федеративных запросов

В сценариях федеративных запросов пользователи могут развернуть отдельную группу вычислительных узлов для запросов к данным внешних таблиц. Это позволяет изолировать нагрузку от запросов к внешним таблицам, например масштабного анализа данных в Hive, от нагрузки от запросов к внутренним таблицам, например быстрого анализа данных с низкой задержкой.

При этом вычислительные узлы, как узлы BE без состояния, легко масштабировать, увеличивая или уменьшая их количество. Например, с помощью k8s можно развернуть кластеры эластичных вычислительных узлов, задействовать больше узлов для анализа данных озера в периоды пиковой нагрузки и быстро сокращать их количество при снижении нагрузки, чтобы уменьшить затраты.

Частые вопросы

1. Можно ли преобразовывать смешанные узлы в вычислительные и наоборот?

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

2. Нужно ли настраивать каталоги хранения данных для вычислительных узлов?

Да. В каталоге хранения данных вычислительных узлов хранятся только служебные файлы самого узла BE, например cluster_id, и некоторые временные файлы, создаваемые во время работы. Пользовательские данные в нём не хранятся.

Каталог хранения вычислительных узлов требует лишь небольшого объёма дискового пространства (порядка МБ) и может быть удалён в любой момент вместе с узлом без ущерба для пользовательских данных.

3. Можно ли настроить каталоги файлового кеша для вычислительных и смешанных узлов?

Файловый кеш ускоряет повторные запросы к тем же данным, кешируя файлы данных из удалённых систем хранения (HDFS или объектного хранилища), к которым недавно выполнялись обращения.

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

4. Нужно ли выводить вычислительные узлы из эксплуатации с помощью операции DECOMMISION?

Нет. Вычислительные узлы можно удалять напрямую с помощью операции DROP BACKEND.

5. Почему запрос к внутренней таблице на вычислительном узле завершается с ошибкой has no queryable replicas?

Это ожидаемое поведение. Узлы BE типа computation не обслуживают запросы к внутренним таблицам. Если все узлы BE в кластере имеют тип computation (или узлов типа mix в кластере недостаточно для размещения реплик внутренней таблицы), запросы к внутренним таблицам завершатся с этой ошибкой.

Решение: сохраните или добавьте в кластере хотя бы один узел BE типа mix для обслуживания запросов к внутренним таблицам.

6. В режиме разделения хранения и вычислений значение NodeRole в выводе SHOW BACKENDS всегда равно mix. Означает ли это, что настройка be_node_role = computation не применилась?

Нет. В режиме разделения хранения и вычислений столбец NodeRole в выводе SHOW BACKENDS всегда отображается со значением mix. Это известная особенность отображения, которая не связана с фактическим значением be_node_role в be.conf. Параметр действует и в режиме разделения хранения и вычислений: узлы, настроенные как computation, будут участвовать только в запросах к внешним таблицам.