--- title: '单刷 3 届 Hackathon，朝着理想中的数据库出发丨TiDB Hackathon 选手访谈' date: '2022-10-11T00:00:00+08:00' status: publish permalink: /blog/participated-in-hackathon-3-times-alone author: - 韩锋 - 韩锋 - PingCAP excerpt: '在等待比赛日的这段时间，TiDB 社区采访了多维 Hackathon 参赛选手，通过访谈为大家分享一下他们对 Hackathon 的理解和感悟，同时探讨开源给他们的个人生活和工作带来了哪些改变。' type: post id: 3169 category: - 社区动态 tag: - 'TiDB Hackathon 2022' post_format: [] profile: - PingCAP algolia_posts_post_records_count: - '7' --- [TiDB Hackathon 2022](https://tidb.net/events/hackathon2022) 正在火热报名中，截止目前已经收到 230+ 位参赛者报名，组队近 60 组。想必各位选手已经摩拳擦掌，开始准备自己项目的 RFC 了。 在等待比赛日的这段时间，**TiDB 社区采访了多位 Hackathon 参赛选手，通过访谈为大家分享一下他们对 Hackathon 的理解和感悟，同时探讨开源给他们的个人生活和工作带来了哪些改变**。当然，作为老选手，也会有极其珍贵的参赛经验分享。已经报名参加本届 Hackathon 的选手或是对 Hackathon 感兴趣的小伙们，赶紧看过来！ 今天与大家见面的参赛选手是**目前在南京邮电大学读研三的陆涣冰同学**，其实他的专业方向本来是卫星通信，但内心却十分热爱计算机底层技术，业余时间基本 all in 在开源分布式数据库上。 本期嘉宾：陆涣冰 -------- > 涣冰同学与 TiDB Hackathon 的缘分源自研一那年：当时看到比赛的信息后就非常想参加，但苦于自己技术水平不够，同时也没找到人组队，差点错过。幸好当时社区的运营同学给了很多鼓励，并说明个人参赛也是规则允许的，这才被引入了 Hackathon 这条路。之后涣冰就一发不可收拾，研一、研二、研三接连三届都参加了 TiDB Hackathon。 以下为采访记录： **Q 为什么选择单刷的方式参加 TiDB Hackathon**？ **陆涣冰**：其实单刷主要是因为自己想做的一些东西，对于很多人而言比较抽象，比较困难。举例来说，我去年做的题目就是用 eBPF 去加速 TiDB 的底层存储路径。这个项目可能需要比较多的底层知识的铺垫，当时问了一圈发现没人对此感兴趣，最终还是自己一个人参赛。其实拿不拿奖无所谓，玩得开心就好。**参加 TiDB Hackathon 帮我整个研究生的三年开了一个头，之后我又参加了各种开源的比赛**，比如阿里的天池数据库大赛、open Euler 高校开发者大赛等等。 我能开启这条路要感谢两个人。第一个人就是当时的社区运营 yanqing，她对我有某种程度上的知遇之恩，如果没有她我后面的这些经历应该都不存在。第二个人是当时在 P 社实习时的 mentor 施闻轩，他对于我在技术上理解的影响是比较深远。 **Q 最早是在什么时候对编程感兴趣的**？ **陆涣冰**：我本科的专业是网络工程，研究生的专业是信息网络，乍一听起来好像都是计算机学科的分支。那时候其实走了一段弯路，当时整个人掉进了安全的圈里，觉得黑客好酷，什么病毒、逆向都觉得非常酷。**但是在深入学习了安全一段时间，就感觉做安全好玩归好玩，但是真的要把这个当做职业，心里感觉还是缺了一点什么**。在 2019 年 2 月 1 日，那天是我的生日，所以我印象特别清晰，在跟朋友聊天时，我问自己以后确定要做安全了吗？还是想更深入地写代码？因为当时身边很多做安全的朋友只是敲敲命令行跑跑脚本，感觉中国的安全确实青黄不接，厉害的确实非常厉害，但菜的实在是太菜了。那时候我这方面的技能，不谦虚地讲可以说是炉火纯青了，但是写代码的功底还是一塌糊涂。 和来自美团、百度的一些圈内朋友聊了聊，他们建议可以考虑一下前端业务应用开发或编译器、数据库、操作系统等更底层的开发。当时也是年少无知，就说要不学个数据库吧。于是从那天就一直学到了今天，然后就发现**一入数据库深似海，这里面的东西实在是太庞大了。不仅要有系统知识，还要涉及编译器的知识，分布式的知识**。伴随着这个学习过程，自己编码的水平也逐渐上来了。 说实话，身边除了自己，再也找不到第二个人做软件开发或者数据库开发。平时在学校的教研室里基本清一色都是前端开发，这三年来，就我一个人坐电脑前自学了三年。在接触到 PingCAP 时，有一种突然找到组织的感觉。 **Q 开源带来的乐趣或收益是什么**？ **陆涣冰**：学习数据库的时候其实已经对开源有了一定的认知，基本上 99% 的知识全部来自于开源，无论对操作系统还是对计算机体系的理解，基本都是构建于开源软件之上的。第一次接触 Linux，我发现这不就是我想要的操作系统？**大家都能改、都能用，改完还能 push 进项目里，开放给别人用。某种程度上开源可以汇聚全人类的智慧去做一些事情**。当然开源协作也会有很多问题，比如贡献的代码好不好，有没有漏洞，能不能和别人达成一致协商等等。有些项目写一半甚至不写了，开发者跑了，撂挑子了，这都很常见。包括开源项目的商业化，哪些拿过来可以做出自己的东西，哪些可以二次开发拿去卖，哪些行为是违规的，都需要开源参与者去考虑。 但那时我还只是开源的使用者，到了读研之后，借由数据库才慢慢把手伸得更远一点，开始把自己的代码贡献给别人。 **Q TiDB Hackathon 与其他比赛在体验上有什么区别**？ **陆涣冰**：那实在是太多了。**第一还是人**，PingCAP 这边的小助手实在是太热情了，工作做得非常好。我参加了三年，基本上会和每一届的小助手成为朋友。第二点是 Hackathon 的所有项目都构建在 TiDB 之上，**TiDB 有非常多的文档，有对于内核、原理的解读，我认为这点在众多参与过的比赛、项目中可以说是最优秀的**。这些工作大大减少了开发者想深入了解 TiDB 所需要的时间。举个例子，我在参加某个比赛的时候，他们就干巴巴地放出赛题以及代码框架，剩下就全部交给你自己了，非常不容易上手，新手非常难做。而 TiDB 的源码与文档可以帮助开发者在比赛中减少非常多的时间。 也说说不足，我已经参加了三届，感觉其实有很多 idea 都是前面已经做过的，总会被不断掏出来翻新。建议官方可以把过往的项目整理出来，避免后面的重复。去年有人说 Hackathon 是不是已经没有太多 idea 可以提了，其实我认为随着 TiDB 的发展，加了很多新的 feature 后 TiDB 已经变得越来越复杂，大家原本对于 TiDB 3.0、4.0 的理解放在 6.0 上可能就不适用了，需要再花大精力去做一些有比较有意思的东西。但这可能就需要花很长时间读源码，深入了解 6.0 的设计，这对于外面想参加的人来说就非常困难，所以他们才会说能做的变少了。其实不是变少了，是难度变得太高了，花费的时间成本更高了。 **Q 作为老选手，能不能给新选手分享一下 Hackathon 创意的灵感**？ **陆涣冰**：其实我有一个想法，有一天我们能把编译器、数据库、操作系统打通，把数据库直接放在与操作系统一样的等级上去。我的所有灵感一直都是围绕这个愿望出发的，**不要为了比赛而想点子，而是为了做出自己理想中的那个数据库，让现在的数据库朝着理想中数据库出发，看看还有什么缺的地方，一步一步实现**。 我今年的思路其实和东旭之前的想法很相似，TiDB 后端现在存储引擎用的是 target 编码，先前计算机如果出了问题，都可以通过添加一层中间件或者中间层来解决。那我就想能不能添加这样一个中间层，把 TiDB 和 TiKV 解耦，让后面的存储引擎能够无缝切换。这是我今年想做的事情，但是不知道能不能做成功，做成什么样子。 Linux 内核进入 6.2 版本之后， Rust for Linux 基本上就能稳定了，**当 Rust 进入 Linux 内核之后，能与数据库更深层次的互动**。这个就是我讲的把操作系统与数据库放在同一个 level，其实一直在朝这个目标在走。 **Q 今年是你第三次参加 TiDB Hackathon，你觉得这些年有哪些变化**？ **陆涣冰**：作为一名底层开发者，**TiDB Hackathon 最吸引我的就是比较硬核的技术，比如 TiDB 先进的存储引擎、高效的性能，它能勾起我们的好奇心，去发掘一下这个数据库到底牛在哪**。 如果是对于前端开发者而言，TiDB Hackathon 对他们的吸引力就是**借由 TiDB 能去开发一些有意思的应用**，比如说无缝切换，比如更 native 的云原生基础组件，甚至替换 Kubernetes 里的某些功能等等。 我看到今年的赛制发生了一些变化，比如去年大多数比赛环节都安排在 48 小时里，初赛、决赛答辩，时间安排得满满当当。但今年主办方把初赛提前了，这能让选手们准备得更充分。参加 TiDB Hackathon 的大部分选手都是有工作经验的，或者是有 TiDB 使用经验的。他们对于这个数据库有着非常深的理解，可以借由 Hackathon 的机会把一些 actions 提前给做了。**但是对于外面的学生或者不是太熟悉 TiDB 架构的人而言，比赛周期的延长就非常有意义了**，他们能够有更充足的时间去阅读源码或者阅读文章，加深理解，能把 demo 做得更好一些。我第一届参赛时连 demo 都没有，根本来不及做。 另外，其实这些年我发现身边做底层开发的小伙伴虽然越来越多，但仍旧是杯水车薪。更多的人还是应用开发者，他们关心如何用数据库，而不是开发数据库，所以应用开发这个赛道的增加就很有意义了。应用开发者可以尽可能发挥，用这个数据库做出一些非常有意思的应用，展现出 TiDB 的更多可能性。 **Q 参赛经验分享** **陆涣冰**：想 idea 的时候千万不能闭门造车，要集思广益，收集一下已有的 RFC 或者 AskTUG 论坛里的一些问题，看一看 TiDB 的痛点在哪儿；再从评委的角度去想一想，是不是能第一时间 get 到你的想法。 我其实还没正式开始写 RFC，我的习惯是先把想法写在纸上，确定好了再腾到电脑上。**写 RFC 首当其冲是要表明你的目的，做这个东西是为了解决什么问题；其次描述一下项目的背景，让评委能明白这个项目的定位是在 TiDB 的哪一个技术分支里面；除此之外，要把图画好，这样才能讲好你的故事**。我第一次 demo 都没做出来，所以答辩的结果也就不尽如人意。第二次答辩确确实实把这个东西做出来了，做得是不是完美其实没有关系，大部分选手时间都一样紧张，关键在于能把你想做的事情、要做的事情、已经做过的事情讲明白就 OK 了。至于什么花里胡哨的画图、图表、效果，都是锦上添花的东西。 关于如何设计 RFC ，可以参考这里： 我从本科到现在，参加了百余场比赛，而且每一场都是单刷。其实参加这些比赛的初衷是想把技术学好，想能为别人再做点什么事情，能做出来一些更实用的东西当然最好，不会太过于关注奖品、名次这些事情，更多还是关注于自己的项目和想法有没有实现。即便没有得到评委的认可，也是自己花时间和精力做出来的，这些写过的代码，对于自己的提升是 100% 是有帮助的。 ? 看过涣冰的经历，你心动了吗？了解 [TiDB Hackathon 2022](https://tidb.net/events/hackathon2022) 更多详情，立即报名参加吧！