Routine Load

Как можно улучшить производительность загрузки?

Метод 1: Увеличить фактический параллелизм задач загрузки путем разделения задания загрузки на как можно больше параллельных задач загрузки.

ВНИМАНИЕ

Этот метод может потреблять больше ресурсов CPU и вызывать слишком много версий tablet.

Фактический параллелизм задач загрузки определяется следующей формулой, состоящей из нескольких параметров, с верхним пределом в виде количества активных узлов BE или количества разделов для потребления.

min(alive_be_number, partition_number, desired_concurrent_number, max_routine_load_task_concurrent_num)

Описание параметров:

• alive_be_number: количество активных узлов BE.
• partition_number: количество разделов для потребления.
• desired_concurrent_number: желаемый параллелизм задач загрузки для задания Routine Load. Значение по умолчанию 3. Вы можете установить более высокое значение для этого параметра, чтобы увеличить фактический параллелизм задач загрузки.
  • Если вы еще не создали задание Routine Load, вам нужно установить этот параметр при использовании CREATE ROUTINE LOAD для создания задания Routine Load.
  • Если вы уже создали задание Routine Load, вам нужно использовать ALTER ROUTINE LOAD для изменения этого параметра.
• max_routine_load_task_concurrent_num: максимальный параллелизм задач по умолчанию для задания Routine Load. Значение по умолчанию 5. Этот параметр является динамическим параметром FE. Для получения дополнительной информации и метода конфигурации см. Конфигурация параметров.

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

Например, количество разделов для потребления равно 7, количество активных узлов BE равно 5, а max_routine_load_task_concurrent_num имеет значение по умолчанию 5. В этом случае, если вам нужно увеличить параллелизм задач загрузки до верхнего предела, вам нужно установить desired_concurrent_number равным 5 (значение по умолчанию 3). Тогда фактический параллелизм задач min(5,7,5,5) вычисляется как 5.

Для получения дополнительных описаний параметров см. CREATE ROUTINE LOAD.

Метод 2: Увеличить объем данных, потребляемых задачей Routine Load из одного или нескольких разделов.

ВНИМАНИЕ

Этот метод может вызвать задержку в загрузке данных.

Верхний предел количества сообщений, которые может потребить задача Routine Load, определяется либо параметром max_routine_load_batch_size, который означает максимальное количество сообщений, которые может потребить задача загрузки, либо параметром routine_load_task_consume_second, который означает максимальную продолжительность потребления сообщений. Как только задача загрузки потребляет достаточно данных, удовлетворяющих любому из требований, потребление завершается. Эти два параметра являются динамическими параметрами FE. Для получения дополнительной информации и метода конфигурации см. Конфигурация параметров.

Вы можете проанализировать, какой параметр определяет верхний предел объема данных, потребляемых задачей загрузки, просмотрев журнал в be/log/be.INFO. Увеличив этот параметр, вы можете увеличить объем данных, потребляемых задачей загрузки.

I0325 20:27:50.410579 15259 data_consumer_group.cpp:131] consumer group done: 41448fb1a0ca59ad-30e34dabfa7e47a0. consume time(ms)=3261, received rows=179190, received bytes=9855450, eos: 1, left_time: -261, left_bytes: 514432550, blocking get time(us): 3065086, blocking put time(us): 24855

Обычно поле left_bytes в журнале больше или равно 0, что указывает на то, что объем данных, потребляемых задачей загрузки, не превысил max_routine_load_batch_size в течение routine_load_task_consume_second. Это означает, что пакет запланированных задач загрузки может потребить все данные из Kafka без задержки в потреблении. В этом сценарии вы можете установить большее значение для routine_load_task_consume_second, чтобы увеличить объем данных, потребляемых задачей загрузки из одного или нескольких разделов.

Если поле left_bytes меньше 0, это означает, что объем данных, потребляемых задачей загрузки, достиг max_routine_load_batch_size в течение routine_load_task_consume_second. Каждый раз данные из Kafka заполняют пакет запланированных задач загрузки. Поэтому весьма вероятно, что в Kafka остались непотребленные данные, что вызывает задержку в потреблении. В этом случае вы можете установить большее значение для max_routine_load_batch_size.

Что делать, если результат SHOW ROUTINE LOAD показывает, что задание загрузки находится в состоянии PAUSED?

• Проверьте поле ReasonOfStateChanged и оно сообщает об ошибке Broker: Offset out of range.

  Анализ причины: Смещение потребителя задания загрузки не существует в разделе Kafka.

  Решение: Вы можете выполнить SHOW ROUTINE LOAD и проверить последнее смещение потребителя задания загрузки в параметре Progress. Затем вы можете проверить, существует ли соответствующее сообщение в разделе Kafka. Если оно не существует, это может быть потому, что

  • Смещение потребителя, указанное при создании задания загрузки, является смещением в будущем.
  • Сообщение по указанному смещению потребителя в разделе Kafka было удалено до того, как было потреблено заданием загрузки. Рекомендуется установить разумную политику очистки журналов Kafka и параметры, такие как log.retention.hours и log.retention.bytes, основываясь на скорости загрузки.

• Проверьте поле ReasonOfStateChanged и оно не сообщает об ошибке Broker: Offset out of range.

  Анализ причины: Количество строк с ошибками в задаче загрузки превышает порог max_error_number.

  Решение: Вы можете устранить неполадки и исправить проблему, используя сообщения об ошибках в полях ReasonOfStateChanged и ErrorLogUrls.

  • Если это вызвано неправильным форматом данных в источнике данных, вам нужно проверить формат данных и исправить проблему. После успешного исправления проблемы вы можете использовать RESUME ROUTINE LOAD для возобновления приостановленного задания загрузки.

  • Если это происходит потому, что Selena не может разобрать формат данных в источнике данных, вам нужно настроить порог max_error_number. Вы можете сначала выполнить SHOW ROUTINE LOAD для просмотра значения max_error_number, а затем использовать ALTER ROUTINE LOAD для увеличения порога. После изменения порога вы можете использовать RESUME ROUTINE LOAD для возобновления приостановленного задания загрузки.

Что делать, если результат SHOW ROUTINE LOAD показывает, что задание загрузки находится в состоянии CANCELLED?

Анализ причины: Задание загрузки столкнулось с исключением во время загрузки, например, таблица была удалена.

Решение: При устранении неполадок и исправлении проблемы вы можете обратиться к сообщениям об ошибках в полях ReasonOfStateChanged и ErrorLogUrls. Однако после исправления проблемы вы не можете возобновить отмененное задание загрузки.

Может ли Routine Load гарантировать семантику согласованности при потреблении из Kafka и записи в Selena?

Routine Load гарантирует семантику exactly-once.

Каждая задача загрузки является отдельной транзакцией. Если во время выполнения транзакции возникает ошибка, транзакция прерывается, и FE не обновляет прогресс потребления соответствующих разделов задач загрузки. Когда FE в следующий раз планирует задачи загрузки из очереди задач, задачи загрузки отправляют запрос на потребление с последней сохраненной позиции потребления разделов, тем самым обеспечивая семантику exactly-once.