Практика использования Stream Load в сложных сетевых средах

В сложных сетевых средах, таких как публичные и частные облака, а также развертывания с несколькими кластерами Kubernetes, загрузка данных сопряжена с особыми трудностями. Балансировщики нагрузки (LB) и сетевая изоляция (доступ внутри VPC и извне) влияют как на гибкость маршрутизации запросов, так и на эффективность пакетной обработки.

Apache Doris решает эти задачи с помощью следующих двух возможностей:

• Поддержка нескольких конечных точек для Stream Load: позволяет гибко настраивать несколько сетевых конечных точек для узлов BE.
• Оптимизация планирования Group Commit при использовании LB: обеспечивает эффективное объединение запросов в пакеты даже после их прохождения через балансировщик нагрузки.

Требование к версии: необходим Doris 3.1.0 или более поздней версии.

Общие сведения

Stream Load

Stream Load представляет собой способ загрузки данных по HTTP с поддержкой таких форматов, как JSON и CSV. Загрузку инициирует клиент: он отправляет данные напрямую на узлы BE через HTTP-запросы, минуя протокол MySQL. Такой подход обеспечивает высокий параллелизм, низкую задержку и высокую пропускную способность, поэтому хорошо подходит для частой записи небольших пакетов данных.

Group Commit

Group Commit повышает пропускную способность, объединяя на стороне сервера множество небольших запросов в крупные пакетные операции. Это сокращает дисковый ввод-вывод, конкуренцию за блокировки и накладные расходы на Compaction. Для максимальной эффективности Group Commit запросы к одной таблице должны направляться на один и тот же узел BE.

Основные трудности в сложных сетевых средах

В облачных средах балансировщики нагрузки случайным образом распределяют запросы между узлами BE, нарушая «привязку к узлу», от которой зависит Group Commit. В результате запросы к одной таблице попадают на разные узлы. Тесты показывают, что из-за этого при высоком параллелизме пропускная способность может снизиться на 20-50%.

Поддержка нескольких конечных точек для Stream Load

Три типа адресов BE

Узел Doris BE поддерживает три типа адресов для разных сценариев сетевого доступа:

Тип адреса	Назначение	Пример
be_host	Внутреннее взаимодействие в кластере	192.168.1.1:9050
public_endpoint	Доступ из внешней публичной сети (через LB или публичный IP-адрес)	11.10.20.12:8010
private_endpoint	Доступ внутри VPC или по IP-адресу Kubernetes Service	10.10.10.9:8020

Настройка конечных точек BE

Используйте операторы SQL, чтобы добавить или изменить сведения о конечных точках узла BE:

-- Add a BE node and configure its endpoints
ALTER SYSTEM ADD BACKEND '192.168.1.1:9050' PROPERTIES(
    'tag.public_endpoint' = '11.10.20.12:8010',
    'tag.private_endpoint' = '10.10.10.9:8020'
);

-- Modify the endpoints of an existing BE node
ALTER SYSTEM MODIFY BACKEND '192.168.1.1:9050' SET (
    'tag.public_endpoint' = '11.10.20.12:8010',
    'tag.private_endpoint' = '10.10.10.9:8020'
);

Политика перенаправления (redirect-policy)

Указав HTTP-заголовок redirect-policy в запросе Stream Load, можно выбрать конечную точку, на которую будет направлен запрос:

Политика	Поведение	Сценарии применения
direct	Направляет на be_host	Внутреннее взаимодействие с низкой задержкой, обмен между pod
public	Направляет на public_endpoint	Доступ из внешней публичной сети
private	Направляет на private_endpoint	Доступ внутри VPC или между кластерами
По умолчанию (пустое значение)	Автоматически выбирает конечную точку по имени хоста	Общие сценарии

Если redirect-policy не задан явно, FE автоматически выбирает конечную точку в следующем порядке:

1. Если имя хоста в запросе совпадает с именем хоста public_endpoint, запрос направляется на public_endpoint.
2. В противном случае, если настроен private_endpoint, запрос направляется на private_endpoint.
3. В остальных случаях используется be_host.

Пример запроса

curl --location-trusted -u user:pass \
    -H "redirect-policy: private" \
    -T data.csv \
    http://doris.example.com:8030/api/db_name/table_name/_stream_load

Принцип работы

1. Клиент отправляет запрос Stream Load на FE, при необходимости добавляя заголовок redirect-policy.
2. FE выбирает целевой адрес из пула адресов BE в соответствии с политикой.
3. FE возвращает HTTP-ответ перенаправления, указывающий на выбранную конечную точку.

Оптимизация планирования Group Commit при использовании LB

Механизм двухэтапной пересылки

Чтобы сохранить эффективность Group Commit при работе через балансировщик нагрузки, Doris использует механизм двухэтапной пересылки:

Этап 1: перенаправление FE

• FE выбирает подходящую конечную точку в соответствии с redirect-policy.
• FE определяет, какой узел BE должен обрабатывать целевую таблицу.
• Запрос перенаправляется через LB, который случайным образом отправляет его на один из узлов BE.

Этап 2: пересылка BE

• Если узел BE, получивший запрос (BE1), не является назначенным узлом для этой таблицы:
• BE1 пересылает запрос по внутренней сети через be_host на нужный узел BE (BE2).
• Благодаря этому все запросы к одной таблице поступают на один и тот же узел.

Пример запроса с включенным Group Commit

Чтобы включить нужный режим Group Commit, достаточно добавить параметр group_commit в заголовок запроса:

curl --location-trusted -u user:pass \
    -H "redirect-policy: private" \
    -H "group_commit: async_mode" \
    -T data.csv \
    http://doris.example.com:8030/api/db_name/table_name/_stream_load

Производительность

Накладные расходы на двухэтапную пересылку минимальны и составляют миллисекунды, а оптимизация пакетной обработки в Group Commit позволяет повысить пропускную способность на 20-50% при высоком параллелизме.

Типичные сценарии использования

Сценарий	Конфигурация	Преимущества
Загрузка логов в реальном времени	Group Commit + несколько конечных точек	Высокая пропускная способность + гибкая маршрутизация
Облачная BI	Внешний доступ через public_endpoint	Безопасный доступ для внешних пользователей
Взаимодействие между кластерами Kubernetes	private_endpoint вместе с IP-адресом Pod / Service	Эффективное взаимодействие между кластерами

Примечания

• Планирование конфигурации: убедитесь, что адреса конечных точек настроены правильно. В средах Kubernetes они должны соответствовать плану IP-адресации Service / Pod.
• Мониторинг: используйте инструменты мониторинга для отслеживания частоты пересылки и показателей производительности, обращая внимание на долю запросов, для которых задействуется двухэтапная пересылка.
• Требование к версии: необходим Doris 3.1.0 или более поздней версии.

Часто задаваемые вопросы

Вопрос 1: Когда нужно настраивать public_endpoint и private_endpoint?

Если между клиентами и узлами BE существует сетевая изоляция (например, клиенты находятся внутри и вне VPC или внутри и вне кластера Kubernetes), необходимо отдельно настроить public_endpoint для публичного/внешнего доступа и private_endpoint для внутреннего доступа/доступа внутри VPC. Это позволит клиентам из разных сетей корректно обращаться к узлам BE.

Вопрос 2: Работает ли Group Commit при использовании балансировщика нагрузки?

Да. Благодаря механизму двухэтапной пересылки Doris гарантирует, что даже при случайном распределении запросов балансировщиком LB узлы BE пересылают запросы к одной таблице на один и тот же узел, сохраняя преимущества пакетной обработки Group Commit.

Вопрос 3: Что произойдет, если не задать redirect-policy?

FE автоматически выбирает конечную точку по имени хоста в запросе: сначала проверяет совпадение с public_endpoint, затем выбирает private_endpoint, а в остальных случаях использует be_host.

Вопрос 4: Значительно ли двухэтапная пересылка увеличивает задержку?

Нет. Внутренняя пересылка между узлами BE добавляет лишь миллисекунды, что несущественно по сравнению с повышением пропускной способности на 20-50%, которое Group Commit обеспечивает при высоком параллелизме.

Устранение неполадок

Симптом	Возможная причина	Решение
Клиент не может обратиться к адресу BE после перенаправления	public_endpoint / private_endpoint не соответствует фактической сети	Исправьте конфигурацию конечных точек с помощью ALTER SYSTEM MODIFY BACKEND
Пропускная способность Stream Load недостаточна при высоком параллелизме	Group Commit не включен или запросы не проходят через двухэтапную пересылку	Добавьте group_commit: async_mode в заголовок запроса и проверьте сетевое соединение между узлами BE
Не удается загрузить данные между кластерами Kubernetes	Отсутствует private_endpoint или не указан redirect-policy	Настройте private_endpoint, указав IP-адрес Pod / Service, и задайте redirect-policy: private
Перенаправление по умолчанию ведет на неверную конечную точку	Правило сопоставления имени хоста не срабатывает ожидаемым образом	Явно укажите redirect-policy: public или private