spark-sql 是 cbo 的吗？

spark-sql的优化器是cost-based的吗？

这是一个很有意思的问题。

大概两年以前，刚开始准备用spark-sql来做点事情的时候，抱着工欲善其事必先利其器的想法，大概看了看关于spark的那几篇论文。

鄙人才疏学浅，其他的也看不太懂，但是对于cbo略知一二，所以下意识的就想看看spark-sql是怎么计算cost的，特别是spark对data geography的处理和我所了解的teradata 截然不同，想知道spark是怎么做的。

结果论文看了半天，发现对于cbo这一块写的及其含糊，读了几遍都不得要领，索性书看不懂去看看代码呗，去github上翻了半天源代码 之后，发现了这么一段：

/**

* Abstract class for transforming [[LogicalPlan]]s into physical plans.

* Child classes are responsible for specifying a list of [[GenericStrategy]] objects that

* each of which can return a list of possible physical plan options.

* If a given strategy is unable to plan all

* of the remaining operators in the tree, it can call [[planLater]], which returns a placeholder

* object that will be filled in using other available strategies.

*

* TODO: RIGHT NOW ONLY ONE PLAN IS RETURNED EVER...

*      PLAN SPACE EXPLORATION WILL BE IMPLEMENTED LATER.

*

*@tparamPhysicalPlanThe type of physical plan produced by this [[QueryPlanner]]

*/

是的，直到前两天发布的2.2.版本之前，spark根本没实现cbo,所有的优化都是基于规则的，跟spark-sql那篇论文上写的一点都不一样。

如果有人只读过论文没实际去看过的话，是不可能知道这个问题的正确答案的。所以现在看到那些写spark-sql 的 blog，很容易就知道水平了。

我打算下次碰见有人自称精通spark的时候，就问问他这个问题 :-)