作者介紹：唐劉，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 辦公室寫程式那種經歷還是非常有意思的。