TiDB 2022 Hackathon产品组决赛的“不负责任”点评

一年一度的 TiDB Hackathon 终于落下了帷幕，这次 Hackathon 分成了两条赛道，产品组和应用组，我做为产品组的决赛评委，全程参与了整个决赛 32 个项目的答辩，见到了很多有意思的项目，这里也不负责任地点评一下了。（点击文末【阅读原文】，查看完整答辩回顾）

本文作者：唐刘，PingCAP 研发副总裁。

我最喜欢的三个项目

既然是我的不负责的点评，首先就先来一点私货，先说说我最喜欢的三个项目，不过很遗憾，这三个项目都没拿到第一名。

TiFlash Collocated Optimization

首先就是「我垫你们蹲」队伍的TiFlash Collocated Optimization 的项目，（RFC 链接：点击此处查看 ）

当我一开始看到这个项目的设计文档的时候，我就对这个项目非常的期待了。极致的性能一直是我们追求的目标，虽然通过 TiFlash，在很多场景都能为客户进行查询的加速，但在一些场景下，TiFlash 的处理能力还是不够，一个很大的原因就在于 TiFlash 缺少 colocated join 的支持，这样就会导致 MPP 在计算的时候，会出现很多的 shuffle，影响了性能。

为了解决这个问题，我垫你们蹲团队采用了一个非常传统的优化方式，就是『空间换时间』，他们给 TiDB 增加了一种新的 index，叫做 redistributed index，能让用户按照特定的数据 partition 规则，将对应的数据调度到同一个节点上面，减少 shuffle。redistributed index 类似于 TiDB 的 clustered index，它存储的值是整个 row，所以我们直接能在节点上面进行所有相关数据的计算。

为什么我非常喜欢这个项目，一方面它尝试解决 TiDB 的一个性能痛点，另外一个就是我看到了 TiDB 未来的一个演化方向，也就是 index service，其实无论是 TiKV，还是 TiFlash，都可以认为是一种 index，便于 TiDB 快速的获取数据。不光如此，我们也可以构建其他独立的 index service，譬如 search index，或者 GIS index，满足特定应用的需求。为了保证数据一致性，整个完全可以通过 Raft 协议来构建。当然，我们还需要有一个强大的优化器，以及执行引擎，能根据负载在不同的 index 上面进行选择。如果能做到这些，TiDB 真的就是非常的强大了。

TiDB 计算微服务

「Canopus」队伍的 TiDB 计算微服务这个也是我非常喜欢的项目（RFC 链接：点击此处查看 ），而且这应该是我认为，在 TiDB cloud 会立刻能落地的一个项目。

微服务化是 TiDB 后面架构重构的一个指导方向，我们在云上面会拆分一切能拆分的组件，第一阶段，我们会对 TiDB 的一些后台服务进行拆分，其中就包括了 DDL。

Canopus 在本次 Hackathon 进行了探索，不过实话，他们这几个本来就是开发 TiDB DDL 的同学，所以从某一层面来说，就是把后面要做的事情，提前到 Hackathon 来展示了。

TiDB 中的 DDL add index，虽然是一个后台的操作，但在 6.3 之前，一个很大的挑战就是速度，因为 TiDB 要从 TiKV 中读取数据，然后在一个事务中生成要添加的 index 数据，然后写回到 TiKV 中。在 6.3 的时候，我们做了一个非常大的优化，就是 TiDB 读取数据之后，直接生成 SST 文件，ingest 到 TiKV 中。这个优化之后，整体的 add index 性能能提升 3 - 4 倍，但 add index 还有另一个问题需要解决，就是在 add index 的时候对在线系统的影响。

在云上面，我们其实非常容易解决这样的问题，我们可以

剥离出来一个 DDL service，处理 add index 操作，这样就不用影响 TiDB 了。

因为新写入的 index 不会跟其他的数据冲突，所以我们可以先启动额外的 TiKV，让 DDL service 快速的将数据写入到这些 TiKV 上面

缩容这些 TiKV 节点，通过 TiKV 自己的调度机制，将数据重新搬迁到之前的 TiKV 上面

通过这样的方式，我们就能不光能加速 add index，也可以保证 add index 不影响在线的系统。当然后面我们可以做的更多，譬如 SST 文件的数据直接下推到 TiKV 生成，以及有了 DDL service，我们完全可以做分布式完全并行的 add index，这些都在 TiDB 的 roadmap 上面。

TiFancy

TiFancy 也是我非常喜欢的一个项目，致力于提升 real-time AP 的 serving 能力（项目链接，点击此处即可查看 ）。对于比较重的 AP 请求而言，我们通常会限制它的并发，因为太多的并发会将整个系统打爆。

要解决这个问题，一个很常用的做法就是 cache。但 cache 又有另外的一个问题，就是查询结果的及时性，但这个在 TiDB 中还是比较容易解决的，原理如下：

第一次查询之后，TiFancy 将结果进行缓存，缓存的时候，会同时记录当前的 timestamp

创建一个 memory sink，开始订阅数据的变更，这个其实就是借用的 CDC 的机制

数据变更之后，直接更新 cache，保证 cache 的实时性

这个机制其实挺简单的，但还是有不少的事情需要考虑，譬如对于一些查询，类似 avg，min，max 这种，其实是一种有状态的查询，TiFancy 也借用了 Flink 流式计算的思路，引入了 Cache State 来做增量计算。

这个项目为啥我非常喜欢，主要是一方面看到了通过 cache 支持 AP serving 的能力，另外一个就是我看到了一点 materialized view 的影子。

性能之巅

每年的 Hackathon，都有不少的性能挑战的项目，这一次的第一名「摸鱼就是」队伍的 Double MyQPS 也是跟性能有关的（RFC 链接：https://github.com/flowbehappy/double_my_qps，复制链接至浏览器即可查看），Double MyQPS 主要做了两个优化：

开启 RocksDB multi get 的 async IO 的功能

将相同的 pattern 的请求，攥成一批，也就是通常的做 batch，batch 里面调用 TiKV 的 multi get 接口

虽然最终的效果上面，并没有 double，但取得了 60% 的提升也是非常不错的。

另外一个让我觉得很实用的功能来自于「The Powerful Elephants」队伍的 make table cache a little better（RFC 链接：https://github.com/dbsid/Better-Table-Cache-RFC，复制链接至浏览器即可查看），当前 TiDB 支持了 Cached Table，如果对 table 是写少读多的场景，并且这个 table 不大，譬如常用的配置表，我们完全可以将这个 table 进行 cache。但当前 TiDB 的机制有一个比较大的性能问题，如果要更新 Cached Table，为了保证数据正确性，我们会有一个 lease 机制等待所有 TiDB 上面这个 lease 过期之后，才能写入，这样写入的性能会降低。

为了解决这个问题，The Powerful Elephants 团队使用了一个非常简单的策略，在 lease 基础之上，引入了及时通知的机制，如果对 Cached Table 有写入，当前写入的 TiDB 会及时的通知其他的 TiDB，让 cache 过期，然后就能写入了。这样就能提升整个 Cached Table 的写入性能。其实我们的 DDL 机制也是类似的做法，所以后面其实可以用一套框架来统一类似的任务。

另外一个在性能上面让我很感兴趣的就是「热点清零」团队的 Fearless Write Hotspot 这个项目（RFC 链接：https://gist.github.com/OneSizeFitsQuorum/da4b1e12b9f216fd3b42e88c57fd9e55，复制链接至浏览器即可查看）。

热点问题是 TiDB 一个比较难处理的问题，虽然我们做了很多的优化，但对于单个 key 这种的热点，或者 append only 的情况，还是有很大的挑战，主要在于这些操作都会在同一个 region 发生，而我们很难通过 region 切分打散的方式来分散热点。要解决单个 region 的热点问题，只能对这个 region 读链路进行优化。热点清零团队这里使用了 parallel Raft，相比于 TiDB 原生的 Raft 算法，parallel Raft 能很好的提升单个 Region 内部多个 Key 的并发写操作。我个人对于这个项目还是蛮期待的，不过也深深的知道要把 parallel Raft 给应用到 TiDB，难度会是非常的大。所以在云上面，我们会不会有一个更好的机制来处理热点，是一个很值得探讨的话题。

功能增强

除开性能，本次 Hackathon 也有不少的同学尝试给 TiDB 添加一些新的功能，还是蛮有意思的。

首先就是「更实用，更易用」队伍的 TiDB holding hands with S3 项目，这个非常的直观易用，其实就是增加了 select into S3 的功能，完成度还不错，当然要真正的在生产级别支持，还需要做容错、重试、安全等工作，不过可以一步一步来。我们当前通过 br 命令其实已经能支持将 TiDB 备份到 S3，后面我直观想到的就是支持 BR 的 SQL 应该就可以了。

另外一个让我比较感兴趣的项目是「Jiekun」队的 FSDS（RFC 链接：https://gist.github.com/jiekun/ac4387b613e91c2d4142df35614cab34，复制链接至浏览器即可查看），主要就是让 CDC 支持了同时全量 + 增量的导出同步功能。这个想法还是挺巧妙的，之前为了将 TiDB 同步到下游数据库，一个常用的做法就是先用 dumpling 导出来全量数据以及对应的 timestamp，然后用 CDC 从这个 timestamp 继续增量同步。所以如果 CDC 如果能直接同步全量数据，整个易用性将会好很多。FSDS 项目非常一个大的创新就是通过分片 scan 全量的数据，并且将其伪装成 insert，让 CDC 能直接同步出去。当然如何非常好的处理全量数据以及对应的增量更新，是这个项目的一个很大的挑战。

Search 一直是历届 Hackathon 大家都踊跃挑战的一个方向，本次 Hackathon 也诞生了「煮酒论英雄」队的 TiInverted 项目（RFC 链接：https://gist.github.com/Dousir9/3600403b85739a8653906e89fa6371bd，复制链接至浏览器即可查看），该项目一个创新就是将分词直接存到了 TiKV 这边，建立了一个倒排索引，让 TiDB 提供了全文检索的能力，实际的效果也还是挺不错的，只不过当前的实现对于更新的处理比较暴力。

另外一个项目是 Leonardo（RFC 链接：https://github.com/yiwen92/Hackathon2022_GIS/blob/main/README.md，复制链接至浏览器即可查看），给 TiDB 增加了 GIS 功能，实际展示的 demo 也是非常炫酷的，但是当前的是实现并没有给 GIS 建立很好的索引，所以 GIS 的查询操作几乎全是暴力扫。

提到 Search 和 GIS，这些都是我们后面想去做的，但到底怎么做，当前我还没太多的想法，在结合到上面我提到的 index service，没准可以通过这样的方式来让 TiDB 支持。

易用性提升

今年在易用性上面，有几个项目让我眼前一亮，尤其是在可视化上面，这些其实都是很好落地的项目。

TiDB 发展到现在，配置已经非常多了，反正我现在已经不知道我们有多少个配置了。配置多了，一个很挑战的问题就在于升级的时候配置是否兼容，所以如果我们有一个很好的工具，能非常方便的处理不同版本之间配置的异同，以及定位到这些不一致是什么提交引入的，那么对于我们处理兼容问题将会有很大的帮助。本次 Hackathon，「你说都对」配置兼容性看护项目（RFC 链接：https://gist.github.com/seiya-annie/95272e315b8ecab27731c579f4d6c2f6，复制链接至浏览器即可查看）就干了这样的事情，而且是一个能立马落地的项目，我也希望在后面我们发版本，以及上线新版本的时候能用上。

另外几个项目，都比较类似，包括 AutoIndex，Optimizer trace，还有 Sibyl，都是在可视化上面做了文章，包括但不限于 SQL advisor 等，我也希望后面我们在 tune 上面做的更加的完善，真正能让所有的用户在云上面都有一个 AI 的 TiDB 专家。我们可以脑补一个场景，我们可以完全说 『小 Ti，小 Ti，帮我看看这个性能问题』，是不是挺有意思的。

另外一个对于易用性的改进，是「龙哥说的都」队的 Placement Rules 可视化配置（RFC 链接：https://gist.github.com/disksing/d9c2b2360e4aaafb260664e450855bfd，复制链接至浏览器即可查看），TiDB 提供了非常强大 placement rule 功能，但强大的同时带来的一个问题在于配置的复杂，反正我是不看文档，很难配置好的。所以 Placement Rules 可视化配置项目提供了一个 web 界面，能让大家方便的去给不同的表配置规则，虽然这个相比之前有了很大的进步，但实话，我个人认为仍然复杂了，其实归根还是我们给用户暴露了太多 TiDB 自身的概念，他们要掌握其实挺难的，所以如果真的要简化整个的操作，没准我们要从更底层抽象新的概念对外出去。或者只是针对一些常用的场景提供解决方案。

生态

这次生态上面，最让我眼前一亮的是「go.unwrap()」队伍的 ticli-rs（RFC 链接：https://github.com/hackathon-2022-ticli/rfc，复制链接至浏览器即可查看），一个完成度如此之高的项目，我在点评的时候都没啥可以说的了，所以下一步，我非常希望的就是这个项目能不能变成 TiKV 官方的 cli 项目了。

另外一个很有意思的项目是「12只喵」队伍的 MoreCat（RFC 链接：https://github.com/12Cat-TiDB/FRC#readme，复制链接至浏览器即可查看），感觉养猫的同学都有一颗喜欢折腾的心。MoreCat 其实就是把 tiup 当做了一个应用分发工具了，类似于 homebrew 等，还是蛮有意思的，我们可以给 tiup 添加自己的 source，下载对应的应用了。这个还是挺实用的，因为我们很多同学给 TiDB 写了不少的运维工具，后面完全可以通过 tiup 来整合到一块了。

另外一个项目就是「P2T」 Postegre sql to TiDB（RFC 链接：https://gist.github.com/lichunzhu/8fb7345e29dd2e5ec29fb28043f2b4cf，复制链接至浏览器即可查看），顾名思义，就是让 DM 支持了从 PG 同步，因为 DM 的框架已经有了，所以难度就在于如何去量导出 PG，以及增量同步 PG，还有 PG 里面不兼容的数据如何来处理这些问题了，从长期来看，我们还是希望能支持更多的 data source 到 TiDB 的。

总结

相比于去年的 Hackathon，今年的 Hackathon 产品组这边一些项目的完成度不算太高，这个也跟赛制有关系，去年报名之后，就可以进行项目的开发了，但今年就是两天的时间，时间上面比较紧张。加上产品组很多项目都要涉及到对 TiDB 内核的改动，还是非常的有挑战性的，所以明年是不是考虑给产品内核这边更多的时间，是我们需要讨论的。

但从另一方面，两天的开发就能爆发出来如此的战斗力，而且有如此都得成果，还是我没预料到的，TiDB Hackathon 再一次体现出来了开放的力量，也再一次让我更加坚信了，持续打造一个活跃，开放的社区是多么有意义和价值的事情，我们会持续的做下去。

另外，如果你有好的 idea，也不用等到 Hackathon 了，欢迎直接联系我来讨论：tl@pingcap.com。

点击此处 查看比赛回放