因为工作的关系，我有机会组织了一个 Apache Doris 优化器的 SIG 小组。在和社区同学合作开发 Doris 新优化器的改造工作的过程中，收获了很多项目上的经验（尤其还收获了很多志同道合的队友们~）。在此记录一下这些经验。（如有不正确的地方欢迎指教~）

背景

Doris 从去年开始就在规划使用 Cascades 架构来实现新优化器的项目，正好恰逢 优化器 SIG 小组的成立。项目有需求，又有人力，新优化器这个项目就开始了。

项目初期

在这个项目初期，首要就是回答这些问题：项目的意义是什么？怎么规划项目路径？团队同学怎么协作？

下面这几点主要解决了这些问题：

Demo

  • 主要是用来验证项目的意义，可行性，预期效果。

制定合理的各阶段目标。

  • 新优化器是一个比较大的项目，他的设计到最终完成落地的时间跨度都是几个 Q 起步的。这就要求我们一定要将一个大的项目，拆解成各个阶段，设立阶段性目标。

在设定短期目标时，很容易遇到的一个问题就是：设定的短期目标却无法短期实现。那就说明设定的短期目标错误，需要继续精简目标。

  • 但是这个精简的方向，不应该是框架上的精简，而应该是横向或者说相似工作的精简。拿新优化器这个项目举个例子，框架上即使是再短期的目标，他也应该保留完整的查询规划的各个阶段。但是每个阶段并不一定要实现的非常全面，比如我可以在 parser 阶段仅支持 join 语法，也可以在 Optimizer 阶段仅支持个别 Rule。

  • 精简的同时保证了目标的连贯性，从而避免在下个阶段中对上个阶段的结果进行推导重来的可能。

使用有效的协作工具和机制

  • 团队协作一定要设定合适的协作工具以及协作机制，更好的凝聚每个队友们的力量。

有了上述这些工作，再加上坚定不移的心态，那就开搞吧 ~

快速迭代 —— 代码质量和研发效率的 Battle

下图其实是一个功能 PR 最终合入必须要经历的过程，每个 PR 的平均合入时间就决定了我们的研发效率。但是一味地去追求快速迭代势必会损失代码质量，如何既保证了代码质量，又不影响研发效率，两者之间的权衡就很重要了。

+----------+      +------------+      +-----------+       +----------+      +--------------+
|  Design  +----->| PR develop +----->| PR review +------>|PR modify +------> CI (part of) |
+----------+      +------------+      +-----^-----+       +-----+----+      +--------------+
                                            |                   |
                                            |                   |
                                            +-------------------+

Step1：设计阶段

充分沟通从而避免后期不必要的返工。

对于长期合作的同学，也可基于效率和功能的大小程度免除这个阶段的沟通。

Step2：PR 开发阶段

有明确的时间节点。这里的时间节点和狭义上的 DeadLine 还不一样，这里的时间节点并不是不可更改的。如果在开发过程中出现新的工作量，也是可以随时更改的。

需要注意的是，不要因为无法预估时间而放弃设定时间节点。一般来说如果无法预估时间，要么就是任务中还存在一些未知，要么就是任务拆解的不细致。在一边了解一边细化的过程中，一定能给出一个合理的时间节点。

Step3：PR Review 阶段

正确性和代码架构是绝对不能牺牲的。盲目的加快 PR Review 的速度只会留下巨大的代码质量问题，解决了短期效率却大幅降低了代码质量，只会在未来花费更多的时间去解决代码质量带来的问题。

当然，如果真的有非常紧急的 Deadline，可以牺牲掉一些细节的问题（通过加 TODO 的方式后期再修改）。

Step4：PR 修改

Review 同学和 PR 开发者一定要有充分的沟通。由于优化器 SIG小组成员的跨公司特殊性，PR Review 和 PR 修改部分一定要进行高效且充分的沟通。

Step5： CI （部分流程）

这里包括但不限于，编译，单测，回归，代码风格检查。PR 合入前的各种测试是代码质量的第一道防线，必须通过后才能合入PR。PR 的合入起码不能影响目前正常的功能，这个是一个 PR 被合入的底线。

效率上，可以通过提升 CI 本身的速度来加快效率，而不是通过跳过这个流程来加快效率。

辅助工具&制度

  1. Google Doc：管理项目描述，调研文档，进度汇总等等
  2. Github Project：管理项目空间，PR 汇总等。
  3. 周会制度：进度同步。

本来一直是使用石墨文档的方式，即能管理项目空间，又有成员组概念，而且还能存各种格式的文档。但是石墨文档的免费版本只能支持 15 个人的协作，多了就会有各种限制 ಥ_ಥ。含泪替换成了 Github Project + Google Doc 的方式。

结语&鸣谢

随着新优化器的逐步迭代，我还会继续在项目协作上有更进一步的认知。自己在这方面还有很多的不足，感谢各位优化器SIG 小组队友们的包容和理解。

在此特别感谢硕哥，华健，昊辰，智强，西哥，正特，文杰，昊鹏，墨影，morningman，新一，继昶，凌聪，尹滔，强哥，社区小伙伴们以及公司领导的大力支持。相信在我们的共同努力下，优化器 SIG 小组一定能越来越繁荣~

广告时间

  1. 优化器 SIG 小组欢迎你的加入。
  2. 敬请期待 Apache Doris 的新优化器，一定能给你的查询性能带来质的飞跃。