假设我有这样的规则： p（v3，v4）： - t1（k1，v1），t2（k1，v2），t3（v1，v3），t4（v2，v4）。
任务是将t1，t2，t3和t4连接在一起以产生关系p。
假设t1，t2，t3和t4已经为其键分配了相同的分区。
一个常见的策略是逐个加入关系，但它会强制进行至少3次重复/重新分区操作。详情如下（假设我有10个分区）。
1.join: x = t1.join(t2)
2.repartition: x = x.map(lambda (k1, (v1,v2)): (v1,v2)).partitionBy(10)
3.join: x = x.join(t3)
4.repartition: x = x.map(lambda (v1, (v2,v3)): (v2,v3)).partitionBy(10)
5.join: x = x.join(t4)
6.repartition: x = x.map(lambda (v2, (v3,v4)): (v3,v4)).partitionBy(10)
因为t1到t4都有相同的分区，并且我在每次连接后重新分配中间结果，所以每个连接操作都不会涉及任何shuffle。
然而，在我的实际代码中，中间结果（即变量x）是巨大的，3次shuffle操作对我来说仍然太多。
我的问题是：
我的评估此规则的策略有什么问题吗？有没有更好，更有效的解决方案？
我对shuffle操作的理解是，对于每个分区，Spark将独立进行重新分区，它将为磁盘上的每个分区生成重新分区结果（所谓的shuffle write）。然后，对于每个分区，Spark将从磁盘获得新的重新分区结果（所谓的随机读取）。如果我的理解是正确的，那么每次shuffle / repartition将始终花费磁盘读写。如果我可以保证我的记忆足以存储所有数据，那就太浪费了。正如在http://www.trongkhoanguyen.com/2015/04/understand-shuffle-component-in-spark.html中所说的那样。是否有任何解决方法来禁用这种shuffle写入和读取操作？我认为我的程序的性能瓶颈是由于洗牌IO开销造成的。
谢谢。