TiDB 2021 Hackathon 決賽不負責任點評

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 到了 huge page 上面。

TPC ，這個專案是我覺得最硬核的專案，我自己也給了非常高的分數，不過遺憾的是，可能太過於硬核，很多評委都不知道在說啥了（比較很多評委其實並不瞭解 TiDB 內部機制），最終只是得了三等獎，我個人覺得這專案其實能衝擊一等獎的 :-) TPC 這個專案做了非常多的工作，當然，我也預感到後續落地的難度，不過這個我還是很期待的。畢竟這也是在我們的 roadmap 上面。我們用了 io uring，不過貌似也遇到了不少的坑，後面可以也可以選擇 AIO，或者單獨的非同步執行緒機制都可以。然後因為用了新的 raft engine（這個會在 TiDB 5.4 GA），也很方便的能做 parallel log write，充分利用多佇列 IO 特性，這個在 cloud 上面也是很關鍵的，因為 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 在雲上智慧的說話 這個專案我也覺得非常贊，甚至我認為不光是在 cloud 上面，TiDB 的運維能收益，在 OP 上面，tiup 也是可以借鑑的。我們在升級的時候，可以引入更多的一些策略，譬如只讓副本的 leader 切換一次，或者根據 TiKV 當前的熱點，流量等來判斷是否該節點能升級。這些策略能很好地降低在升級過程中對使用者業務的影響。

TiDB 冷熱資料分層儲存 ，這個專案獲得了本次 hackathon 的一等獎，在跟本次 hackathon 另外一個類似專案整合，會為後面 TiDB 跟 S3 的整合打下不錯的基礎，至少這次 hackathon 驗證了可行性。其實原理很簡單，將冷的資料放到 S3，然後將運算元儘量的下推到 S3，通過 S3 原生的 select 功能來加速查詢。當然，如果資料已經在 S3，我們還可以通過 cloud 上面其他的服務，譬如 Athena， 來做更多的查詢聚合操作，加速查詢。這次大家都是在通過 partition 做文章，畢竟根據時間片來分的 parittion 是非常常用的一種操作，後面，我們內部現在也在通過 LSM 做一些跟 S3 整合的研究，我還是很期待這些都能在今年看到不少的成果產出。譬如我們的 TiDB cloud dev tier 叢集就可以完全用這套機制來先驗證。

診斷效能

今年 Hackathon 我個人覺得最開心的應該是凱哥，他現在是負責 TiDB 可觀測性以及診斷易用性提升的，今年的幾個專案做好了都可以很好的落地，其實有的都已經在我們的 roadmap 裡面了。

自動調配置(Matrix) 是 PingCAP 同學跟華中科技大學的同學一起弄的一個專案，不得不說，現在的學生真的很牛了。通過這個專案，我才知道原來 TiDB 5.3 已經由 800 多個引數了，所以後面我們真的需要出一些開發原則，譬如如何來增加引數，配置，session variable 這些，不然這些膨脹了，後續調優會更加的困難。其實之前 hackathon 也有不少的自動 tune 的嘗試，但這次我覺得很大的一個突破點，是在於該團隊可視化了重要引數的影響程度。

自動診斷(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 沒太多理解，寫不了太 hardcore 的程式，但也可以從另外的方向來突破。

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 登入，支援 open API，變得對開發者更加友好，這樣才能為後面的生態擴充套件打下基礎。

總結

當然，這裡只是列出來大部分的專案，還有一些專案這裡就沒詳細的點評了，譬如 TiTravel，oom.ai，TiMultiple，Bubbles 等，都是很不錯的專案，後面有空再補充下，大家可以自己去了解關注下。

總的來說，這次 hackathon 做了兩天的評委，在體力和腦力上面被嚴重的 burn out，但還是讓我非常興奮，因為我看到了 TiDB 未來無限的可能性，這次 hackathon 的 slogan 是 explore the sky。sky 離我們並不遙遠，譬如我現在就在高空飛機上寫這篇文章 :-)

不過這次 hackathon 還是有點小遺憾的，我認為 hackathon 的一個精髓就是 24 小時的高強度程式設計，但因為疫情原因，沒法實施，希望疫情在今年真的能有好轉，大家帶著睡袋，在 PingCAP 辦公室寫程式那種經歷還是非常有意思的。