一个
首先，我阅读一条推文，并通过映射到我的解析函数parseTweet中，将其解析为一个推文案例类：
val tweets = sc.textFile("/home/gakuo/Documents/bigdata/NintendoTweets").map(parseTweet)
两个
然后，我使用一个函数来配对RDD，该函数通过对PairRdd内的映射生成(hashtags, likes)形式的一对RDD：
val pairedRDD = toPairRdd(tweets).persist()
问题
在上面（一个）中读取我的RDD之后，是否有帮助将其持久化，因为（两个）中的内容是一种转换？我在想，因为两者都很懒，所以坚持实际上是在浪费记忆。
三个
计算pairRDD之后，我想计算每个主题标签的分数：toScores使用reduceByKey
val scores = toScores(pairedRDD).persist()
问题
我使用reduceByKey。此pairRDD方法会导致改组吗？我读过一篇论文，指出：
当产生的RDD依赖于同一RDD或另一个RDD中的其他元素时，可能会发生洗牌。 cogroup，groupWith，join，leftOuterJoin，rightOuterJoin， groupByKey，reduceByKey，combiningByKey，distinct，交集， 分区，合并导致改组。为避免此类操作乱序，请确保转换遵循与原始RDD相同的分区”
同一篇论文还指出，reduceByKey与原始RDD遵循相同的分区。
答案 0 :(得分：1)
当您有很多操作总是再次执行相同转换次数时，必须使用persist（在mem / disk /上）。如果一次又一次重新计算花费的时间太长。
答案 1 :(得分：1)
在您的情况下，因为它是一个一次性过程，所以不需要持久性或缓存。您需要知道，阶段已生成，在重新排列之前将尽可能多的转换放在一起。您这里有2个。
如果要使用pairedRDD处理其他一些数据要求，则建议坚持。
无论如何，这些动作都更重要。
答案 2 :(得分：0)
如果您使用相同的rdd进行了多项操作，则建议您坚持执行。到目前为止，您的代码中看不到任何动作。因此，我看不到任何原因来缓存rdd。持久性/缓存也懒洋洋地评估。
持久性/高速缓存-由于持久性遵循LRU最近最少使用的算法（如果内存已满，可能会根据最少使用的rdd刷新数据），因此不能保证在执行的整个生命周期中都会保留数据。持续使用时需要牢记所有事情。
Reducebykey-可能会发生洗牌，这是一个很大的转变。但首先它确实会在分区内没有键的情况下合并数据，然后再进行归约操作。因此成本更低。始终避免使用groupbykey而不直接在分区中合并键的情况下直接对数据进行混洗。编码时请避免使用groupbykey。