社区 | 如何优雅降落到 TiDB 星球？

提到「开源项目 TiDB」人们总是习惯性反应：它在 GitHub 上 Star 数已经超过 17000，并拥有 260+ 位全球各地的 Contributors 。但数据总归是冷冰冰的，不能生动的展现 TiDB 社区的魅力。所以今天推送一篇 TiDB contributor 杜川同学加入 TiDB 社区前后的「心路历程」，他从亲历者的角度告诉你——

PingCAPer 够 nice 么？ 积极参与 TiDB 社区对自己的能力提升有何帮助？ 如何在 TiDB 星球上找到最适合自己的落点？（ 或者在大树上找到自己最擅长的“小树杈”hhhhhh） 以及…利用好碎片时间，你也可以一年给 TiDB 提 70 个 PR！

🚀 作者：杜川，TiDB contributor

最近这一年多断断续续一直在往 TiDB 中提交一些修改，前两天看了一些 GitHub 提交记录，发现竟然已经累计了 70 来个 PR 了。考虑到最近这一年基本处于疯狂加班的节奏，另外忙里偷闲还基本上刷完了之前列的十几本书的读书清单，我觉得这也算一个不大不小的成就吧，值得 mark 一下。

话说回来，虽然我 17 年年中才开始给 TiDB 提交 PR，其实在之前一年多以前，大概在 2016 年 4 月份左右, 就听说过 TiDB 这个项目了。当时我的主要工作也是车一个 SQL 执行引擎，所以对分布式数据库业界的相关新闻还是比较关注的。

虽然数据库是一个轮子高发领域，各种轮子五花八门，但是在国内，数据库，特别是分布式数据库这块的轮子，基本还是几个大厂在车，要么不开源，要么开源了社区也不甚活跃。像 TiDB 这样要从头车一个分布式数据库，并且还是完全开源的方式来搞，确实让我印象深刻。后来组里一个小哥离职投奔 PingCAP，我借着面基的名义陆陆续续参加了 TiDB 几次线下 Meetup，也由此认识了很多 TiDB 社区的小伙伴。

16 年底从北京回到成都以后，工作重心发生了一些变化，从之前的纯做 infra，转变为更多地要面对业务层面的需求。不过做了几年 infra，自己本身对数据库内核还是很感兴趣的，所以工作之余，开始研究 TiDB 的实现，并且搭了一套 TiDB，在开发环境里代替 MySQL。我们都知道，MySQL 经过多年的发展，其 SQL 语法是比较复杂的。TiDB 虽然全面兼容 MySQL 的语法和协议，但是因为没有复用 MySQL 代码，肯定不可能做到 100% 兼容，落实到一些具体的语句上，肯定会和 MySQL 有一些区别。因为之前我也一直在做 OLAP 系统的 SQL 引擎的开发工作，对这一块比较熟悉，在遇到这方面问题后，感觉解决起来也并不很麻烦，因此慢慢开始在这个方面给 TiDB 提一些 PR。到后面熟悉了以后，有时间的话也会到 TiDB 的 issue list 上捞相关的 issue 解决，主要集中于 SQL Parser, 表达式计算和 MySQL 兼容性等方面。最近抽空在做的是和聚合函数相关的一些 Feature。

因为平时工作还是比较忙，加班也是家常便饭，因此给 TiDB 提交 PR，回复 Review 意见的时间段基本都集中在周末，晚上老婆睡觉以后，或者午休间隙。这样有一个问题是时间段比较离散，很难有长时间的连贯思考的时间。因此现阶段一方面我在提 PR 的时候会选择一些相对较小，独立一些的 Feature。另一方面，我尽量把开发放在时间相对充裕的周末，把晚上和其他零碎时间用来查看和回复 Review 意见，Update 代码和跑回归测试。这样算下来，平均提交一个 PR，算上开发，测试，和社区小伙伴沟通，大概要消耗 3 到 5 个工时。

不过这个时间投入我觉得倒是非常划算，一是因为我本身对数据库就非常感兴趣，把参与 TiDB 社区开发当成了一种兴趣，可以看做是工作之余的一种放松，二是我一直在从事数据库相关的工作，包括之前 OLAP SQL 引擎的运行时优化相关工作，和现在云数据库相关的工作，其实和在社区所做的事情都是密切相关的。比如一个 MySQL Builtin 函数, 在各种极端输入下的表现是怎样的，或是 SQL_MODE 的各种组合对这个 Builtin 函数的行为有什么样的影响，这些问题在平时工作中，我可能很难考虑得非常周全；但是要在社区中提一个 PR 实现这个 Builtin 函数，我就非得把这些问题考虑清楚，并经受社区小伙伴各种 Case 的轰炸考验。等这个 PR 顺利被 Commit，这些细节我也烂熟于心了。

image

说到社区，我觉得 TiDB 做得相当不错。一方面 PingCAPers 都很活跃，在 GitHub 上提的 Issue 一般很快就能得到回复, 有什么疑问通过 GitHub, 微信群甚至知乎提问等很快都能得到反馈；另一方面更重要的是在 Review PR 的时候社区小伙伴能保持比较严谨的态度。

就我的经历而言，我在开发过程中没有注意到的一些 Corner Case 和细节错误，基本都能在 Review PR 过程被翻出来，这不仅需要 Reviewer 理清楚 PR 对应 Feature 的相关细节，构造出可能有问题的场景，还需要 Reviewer 理解 PR 作者的开发思路。其中需要花费的精力，常常不低于开发这个 Feature 本身。此外，还有一个我觉得很赞的方面是 TiDB 花了很多心思来构建从 UT，FT 到集成测试的一系列测试框架，让我在参与开发工程中比较容易对自己开发的 Feature 进行各个方位的测试，节省了很多来回捣腾的麻烦。

总的来说，参与 TiDB 社区是一件非常有意思的事情，给我带来很多收获，我也会继续关注 TiDB 项目的进展。短时间来看，我的计划主要还是抽空完成手头聚合函数相关的一些 Feature，包括对 MySQL 聚合函数 STDDEV，VARIANCE 等的支持，以及在 TiKV Coprocessor 侧的对应改动。之后，我打算看看能不能够结合我之前在 OLAP SQL 引擎的运行时优化方面的经验，提升 TiDB 在 OLAP 领域的能力。不过这个是一个比较大的目标了，到时候还要和社区的小伙伴多多讨论。

TiDB 社区大事件

TiDB TechDay2018 即将于 7 月 28 日在深圳举办，目前报名已满，我们周六见哦！点击【这里】查看活动详情。P.S 欢迎踊跃勾搭 TiDB Robot （微信号：tidbai）加入 TiDB 星球～