TiFlash & TiSpark？那都是 AP 團隊開的坑 ！ | PingCAP 招聘季

前面兩期咱們介紹了  TiDB 團隊和  TiKV 團隊，頗受好評，今天我司數據庫專家 馬曉宇老師將爲你們介紹 PingCAP 最具活力的團隊——  AP（Analytical Product） 團隊，若是你對親手打造酷炫的大數據分析產品感興趣，就快快投個簡從來和咱們聊聊吧～

你們都知道 TiDB 是一款定位於在線事務處理/在線分析處理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型數據庫產品，增強和補齊 HTAP 中的 AP 環節是這個團隊的重要工做職責。

TiDB 的 Coprocessor（協處理器）架構使得大量計算能夠並行進行，例如由協處理器進行謂詞過濾，預聚合等等，這樣一來不少計算被衆多 TiKV 資源分擔，而且匯聚到 TiDB 的計算將大大減小，由此雖然 TiDB 自己仍然是單機，卻能夠很大程度知足 AP 需求。

不過這並非 AP 團隊工做的所有。

TiFlash

TiFlash 是一個相對獨立完整的分析型數據庫產品。獨立，說明歷史包袱會比較小，能夠嘗試各類可能的設計；同時，咱們也但願它儘量完整，能承擔一個分析型數據庫應有的職責。這個項目須要熟悉 C++，熟悉分佈式系統的 Infra 工程師同窗們入夥。

Why

也許您看了 TiDB / TiSpark 的架構，會有個疑問。TiDB 仍然使用的是行格式存儲，但彷佛大多數分析型數據庫都是列式存儲喔？

沒錯。這就是咱們開新坑的主要目的之一。

列式存儲能提供更高的壓縮比，增長 IO 效率（畢竟 IO 在不少時候是最慢的一環），也使引擎能只讀取須要的列，更進一步加快讀取速度。可是列式存儲在 TP 場景下會使 IO 變得零散，若是使用了壓縮就會更麻煩。所以基本上交易型系統仍是會使用行格式存儲的（就像 TiDB 如今這樣）。

另外，HTAP 系統面臨的另外一個挑戰是資源隔離。當全部計算任務都依賴於 TiKV 存儲的時候，咱們很難有效地進行資源隔離：無論如何處理，AP 任務都有可能影響 TP 的穩定。所以，咱們但願有一組獨立的資源提供 AP 服務。

Raft 和列存副本

Multi-Raft 協議使咱們有了另外一種選擇：何不把列存當作一個 Raft Learner 副原本實現呢？Raft Learner 接入讓咱們得以在對 TP 端極低的消耗下，提供一致性的數據讀取，同時又兼顧了資源隔離。這大概算是一個至關有創新的作法了 :)

其實您也能夠認爲列存副本是某種奇特索引結構，所以計算層其實能夠在行存和列存中根據代價進行選擇。例如咱們進行兩表 Join，也許一張表能夠經過索引過濾大部分數據，而另外一邊則但願經過列存減小掃描代價，那麼咱們也能夠同時使用行存+索引和列存進行 Join。

列存 + Raft 副本是一個正在進行的任務，爲了使列存可以支持快速的 MVCC 更新和刪除，咱們專門開發了新的存儲引擎，同時也在和 TiKV 組緊密合做對接 Raft 協議。

如上圖，這就是一個 TiFlash + TiDB 集羣。最上層仍然是 TiSpark + TiDB 的計算層，而下層則是相似 TiKV 的存儲 + 協處理器的架構。其中一部分存儲引擎節點將經過 Raft 協議和 TP 區鏈接，實時同步數據；而另外一部分則做爲獨立的寫入區，支持純 AP 需求。

如今咱們的列存引擎還只是第一版，咱們正在進行更多的探索，嘗試不一樣的存儲格式和技術，讓它變得更快，適合更多場景。而要支持獨立寫入，也表明 TiFlash 自己將會向一個完整的 MPP 數據庫演進，而這無疑須要耗費大量人力。總之，很是期待各位同窗的加盟。

TiFlash MPP Engine

另外一個計劃中可是仍然沒有開工的事情是，咱們但願在協處理器層加入 Exchange / Shuffle 功能，讓數據能夠經過網絡進行 MPP 模型的重分佈操做。

若是咱們在協處理器層加入 Pipeline 模型的數據交換，計算層 TiDB 做爲一個單節點服務器也能夠享受到集羣計算的加速。而 TiSpark 在運行非長時間 ETL 任務時也能夠選擇下推計算到 MPP 計算節點以免 Spark Shuffle 高容錯模型帶來的消耗。

實際上要實現基於 Exchange 和重分佈的 Query Engine 是很是龐大的一件事。幾乎大部分算子都須要從新改造，徹底作到須要好久。不過好在咱們的計算層各自都已經實現了完備的算子集，這樣咱們能夠按照合理的進度逐步構建 MPP 引擎，逐步開放更多可下推的算子。

與此同時，在這個引擎上，咱們也但願試驗一些更新的計算模型，例如完整的向量化算子實現，或者結合 JIT 進行加速，甚至嘗試 GPU 等，都是預期中的任務。

TiSpark

TiSpark 是咱們組的另外一個產品。TiSpark 是一款深度訂製的 Spark Connection Layer，將 Spark 平臺深度整合到現有的 TiDB 產品棧裏。它藉助了 Apache Spark 的計算平臺，直接對接存儲層（TiKV 和 TiFlash）讀取數據，並下推可能的計算以加速。

TiSpark 的定位是多重的：一方面在 TiFlash 還沒法完整承擔 MPP 引擎職責的當下，它是咱們在超規模計算下的首選；另外一方面，藉助 Spark 咱們將 TiDB 延伸到了大數據領域，配合 TiFlash，咱們能夠替代至關一部分傳統上須要 Hadoop 集羣的場景。

經過對接 Spark 的 Extension 接口，TiSpark 得以在不直接修改 Spark 源代碼的前提下，深度訂製 Spark SQL 的根本行爲，包括加入算子，擴充語法，修改執行計劃等等，讓它看起來更像是一款 Spark 原生產品而非第三方擴展。

因爲直接對接了存儲，咱們也能夠像傳統數據庫同樣利用好存儲的特色，實現一些 Hadoop 體系沒法完成的功能，例如 IndexJoin，Index only scan 等。另外，安全和審計體系，基於 Spark Streaming 的異步觸發器和看板，或者 PL/SQL 等，都是以後可能的選擇。總之，這個項目還很初步，還有不少能夠折騰的事情。

另外，TiSpark 暫時仍是一個只讀的系統，可是咱們也準備加入寫入和修改的支持（數據編碼，索引維護，事務支持等等），這樣 TiSpark 也將成爲一個能相對獨立使用的完整產品。

咱們也期待您的加盟。若是您是大數據領域新手，這個項目可讓你深刻了解 Spark 的架構和實現細節；若是您是老鳥，除了一塊兒快樂寫代碼，還能夠一塊兒制定產品 Roadmap 也許也是您樂意作的事情；總之，這是一個老小咸宜的項目。

因此來聊聊看吧？這兩個項目是眼下 AP 團隊正在折騰的東西，不少部分都還處在比較初期的階段，並且這裏寫的都只是咱們比較肯定會開展的工做，有一些想法由於人力不足經驗不足咱們只敢想卻沒辦法寫在這裏。若是有了各位同窗的加盟，相信這些產品能夠變得更完善，更野心勃勃。

加入咱們吧！

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

• A Quick Learner
• An Earnest Curiosity
• Faith in Open Source
• Self-driven    
• Get Things Done

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

https://www.pingcap.com/recruit-cn/join/#positions

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

實習生：公司的各項福利和學習資源對實習生全面開放，更重要的是實習生還未畢業就有機會接觸工業級項目，並且實習期間表現優異者將有機會得到校招綠色通道特權。若是小夥伴們時間不夠充裕，也能夠先從社區 Contributor 作起，或許下一期 Talent Plan 的主角就是你！

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