[undo][spark]RDD&DataFrame 使用RDD避免shuffle&大量Join记录

写在开头

由于自己对于大数据方面的知识只能说皮毛都没懂，很多问题不知道怎么解决和解释，所以有这么一个分类

该分类下只记录一些操作，以及粗略的解释，还有一些自己的思考以及顾虑，当作是记录自己从业的点滴吧。

任务场景

处理X个特征后拼接到原始表上，X * [id1,id2,raw_feature_1,...,raw_feature_N] -> X * [id1,id2,feature_1,...,feature_N] -> [id1,id2,feature_11,...,feature_XN]。

我开始的处理思路

其实我开始考虑了两种处理思路
V01 单独处理，处理结束后Join X 次。
V02 一开始JoinX次，然后转换成RDD，利用MAP进行处理
我选择了V01
为什么呢？对比这两个方法，前者是串行，只需要框架算就行了，而且在特征归一化/向量化处理中，不需要考虑DF的重名问题，实现上也比较简单。后者是并行，V02我一开始有一个顾虑就是，V01只有N+2列数据，如果V01处理不了，那么V02一开始先join，会造成X * (N)+2 的数据，就更处理不了了。
结局：很明显，这方法不太行，甚至这个坑还让我学了Checkpoint机制，甚至我一开始还不知道DF和RDD的Checkpoint还不一样，踩了新坑。
保留疑问
实际上，这问题不能就这么解决了，为什么这个方法不行？
我不解的是，我利用checkpoint&persist存下来了DF，成了；但当我将join从归并的实现方法（存一个列表[df0,...,dfX]->两两join直到只剩一个DF）变成AjoinBjoinC直到一个DF时,又不好使了，等以后我学习了spark以后，能解决这个这个问题时，我再来总结。

优化的处理思路

显然，使用的是V02方法，利用SQL将所有需要处理的特征join后取出来，这样就避免掉了shuffle join 操作，效率up，然后利用spark.createDataFrame(old.rdd,new_name_col_list)构建一个新的DF，题外话，我一开始用的是old.toDF(new_name)，参数大概几百个吧，虽然不是手打的。

写在结尾

希望几年后回看这些，能不忘初心吧。