Question

所有，我将需要分发一些计算（现在它只是学术性的），我正计划使用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')

并在600k行文本文件中运行，然后是我已经进行了本地火花安装，并运行了以下代码：

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个VM中，正如预期的那样，结果更糟。

我确实知道有一些开销，特别是在使用虚拟机时，问题是：

1） - 我的推理是否合理？ Spark是分发此类工作的合适工具吗？（现在，我只是对线条进行求和，但线条可能非常大，操作可能要复杂得多（想想遗传编程健身评估））

2） - 我的代码是否适合分发计算？

3） - 如何提高速度？

Answer 1

A1）不，Spark可能是其他任务的绝佳工具，但不适用于GP

GP方法所开启的权力背后的核心理念是对该过程进行零灌输。它是进化的，它是过程'自我发展的候选人的多样性（每个人口成员是候选解决方案，具有（非常）不同的适应性（“最佳适合度”））。因此，大多数处理能力都符合用于增加潜力的原则，以允许演化进化搜索的最大宽度，其中遗传操作介导自我实现（通过交叉，突变和架构的变化）与自我繁殖。 Spark适用于相反的情况 - 对于严格的脚本化工作流程，任何进化行为都没有空间。

进化发生器能够扫描的人口成员的丰富多样性越好。因此，让多样性变得更加广泛，忘记刚性和工具的工具。重复的RDD演算（其中RDD是 Spark中的基本抽象。表示不可变，可以并行操作的分区元素集合“。注意单词不可变 。）。

Nota Bene： 使用虚拟机测试并行的（潜在）加速（实际上不是[PARALLEL]而是“只是” - （可能是高度的） - [CONCURENT]调度）处理性能是非常糟糕的主意。为什么？消耗更多的开销到共享资源（在基于容器的部署的情况下）以及在虚拟机管理程序服务平面中消耗额外的开销，接下来绝对破坏了VM抽象的vCPU / vCore的L1内的所有时间缓存局部性L2 / L3缓存，所有这些都被外部操作系统纵横交错，为外部进程调度程序上的几个CPU-CLK-ticks而战，所以这个想法确实是一个糟糕的，非常糟糕的反模式，这可能会得到云主角支持的一些超级教条广告（硬核，技术上没有调整的公关陈词滥调+沉重的钟声和哨声$），但如果对原始硅执行进行严格验证，则会产生负面的性能提升。 / p>

A2）+ A3）进化系统的分布式性质很大程度上取决于处理的性质（工作）

鉴于我们在这里关于GP，分布式执行可能最有助于生成演化加速多样性的增加宽度，而不是天真的代码执行。

在GP中非常有益的是进化概念的全局自我稳健性 - 许多不协调（异步）和非常独立的处理节点通常更强大（就所实现的全球TFLOP水平而言）和实际报告甚至显示，那些失败的节点，即使是大型单位（如果不是几十个百分点（!!））仍然没有破坏全球搜索的最后时代的最终实现的质量，跨越自我发展的人口。这是重点！如果您能够将这些少数核心原则正确地用于分布式计算节点的轻量级异步群，那么您确实会喜欢GP。仅适用于HPC统治的GP / GA搜索！

最佳下一步：

要获得一些非常第一手的经验，请阅读John R. KOZA关于他的GP分布式处理概念的评论，其中实际使用了+ 99％的问题（以及受CPU限制的处理应得的地方）最大可能的加速度（令人惊讶的是不是通过重新分配，因为不愿意放松单个项目的地点））。我几乎可以肯定，如果你认真对待GP / GA，你会喜欢它和它。受益于他的开创性工作。

如何使用Spark来分配处理负载？

1 个答案:

A1）不，Spark可能是其他任务的绝佳工具，但不适用于GP

A2）+ A3）进化系统的分布式性质很大程度上取决于处理的性质（工作）

最佳下一步：