Spark解决SQL和RDDjoin结果不一致问题工作实录

问题描述：DataFrame的join结果不正确，dataframeA(6000无重复条数据) join dataframeB(220条无重复数据，由dataframeA转化而来，key值均源于dataframeA) 只有200条数据，丢了20条

问题验证：

1，查询丢的20条数据，均无异常，不存在Null，数据不存在空格

2，重新运行算法，丢18条数据，证明丢数据存在一定随机性

3，简化问题到最简模式，代码如下：

    val xxx1= phySiteEvaluationPhySiteKey.select("physitekey").distinct()
    val xxx2= physitefinal.select("physitekey").distinct()
    val xxx3 = xxx1.join(xxx2, Seq("physitekey"))

    val rdd1=xxx1.rdd.map(r=>r.getAs[String]("physitekey")).map(r=>(r,r))
    val rdd2 =xxx2.rdd.map(r=>r.getAs[String]("physitekey")).map(r=>(r,r))
    val rdd3=rdd1.join(rdd2)

    log.info(s"rdd3=${rdd3.count()}")
    log.info(s"xxx3==${xxx3.count()}")

xxx3和rdd3的结果居然不相等！！违背了spark常识

问题分析：

1，据spark原理可知，DataFrame的底层实现就是RDD，具体实现在Catalyst包类，需要DataFrame=>未解析的逻辑执行计划=>解析逻辑计划=>优化逻辑执行计划=>物理执行计划=>RDD执行

也就是说xxx3的执行计划生成出的RDD执行方案与RDD3结果不一致，因此在这里我打印了xxx3的执行计划，期望有所发现

    xxx1.join(xxx2, Seq("physitekey")).explain()

执行计划长达1000多行，涉及内部实现因项目保密需要无法展示。

2，执行计划超长是因为phySiteEvaluationPhySiteKey、physitefinal均为迭代计算结果，不是直接来源于输入表

3，依据执行计划，我猜测Spark在逻辑计划优化的时候出错，导致结果不符合预期

4，验证方案：为xxx1、xxx2的取值加上checkpoint，斩断血缘依赖，重新查看执行计划是否符合预期

    val xxx1= phySiteEvaluationPhySiteKey.select("physitekey").distinct().checkpoint()
    val xxx2= physitefinal.select("physitekey").distinct().checkpoint()
    xxx1.join(xxx2, Seq("physitekey")).explain()
    val xxx3 = xxx1.join(xxx2, Seq("physitekey"))

    val rdd1=xxx1.rdd.map(r=>r.getAs[String]("physitekey")).map(r=>(r,r))
    val rdd2 =xxx2.rdd.map(r=>r.getAs[String]("physitekey")).map(r=>(r,r))
    val rdd3=rdd1.join(rdd2)

    log.info(s"rdd3=${rdd3.count()}")
    log.info(s"xxx3==${xxx3.count()}")

结果执行计划如下：

== Physical Plan ==
*Project [physitekey#1648]
+- *SortMergeJoin [physitekey#1648], [physitekey#43875], Inner
   :- *Sort [physitekey#1648 ASC NULLS FirsT], false, 0
   :  +- Exchange(coordinator id: 1135069612) hashpartitioning(physitekey#1648, 200), coordinator[target post-shuffle partition size: 67108864]
   :     +- *Filter isnotnull(physitekey#1648)
   :        +- Scan ExistinGrdD[physitekey#1648]
   +- *Sort [physitekey#43875 ASC NULLS FirsT], false, 0
      +- Exchange(coordinator id: 1135069612) hashpartitioning(physitekey#43875, 200), coordinator[target post-shuffle partition size: 67108864]
         +- *Filter isnotnull(physitekey#43875)
            +- Scan ExistinGrdD[physitekey#43875]

没有问题，RDD3与XXX3结果相等，正确了。

确认问题出在Spark中DataFrame在持有超长血缘关系时转化为RDD执行出错，具体错误有机会下次分析，应当是仅在一定特殊情况下才会暴露的BUG

5、问题反思

开源组件也是可能存在BUG的，应当在使用时尽量使用其最常见的用法，列如在本问题中，如果迭代计算之后及时斩断血缘依赖，就不会出现问题