共计 4962 个字符，预计需要花费 13 分钟才能阅读完成。
作者介绍：唐刘，PingCAP VP of Engineering，TiDB Hackathon 2021 特邀评委。
TiDB 2021 Hackathon 终于落下帷幕，最开始我还放心，往年 Hackathon 还有啥货色能进去，后果却大大超出我的预期，很多我的项目真的能用惊艳来形容，大家都在自嘲，说『内卷得太厉害』。作为评委，全程参加了预赛内核组以及决赛的问难，还是有很多感触的，之前曾经写了一篇预赛的点评（点击文末“浏览原文”即可查看），这次也对决赛做一次不负责任的点评。
决赛这次有 20 个我的项目，我大略分几个维度做一个对立介绍。
性能 / 性能加强
这次在 TiDB 内核上，做的不少性能晋升性能真的很惊艳，因为我预赛点评的次要是内核组的货色，所以在这里简略进行一下汇总。
增量 Analytic Table
这个性能通过 Region Cache 统计信息的形式来减速全表的 analyze，在表越大的状况下，收益会越加显著。一方面减速了 analyze 的速度，另外一方面也能缓解 analyze 造成的大量 IO 和 CPU 开销，升高了零碎的压力。不过这个实现有一个前提假如，就是大部分业务依然是热点更新，或者增量写入为主。不过即便呈现了大范畴的更新，因为统计信息当初间接是放在 region cache 的，理论在 full analyze 的时候，成果也可能会比当初的实现要好。另外，咱们前面可能还能够通过 TiFlash 进行 analyze 的操作，这样也会快很多。
TiExec
这个我的项目尽管之前不是在内核赛道，但我感觉这玩意足够 hardcore 了。这也是咱们在之前 PoC 过程中理论遇到的一个问题，咱们发现调整一些内核的配置，或者 Go GC 的调整，性能就能晋升。这次就是针对 iTBL-Cache-Miss 的问题进行优化。而后大家将 .text 这个 segment 映射到了 hugepage 下面，升高了 cache miss，晋升了性能。原本评委还放心用了 hugepage 性能会不会降落，但理论这里并不是全局关上的 transparent hugepage，而只是独自的将某一段区间的数据 remap 到了 hugepage 下面。
TPC
这个我的项目是我感觉最硬核的我的项目，我本人也给了十分高的分数，不过遗憾的是，可能太过于硬核，很多评委都不晓得它在说什么（因为并不是所有评委都十分理解 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 的数据。
MVCC 时光机
这个我的项目对于运维同学来说是在某些时候能救命的性能。TiDB 在数据存储下面，应用的是 MVCC 机制，也就是一条数据，可能会有多个版本，所以即便用户误删除了这一条数据，咱们依然能够在老的版本下面将其复原。当初的复原流程就是先用一个老的版本号（这里就是 timestamp）查问到老的数据，而后将其从新插入回去。这个操作对于单条要复原的数据还是比较简单的，但如果咱们是一批数据的复原，操作就十分麻烦。这个我的项目通过 SQL 很好地解决了运维的操作问题。更赞的是，该我的项目引入了多 safepoint 机制，也就是能够给 TiDB 集群定期做一些全局 snapshot，进行疾速轻量级的逻辑备份。不过随着要保留的 snapshot 增多，数据的 MVCC 版本也会增多，对于 scan 这种操作可能会有影响，前面如果咱们将历史版本挪动到另外的中央，这个问题就能缓解了。
让 TiDB 在云上智能的谈话
这个我的项目我也感觉十分赞，甚至我认为不光是在云下面，TiDB 的智能运维收益，在 OP 下面，TiUP 也是能够借鉴的。咱们在降级的时候，能够引入更多的策略，譬如只让正本的 leader 切换一次，或者依据 TiKV 以后的热点、流量等来判断是否该节点能降级。这些策略能很好地升高降级过程对用户业务的影响。
TiDB 冷热数据分层存储
这个我的项目取得了本次 Hackathon 的一等奖，再跟本次 Hackathon 另外一个相似我的项目联结，会为前面 TiDB 跟 S3 的整合打下不错的根底，至多这次 Hackathon 验证了可行性。其实原理很简略，将冷的数据放到 S3，而后将算子尽量公开推到 S3，通过 S3 原生的 Select 性能来减速查问。当然，如果数据曾经在 S3，咱们还能够通过云下面其余的服务，譬如 Athena，来做更多的查问聚合操作，减速查问。这次大家都是在通过 partition 做文章，毕竟依据工夫片来分 partition 是很罕用的一种操作，咱们外部当初也在通过 LSM 做一些跟 S3 整合的钻研，我还是很期待这些都能在往年看到成绩。譬如咱们的 TiDB Cloud Developer Tier 集群就能够齐全用这套机制来先验证。
诊断效力
往年 Hackathon 我集体感觉最开心的应该是凯哥，他当初负责 TiDB 可观测性以及诊断易用性晋升，往年的几个我的项目做好了都能够很好地落地，其实有一些都曾经在咱们的 roadmap 外面了。
主动调配置（Matrix）
Matrix 是 PingCAP 同学跟华中科技大学的同学一起弄的一个我的项目，不得不说，当初的学生真的是很牛。通过这个我的项目我才晓得，原来 TiDB 5.3 曾经有 800 多个参数了，所以前面咱们真的须要出一些开发准则，譬如如何来减少参数、配置、session variable 等，不然后续调优会更加艰难。其实之前 Hackathon 也有不少的主动 tune 的尝试，但这次我感觉很大的一个突破点，是在于该团队可视化了重要参数的影响水平。
主动诊断（Collie）
主动诊断 (Collie) 团队的队名（咱们这么菜评委不会怄气吧）还是蛮有意思的，其实你们一点都不菜，而且还帮忙优化了 TiUP diag 的性能，这个曾经很厉害了。通过这个我的项目我才晓得，原来咱们 metrics 指标曾经快 8000 个了，说实话，我感觉再倒退上来，人曾经没法 debug 了……
log 剖析（Naglfar）
日志也是 TiDB 外面一个急需优化的点，咱们打了一些无用的日志，这个前面须要清理，但在诊断问题的时候，咱们须要对日志进行关联剖析，以及察看某一个日志的趋势，提前发现问题。Naglfar 在这块开了一个不错的头。
慢 SQL 诊断（TiVP）
当我终于看到可视化的执行打算时，我简直留下了冲动的泪水。毕竟咱们之前诊断慢 SQL 切实是太苦了，那么一大屏的执行打算，简直叫做没法看，而且如果要比照两个执行打算的异同，就更解体了。有了可视化，至多剖析到底哪里慢的效率会晋升很多，而且前面咱们齐全能够将 SQL advisor 的性能间接整合到 TiVP 下面，让大家间接在线能进行 SQL bind，add/drop index 这些操作。看完这个我的项目，我立即问了下 wish 同学，他间接甩给我一张更丑陋的 Visual Plan 的图，原来曾经排在了 roadmap 外面，大家刮目相待。
生态扩大
往年的生态，能够用百花齐放来形容吧，看到了太多不一样的货色。我其实始终十分喜爱生态相干的我的项目，如果说 Hackathon 内核相干的我的项目是减少 TiDB 的技术深度，那我感觉生态这块就是扩充 TiDB 的广度。对一个数据库来说，『广』就意味着市场占有率的晋升。
TiMatch – 语法齐备的分布式图数据库
去年 TiGraph 曾经让大家惊艳，往年 TiMatch 更让人期待了。这次易用性更好，而且对于老集群也能间接降级应用。因为 TiMatch 只是外部建设了一套 graph index，通过 TiDB 分布式事务机制，跟原先关系表的数据对立更新。语法下面，借鉴了 Oracle graph 的语法，所以曾经是关系齐备的了，不过我感觉前面的挑战在于性能下面，心愿下一届该我的项目能给大家展现相干的数据。
TiLaker: 为 TiDB 插上入湖的翅膀
去年 Hackathon 其实有不少跟 Flink 整合的我的项目，不过往年决赛就看到一个，说实话我还是有点小悲观的。但往年 TiLaker 做的还是挺齐备的，毕竟有 Flink Committer 的参加，大家给 Flink 实现了一个 CDC Connector，这样能让 Flink 间接读取 TiDB 的增量数据，同步到上游了。借助 Flink 的能力，让 TiDB 更好地跟上游生态进行了买通，前面也心愿有不少的利用案例能进去。
pCloud
这是一个十分有意思的我的项目。贵司的 CTO 东旭同学间接上场带货，先抛开他集体极大的现场感染力，从理论来看，pCloud 做得真的很不错。东旭只是展现了产品成果，聊了聊商业模式这些，但我其实是晓得这个我的项目的底层实现的，还是很有挑战的。不过这也给了下一届 Hackathon 参赛的同学另一种参考，一个我的项目，有时大家更容易关注技术自身，但如果咱们是做一个产品，或者一个 SaaS 服务，对于用户及商业的了解也是十分要害的。所以即便大家感觉本人对 TiDB 没太多了解，写不了太硬核的程序，也能够从另外的方向来冲破。
Dujiang Weir
这个我的项目也挺有意思，晓光在 Weir 下面实现了一些 plugin，扩大了 TiDB 的性能。譬如他写了一个 Redis 的 plugin，为 TiDB 提供了缓存反对的能力，不过我当初在想，是不是 TiDB 本人把 plugin 机制做好一点更好？当初咱们的 plugin 是用 Go 自带的 plugin 机制，在可扩展性、可维护性上做得不怎么好，如果咱们用了 Hashicorp 的 go-plugin，通过 RPC 来交互，尽管性能有损失，但会不会成果更好？这块将来能够跟晓光他们持续探讨下。
TiClick
这是我最喜爱的一个我的项目，我集体给了最高的分数，并不是因为 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 办公室写程序那种经验还是十分有意思的。
