作者：陈梓立（tison）
本周是 v5.2 开发周期的第二周，大部分开发小组仍然在讨论设计方案或初步尝试实现当中。我打算先罗列一些主要的开发活动和论坛讨论，再做一点讨论。
TiDB v5.2 Planninginternals.tidb.io
上周我们说到 TiDB v5.2 的开发计划已经发布在开发者论坛上了，除去部分 tracking issue 尚未同步的开发小组，我们挑几个来看下他们各自要做什么内容，目前是什么状况吧。
Support spill HashAgg to disk · Issue #25882 · pingcap/tidbgithub.com
众所周知，SQL 查询当中的 JOIN 语句会带来不可忽视的 shuffle 网络开销和关联时的内存开销，HashAgg 的实现方式在大表关联大表时也会遇到同样的问题。
目前 TiDB 不支持 HashAgg 在内存不足的情况下 spill 到外存，且 TiDB 单个 TP 查询的计算节点是单点的，这会导致大量数据 JOIN 时 TiDB 计算节点内存耗尽挂掉。
这个工作的主要目的就是支持 HashAgg 在内存不足的情况下 spill 到外存，目前是设计文档和功能开发两个 PR 一起做代码评审当中。从形式上说稍微有些奇怪，因为设计尚未被接受，为啥就开发起功能了呢？虽说 HashAgg spill 的需求比较直接，也没有复杂的设计阶段，不过在开发过程中可以借鉴之前在开发者论坛提到的功能分支开发模式，即
- 设计阶段仅在 TiDB 上游仓库推送设计 PR，在功能分支开发功能并由开发小组评审。
- 开发阶段从功能分支按照差异集原子地推送实现 PR，由于开发小组此前已经评审过，这一次评审的速度可以快一些，但仍然是一个有效的最终评审。
@wjhuang2016 在开发者论坛中对此也有过介绍并乐于提供指导意见，欢迎到对应贴子下留言。
Proposal: try to develop new feature in separated branchinternals.tidb.io
Support temporary table · Issue #24169 · pingcap/tidbgithub.com
TiDB v5.1 发布了符合 Oracle 语义的全局临时表的支持，在 v5.2 中将开发本地临时表的功能。简单来说，本地临时表其实是会话级别的，它会在会话结束时清理表中数据并删除表的元数据，也就是整个表都会被回收；而全局临时表在会话结束时也会清理表中数据，但是会保留表的元数据。
这个功能的设计早在几个月前就已经敲定，目前是第二阶段也就是上面提到的本地临时表的功能开发。开发小组成员有 @djshow832 @tiancaiamao @mmyj @Howie59 四位。
proposal: remove TiDB-to-TiDB RPC from tikv client · Issue #25808 · pingcap/tidbgithub.com
@disksing 在从 TiDB 代码中剥离 TiKV Go Client 的过程中，发现了此前为了实现多台 TiDB 之间互相访问数据在 TiKV Client 里混进了访问 TiDB 实例的逻辑。这其实就是代码在一起，写起来就容易耦合的一个实证。类似于 Flink 的用户一般会依赖提供的公共接口实现功能，而拥有 Flink 项目写权限的开发者则会倾向于修改内核代码来实现功能。
因为 TiDB 和 TiKV 完全是不同的存储系统，剥离出来的 TiKV Go Client 里面有在强行归到同一个抽象以后 if else 出不同情况的两条平行的代码路径。这样不利于关注点分离，因为只想处理 TiKV 访问逻辑的开发者可能在无意间破坏了访问 TiDB 的逻辑的部分假设。
因此 @disksing 提出要将 TiDB 之间的 RPC 访问逻辑归还给 TiDB 仓库，进而从 TiKV Go Client 当中移除的提案。这一工作目前也计划在 v5.2 的开发周期里推进。
Tracking issue for restructure tests · Issue #26022 · pingcap/tidbgithub.com
@tisonkun 之前在论坛上提到的针对 TiDB 测试改良并迁移到 stretchr/testify 的方案已经通过评审，目前正在落地。
这一工作涉及到整个 codebase，因此为了缩短两个测试框架并存带来的软件复杂性，非常欢迎任何感兴趣的开发者参与进来。我在上面链接导向的 tracking issue 中已经详细说明了如何参与进来的方式。
关于测试，这其实是软件质量的一个重要保证。尤其是这个 proposal 主要关注的单元测试和同一仓库下不同包之间的集成测试，是软件质量的基石。参与测试重构，是一个技术门槛不高，但是又能够比较舒服地切入 TiDB 项目的路径。测试目的性强，不要求找到功能目标进行设计；测试是功能代码的消费者，其实是最好的理解功能代码的入手点；比起单纯的阅读测试，理解并迁移测试能够倒逼对功能代码的理解，并从中发现测试尚未覆盖、缺乏可测试性等等功能代码的问题，在 proposal 之外建立针对功能代码的优化。
可以说，从测试入手，是一个非常好的理解 TiDB 代码并逐步做出有价值改进的方向。
Copy & Paste 三行代码让 TiDB 性能翻倍blog.zhuangty.com
@TennyZhuang 受到此前 @leiysky 对 TiDB 向量化表达式的挑战的启发优化 TiDB 表达式性能的博文。其实 PR 在二十几天前就已经发了并且合并了，这篇博文是对整个 PR 过程的一个回顾。随后 @TennyZhuang 又在开发者论坛上就此展开分享了 Golang 编译器针对 LogicalNot 生成代码的分析。
Golang generate stupid code for LogicalNotinternals.tidb.io
原博文对可能的优化点进行了介绍，上面关于 Golang 编译器的分析对于如何压榨 Golang 以提升 TiDB 表达式的性能也有一定的启发性，不妨一读。
TiKV v5.2 Planninginternals.tidb.io
TiKV 的技术领袖 @BusyJay 发布了 v5.2 开发周期 TiKV 的开发计划，包括在存储性能，稳定性，以及调度策略上的改进。所有列出的计划中的工作均对应了记录进展的 tracking issue，感兴趣的同学可以从连接跳转过去了解详情。
由于是周五新发的 planning，我还没来得及仔细看内容，等到下期 Weekly 的时候再结合进展做分享吧。
Appendix
这周的 Weekly 额外讨论一个话题，关于如何参与 TiDB 技术社区。
我是 Apache Flink 的 Committer 和 Apache Curator 的 PMC 成员，之前在知乎上也发布过一篇文章介绍如何参与 Apache 项目社区。
tison：如何参与 Apache 项目社区zhuanlan.zhihu.com
这里不对其内容做展开，可以从上面链接跳转查看。
对于 TiDB 技术社区来说，它也是一个开源软件的技术社区。TiDB 以 GitHub 作为代码托管和开发活动的平台，TiDB Internals 论坛作为技术交流等开放式讨论的场所，作为贡献者的一员，可以遵循上面链接介绍的方式参与到 TiDB 的技术社区当中来。
针对目前 TiDB 技术社区在贡献者参与过程中碰到的两个常见问题，这里搬运一下我做过的回答。
社区不同背景的开发者合作开发太难了
合作开发不是 50-50 开发，还是要有人主导的，因为软件开发的典型形式是外科手术形式。所谓合作更多的是说在整个软件层面上，不同功能之间的协同。协同过程中在不同功能小组之中发挥不同的作用。比如及时 review 并报告可能的冲突点，或者完成功能小组需要完成但是又不熟悉的其他内容整合部分，等等。
另一方面，此前 TiDB 的开发周期不够明确，完全依靠兴趣的方式来进行开发，交付的可靠性和时效性很难得到保障。大部分开源社区会有版本发布的惯例，例如 Flink 和 Kafka 会每四个月发一个版本，Beam 和 ZooKeeper 会追踪正在开发的工作并在社区同步将要发布版本并交付明确的功能集合。
TiDB 技术社区在这方面也有所动作，包括上面提到的 TiDB 和 TiKV v5.2 的计划，就明确了目前要在下个版本交付的功能，并且说明了目前预计的代码冻结即发布分支切换时间是 8 月 6 日。
前不久上线并持续更新的 TiDB Development Guide 也有一整个章节的内容介绍社区功能开发协作的最佳实践。
Contribute to TiDBpingcap.github.io
后续还会更新 TiDB 在软件工程上的经验和实际采用的规则。
Project Managementpingcap.github.io
欢迎反馈实际遇到的问题或指南文字有所未逮的部分。
pingcap/tidb-dev-guidegithub.com
TiDB / TiKV 的技术架构太复杂了
TiKV 的理论基础脱胎于 Spanner 论文和 Percolator 论文，TiDB 参考了 F1 等论文的思路，这些都是公开的材料。当然，在学术理论、基础架构图到实际代码之间，层层深入的中间过程的解析，除了几年前的源码阅读系列以外，确实缺乏相关材料和宣传。TiDB 代码也有不必要的耦合和复杂度。
这些，一方面在上面提到的 TiDB Development Guide 当中有正在撰写的 Understanding TiDB 一节，将会作为实时源码阅读系列补齐中间的断层。另一方面，TiDB v5.2 planning 提到的 executor 重构，TiDB-to-TiDB RPC 重构，也是改善软件可理解性的相关尝试。
另一方面，由于此前没有运转良好的 TiDB Internals 相似的开发者论坛，开放式讨论以 Issue 形式存在往往被实际具体的开发活动所掩盖，得不到充分的交流。如今我们有一个开放的技术论坛，如果你对 TiDB / TiKV 的技术架构有问题，有想到的优化点，可以发类似这样的贴子。
I beat TiDB with 20 LOCinternals.tidb.ioRemove pingcap/errors and switch to testifyinternals.tidb.io
代码实现上有看不懂的，可以提问。
Where is the implementation of self.send of RaftRouter?internals.tidb.io
对于 planning 当中提出的 feature，
- 有想做的其他 feature，可以 comment 加入 planning，例如 @disksing 把 TiDB-to-TiDB RPC 重构加了上去。
- 有想参与的某个 feature，可以在贴子会 tracking issue 下回复，例如 @skyzh 表达了对 executor framework 重构的兴趣。
- 有想了解细节的，可以在贴子会 tracking issue 下回复。feature 设计的好，可以点赞；feature 设计得有遗漏，可以挑战。
开源协同的魅力在于开放的技术实现和自由的技术讨论。技术讨论不是单方面的灌输，而是多方面主动分享产生的化学反应。
Apache 基金会的董事吴晟说过，真正伤害开源的是开发者本身。
…中国的开发者认为，软件作者去帮助他人是天经地义的，因为整个软件是你写的，所以我来问你问题，你就应该有问必答。如果你不答，就认为你这个人摆架子。而不是考虑因为软件作者用了自己的时间提供服务，所以应该表示感谢。
开源布道师适兕在一次线下讨论中提到过
你啥也没做就来对社区提出要求。这个做法是错误的。尊重一下社区规范，想要有所收获，先付出一点。
开源软件技术社区的贡献者相互之间是平等的，按照 Apache Way 的说法，他们通过自己的贡献赢得权威（ Earned Authority ）。贡献者之间主要是合作关系，少部分布道师跟新人之间的教学关系，没有上下级关系。
TiDB 社区有许多可以参与的切入点，包括上面提到的 v5.2 planning，包括 Dev Guide，包括每一个 issue 和 PR 没有禁止的评论权利。如果你想参与社区，就需要主动的表达自己的观点。对于技术架构复杂的部分，是软件固有复杂性的，理解并分享理解的过程给更多的人；是软件质量不足造成的额外复杂性的，挑战并着手修复。
小伙伴们注意啦～
为了可以给 TiDB 社区 的小伙伴提供更加好的体验，我们开通认证入口啦~完成认证，即可获得**“加急**”处理问题权限，加快问题响应速度：https://tidb.io/account/organization/new
TiDB 社区精美周边领取指南： TiDB 帆布包； TiDB 解压魔方； TiDB 纪念款金属芯签字笔1支 ；TiDB 三合一充电线，任一款周边 【人人有份】TiDB 社区精美周边获取指南，人手一份
