摘要：不過這并不是團隊工作的全部。另外，系統(tǒng)面臨的另一個挑戰(zhàn)是資源隔離。最上層仍然是的計算層，而下層則是類似的存儲協(xié)處理器的架構(gòu)。另一個計劃中但是仍然沒有開工的事情是，我們希望在協(xié)處理器層加入功能，讓數(shù)據(jù)可以通過網(wǎng)絡進行模型的重分布操作。

前面兩期我們介紹了?TiDB 團隊和?TiKV 團隊，頗受好評，今天我司數(shù)據(jù)庫專家馬曉宇老師將為大家介紹 PingCAP 最具活力的團隊——?AP（Analytical Product）?團隊，如果你對親手打造酷炫的大數(shù)據(jù)分析產(chǎn)品感興趣，就快快投個簡歷來和我們聊聊吧～

大家都知道 TiDB 是一款定位于在線事務處理/在線分析處理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型數(shù)據(jù)庫產(chǎn)品，加強和補齊 HTAP 中的 AP 環(huán)節(jié)是這個團隊的重要工作職責。

TiDB 的 Coprocessor（協(xié)處理器）架構(gòu)使得大量計算可以并行進行，例如由協(xié)處理器進行謂詞過濾，預聚合等等，這樣一來很多計算被眾多 TiKV 資源分擔，并且匯聚到 TiDB 的計算將大大減少，由此雖然 TiDB 本身仍然是單機，卻可以很大程度滿足 AP 需求。

不過這并不是 AP 團隊工作的全部。

TiFlash 是一個相對獨立完整的分析型數(shù)據(jù)庫產(chǎn)品。獨立，說明歷史包袱會比較小，可以嘗試各種可能的設計；同時，我們也希望它盡可能完整，能承擔一個分析型數(shù)據(jù)庫應有的職責。這個項目需要熟悉 C++，熟悉分布式系統(tǒng)的 Infra 工程師同學們?nèi)牖铩?/p> Why

也許您看了 TiDB / TiSpark 的架構(gòu)，會有個疑問。TiDB 仍然使用的是行格式存儲，但似乎大多數(shù)分析型數(shù)據(jù)庫都是列式存儲喔？

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

列式存儲能提供更高的壓縮比，增加 IO 效率（畢竟 IO 在很多時候是最慢的一環(huán)），也使引擎能只讀取需要的列，更進一步加快讀取速度。但是列式存儲在 TP 場景下會使 IO 變得零散，如果使用了壓縮就會更麻煩。因此基本上交易型系統(tǒng)還是會使用行格式存儲的（就像 TiDB 現(xiàn)在這樣）。

另外，HTAP 系統(tǒng)面臨的另一個挑戰(zhàn)是資源隔離。當所有計算任務都依賴于 TiKV 存儲的時候，我們很難有效地進行資源隔離：不管如何處理，AP 任務都有可能影響 TP 的穩(wěn)定。因此，我們希望有一組獨立的資源提供 AP 服務。

Multi-Raft 協(xié)議使我們有了另一種選擇：何不把列存當做一個 Raft Learner 副本來實現(xiàn)呢？Raft Learner 接入讓我們得以在對 TP 端極低的消耗下，提供一致性的數(shù)據(jù)讀取，同時又兼顧了資源隔離。這大概算是一個相當有創(chuàng)新的做法了 :)

其實您也可以認為列存副本是某種奇特索引結(jié)構(gòu)，因此計算層其實可以在行存和列存中根據(jù)代價進行選擇。例如我們進行兩表 Join，也許一張表可以通過索引過濾大部分數(shù)據(jù)，而另一邊則希望通過列存減少掃描代價，那么我們也可以同時使用行存+索引和列存進行 Join。

列存 + Raft 副本是一個正在進行的任務，為了使列存能夠支持快速的 MVCC 更新和刪除，我們專門開發(fā)了新的存儲引擎，同時也在和 TiKV 組緊密合作對接 Raft 協(xié)議。

如上圖，這就是一個 TiFlash + TiDB 集群。最上層仍然是 TiSpark + TiDB 的計算層，而下層則是類似 TiKV 的存儲 + 協(xié)處理器的架構(gòu)。其中一部分存儲引擎節(jié)點將通過 Raft 協(xié)議和 TP 區(qū)連接，實時同步數(shù)據(jù)；而另一部分則作為獨立的寫入?yún)^(qū)，支持純 AP 需求。

現(xiàn)在我們的列存引擎還只是初版，我們正在進行更多的探索，嘗試不同的存儲格式和技術，讓它變得更快，適合更多場景。而要支持獨立寫入，也代表 TiFlash 本身將會向一個完整的 MPP 數(shù)據(jù)庫演進，而這無疑需要耗費大量人力?？傊浅Ｆ诖魑煌瑢W的加盟。

另一個計劃中但是仍然沒有開工的事情是，我們希望在協(xié)處理器層加入 Exchange / Shuffle 功能，讓數(shù)據(jù)可以通過網(wǎng)絡進行 MPP 模型的重分布操作。

如果我們在協(xié)處理器層加入 Pipeline 模型的數(shù)據(jù)交換，計算層 TiDB 作為一個單節(jié)點服務器也可以享受到集群計算的加速。而 TiSpark 在運行非長時間 ETL 任務時也可以選擇下推計算到 MPP 計算節(jié)點以避免 Spark Shuffle 高容錯模型帶來的消耗。

實際上要實現(xiàn)基于 Exchange 和重分布的 Query Engine 是非常龐大的一件事。幾乎大部分算子都需要重新改造，完全做到需要很久。不過好在我們的計算層各自都已經(jīng)實現(xiàn)了完備的算子集，這樣我們可以按照合理的進度逐步構(gòu)建 MPP 引擎，逐步開放更多可下推的算子。

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

TiSpark 是我們組的另一個產(chǎn)品。TiSpark 是一款深度訂制的 Spark Connection Layer，將 Spark 平臺深度整合到現(xiàn)有的 TiDB 產(chǎn)品棧里。它借助了 Apache Spark 的計算平臺，直接對接存儲層（TiKV 和 TiFlash）讀取數(shù)據(jù)，并下推可能的計算以加速。

TiSpark 的定位是多重的：一方面在 TiFlash 還無法完整承擔 MPP 引擎職責的當下，它是我們在超規(guī)模計算下的首選；另一方面，借助 Spark 我們將 TiDB 延伸到了大數(shù)據(jù)領域，配合 TiFlash，我們可以替代相當一部分傳統(tǒng)上需要 Hadoop 集群的場景。

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

由于直接對接了存儲，我們也可以像傳統(tǒng)數(shù)據(jù)庫一樣利用好存儲的特點，實現(xiàn)一些 Hadoop 體系無法完成的功能，例如 IndexJoin，Index only scan 等。另外，安全和審計體系，基于 Spark Streaming 的異步觸發(fā)器和看板，或者 PL/SQL 等，都是之后可能的選擇?？傊?，這個項目還很初步，還有很多可以折騰的事情。

另外，TiSpark 暫時還是一個只讀的系統(tǒng)，但是我們也準備加入寫入和修改的支持（數(shù)據(jù)編碼，索引維護，事務支持等等），這樣 TiSpark 也將成為一個能相對獨立使用的完整產(chǎn)品。

我們也期待您的加盟。如果您是大數(shù)據(jù)領域新手，這個項目可以讓你深入了解 Spark 的架構(gòu)和實現(xiàn)細節(jié)；如果您是老鳥，除了一起快樂寫代碼，還可以一起制定產(chǎn)品 Roadmap 也許也是您樂意做的事情；總之，這是一個老少咸宜的項目。

所以來聊聊看吧？這兩個項目是眼下 AP 團隊正在折騰的東西，很多部分都還處在比較初期的階段，而且這里寫的都只是我們比較確定會開展的工作，有一些想法因為人力不足經(jīng)驗不足我們只敢想?yún)s沒辦法寫在這里。如果有了各位同學的加盟，相信這些產(chǎn)品可以變得更完善，更野心勃勃。

我們認為優(yōu)秀的工程師或多或少有以下共同特質(zhì)：

A Quick Learner

An Earnest Curiosity

Faith in Open Source

Self-driven? ??

Get Things Done

如果你符合以上特質(zhì)，歡迎進入招聘頁面查看目前開放的工作機會：

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

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

實習生：公司的各項福利和學習資源對實習生全面開放，更重要的是實習生還未畢業(yè)就有機會接觸工業(yè)級項目，而且實習期間表現(xiàn)優(yōu)異者將有機會獲得校招綠色通道特權。如果小伙伴們時間不夠充裕，也可以先從社區(qū) Contributor 做起，或許下一期?Talent Plan?的主角就是你！

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