Как избежать того, чтобы Spark executor потерялся и контейнер пряжи убил его из-за ограничения памяти?
У меня есть следующий код, который срабатывает hiveContext.sql() большую часть времени. Моя задача состоит в том, чтобы создать несколько таблиц и вставить значения в после обработки для всех разделов таблицы hive.
Поэтому я сначала запускаю
show partitions и, используя его выход в цикле for, вызываю несколько методов, которые создают таблицу (если она не существует) и вставляют в них с помощью hiveContext.sql. Теперь мы не можем выполнить hiveContext в исполнителе, поэтому я должен выполнить это в цикле for В программе драйвера и должен запустить последовательно один на один. Когда я представляю эту работу искры в кластере пряжи, почти все время мой исполнитель теряется из-за перетасовки не найденного исключения.
Теперь это происходит потому, что пряжа убивает моего исполнителя из-за перегрузки памяти. Я не понимаю, почему, поскольку у меня очень маленький набор данных для каждого раздела улья, но все равно это заставляет YARN убивать моего исполнителя.
Будет ли следующий код делать все параллельно и пытаться разместить все данные раздела Улья в памяти одновременно время?
public static void main(String[] args) throws IOException {
SparkConf conf = new SparkConf();
SparkContext sc = new SparkContext(conf);
HiveContext hc = new HiveContext(sc);
DataFrame partitionFrame = hiveContext.sql(" show partitions dbdata partition(date="2015-08-05")");
Row[] rowArr = partitionFrame.collect();
for(Row row : rowArr) {
String[] splitArr = row.getString(0).split("/");
String server = splitArr[0].split("=")[1];
String date = splitArr[1].split("=")[1];
String csvPath = "hdfs:///user/db/ext/"+server+".csv";
if(fs.exists(new Path(csvPath))) {
hiveContext.sql("ADD FILE " + csvPath);
}
createInsertIntoTableABC(hc,entity, date);
createInsertIntoTableDEF(hc,entity, date);
createInsertIntoTableGHI(hc,entity,date);
createInsertIntoTableJKL(hc,entity, date);
createInsertIntoTableMNO(hc,entity,date);
}
}
1 ответ:
Как правило, вы всегда должны копаться в журналах, чтобы получить реальное исключение (по крайней мере, в Spark 1.3.1).
Tl; dr
безопасная конфигурация для Искры под пряжейspark.shuffle.memoryFraction=0.5- это позволит shuffle использовать больше выделенной памятиspark.yarn.executor.memoryOverhead=1024- это установлено в MB. Yarn убивает исполнителей, когда его использование памяти больше, чем (executor-memory + executor.memoryOverhead)Немного больше информации
Читая ваш вопрос, вы упоминаете, что вы получаете shuffle не найден исключение.
В случае
org.apache.spark.shuffle.MetadataFetchFailedException: Missing an output location for shuffleвы должны увеличитьspark.shuffle.memoryFraction, например, до 0,5Самой распространенной причиной убийства моих исполнителей Yarn было использование памяти сверх того, что она ожидала. Чтобы избежать увеличения
spark.yarn.executor.memoryOverhead, я установил его на 1024, даже если мои исполнители используют только 2-3G памяти.
Comments