作者介绍：唐刘，PingCAP VP of Engineering，TiDB Hackathon 2021 特邀评委。
TiDB 2021 Hackathon 终于落下帷幕，最开始我还担心，今年 Hackathon 还有啥东西能出来，结果却大大超出我的预期，很多项目真的能用惊艳来形容，大家都在自嘲，说『内卷得太厉害』。作为评委，全程参与了预赛内核组以及决赛的答辩，还是有很多感触的，之前已经写了一篇预赛的点评（点击文末“阅读原文”即可查看） ，这次也对决赛做一次不负责任的点评。
决赛这次有 20 个项目，我大概分几个维度做一个统一介绍。
这次在 TiDB 内核上，做的不少性能提升功能真的很惊艳，因为我预赛点评的主要是内核组的东西，所以在这里简单进行一下汇总。这个功能通过 Region Cache 统计信息的方式来加速全表的 analyze，在表越大的情况下，收益会越加明显。一方面加速了 analyze 的速度，另外一方面也能缓解 analyze 造成的大量 IO 和 CPU 开销，降低了系统的压力。不过这个实现有一个前提假设，就是大部分业务仍然是热点更新，或者增量写入为主。不过即使出现了大范围的更新，因为统计信息现在直接是放在 region cache 的，实际在 full analyze 的时候，效果也可能会比现在的实现要好。另外，我们后面可能还可以通过 TiFlash 进行 analyze 的操作，这样也会快很多。这个项目虽然之前不是在内核赛道，但我觉得这玩意足够 hardcore 了。这也是我们在之前 PoC 过程中实际遇到的一个问题，我们发现调整一些内核的配置，或者 Go GC 的调整，性能就能提升。这次就是针对 iTBL-Cache-Miss 的问题进行优化。然后大家将 .text 这个 segment 映射到了 hugepage 上面，降低了 cache miss，提升了性能。本来评委还担心用了 hugepage 性能会不会下降，但实际这里并不是全局打开的 transparent hugepage，而只是单独的将某一段区间的数据 remap 到了 hugepage 上面。
这个项目是我觉得最硬核的项目，我自己也给了非常高的分数，不过遗憾的是，可能太过于硬核，很多评委都不知道它在说什么（因为并不是所有评委都非常了解 TiDB 的内部机制），最终只得了三等奖，我个人觉得这个项目其实是能冲击一等奖的。
TPC 这个项目做了非常多的工作，虽然能预感到后续落地的难度，我还是很期待的，毕竟这也在我们的 roadmap 上。我们用了 io uring，不过貌似也遇到了不少的坑，后面也可以选择 AIO，或者单独的异步线程机制都可以。因为用了新的 raft engine（这个会在 TiDB 5.4 GA），也能很方便地做 parallel log write，充分利用多队列 IO 特性，这个在云上也是很关键的，因为 EBS 单线程的写入 IOPS 其实真不高。另外，后面大家还会去掉 KV RocksDB 的 WAL，这样几个线程池就真能合并，只做计算操作，IO 操作都完全变成异步。通过 Lightning 来加速 add index
这个也是我非常喜欢的一个项目，也是我们在实际 PoC 中多次遇到的一个问题。通过 Lighting 直接 ingest SST，能极大地提升 add index 的速度，决赛实际展示的效果也是把性能提升了一个数量级。这个功能也是在我们的 roadmap 上面的，所以后面我还蛮期待的。另外，其实只要解决了 Lighting ingest SST 过程中，另外操作 update 等操作冲突问题，那么我们完全可以让 Lighting 支持 online 导入。另外在云上面，未来我们可以通过 EMR 这些来进行排序，然后将数据先写入到 S3，再让 TiKV 从 S3 拉取，或者直接使用 S3 的数据。这个项目对于运维同学来说是在某些时候能救命的功能。TiDB 在数据存储上面，使用的是 MVCC 机制，也就是一条数据，可能会有多个版本，所以即使用户误删除了这一条数据，我们仍然可以在老的版本上面将其恢复。现在的恢复流程就是先用一个老的版本号（这里就是 timestamp）查询到老的数据，然后将其重新插入回去。这个操作对于单条要恢复的数据还是比较简单的，但如果我们是一批数据的恢复，操作就非常麻烦。这个项目通过 SQL 很好地解决了运维的操作问题。更赞的是，该项目引入了多 safepoint 机制，也就是可以给 TiDB 集群定期做一些全局 snapshot，进行快速轻量级的逻辑备份。不过随着要保存的 snapshot 增多，数据的 MVCC 版本也会增多，对于 scan 这种操作可能会有影响，后面如果我们将历史版本移动到另外的地方，这个问题就能缓解了。这个项目我也觉得非常赞，甚至我认为不光是在云上面，TiDB 的智能运维收益，在 OP 上面， TiUP 也是可以借鉴的。我们在升级的时候，可以引入更多的策略，譬如只让副本的 leader 切换一次，或者根据 TiKV 当前的热点、流量等来判断是否该节点能升级。这些策略能很好地降低升级过程对用户业务的影响。这个项目获得了本次 Hackathon 的一等奖，再跟本次 Hackathon 另外一个类似项目联合，会为后面 TiDB 跟 S3 的整合打下不错的基础，至少这次 Hackathon 验证了可行性。其实原理很简单，将冷的数据放到 S3，然后将算子尽量地下推到 S3，通过 S3 原生的 Select 功能来加速查询。当然，如果数据已经在 S3，我们还可以通过云上面其他的服务，譬如 Athena， 来做更多的查询聚合操作，加速查询。这次大家都是在通过 partition 做文章，毕竟根据时间片来分 partition 是很常用的一种操作，我们内部现在也在通过 LSM 做一些跟 S3 整合的研究，我还是很期待这些都能在今年看到成果。譬如我们的 TiDB Cloud Developer Tier 集群就可以完全用这套机制来先验证。今年 Hackathon 我个人觉得最开心的应该是凯哥，他现在负责 TiDB 可观测性以及诊断易用性提升，今年的几个项目做好了都可以很好地落地，其实有一些都已经在我们的 roadmap 里面了。Matrix 是 PingCAP 同学跟华中科技大学的同学一起弄的一个项目，不得不说，现在的学生真的是很牛。通过这个项目我才知道，原来 TiDB 5.3 已经有 800 多个参数了，所以后面我们真的需要出一些开发原则，譬如如何来增加参数、配置、session variable 等，不然后续调优会更加困难。其实之前 Hackathon 也有不少的自动 tune 的尝试，但这次我觉得很大的一个突破点，是在于该团队可视化了重要参数的影响程度。自动诊断(Collie) 团队的队名（我们这么菜评委不会生气吧）还是蛮有意思的，其实你们一点都不菜，而且还帮助优化了 TiUP diag 的功能，这个已经很厉害了。通过这个项目我才知道，原来我们 metrics 指标已经快 8000 个了，说实话，我觉得再发展下去，人已经没法 debug 了……
日志也是 TiDB 里面一个急需优化的点，我们打了一些无用的日志，这个后面需要清理，但在诊断问题的时候，我们需要对日志进行关联分析，以及观察某一个日志的趋势，提前发现问题。Naglfar 在这块开了一个不错的头。当我终于看到可视化的执行计划时，我几乎留下了激动的泪水。毕竟我们之前诊断慢 SQL 实在是太苦了，那么一大屏的执行计划，几乎叫做没法看，而且如果要对比两个执行计划的异同，就更崩溃了。有了可视化，至少分析到底哪里慢的效率会提升很多，而且后面我们完全可以将 SQL advisor 的功能直接整合到 TiVP 上面，让大家直接在线能进行 SQL bind，add/drop index 这些操作。看完这个项目，我立刻问了下 wish 同学，他直接甩给我一张更漂亮的 Visual Plan 的图，原来已经排在了 roadmap 里面，大家拭目以待。今年的生态，可以用百花齐放来形容吧，看到了太多不一样的东西。我其实一直非常喜欢生态相关的项目，如果说 Hackathon 内核相关的项目是增加 TiDB 的技术深度，那我觉得生态这块就是扩大 TiDB 的广度。对一个数据库来说，『广』就意味着市场占有率的提升。去年 TiGraph 已经让大家惊艳，今年 TiMatch 更让人期待了。这次易用性更好，而且对于老集群也能直接升级使用。因为 TiMatch 只是内部建立了一套 graph index，通过 TiDB 分布式事务机制，跟原先关系表的数据统一更新。语法上面，借鉴了 Oracle graph 的语法，所以已经是关系完备的了，不过我觉得后面的挑战在于性能上面，希望下一届该项目能给大家展示相关的数据。
去年 Hackathon 其实有不少跟 Flink 整合的项目，不过今年决赛就看到一个，说实话我还是有点小失望的。但今年 TiLaker 做的还是挺完备的，毕竟有 Flink Committer 的参与，大家给 Flink 实现了一个 CDC Connector，这样能让 Flink 直接读取 TiDB 的增量数据，同步到下游了。借助 Flink 的能力，让 TiDB 更好地跟下游生态进行了打通，后面也希望有不少的应用案例能出来。这是一个非常有意思的项目。贵司的 CTO 东旭同学直接上场带货，先抛开他个人极大的现场感染力，从实际来看，pCloud 做得真的很不错。东旭只是展示了产品效果，聊了聊商业模式这些，但我其实是知道这个项目的底层实现的，还是很有挑战的。不过这也给了下一届 Hackathon 参赛的同学另一种参考，一个项目，有时大家更容易关注技术本身，但如果我们是做一个产品，或者一个 SaaS 服务，对于用户及商业的理解也是非常关键的。所以即使大家觉得自己对 TiDB 没太多理解，写不了太硬核的程序，也可以从另外的方向来突破。这个项目也挺有意思，晓光在 Weir 上面实现了一些 plugin，扩展了 TiDB 的功能。譬如他写了一个 Redis 的 plugin，为 TiDB 提供了缓存支持的能力，不过我现在在想，是不是 TiDB 自己把 plugin 机制做好一点更好？现在我们的 plugin 是用 Go 自带的 plugin 机制，在可扩展性、可维护性上做得不怎么好，如果我们用了 Hashicorp 的 go-plugin，通过 RPC 来交互，虽然性能有损失，但会不会效果更好？这块未来可以跟晓光他们继续探讨下。这是我最喜欢的一个项目，我个人给了最高的分数，并不是因为 Sai 同学激情的演讲，也不是因为炫酷的 web 界面，而是我看到了 TiDB 如何能能更好地吸引开发者的一个方向。针对开发者学习 TiDB 这个问题，后面我相信大概率就是一个 SaaS 服务，开发者通过浏览器就能直接学习了解 TiDB。这个项目让我看到了落地的可行性，我也希望能快速的落地。不过我也知道，当下最重要的是让 TiDB Cloud 支持 GitHub SSO 登录、支持 OpenAPI，变得对开发者更加友好，这样才能为后面的生态扩展打下基础。
当然，这里只是列出来大部分的项目，还有一些项目没在这里详细点评，譬如 TiTravel，oom.ai，TiMultiple，Bubbles 等，都是很不错的项目，后面有空再补充下，大家可以自己去了解关注下。
总的来说，这次 Hackathon 做了两天的评委，在体力和脑力上被严重的 burn out，但还是让我非常兴奋，因为我看到了 TiDB 未来无限的可能性，这次 Hackathon 的 slogan 是 Explore the Sky。Sky 离我们并不遥远，譬如我现在就在高空、在飞机上写这篇文章 :-)不过这次 Hackathon 还是有点小遗憾的，我个人认为 Hackathon 的一个精髓就是 24 小时的高强度编程，但因为疫情原因，没法实现，希望疫情在今年能有所好转，大家带着睡袋，在 PingCAP 办公室写程序那种经历还是非常有意思的。
