近日，由 TiDB 社區主辦，專屬於全球開發者與技術愛好者的頂級挑戰賽事——TiDB Hackathon 2020 比賽圓滿落幕。今年是 TiDB Hackathon 第四次舉辦，參賽隊伍規模創歷屆之最，共有 45 支來自全球各地的隊伍報名，首次實現全球聯動。經過 2 天時間的極限挑戰， 大賽湧現出不少令人激動的項目。爲了讓更多朋友瞭解這些參賽團隊背後的故事， 我們將開啓 TiDB Hackathon 2020 優秀項目分享系列，本篇文章將介紹 Mods 團隊賽前幕後的精彩故事。
Mods 團隊的兩位成員孫若曦、徐飛相識已久，笑稱對方爲「 最默契的人 」。在本次Hackathon 中他們使用 GPU 加速技術，爲 TiDB 帶來新的擴展性提升。該項目最終獲得三等獎和雲啓資本 — 最具市場潛力獎。今天我們將分享作爲決賽第一組進行答辯的 Mods 團隊與雲啓資本合夥人陳昱的訪談 ，探祕三位工程師（陳昱此前曾是 Google 的工程師，曾和 Spanner 論文其中一個作者坐在同一格子間裏）關於 「 GPU 加速 TiDB 的緊張故事 」。
Q：Mods 團隊的名字的由來和組隊趣事兒？
Mods ： 我們隊伍的兩個人都是畢業就進入 N 廠（英偉達），一起在上海的 GPU Mods 組，後來又都進入了 P 社（ PingCAP）。這次我們想做一個 GPU 加速的項目，索性就直接用了 Mods 這個隊名。
Q：很好奇，英偉達大家都會去做偏 AI 的東西，當時爲什麼會加入一家數據庫公司？
Mods ： 加入 PingCAP 的原因是我們都認爲大數據和數據庫市場的前景是比較廣的，而且我們在英偉達更多的也是做一些偏底層、偏基礎設施方面的工作，我們覺得這方面的經驗是有可能被應用到同樣是基礎軟件的大數據和數據庫這方面的工作上的，因此就做了這樣的選擇。
Q：陳昱老師也是工程師出身，最終選擇 Mods 團隊的原因有哪些？
雲啓資本陳昱： 早在 2017 年，我就關注 GPU 加速的應用，在我看來用 GPU 來加速數據分析，是蠻有商業價值的。
除了這個項目的 idea 我很喜歡之外，從投資人的角度來看，我更看中項目的獨立性。比如本次獲得第一名的 UDF 的項目我也很喜歡，但是它需要依附 PingCAP 的生態，比較難獨立孵化，當然在生態裏實現也很不錯，但是從投資人的角度考慮，會更希望有朝一日可以孵化出一個獨立的公司。
Q：陳昱老師之前應該也有參加過 Hackathon 嗎，是如何看待這種活動形式的？
雲啓資本陳昱： 之前在谷歌比較少會有公司範圍的 Hackathon，更多的可能是在組內或者大組內對一個項目本身的 Hackathon ，性質也偏向於修復臭蟲和做一些平時優先級沒這麼高的任務，很少做大 feature。
以前在 Google 的時候有所謂的 “20 時間”，就是員工可以花 20% 的時間做任何事情，這和 PingCAP 的 Hackathon 在某種意義上是很類似的，給大家一個機會去實現自己的想法，很著名的 Gmail 最初就是從這 “20 時間”中創造出來的。對 PingCAP 來說也是同樣的，每年都會有幾個項目最後會成爲 PingCAP 產品的一部分。
如果沒有 Hackathon 這個機會，可能很多 idea 就會永遠被埋沒在沙堆裏面，因爲大家日常工作都會有自己的開發計劃，都會忙着往前推進，很少有時間去思考、去實現一些很創新的想法，所以我覺得這個機制是很好的。
Q：Mods 團隊可以分享一下最初做這個項目的靈感和分工嗎？
Mods： 我們兩人之前在英偉達都是做 GPU 相關的工作，雖然後來更多的是在做大數據方向，但是對 GPU 的大方向還是比較關注的。恰巧去年在網上看到一家硅谷公司，他們的團隊做了一個 GPU 的關係型數據庫，當時的 benchmark 效果很驚人，我們順着源代碼研究發現已經有一些相對比較成熟和獨立的使用 GPU 來加速數據分析的基礎組件，印象很深刻。今年 Hackathon 招募出來之後，我們就第一時間想到了這個 idea。
分工方面主要還是從項目的整體設計和架構出發，先頭腦風暴出一個比較乾淨和優雅的分層，架構分層乾淨意味着可以互相解耦，各自獨立開發，從而效率得到保證。接下來再細化分層之間交互的接口，我們對整個分層之間的 API 做了很精細的設計，具體細化到了每個 API 的參數、返回值、調用順序、併發模型等等。雖然前期的設計和討論花了比較長的時間，但帶來了更多中後期開發效率上的收益（雖然整個項目週期也沒有很長，笑～），各自實現自己模塊的時候，不會被對方的節奏和進度打亂。
具體的分工上，我會去實現 GPU 計算層的整體框架和一部分 GPU 算子，徐指導實現 TiDB 側的對接，包括執行計劃的翻譯以及執行器的實現，以及另一部分 GPU 算子。我們知道 Apple 在 2020 年已經不再支持 N 卡和 CUDA 開發了，而我們兩個的主力開發機都是 MacBook，只有我家裏一臺裝了 RTX 2080 的臺機可以用來寫 GPU 代碼。這時候架構上的分層設計就體現出了它的意義。我們將算子的具體實現從框架層剝離開，並在非 GPU 環境下提供了一套十分原始但是可運行的 CPU 算子實現，使得 GPU 無關的代碼可以搭配這套 CPU 算子在非 GPU 環境下獨立進行開發和調試，這就極大減小了我們對我那個臺機的依賴。至於 GPU 算子，只能在我的臺機上開發調試，我和徐指導基本上是分時複用，因爲作息配合也比較默契所以沒什麼衝突（或者發生衝突時我把徐指導 kill 掉因爲畢竟機器在我手裏）。
另外一點，就像前面提到的，我們通過分層設計以及抽象出一組簡潔的 API，使得整個項目具有很大的架構上的靈活性。我們只需在 TiKV 或 TiFlash 中完成與 TiDB 對接相同的工作，就可以將這套算子整合到其中，從而實現下推到 TiKV 和 TiFlash 的計算也通過 GPU 來加速執行，這樣就具備了擴圈到整個 TiDB 生態甚至生態之外的擴展性。
Q：這個東西實際上是可以泛化去支持其他（素板卡）類型，比如說 A 卡我能不能用（OpenCL ）去做加速或者怎麼樣？
Mods： 沒錯，前面提到我們將算子的具體實現從框架層剝離開，並且爲了減小開發環境的制約而實現了一套原始但可運行的 CPU 算子。這個方法同樣適用於爲 GPU 算子提供不同的實現，比如提問中的 OpenCL（N 卡和 A 卡都能跑），甚至可以考慮在 FPGA 上面做一些支持。而這些只需要通過編譯開關簡單的控制即可。
Q：聽完 Mods 團隊分享的前期靈感及分工故事，陳昱老師有什麼其它想法希望分享的？
雲啓資本陳昱： 大家都知道，我們一直在持續做基礎軟件方向的投資。有幾個關於大數據的方向我比較看好：數據庫即服務，批流一體數倉，還有就是基於新型硬件做優化的數據庫。數據庫是個複雜的系統，不單純是軟件，硬件對它的設計也有很大的影響。像 Mods 做的 GPU 加速就是個很好的例子，還有就是非易失存儲，用好了能極大的降低 IO 延遲。
Q：Mods 團隊是第一個進行決賽 demo 的團隊，這裏有什麼緩解緊張故事可以分享的？
Mods： 這是一個緊張的故事，最開始我是聽到隔壁組的抽籤結果，他們第二個答辯，我們還安慰他們說沒事。結果幾秒鐘之後看到我們竟然是第一個答辯，然後他們就來安慰我們了。當時的第一反應是來不及緊張了，直接抱着電腦去調試設備。另外在場的其他組的小夥伴還是給了我們很大的鼓勵，說早早答辯完，就可以一下午喫喫喝喝看別的組翻車，多舒服。雖然可能這些話他們自己都不大信，但是確實讓我們心情平靜了很多。我們的心裏建設也就是給自己打一針雞血，幹就完了，爭取把場子熱起來，給大家開個好頭。
Q：陳昱老師是如何在看完剩下 27 個項目之後還沒有變心的？
雲啓資本陳昱： 哈哈哈，其實在最開始看 RFC 的時候，就很喜歡他們。而且早一點講也是有好處的，大家可以有更多的精力來關注他們的演講，因爲一天二十幾個項目聽下來對評委的體力和心力有很大的消耗。他們有個優勢的 demo 效果特別好，這和他們合理分配時間不無關係。這次答辯過程中，我發現有很多團隊的 idea 也都特別好，但是他們展示的時間安排的不合理，有些項目花在講 PPT 的時間太多了，導致最後沒時間進行 demo，不做 demo 大家很難有直觀的認識，影響了得分。
Q：今年的 Hackathon 只有 24 小時的時間來做項目，Mods 可以分享一些你們在比賽過程中有遇到一些什麼困難以及是如何解決的？
Mods ： 我們遇到最大的困難還是我們的硬件本身，我這塊 RTX 2080 是前年買的，只有 8GB 的顯存，新出的卡又很難買。而大批量數據的計算是要喫很多主存和顯存的，8GB 顯存處理 50GB 規模的數據還是稍微有些緊張的。這就迫使我們去絞盡腦汁想一些對顯存使用比較經濟的算法。
比如 TPCH q17，經過 TiDB 優化之後的 plan 中會有一個對 lineitem 表（最大的表）做一個 aggregate。我們原始的 aggregate 實現中會直接把這個大表所需要的列全部加載到顯存，一次性完成 aggregate，這樣實現起來很快，效率也最高。但是因爲我們的硬件只有 8GB 顯存，而 aggregate 之前的大表數據已經佔用了 6GB 顯存，後面進行 aggregate 計算所需要的資源就不夠了。所以我們被迫使用了分桶的方法，將 aggregate 之前的數據預先分好桶，然後每個桶分別計算 aggregate，技術上很簡單，但需要一些相對比較煩瑣的編程及調參，另外效率上也不及一次性算完。最後我們分了 16 個桶才把這個 aggregate 算出來。
另外一個就是編程語言的問題。TiDB 是用 Go 語言實現的，而我們這個項目因爲要使用 CUDA，因此只能使用 C/C++ 技術棧，把 Go 語言和 C/C++ 結合起來只能藉助 Cgo。大量使用 Cgo 會帶來很大的編程負擔，好在我們有了分層的設計和中間一套簡潔優雅的 API，Cgo 只需要在 API 層使用，極大的減小了這部分負擔。另外，Go 和 C/C++ 的最大的區別在於 Go 是 GC 語言，而 C/C++ 是沒有 GC 的，需要手動管理內存，對於需要使用大量內存處理大批數據，同時對顯存的使用又必須非常精細的這樣一個項目，兩邊對象的生命期管理就成爲一個很大的挑戰。但也因爲有這樣一個強力的約束，倒逼我們去更加仔細的編碼和測試，從而完成最後的 demo。
在 TiDB 接 GPU 的過程中還有個困難就是兩邊的數據格式不太一樣。一些 primitive 的 type 比如 Int、Float 之類的是可以直接兼容的，但是像 String、Date、Decimal 這些複雜類型就不是很容易兼容了，爲了讓 TPCH 能跑起來，我們對 String 類型在 TiDB 這邊做了一定的修改使得它能兼容 GPU 的計算引擎，而 Date 類型則在 GPU 計算引擎那邊兼容了 TiDB 的 Date 格式，相比 String 和 Date 這種只需要做小部分改動，Decimal 類型要兼容則困難了許多，由於時間實在有限，我們最後選擇在生成 TPCH schema 的時候把 Decimal 類型替換成 Double 來繞過了這個問題（如果有足夠多的時間能讓我們完成 Decimal 類型的兼容的話，那 GPU 的加速應該還能更明顯一點，這點也算是我們的一點遺憾吧。）
TiDB 的生態很廣，所選用的編程語言也非常龐雜：TiDB 是 Go，TiKV 是 Rust，TiFlash 是 C++，TiSpark 是 Java 和 Scala。徐指導是我認識的唯一一個這五門語言全都寫過的 TiDB 開發者。
Q：剛剛說到了一些遺憾，那如果時間更充裕，有什麼可以做的更好的？
Mods ： 我們覺得比較遺憾的地方是因爲時間有限，對 GPU 硬件利用率的調優還有一定的空間。從一開始，我們的設計就基於了這樣一個假設：GPU 作爲處理器的一個基本哲學是靠足夠多的計算任務來 hide 單個任務的 latency，從而提高系統整體的吞吐率，於是我們可以通過增加 CPU 端的併發以增大 GPU 端單位時間內的任務量，從而提高 GPU 硬件的利用率。爲此我們在框架層設計了可以支持 CPU 端任意併發的精細 pipeline 模型。
然而在後期實驗的時候，我們沒有看到隨着 CPU 端併發的增加，GPU 的利用率隨之提高。我們考察的幾個 GPU 的 profile 指標，包括 kernel / kernel overlap 和 kernel / memory overlap，都沒有顯著的變化。因爲當時我們 demo 的幾個 query 效果都已經比較理想了，時間也有限，就沒有進一步研究這一塊。後面有時間的話，可能會再做一些更加深入的 profiling。
Q：剛剛 Mods 團隊分享了他們在過程中遇到的一些技術困難和遺憾，陳昱老師作爲工程師有什麼其它建議或者想要了解的更多細節嗎？
雲啓資本陳昱： 對，其實也是和顯存相關的東西。做 GPU 計算的時候，需要把數據裝載到顯存裏，但單塊顯卡的顯存畢竟是有限的，是否能利用虛擬化的方法，把機器上的若干塊板卡，甚至說其他機器的板卡，組成一塊大的 GPU 虛擬板卡，這樣就能有幾乎無限的存儲和算力來完成 GPU 計算任務。
Mods： 大家對 GPU 的資源本身比較有限這一塊基本形成共識了，對應的也出現了很多解決這類問題的方案，包括多個 GPU 互連，GPU 虛擬化，甚至是分佈式的 GPU 集羣這樣的技術。我們也在持續關注這些領域，另外我們也認爲未來這個幾乎是一個必然的方向。
Q：Mods 團隊獲得了兩個獎，陳昱老師對這個項目未來有什麼期待與展望嗎？
雲啓資本陳昱： 希望他們趕快合併到 TiDB 的主代碼庫，這是最大的期許了。
Q：Mods 團隊自己有什麼期待？
Mods： 我們肯定和陳昱老師的期待一樣。不過後續產品化中的困難還有很多，包括數據類型不兼容，開發環境是否友好等等。雖然演示的 demo 效果很好，不過不管是軟件、硬件，還是對整個 TiDB 生態上，還有很多需要克服的困難。這方面討論後續肯定會繼續推進。
我們最喜歡 Hackthon 的地方就是你可以無拘無束的去 hack 一個 idea，通過 demo 來驗證它。但後續產品化方面，就要很嚴肅的去討論，這是產品成型的必然路徑。我們當然希望能快速落地，也會朝這個方向去努力爭取的。
Q：最後的彩蛋緩環節，請大家分享一下除了自己的項目外，最喜歡哪個項目？
雲啓資本陳昱： 我覺得比較喜歡一個是拿第一名的 UDF 項目，還有另一個三等獎項目 zh.md。程序員是最不喜歡寫文檔的，任何能提高程序員生產文檔的工具都很受歡迎。還有一個獲得最佳人氣獎的 TiFlink 我也很關注。
Mods 團隊-孫若曦： 只能說一個項目的話，那就是一等獎的團隊 'or 0=0 or' 做的 UDF 項目。我覺得不管是從架構還是實現來看，都非常優雅，而且完成度很高，整個演示的過程也很令人愉悅，我個人非常喜歡。
Mods 團隊-徐飛： 我也很喜歡第一名做 UDF 的項目，而且之前我們做過存儲過程相關的事情，知道會有哪些技術難點，但這個項目把這些問題都解決的非常優雅。
關於雲啓資本
雲啓資本成立於2014年，一直堅持專注於To B領域的早中期投資，圍繞技術賦能產業升級，進行系統化佈局，投資領域覆蓋企業服務SaaS、產業數字化、智聯設備、先進製造等行業，投資組合包括360數科 (NASDAQ: QFIN)、英科醫療（SZ: 300677)、一起寫(被快手收購）、酷家樂、百布、PingCAP, Zilliz, 德風科技、冰鑑科技、XTransfer, 環世物流、找鋼網、小胖熊、智齒科技、曉羊教育、擎朗智能、新石器、e換電等近100家優秀創業公司。