Как использовать Spark для распределения вычислительной нагрузки?

Все, мне нужно будет распределить некоторые вычисления (пока это только академические), и я планировал использовать для этого Spark.

Сейчас я провожу некоторые тесты, и они выглядят так:

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

def linesum(inputline):
    m=0
    for i in inputline:
        m=m+i
    return m

with open('numbers.txt', 'r') as f:
    reader = csv.reader(f, delimiter=';')
    testdata = [list(map(float, rec)) for rec in reader]
testdata_out=list()
print('input  : ' + str(testdata))
for i in testdata:
    testdata_out.append(linesum(i))
testdata=testdata_out[:]

print('output : ' + str(testdata_out))
print(len(testdata))
print('OK')

и запустить в текстовом файле на 600 тыс. строк, затем
я сделал локальную установку искры и запустил следующий код:

if 'SPARK_HOME' not in os.environ:
    os.environ['SPARK_HOME'] = 'C:\spark\spark-2.0.1-bin-hadoop2.7'

conf = SparkConf().setAppName('file_read_sum').setMaster('local[4]')

sc = SparkContext(conf=conf)



from pyspark.sql import SparkSession

def linesum(inputline):
    m=0
    tmpout=list()
    tmpout=[]
    for i in inputline:
        m=m+i

    return m

with open('numbers.txt', 'r') as f:
    reader = csv.reader(f, delimiter=';')
    testdata = [list(map(float, rec)) for rec in reader]

print('input  : ' + str(testdata))
print(len(testdata))


testdata_rdd = sc.parallelize(testdata, numSlices=(len(testdata)/10000))

testdata_out = testdata_rdd.map(linesum).collect()

testdata=testdata_out[:]

print('output : ' + str(testdata_out))
print(len(testdata_out))
print('OK')

Результаты совпадают, но первый (без Spark) намного быстрее второго, я также сделал распределенную установку Spark на 4 ВМ и, как и ожидалось, результат еще хуже.

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

1) – Мои рассуждения верны? Является ли Spark подходящим инструментом для распространения такой работы? (на данный момент я только суммирую линии, но линии могут быть ОЧЕНЬ большими, а операции могут быть гораздо более сложными (подумайте здесь об оценке пригодности генетического программирования))

2) – Подходит ли мой код для распределения вычислений?

3) – Как увеличить скорость?


person Jorge Canelhas    schedule 07.08.2017    source источник


Ответы (1)


A1) Нет, Spark может быть отличным инструментом для других задач, но не для GP

Основная идея, лежащая в основе возможностей, которые открыли подходы общей практики, заключается в нулевой индоктринации процесса. Это эволюционно, это саморазвивающееся разнообразие кандидатов процесса (каждый член популяции является кандидатом решения, имеющим (очень) различную пригодность («наилучшее соответствие»)). Таким образом, большинство вычислительных мощностей верны в принципе, используемом для увеличения потенциала, позволяющего развить максимальную ширину эволюционного поиска, где генетические операции опосредуют самоактуализацию (путем кроссинговера, мутации и изменения архитектуры) вместе с самовоспроизведение. Spark подходит для прямо противоположного — для жесткого сценария рабочего процесса, не имеющего места для любого эволюционного поведения.

Чем большее разнообразие членов популяции сможет просканировать эволюционный генератор, тем лучше. Так что позвольте разнообразию стать шире и забудьте об инструментах для жесткого и повторяющегося исчисления RDD (где RDD — это базовая абстракция в Spark. Представляет собой неизменяемый, разделенный набор элементов, с которыми можно работать в parallel". Обратите внимание на слово неизменный. ).

Nota Bene: использование виртуальных машин для тестирования (потенциального) ускорения параллельного (ну, на практике не [PARALLEL], а "просто"-(может быть, очень) -[CONCURENT] планирование ) производительность обработки - исключительно плохая идея. Почему? Потребление дополнительных накладных расходов на общие ресурсы (в случае развертывания только на основе контейнеров) плюс потребление дополнительных накладных расходов в плоскостях обслуживания гипервизора, затем полностью опустошило все временные кэш-локали внутри абстрагированных от виртуальных машин vCPU/vCore(s) L1/ L2/L3-кэши, все это перерезано внешней ОС, борется за его несколько CPU-CLK-тиков на внешнем планировщике процессов, так что идея действительно плохой, очень плохой антипаттерн, это может получить лишь некоторую сверхдогматическую рекламу от поддержки облачных протагонистов (хардкорное, технически не отрегулированное PR-клише + тяжелый колокольчик и свисток$), но с отрицательным приростом производительности, если его тщательно проверить на сыром кремниевом исполнении.

A2) + A3) Распределенный характер эволюционных систем во многом зависит от характера обработки (Работа)

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

Очень полезной в GP является глобальная самонадежность эволюционной концепции — многие нескоординированные (асинхронные) и очень независимые узлы обработки обычно намного мощнее (с точки зрения достигнутых глобальных уровней TFLOP), и практические отчеты даже показывают, что отказавшие узлы , даже в крупных единицах (если не в малых десятках процентов (!!)) все равно не опустошают окончательно достигнутого качества последних эпох глобальный поиск по саморазвивающимся популяциям. Это точка! Вам действительно понравится GP, если вы сможете использовать эти несколько основных принципов в легком асинхронном стаде распределенных вычислительных узлов правильно и достаточно для управляемых HPC GP/GA-поисков!


Лучший следующий шаг:

Чтобы получить некоторый опыт из первых рук, прочитайте комментарии Джона Р. КОЗА о его концепциях распределенной обработки GP, где на самом деле используется + 99% проблемы (и где обработка с привязкой к ЦП заслуживает максимально возможной). ускорение (на удивление, не за счет перераспределения, а именно из-за нежелания терять местоположение одного предмета)). Я почти уверен, что если вы серьезно относитесь к GP/GA, вам это понравится и вы извлечете пользу из его новаторской работы.

person user3666197    schedule 03.09.2017
comment
Привет, спасибо за БОЛЬШОЙ awnser. Однако все еще есть одно сомнение, теперь, немного отойдя от искры. Вы говорите, что разделение популяции будет иметь негативный эффект, в этом есть смысл, однако есть несколько работ по делению популяции на клады. Каково ваше мнение по этому поводу? Спасибо - person Jorge Canelhas; 04.09.2017
comment
Рад видеть, что вы нашли это интересным и полезным. Не уверен в вашей гипотезе. Не могли бы вы указать источник? Я могу себе представить последствия ограниченного размножения (одним из таких является административное разделение или разделение на основе производительности), и у Козы есть замечания по поводу того, чтобы оставить некоторые длительные локальные эволюционные периоды, чтобы позволить популяции развить более подходящего кандидата, который был бы потерян из-за эволюционной конкуренции, если бы он были подвержены миграции и отбору слишком рано в своей эволюционной траектории, но мы смотрим со слишком высокого уровня. Эксперименты показывают точные данные для сравнения и для A/B-тестов. - person user3666197; 04.09.2017
comment
у вас есть ссылка на газету kozas? - person Jorge Canelhas; 04.09.2017
comment
Можно начать с общего вида, собранного здесь ››› genetic-programming.com/parallel.html< /а> - person user3666197; 04.09.2017
comment
Рад видеть реальный интерес к предмету и действиям, чтобы получить действительно Citius, Altius, Fortius - признак усилий, направленных в многообещающем направлении. Оставайтесь в курсе, будьте настойчивы и продолжайте идти! - person user3666197; 06.09.2017
comment
Спасибо, кстати, есть ли какая-либо группа пользователей или сообщество о GP в целом, я заканчиваю свою магистерскую диссертацию по этой теме и хотел бы продолжить работу над этой темой после этого. - person Jorge Canelhas; 07.09.2017