Оптимизировать запрос улья. java.lang.OutOfMemoryError: превышен предел объема кучи Java / накладных расходов сборщика мусора

Как я могу оптимизировать запрос этой формы, если я постоянно сталкиваюсь с этой ошибкой OOM? Или придумать лучший план выполнения? Если бы я удалил предложение подстроки, запрос работал бы нормально, предполагая, что это займет много памяти.

В случае сбоя задания в выводе beeline отображается пространство кучи OOM Java. Читая онлайн, я предлагал увеличить export HADOOP_HEAPSIZE, но это все равно приводит к ошибке. Еще я попробовал увеличить hive.tez.container.size и hive.tez.java.opts (tez heap), но по-прежнему имеет эту ошибку. В журналах YARN будет превышен предел накладных расходов сборщика мусора, что говорит о том, что комбинация нехватки памяти и / или плана запроса крайне неэффективна, поскольку не может собрать достаточно памяти.

Я использую интерактивный запрос Azure HDInsight 4.0. 20 рабочих узлов, 8 ядер D13v2 и 56 ГБ ОЗУ.

Исходная таблица

create external table database.sourcetable(
  a,
  b,
  c,
  ...
  (183 total columns)
  ...
)
PARTITIONED BY ( 
  W string, 
  X int, 
  Y string, 
  Z int
)

Целевая таблица

create external table database.NEWTABLE(
  a,
  b,
  c,
  ...
  (187 total columns)
  ...
  W,
  X,
  Y,
  Z
)
PARTITIONED BY (
  aAAA,
  bBBB
)

Запрос

insert overwrite table database.NEWTABLE partition(aAAA, bBBB, cCCC)
select
a,
b,
c,
...
(187 total columns)
...
W,
X,
Y,
Z,
cast(a as string) as aAAA, 
from_unixtime(unix_timestamp(b,'yyMMdd'),'yyyyMMdd') as bBBB,
substring(upper(c),1,2) as cCCC
from database.sourcetable

sql out-of-memory hive azure-hdinsight beeline
person user7644509    schedule 08.07.2020    source источник
comment
Здравствуйте! Если приведенный ниже ответ полезен для вас, вы можете принять его как ответ (щелкните галочку рядом с ответом, чтобы переключить его с серого на заполненный). Это может быть полезно для других членов сообщества. Спасибо.   -  person CHEEKATLAPRADEEP-MSFT    schedule 15.07.2020

Ответы (2)


arrow_upward
1
arrow_downward

Если все остальное в порядке, попробуйте добавить распределение по ключу разделения в конце вашего запроса:

  from database.sourcetable 
  distribute by aAAA, bBBB, cCCC

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

person leftjoin    schedule 09.07.2020
comment
Я добавил целевую таблицу, чтобы получить четкую картину. Правильны ли целевая таблица и запрос при секционировании? И не забудьте спросить, почему мы распределяем по разделам исходной таблицы, а не по целевой таблице? - person user7644509; 09.07.2020
comment
@ user7644509 Извините, пропустил. Это может быть целевое разбиение. Неправильно прочитайте свой вопрос .. Верно - person leftjoin; 09.07.2020

arrow_upward
0
arrow_downward

Попробуйте отсортировать разделенные столбцы:

SET hive.optimize.sort.dynamic.partition=true;

Если этот параметр включен, столбец динамического разбиения будет отсортирован глобально. Таким образом, мы можем держать открытым только один модуль записи для каждого значения раздела в редукторе, тем самым снижая нагрузку на память редукторов.

https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties

person davidemm    schedule 10.07.2020