单刷 3 届 Hackathon，朝着理想中的数据库出发丨TiDB Hackathon 选手访谈

TiDB Hackathon 2022 正在火热报名中，截止目前已经收到 230+ 位参赛者报名，组队近 60 组。想必各位选手已经摩拳擦掌，开始准备自己项目的 RFC 了。在等待比赛日的这段时间，TiDB 社区采访了多位 Hackathon 参赛选手，通过访谈为大家分享一下他们对 Hackathon 的理解和感悟，同时探讨开源给他们的个人生活和工作带来了哪些改变。当然，作为老选手，也会有极其珍贵的参赛经验分享。已经报名参加本届 Hackathon 的选手或是对 Hackathon 感兴趣的小伙们，赶紧看过来！

今天与大家见面的参赛选手是目前在南京邮电大学读研三的陆涣冰同学，其实他的专业方向本来是卫星通信，但内心却十分热爱计算机底层技术，业余时间基本 all in 在开源分布式数据库上。

涣冰同学与 TiDB Hackathon 的缘分源自研一那年：当时看到比赛的信息后就非常想参加，但苦于自己技术水平不够，同时也没找到人组队，差点错过。幸好当时社区的运营同学给了很多鼓励，并说明个人参赛也是规则允许的，这才被引入了 Hackathon 这条路。之后涣冰就一发不可收拾，研一、研二、研三接连三届都参加了 TiDB Hackathon。

以下为采访记录：

Q1：为什么选择单刷的方式参加 TiDB Hackathon？

陆涣冰：其实单刷主要是因为自己想做的一些东西，对于很多人而言比较抽象，比较困难。举例来说，我去年做的题目就是用 eBPF 去加速 TiDB 的底层存储路径。这个项目可能需要比较多的底层知识的铺垫，当时问了一圈发现没人对此感兴趣，最终还是自己一个人参赛。其实拿不拿奖无所谓，玩得开心就好。

参加 TiDB Hackathon 帮我整个研究生的三年开了一个头，之后我又参加了各种开源的比赛，比如阿里的天池数据库大赛、 open Euler 高校开发者大赛等等。

我能开启这条路要感谢两个人。第一个人就是当时的社区运营 yanqing，她对我有某种程度上的知遇之恩，如果没有她我后面的这些经历应该都不存在。第二个人是当时在 P 社实习时的 mentor 施闻轩，他对于我在技术上理解的影响是比较深远。

Q2：最早是在什么时候对编程感兴趣的？

陆涣冰：我本科的专业是网络工程，研究生的专业是信息网络，乍一听起来好像都是计算机学科的分支。那时候其实走了一段弯路，当时整个人掉进了安全的圈里，觉得黑客好酷，什么病毒、逆向都觉得非常酷。但是在深入学习了安全一段时间，就感觉做安全好玩归好玩，但是真的要把这个当做职业，心里感觉还是缺了一点什么。在 2019 年 2 月 1 日，那天是我的生日，所以我印象特别清晰，在跟朋友聊天时，我问自己以后确定要做安全了吗？还是想更深入地写代码？因为当时身边很多做安全的朋友只是敲敲命令行跑跑脚本，感觉中国的安全确实青黄不接，厉害的确实非常厉害，但菜的实在是太菜了。那时候我这方面的技能，不谦虚地讲可以说是炉火纯青了，但是写代码的功底还是一塌糊涂。

和来自美团、百度的一些圈内朋友聊了聊，他们建议可以考虑一下前端业务应用开发或编译器、数据库、操作系统等更底层的开发。当时也是年少无知，就说要不学个数据库吧。于是从那天就一直学到了今天，然后就发现一入数据库深似海，这里面的东西实在是太庞大了。不仅要有系统知识，还要涉及编译器的知识，分布式的知识。伴随着这个学习过程，自己编码的水平也逐渐上来了。

说实话，身边除了自己，再也找不到第二个人做软件开发或者数据库开发。平时在学校的教研室里基本清一色都是前端开发，这三年来，就我一个人坐电脑前自学了三年。在接触到 PingCAP 时，有一种突然找到组织的感觉。

Q3：开源带来的乐趣或收益是什么？

陆涣冰：学习数据库的时候其实已经对开源有了一定的认知，基本上 99% 的知识全部来自于开源，无论对操作系统还是对计算机体系的理解，基本都是构建于开源软件之上的。

第一次接触 Linux，我发现这不就是我想要的操作系统？大家都能改，都能用，改完还能 push 进项目里，开放给别人用。某种程度上开源可以汇聚全人类的智慧去做一些事情。当然开源协作也会有很多问题，比如贡献的代码好不好，有没有漏洞，能不能和别人达成一致协商等等。有些项目写一半甚至不写了，开发者跑了，撂挑子了，这都很常见。包括开源项目的商业化，哪些拿过来可以做出自己的东西，哪些可以二次开发拿去卖，哪些行为是违规的，都需要开源参与者去考虑。

但那时我还只是开源的使用者，到了读研之后，借由数据库才慢慢把手伸得更远一点，开始把自己的代码贡献给别人。

Q4：TiDB Hackathon 与其他比赛在体验上有什么区别？

陆涣冰：那实在是太多了。第一还是人，PingCAP 这边的小助手实在是太热情了，工作做得非常好。我参加了三年，基本上会和每一届的小助手成为朋友。第二点是 Hackathon 的所有项目都构建在 TiDB 之上，TiDB 有非常多的文档，有对于内核、原理的解读，我认为这点在众多参与过的比赛、项目中可以说是最优秀的。这些工作大大减少了开发者想深入了解 TiDB 所需要的时间。举个例子，我在参加某个比赛的时候，他们就干巴巴地放出赛题以及代码框架，剩下就全部交给你自己了，非常不容易上手，新手非常难做。而 TiDB 的源码与文档可以帮助开发者在比赛中减少非常多的时间。

也说说不足，我已经参加了三届，感觉其实有很多 idea 都是前面已经做过的，总会被不断掏出来翻新。建议官方可以把过往的项目整理出来，避免后面的重复。去年有人说 Hackathon 是不是已经没有太多 idea 可以提了，其实我认为随着 TiDB 的发展，加了很多新的 feature 后 TiDB 已经变得越来越复杂，大家原本对于 TiDB 3.0、4.0 的理解放在 6.0 上可能就不适用了，需要再花大精力去做一些有比较有意思的东西。但这可能就需要花很长时间读源码，深入了解 6.0 的设计，这对于外面想参加的人来说就非常困难，所以他们才会说能做的变少了。其实不是变少了，是难度变得太高了，花费的时间成本更高了。

Q5：作为老选手，能不能给新选手分享一下 Hackathon 创意的灵感？

陆涣冰：其实我有一个想法，有一天我们能把编译器、数据库、操作系统打通，把数据库直接放在与操作系统一样的等级上去。我的所有灵感一直都是围绕这个愿望出发的，不要为了比赛而想点子，而是为了做出自己理想中的那个数据库，让现在的数据库朝着理想中数据库出发，看看还有什么缺的地方，一步一步实现。

我今年的思路其实和东旭之前的想法很相似，TiDB 后端现在存储引擎用的是 target 编码，先前计算机如果出了问题，都可以通过添加一层中间件或者中间层来解决。那我就想能不能添加这样一个中间层，把 TiDB 和 TiKV 解耦，让后面的存储引擎能够无缝切换。这是我今年想做的事情，但是不知道能不能做成功，做成什么样子。

Linux 内核进入 6.2 版本之后， Rust for Linux 基本上就能稳定了。当 Rust 进入 Linux 内核之后，能和数据库带来更深层次的互动。这个就是我讲的把操作系统与数据库放在同一个 level，其实一直在朝这个目标在走。

Q6：今年是你第三次参加 TiDB Hackathon，你觉得这些年有哪些变化？

陆涣冰：作为一名底层开发者，TiDB Hackathon 最吸引我的就是比较硬核的技术，比如 TiDB 先进的存储引擎、高效的性能，它能勾起我们的好奇心，去发掘一下这个数据库到底牛在哪。

如果是对于前端开发者而言，TiDB Hackathon 对他们的吸引就是借由 TiDB 能去开发一些有意思的应用，比如说无缝切换，比如更 native 的云原生基础组件，甚至替换 Kubernetes 里的某些功能等等。

我看到今年的赛制发生了一些变化，比如去年大多数比赛环节都安排在 48 小时里，初赛、决赛答辩，时间安排得满满当当。但今年主办方把初赛提前了，这能让选手们准备得更充分。参加 TiDB Hackathon 的大部分选手都是有工作经验的，或者是有 TiDB 使用经验的。他们对于这个数据库有着非常深的理解，可以借由 Hackathon 的机会把一些 actions 提前给做了。但是对于外面的学生或者不是太熟悉 TiDB 架构的人而言，比赛周期的延长就非常有意义了，他们能够有更充足的时间去阅读源码或者阅读文章，加深理解，能把 demo 做得更好一些。我第一届参赛时连 demo 都没有，根本来不及做。

另外，其实这些年我发现身边做底层开发的小伙伴虽然越来越多，但仍旧是杯水车薪。更多的人还是应用开发者，他们关心如何用数据库，而不是开发数据库，所以应用开发这个赛道的增加就很有意义了。应用开发者可以尽可能发挥，用这个数据库做出一些非常有意思的应用，展现出 TiDB 的更多可能性。

Q7：参赛经验分享

陆涣冰：想 idea 的时候千万不能闭门造车，要集思广益，收集一下已有的 RFC 或者 AskTUG 论坛里的一些问题，看一看 TiDB 的痛点在哪儿；再从评委的角度去想一想，是不是能第一时间 get 到你的想法。

我其实还没正式开始写 RFC，我的习惯是先把想法写在纸上，确定好了再腾到电脑上。写 RFC 首当其冲是要表明你的目的，做这个东西是为了解决什么问题；其次描述一下项目的背景，让评委能明白这个项目的定位是在 TiDB 的哪一个技术分支里面；除此之外，要把图画好，这样才能讲好你的故事。我第一次 demo 都没做出来，所以答辩的结果也就不尽如人意。第二次答辩确确实实把这个东西做出来了，做得是不是完美其实没有关系，大部分选手时间都一样紧张，关键在于能把你想做的事情、要做的事情、已经做过的事情讲明白就 OK 了。至于什么花里胡哨的画图、图表、效果，都是锦上添花的东西。

关于如何设计 RFC ，可以参考这里：
https://asktug.com/t/topic/903770

我从本科到现在，参加了百余场比赛，而且每一场都是单刷。其实参加这些比赛的初衷是想把技术学好，想能为别人再做点什么事情，能做出来一些更实用的东西当然最好，不会太过于关注奖品、名次这些事情，更多还是关注于自己的项目和想法有没有实现。即便没有得到评委的认可，也是自己花时间和精力做出来的，这些写过的代码，对于自己的提升是 100% 是有帮助的。

看过涣冰的经历，你心动了吗？点击文末阅读原文了解更多赛事详情！