Python 使用join时，Spark迭代时间呈指数增长

我是Spark的新手，我正在尝试使用马尔可夫模型表示的质心实现一些迭代聚类算法（期望最大化）。所以我需要进行迭代和连接

我遇到的一个问题是，每次迭代的时间都呈指数增长。
经过一些实验，我发现在进行迭代时，需要持久化RDD，以便在下一次迭代中重用，否则每个迭代火花都会创建执行计划，从一开始就重新计算RDD，从而增加计算时间

init = sc.parallelize(xrange(10000000), 3)
init.cache()

for i in range(6):
    print i
    start = datetime.datetime.now()

    init2 = init.map(lambda n: (n, n*3))        
    init = init2.map(lambda n: n[0])
#     init.cache()

    print init.count()    
    print str(datetime.datetime.now() - start)

结果：

0
10000000
0:00:04.283652
1
10000000
0:00:05.998830
2
10000000
0:00:08.771984
3
10000000
0:00:11.399581
4
10000000
0:00:14.206069
5
10000000
0:00:16.856993

因此，添加cache（）有助于使迭代时间保持不变

init = sc.parallelize(xrange(10000000), 3)
init.cache()

for i in range(6):
    print i
    start = datetime.datetime.now()

    init2 = init.map(lambda n: (n, n*3))        
    init = init2.map(lambda n: n[0])
    init.cache()

    print init.count()    
    print str(datetime.datetime.now() - start)
0
10000000
0:00:04.966835
1
10000000
0:00:04.609885
2
10000000
0:00:04.324358
3
10000000
0:00:04.248709
4
10000000
0:00:04.218724
5
10000000
0:00:04.223368

但是当在迭代中进行连接时，问题又回来了。 下面是一些简单的代码，我演示了这个问题。即使在每个RDD转换上进行缓存也不能解决问题：

init = sc.parallelize(xrange(10000), 3)
init.cache()

for i in range(6):
    print i
    start = datetime.datetime.now()

    init2 = init.map(lambda n: (n, n*3))
    init2.cache()

    init3 = init.map(lambda n: (n, n*2))
    init3.cache()

    init4 = init2.join(init3)
    init4.count()
    init4.cache()

    init = init4.map(lambda n: n[0])
    init.cache()

    print init.count()    
    print str(datetime.datetime.now() - start)

这是输出。如您所见，迭代时间呈指数增长：(

---

我非常感谢您的帮助：）

RDD是不可变的。尝试执行rdd=rdd.cache（）

一般来说，迭代算法，尤其是具有自连接或自并集的迭代算法，需要控制：

• 血统的长度（参见示例和）
• 分区数

这里描述的问题是缺乏前一个问题的结果。在每次迭代中，分区的数量随着自连接的增加而增加，从而形成指数模式。为了解决这个问题，您必须在每次迭代中控制分区的数量（见下文），或者使用全局工具，如

spark.default.parallelism

（见下文）。一般来说，第一种方法提供了更多的控制，并且不会影响代码的其他部分

原始答案：

据我所知，这里有两个交错的问题——不断增长的分区数量和连接期间的洗牌开销。两者都很容易处理，所以让我们一步一步来

首先，让我们创建一个帮助器来收集统计信息：

import datetime

def get_stats(i, init, init2, init3, init4,
       start, end, desc, cache, part, hashp):
    return {
        "i": i,
        "init": init.getNumPartitions(),
        "init1": init2.getNumPartitions(),
        "init2": init3.getNumPartitions(),
        "init4": init4.getNumPartitions(),
        "time": str(end - start),
        "timen": (end - start).seconds + (end - start).microseconds * 10 **-6,
        "desc": desc,
        "cache": cache,
        "part": part,
        "hashp": hashp
    }

处理缓存/分区的另一个助手

def procRDD(rdd, cache=True, part=False, hashp=False, npart=16):
    rdd = rdd if not part else rdd.repartition(npart)
    rdd = rdd if not hashp else rdd.partitionBy(npart)
    return rdd if not cache else rdd.cache()

提取管道逻辑：

def run(init, description, cache=True, part=False, hashp=False, 
    npart=16, n=6):
    times = []

    for i in range(n):
        start = datetime.datetime.now()

        init2 = procRDD(
                init.map(lambda n: (n, n*3)),
                cache, part, hashp, npart)
        init3 = procRDD(
                init.map(lambda n: (n, n*2)),
                cache, part, hashp, npart)


        # If part set to True limit number of the output partitions
        init4 = init2.join(init3, npart) if part else init2.join(init3) 
        init = init4.map(lambda n: n[0])

        if cache:
            init4.cache()
            init.cache()

        init.count() # Force computations to get time
        end = datetime.datetime.now() 

        times.append(get_stats(
            i, init, init2, init3, init4,
            start, end, description,
            cache, part, hashp
        ))

    return times

并创建初始数据：

ncores = 8
init = sc.parallelize(xrange(10000), ncores * 2).cache()

Join操作本身，如果未提供

numPartitions

参数，则根据输入RDD的分区数调整输出中的分区数。这意味着每次迭代都会增加分区的数量。如果分区的数量太大，事情就会变得糟糕。您可以通过在每次迭代中为联接或重新分区RDD提供

numPartitions

参数来处理这些问题

timesCachePart = sqlContext.createDataFrame(
        run(init, "cache + partition", True, True, False, ncores * 2))
timesCachePart.select("i", "init1", "init2", "init4", "time", "desc").show()

+-+-----+-----+-----+--------------+-----------------+
|i|init1|init2|init4|          time|             desc|
+-+-----+-----+-----+--------------+-----------------+
|0|   16|   16|   16|0:00:01.145625|cache + partition|
|1|   16|   16|   16|0:00:01.090468|cache + partition|
|2|   16|   16|   16|0:00:01.059316|cache + partition|
|3|   16|   16|   16|0:00:01.029544|cache + partition|
|4|   16|   16|   16|0:00:01.033493|cache + partition|
|5|   16|   16|   16|0:00:01.007598|cache + partition|
+-+-----+-----+-----+--------------+-----------------+

正如您所看到的，当我们重新分区时，执行时间或多或少是恒定的。 第二个问题是，上面的数据是随机分区的。为了确保连接性能，我们希望在单个分区上有相同的密钥。为了实现这一点，我们可以使用哈希分区器：

timesCacheHashPart = sqlContext.createDataFrame(
    run(init, "cache + hashpart", True, True, True, ncores * 2))
timesCacheHashPart.select("i", "init1", "init2", "init4", "time", "desc").show()

+-+-----+-----+-----+--------------+----------------+
|i|init1|init2|init4|          time|            desc|
+-+-----+-----+-----+--------------+----------------+
|0|   16|   16|   16|0:00:00.946379|cache + hashpart|
|1|   16|   16|   16|0:00:00.966519|cache + hashpart|
|2|   16|   16|   16|0:00:00.945501|cache + hashpart|
|3|   16|   16|   16|0:00:00.986777|cache + hashpart|
|4|   16|   16|   16|0:00:00.960989|cache + hashpart|
|5|   16|   16|   16|0:00:01.026648|cache + hashpart|
+-+-----+-----+-----+--------------+----------------+

timesCacheHashPart512 = sqlContext.createDataFrame(
    run(init, "cache + hashpart 512", True, True, True, 512))
timesCacheHashPart512.select(
    "i", "init1", "init2", "init4", "time", "desc").show()
+-+-----+-----+-----+--------------+--------------------+
|i|init1|init2|init4|          time|                desc|
+-+-----+-----+-----+--------------+--------------------+
|0|  512|  512|  512|0:00:14.492690|cache + hashpart 512|
|1|  512|  512|  512|0:00:20.215408|cache + hashpart 512|
|2|  512|  512|  512|0:00:20.408070|cache + hashpart 512|
|3|  512|  512|  512|0:00:20.390267|cache + hashpart 512|
|4|  512|  512|  512|0:00:20.362354|cache + hashpart 512|
|5|  512|  512|  512|0:00:19.878525|cache + hashpart 512|
+-+-----+-----+-----+--------------+--------------------+

执行时间和以前一样是恒定的，与基本分区相比有一点改进

现在让我们仅将缓存用作参考：

timesCacheOnly = sqlContext.createDataFrame(
    run(init, "cache-only", True, False, False, ncores * 2))
timesCacheOnly.select("i", "init1", "init2", "init4", "time", "desc").show()


+-+-----+-----+-----+--------------+----------+
|i|init1|init2|init4|          time|      desc|
+-+-----+-----+-----+--------------+----------+
|0|   16|   16|   32|0:00:00.992865|cache-only|
|1|   32|   32|   64|0:00:01.766940|cache-only|
|2|   64|   64|  128|0:00:03.675924|cache-only|
|3|  128|  128|  256|0:00:06.477492|cache-only|
|4|  256|  256|  512|0:00:11.929242|cache-only|
|5|  512|  512| 1024|0:00:23.284508|cache-only|
+-+-----+-----+-----+--------------+----------+

正如您所看到的，仅缓存版本的分区数（init2、init3、init4）随着每次迭代而加倍，并且执行时间与分区数成正比

最后，如果使用hash partitioner，我们可以检查是否可以提高大量分区的性能：

timesCacheHashPart = sqlContext.createDataFrame(
    run(init, "cache + hashpart", True, True, True, ncores * 2))
timesCacheHashPart.select("i", "init1", "init2", "init4", "time", "desc").show()

+-+-----+-----+-----+--------------+----------------+
|i|init1|init2|init4|          time|            desc|
+-+-----+-----+-----+--------------+----------------+
|0|   16|   16|   16|0:00:00.946379|cache + hashpart|
|1|   16|   16|   16|0:00:00.966519|cache + hashpart|
|2|   16|   16|   16|0:00:00.945501|cache + hashpart|
|3|   16|   16|   16|0:00:00.986777|cache + hashpart|
|4|   16|   16|   16|0:00:00.960989|cache + hashpart|
|5|   16|   16|   16|0:00:01.026648|cache + hashpart|
+-+-----+-----+-----+--------------+----------------+

timesCacheHashPart512 = sqlContext.createDataFrame(
    run(init, "cache + hashpart 512", True, True, True, 512))
timesCacheHashPart512.select(
    "i", "init1", "init2", "init4", "time", "desc").show()
+-+-----+-----+-----+--------------+--------------------+
|i|init1|init2|init4|          time|                desc|
+-+-----+-----+-----+--------------+--------------------+
|0|  512|  512|  512|0:00:14.492690|cache + hashpart 512|
|1|  512|  512|  512|0:00:20.215408|cache + hashpart 512|
|2|  512|  512|  512|0:00:20.408070|cache + hashpart 512|
|3|  512|  512|  512|0:00:20.390267|cache + hashpart 512|
|4|  512|  512|  512|0:00:20.362354|cache + hashpart 512|
|5|  512|  512|  512|0:00:19.878525|cache + hashpart 512|
+-+-----+-----+-----+--------------+--------------------+

改进并不令人印象深刻，但如果您有一个小集群和大量数据，它仍然值得一试

我想这里的外卖信息是分区问题。在某些上下文中，它是为您处理的（

mllib

，

sql

），但如果您使用低级操作，则这是您的责任

问题在于（正如zero323在其彻底的回答中指出的那样），调用join而不指定分区的数量可能会导致分区数量的增加。分区的数量（显然）可以不受限制地增长。在重复调用join时，有（至少）两种方法可以防止分区数量增加（无绑定）

方法1:

正如zero323所指出的，您可以在调用join时手动指定分区数。比如说

rdd1.join(rdd2, numPartitions)

这将确保分区的数量不会超过numPartitions，特别是分区的数量不会持续增长

方法2:

创建SparkConf时，可以指定默认的并行级别。如果设置了此值，那么当您在不指定numPartitions的情况下调用函数（如

join

）时，将使用默认的并行性，从而有效地限制分区的数量并防止其增长。您可以将此参数设置为

conf=SparkConf.set("spark.default.parallelism", numPartitions)
sc = SparkContex(conf=conf)   

---

这里没有问题：

rdd=sc.parallelize（[]）；rdd.u被缓存；缓存（）；rdd.被缓存

cache（）

实际上修改了

is\u cached

字段。好的，我发现在交互内部调用会造成沿袭增长的问题。因此，如果迭代次数不变，您不需要在迭代之间缓存rdd，这与集群不同，因为我希望停止依赖于收敛的迭代。zero323它像一个魅力一样解决了我的问题，并提高了我对spark的理解-非常感谢！！！还有一个问题-为什么要将分区数从

init=sc.parallelize（xrange（10000），ncores）

加倍到

init2=init.map（lambda n:（n，n*3））.partitionBy（ncores*2.cache（）init3=init.map（lambda n:（n，n*2））.partitionBy（ncores*2.cache（）init4=init2.join（init3，ncores*2.cache（）

没有特别的原因。这只是我本地机器上的默认值。根据经验，您应该使用两倍于可用内核数量的分区，但这取决于其他因素，如数据量、IO吞吐量等。@zero323，我遇到了graph对象的一个simlilar问题，在这种情况下，rdd的解决方案似乎不适用于graph顶点rdd。I