Несмотря на разметку, я продолжаю взрывать искровой кластер

Question

У меня есть искра, которая взрывает наш кластер CDH одним из двух способов в зависимости от того, как я разбиваю вещи. Цель этого задания - генерировать где-то между 1 и 210 094 780 875 наборами из четырех целых чисел. Работа отправляется через spark-submit, для мастера задано значение YARN. Ниже приведен код СниП уместен на этот вопрос:

// build rdd and let cluster build up the ngram list   
    val streamList_rdd = sc.parallelize(streamList).repartition(partitionCount) 
    val rdd_results = streamList_rdd.flatMap { x => x.toList } 
    println(rdd_results.count()) 

streamList является список генераторов, которые были посеяны со значением пола/потолка (кортеж, содержащими два Ints), который будет генерировать наборы из четырех целых чисел ограничены по полу/потолку. Идея состоит в том, чтобы обрабатывать работу по генерации через кластер, и именно там фронт падает. Если partitionCount слишком низок (и, следовательно, размер каждого раздела большой), рабочие взрываются из-за нехватки памяти. Если partitionCount высок (и, таким образом, размер каждого раздела является управляемым с точки зрения памяти), вы начинаете видеть ошибки, как это:

java.io.IOException: Connection reset by peer 
at sun.nio.ch.FileDispatcherImpl.read0(Native Method) 
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) 
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) 
at sun.nio.ch.IOUtil.read(IOUtil.java:192) 
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) 
at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:313) 
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:881) 
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:242) 
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:119) 
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) 
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) 
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) 
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) 
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111) 
at java.lang.Thread.run(Thread.java:745) 

Проблема памяти я понимаю - то, что я не понимание является почему возникают проблемы с большим количеством разделов (~ 100 тыс. или более). Есть ли способ сделать эту работу, сохраняя роль YARN в управлении ресурсами кластера?

Answer 1

Учитывая количество данных и наличие ошибок памяти, я думаю, вам нужно назначить больше ресурсов кластера.

Увеличение перегородок улучшает параллелизм, но за счет потребления большего количества ресурсов на кластере с недостаточным размером. Я также подозреваю, что операция перераспределения вызывает перетасовку, которая является дорогостоящей операцией в лучшие времена, очень плохая (катастрофическая!), Когда у вас достаточно данных для выхода из памяти. Но без журналов это гипотеза.

Причина сердцебиения неудачи, скорее всего, либо исполнитель находится под таким тяжелым грузом он не реагирует вовремя, или процесс разбился/был убит ПРЯЖЕЙ ...