关于Greenplum ORCA 优化器的一些思考和经验

最近一两年接触 GP-ORCA 比较多，本文也更多是关于 ORCA 整体的一些思考和反思。

《Orca: A Modular Query Optimizer Architecture for Big Data》这篇论文主要介绍了 Greenplum 上分布式优化器的设计与实现，Orca从设计上有以下几个重点：

1. 可扩展性：可以应用于各种 DB/分布式事务 系统
2. 分布式：支持生成分布式计划，多核Ready
3. 多线程优化；
4. 可验证性：开发相关工具验证，复现产生Plan的过程；

按照设计，优化器通过DXL（XML格式）来和其他模块做交互和对接，其他系统接入只需要实现对应的DXL接口，就可以使用优化器来实现一个自己的优化器。简单来说，它的算法如下：

INPUT：

1. SQL对应的原始 plan-tree，需要翻译成 DXL

2. 其他模块或者外部系统实现 IMDProvider 来提供优化器所需的 metadata 信息，包括表的属性，统计信息等。

OUTPUT：优化后的物理 plan 对应的 XML 表示格式

但是从个人经验来看，这种设计会带来比较多的额外性能开销和维护成本，主要有两点：

1. 从 Perf 的情况上看，DXL 这个框架的性能比较差，一启动就会有不少的 effort（这里应该是 orca 依赖的 xml 包导致）。另外 DXL 本质上和 LogicalPlan 没啥区别，只做了等价的信息翻译，这些翻译和使用都有额外的开销。所以如果是引入 Orca 做自己系统的优化器，建议可以去除 DXL 这层抽象，直接做 LogicalPlan 翻译对接。
2. 其次如果有新的语法或者特性需要新加支持，改动链路会非常长，开发效率相当低。此外这里会很容易做一些hack 的操作，毕竟这里也拥有了 LogicalPlan 所需的全部信息，一旦改动多了之后可维护性就很差了。

最后，我个人感觉优化器要做的特别通用，对大多数数仓产品来说，需求其实不是特别强烈。如果想要把优化器实现的足够靠谱，必须强依赖自身系统的特性来做优化和选择，所以其他模块有多少创新，就会有很多细节调整。市面上很多产品真正需要的只是一个简单的 SQL 语法支持，并不真正需要一个完整靠谱的优化器模块。

从开源的优化器框架来比较，Orca 在这方面确实算是很完备的工程实现。物理属性Enforce，统计信息使用推导以及完整的 Cascades 框架实现都做的比较完备。从这个角度看，Orca是一个很好的优化器参考实现。但是这来也有几点是值得说明下：

1. ORCA 是一个 Cascades 搜索框架下的实现，对于复杂的查询这种框架是比较好的，但是对于简单查询就有点杀鸡用牛刀的感觉了。Greenplum 是可以用 PG 原始的优化链路做兜底的，所以在简单的查询场景下（一些ORCA不支持的场景下）是仍然可以保证非常好的性能。但是其他产品想直接复用的话，为了应对这种 CASE，就需要加一些 RBO 的分支了（但是这种情况下又会破坏一些 ORCA 的潜在假设，也比较折腾，此处就不多言，后续有机会再开新坑说明）。
2. ORCA 的物理属性的分类有点太多，第一次看代码确实震惊到我，毕竟这东西带来的性能回退是指数级的。不过社区也有在做一些调整，分区属性已经移除了。

总之在分布式计划和 Cascades 框架方面， ORCA 是很具备参考性的，整体框架代码实现也比较干净。

多线程更多是一个 Demo 验证，工程实现远达不到企业级软件标准，难点在于依赖控制，这里还是很复杂的。不过目前看过开源的闭源的各种优化器，都还没怎么在多线程上有实际效果的，理论上一般也没这个性能需求。

GPOS 里能看出来 ORCA 是个早期C代码实现的项目再慢慢演进过来的。比如里面手动引用计数做内存管理，确实给工程实现带来不少的难点，哭。特别是在引用链路比较深，一些基础的类最终被发现内存泄漏或者提前释放野指针的时候，整个排查过程真的是让人头秃。这里要是能用上智能指针应该就好很多了，期待一下。