TiDB SQL Engine Team：純手工打磨前沿的優化器和執行引擎｜PingCAP 招聘季

「SQL at SCALE」（出自 PingCAP 官網）是咱們對 TiDB 的一個精簡歸納，而咱們 TiDB SQL Engine Team 正是負責這 3 個單詞中的 「SQL」 部分，其重要性可見一斑。SQL 在數據庫中的大體處理流程能夠簡短歸納爲查詢優化和執行，這期間涉及到 SQL Parser、優化器、統計信息和執行引擎等模塊，他們就是 TiDB SQL Engine Team 目前所負責的模塊。接下來我會用簡短的篇幅向你們介紹 SQL Engine 的背景知識，以及咱們在作的事情，面臨的挑戰等。

關於查詢優化

優化器是 SQL 引擎的大腦，負責查詢優化。查詢優化的主要工做歸納起來很簡單：搜索可行的執行計劃，從中挑一個最好的。但要作好這兩件事倒是整個分佈式數據庫中最難的地方。

1979 年 Selinger 發佈了 「Access Path Selection in a Relational Database Management System」，正式拉開了 Cost Based Optimization 的帷幕，這篇論文也被視爲 CBO 優化器的聖經。在這以後陸續出現了 Starburst（1988 年），Volcano Optimizer Generator（1993 年）和 Cascades Framework（1995 年） 等，每一年數據庫三大頂會中也能看到很多查詢優化相關的論文，整個優化器領域可謂是蓬勃發展。但即便如此，優化器也仍然有不少問題未能獲得很好的解決，好比：

1. Guy Lohman 2014 年在 「Is Query Optimization a 「Solved」 Problem?」 中詳細講述的 SQL 算子結果集估算的難題。簡單來講，要估算某個表須要掃多少行數據比較容易，可是要再估算更上層的 SQL 算子，好比 Join 或者 Join 以後再 Group By 的結果集有多大，這個就很難了。能夠想象的是，估算偏差會隨着層數的增長而被放大，這個放大有時候是數量級的。此外還會出現負負得正的狀況：明明估算錯了，可是執行計劃倒是對的，糾正估算偏差後，執行計劃反而不對了 🤷‍。
2. Viktor Leis 等人在 2015 年的論文 How Good Are Query Optimizers, Really? 中討論了優化器的另外一朵烏雲：Join Order。若是枚舉全部可行的 Join Order，光是考慮左深樹，N 個表的 Join 就可能有 N! 種執行計劃。目前你們廣泛採用一種妥協的方案：當參與 Join 的表比較少時用動態規劃來肯定 Join 的順序，表比較多的時候用貪心或者遺傳算法（PG 用的模擬退火）來作。可是採用什麼樣的動態規劃和搜索算法也仍然處在熱烈的研究中，而算子結果集的估算偏差又進一步讓這個問題雪上加霜，難上加難。

做爲一個從頭至尾徹底本身手寫的優化器，TiDB 優化器的發展歷史也算精彩：一開始咱們是 Selinger 的 System R 模型，可是它的擴展性不是很好，搜索空間有限，維護成本也高，因而咱們調研後，決定開發 Cascades 模型的新優化器。具體請參考：十分鐘成爲Contributor 系列| 爲Cascades Planner 添加優化規則 和 揭祕TiDB 新優化器：Cascades Planner 原理解析。在開發 Cascades Planner 的同時，咱們還在作着另一件很是重要的事情，提高優化器的穩定性：

1. 優化器的穩定性很是重要。去年以前咱們常常遇到選錯索引，或者乾脆不選索引的問題。這個對業務的影響很是大，有時候一個慢查詢可能拖垮整個集羣，不少用戶都吐槽過這個問題。後來調查研究後，咱們引入了 Skyline Pruning 的剪枝優化，極大地提高了優化器選擇索引的穩定性。參考：Proposal: Support Skyline Pruning。
2. 優化器的穩定性很是重要。要穩定的作出好的執行計劃，統計信息很是很是關鍵。之前咱們收集統計信息須要整個表都掃描一遍，掃的過程當中用蓄水池算法作抽樣。小表這樣作沒啥問題，大表也這樣作就不行了：一方面擔憂對正在運行的業務形成影響，另外一方面這種方式也很低效。因而咱們結合 TiKV 的存儲特色引入了 Fast Analyze，極大的提高了統計信息的蒐集速度，也下降了對業務負載的影響。參考：PR/10214。
3. 優化器的穩定性很是重要。即便咱們作了各類優化，解了各類 Bug，仍然會出現執行計劃不優的問題。有條件的用戶還能夠改一改 SQL，那沒條件的呢？好比 SQL 是經過第三方工具自動拼接的怎麼改？爲了解決這些問題，咱們決定引入 SQL Plan Management，先實現了給 SQL 綁定執行計劃的功能，使得不用更改業務也能搶救 SQL 的執行計劃（Issue/8935）；爲了可以應對更多業務場景，更加細粒度的控制優化行爲，咱們還豐富了 SQL Hint 集合（Issue/12304）；爲了讓 SQL 執行計劃不會變差，咱們爲 SQL 肯定了 Plan 的 Baseline，而且再往前走一步，咱們作了 Baseline 的自動演進，使得執行計劃不但不會變壞，並且只會變的愈來愈好。

重要的事情重複 3 遍：優化器的穩定性很是重要。

除了穩定性以外，還有性能問題：

• 如何在儘可能短的時間內消耗盡可能少的硬件資源找到最佳執行計劃？
• 而目前 TiDB 正在 HTAP 之路上邁出堅實步伐，如何自動識別一條 SQL 是 AP 仍是 TP 查詢？
• 如何爲 TP 查詢選擇合理的索引？
• 又如何爲 AP 查詢作出一個高效的分佈式執行計劃？

能夠預見，在這條道路上，優化器又將迎接新的困難和挑戰，不斷自我演進。

關於查詢執行

個人第一份工做從執行引擎開始，對它的感情異常深厚。執行引擎的目標是儘可能利用計算資源，正確且快速的完成執行計劃所描述的計算任務。光有看起來很完美的執行計劃，卻沒有高效的執行引擎，整個 SQL 引擎也是廢的。

執行引擎也是一個熱門的研究領域。最經典的執行模型當屬 1994 年 Goetz Graefe 發表的 Volcano 迭代器模型，至今仍被廣大數據庫使用。緣由很簡單：接口抽象度高，擴展性好，實現起來簡單。在數據量不大的 TP 請求中，這種模型足夠用了。不事後來你們發現，隨着數據量的上升，這玩意的執行性能不好：每完成一條數據的計算，要額外花費的不少 CPU 指令，計算效率很是低。因而有了後來的兩大優化方向：Vectorization 和 Compilation，各自的表明分別爲：2005 年 Marcin Zukowski 的 」MonetDB/X100: Hyper-Pipelining Query Execution」 和 2011 年 Thomas Neumann 的 「Efficiently Compiling Efficient Query Plans for Modern Hardware」。

除了執行框架，如何利用 CPU 硬件特性優化各類執行算子也被普遍的討論和研究。好比 2013 年的《Multi-Core, Main-Memory Joins: Sort vs. Hash Revisited》這篇論文詳細的探討和對比了 Hash Join 和 Merge Join 的實現和性能，2015 年的《Rethinking SIMD Vectorization for In-Memory Databases》這篇論文詳細討論瞭如何利用 SIMD 指令提高 SQL 算子性能。此外，底層軟硬件技術的革新帶來更多的優化機會，好比還有一系列論文來討論如何適配 NUMA 架構，提高算子執行性能等。

做爲一個從頭至尾徹底本身手寫的執行引擎，TiDB 執行引擎的發展也很是豐富多彩：一開始咱們使用的是傳統 Volcano 迭代器模型，後來咱們和社區同窗在 TiDB 2.0 版本中將其優化成了向量化模型（Issue/5261），獲得了巨大的性能提高：TPC-H 50G, TiDB 2.0 VS 1.0。以後咱們和社區同窗優化了聚合算子，重構了整個聚合函數的執行框架，執行性能又取得了飛躍的發展（Issue/6952）。再以後，咱們和社區同窗優化了表達式執行框架，使得表達式執行效率獲得了 10 倍的性能提高，這期間 10x Performance Improvement for Expression Evaluation Made Possible by Vectorized Execution and the Community 這篇文章還佔據了 Hacker News 的首頁和 DZone Database 頭版頭條。

穩定性和易用性也很是重要。爲了解決用戶 OOM 的問題，咱們前後引入了內存追蹤和記錄的機制，後來乾脆讓算子落盤真正解決內存使用過多的問題，另外咱們也在優化排查問題的調查工具，方便在出問題時快速定位和 workaround。

如前文所說，目前 TiDB 正在 HTAP 之路上邁出堅實的步伐。執行引擎將在新的征程上肩負着新的使命。在分佈式數據庫中，廣義上的執行引擎須要考慮更多的事情：任務如何調度？shuffle 如何優化？目前三套執行引擎（TiDB、TiKV、TiFlash）三套代碼的維護成本如何下降？這些問題都等待着咱們去探索和解決，能夠預見，在這條道路上，執行引擎又將迎接新的困難和挑戰，不斷自我演進。

期待你的加入

很開心，TiDB 的優化器和執行引擎是從零開始由咱們的小夥伴們純手工打造的，咱們有很大的自由度來發揮本身的創造力；很緊張，上面這些列出來的種種問題咱們都會遇到；很榮幸，咱們可以和業界大牛、廣大開源愛好者們一塊兒來攻克這些難題；也頗有成就感，咱們能在廣大 TiDB 用戶的業務中看到這些改進爲他們帶來的價值。

咱們熱愛開源，相信開源可以爲咱們的產品帶來巨大的收益，也願意爲開源奉獻，很是期待一樣熱愛開源的你的加入。若是你：

1. 熱愛和相信開源，聰明且有激情；
2. 勇於挑戰上面那些難題，突破極限；
3. 熟悉分佈式系統、優化器和執行引擎的實現，熟悉 CPU 硬件特性；
4. 有團隊帶領經驗（加分項）。

那麼咱們就加入咱們吧，一塊兒向這些難題發起挑戰，構建一個前沿、穩定的優化器和高效易用的執行引擎。

加入咱們吧！

咱們認爲優秀的工程師或多或少有如下共同特質：

· A Quick Learner
· A- n Earnest Curiosity
· Faith in Open Source
· Self-driven
· Get Things Done

若是你符合以上特質，歡迎進入招聘頁面查看目前開放的工做機會。

簡歷投遞通道：hire@pingcap.com

實習生：公司的各項福利和學習資源對實習生全面開放，更重要的是實習生還未畢業就有機會接觸工業級項目，並且實習期間表現優異者將有機會得到校招綠色通道特權。針對實習時間並不充裕的小夥伴，你能夠先經過 Talent Plan 豐富基礎知識（https://university.pingcap.co...），也能夠經過參與 TiDB 開源社區得到更多實踐機會！

伯樂推薦：若是你身邊有符合以上要求的小夥伴，也能夠找咱們聊一聊，推薦成功就有機會得到伯樂推薦獎勵。伯樂推薦郵件格式：[伯樂推薦] 候選人姓名-職位名稱-推薦人姓名-推薦人手機號。

延展閱讀

是的，咱們在招人！PingCAP 2020 招聘季正式開啓

TiDB Architecture Team：挑戰數據庫的本質難題

揭祕 PingCAP 年輕前沿的團隊：用戶生態

TiDB SQL Infra Team：一塊兒打造從計算層到存儲層的完美橋樑