Улей, Hadoop, и механика позади hive.exec.reducers.max

Question

В контексте этого другого вопроса здесь

Использование директивы hive.exec.reducers.max действительно сбило меня с толку.

С моей точки зрения, я думал, что улей работает по некоторой логике, например, у меня N # блоков в желаемом запросе, поэтому мне нужно N карт.От NI потребуется некоторый разумный диапазон редукторов R, который может быть где угодно от R = N / 2 до R = 1. Для отчета по улью, над которым я работал, было более 1200 карт, и без какого-либо влияния улей составил план на 400редукторы, что было хорошо, за исключением того, что я работал над кластером, в котором было всего 70 редукторов.Даже с честным планировщиком заданий это привело к отставанию, которое могло бы привести к зависанию других заданий.Поэтому я пробовал много разных экспериментов, пока не нашел hive.exec.reducers.max и установил его примерно равным 60.

В результате улей занял 248 минут и завершился за 155 минут безизменения в результате.Меня беспокоит, почему бы не задавать значение куста по умолчанию, равное N, которое никогда не превышает емкость кластера-редуктора, и, поскольку я могу пролистать несколько терабайт данных с сокращенным набором редукторов, то, что улей считает правильным, лучше всегда пробоватьи настроить это количество?

Answer 1

По моему опыту с настройкой кустов mapred.job.reuse.jvm.num.tasks для здорового числа (в моем случае 8) помогает во многих из этих специальных запросов.На создание JVM уходит около 20-30 секунд, поэтому повторное использование может помочь с кратковременными мапперами и редукторами (<30 секунд). </p>

Answer 2

Вы можете посмотреть (что говорит об оптимизации количества слотов): http://wiki.apache.org/hadoop/LimitingTaskSlotUsage

Вот мое мнение о том же:

1) В идеале Hive попытается оптимизировать число редукторов на основе ожидаемого объема данных, которые генерируются после задания карты. Ожидается, что базовый кластер будет настроен для поддержки того же.

2) Относительно того, может ли быть плохой идеей изменить этот счет или нет:

• Сначала попробуем проанализировать, что может быть причиной того, что время выполнения сократилось с 248 минут до 155 минут:

Case1: Hive использует 400 редукторов Проблема: только 70 редукторов могут работать в данный момент времени.

• Предполагается, что повторное использование JVM отсутствует. Создание JVM снова и снова добавило бы большие накладные расходы.

• Не уверен в этом: ожидание 400 редукторов может привести к такой проблеме, как фрагментация. Предположим, я знаю, что могут работать только 70 редукторов, тогда моя промежуточная стратегия хранения файлов будет зависеть от этого. Но с 400 редукторами вся стратегия сводится к броску.

Case2: Hive использует 70 редукторов - Обе проблемы решаются путем установки этого числа.

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