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的时候，就问问他这个问题 :-)
