1.Spark本身其实并没有实现成本模型，目前一个逻辑计划可能生成多个物理计划，Spark源码直接调用.next来获取列表的第一个物理计划。只是列表的顺序是按照经验值排序的，比如broadcastjoin排序在sortmergejoin之前
2.cbo是基于数据静态信息统计，以及抽样数据进行成本估算实现的。这部分代码在catalsy其实是属于生成逻辑计划的部分。
还是以broadcastjoin举例。
select * from a join b on a.key = b.key where b.value > 123;
如果a本身大小大于autoBroadcastJoinThreshold，但是经过filte后小于该值，那么不开启cbo的情况下，这里还是smj而不是bcj。
3.
Spark SQL / Catalyst 和 CBO 的优化，从查询本身与目标数据的特点的角度尽可能保证了最终生成的执行计划的高效性。但是
- 执行计划一旦生成，便不可更改，即使执行过程中发现后续执行计划可以进一步优化，也只能按原计划执行；
- CBO 基于统计信息生成最优执行计划，需要提前生成统计信息，成本较大，且不适合数据更新频繁的场景；
- CBO 基于基础表的统计信息与操作对数据的影响推测中间结果的信息，只是估算，不够精确。
Adaptive Execution 将可以根据执行过程中的中间数据优化后续执行，从而提高整体执行效率。核心在于两点：
- 执行计划可动态调整
- 调整的依据是中间结果的精确统计信息
还是以broadcastjoin举例
select * from a join b on a.key = b.key where b.value > 123;
a很小，但不是静态表，可能是一张经过计算的中间结果表(没有静态信息，不能被cbo事先统计，或者被cbo估算后其值大于设置的阈值)那么不开启aqe的情况下，这里还是smj而不是bcj。
