導語 | TBase 是騰訊TEG資料平臺團隊在開源 PostgreSQL 的基礎上研發的企業級分散式 HTAP 資料庫系統，可在同一資料庫叢集中同時為客戶提供強一致高併發的分散式線上事務能力以及高效能的資料線上分析能力。本文是對騰訊 TBase 專家工程師伍鑫在雲＋社群沙龍 online 的分享整理，將為大家帶來騰訊雲 TBase 在分散式 HTAP 領域的探索與實踐。
一、TBase分散式資料庫介紹
1. TBase 發展歷程
騰訊雲從 2009 年便開始在內部的業務上進行嘗試，在企業分散式資料庫領域的自研過程是比較有經驗的。當時主要是為了滿足一些較小的需求，比如引入PostgreSQL 作為 TDW 的補充，彌補 TDW 小資料分析效能低的不足，處理的需求量也較小。
但業務慢慢的大了後，需要有一個更高效的線上交易事務的處理能力，對資料庫要進行一個擴充套件，所以後面我們就持續的投入到資料庫的開發過程中。
2014 年 TBase 釋出的第一個版本開始在騰訊大資料平臺內部使用；2015 年 TBase 微信支付商戶叢集上線，支援著每天超過 6 億筆的交易；2018 年的時候 V2 版本對事務、查詢優化以及企業級功能做了較大增強，慢慢的開始面向一些外部客戶；2019 年 TBase 中標了 PICC 集團的核心業務，協助了他們在國內保險行業比較領先的核心繫統，並穩定服務了很長的時間。
考慮到 TBase 整體能力的持續發展，我們是希望把 TBase 的能力貢獻給開源社群，這樣能更多的支援資料庫國產化專案。於是在 2019 年 11 月，我們把資料庫進行了開源，希望能助力數字化產業升級。
2. PostgreSQL 資料庫簡介
TBase 是基於單機 PostgreSQL 自研的一個分散式資料庫，除了具備完善的關係型資料庫能力外，還具備很多企業級的能力。同時增強了分散式事務能力，以及比較好的支援線上分析業務，提供一站式的解決方案。
在資料安全上，我們有著獨特之處，包括三權分立的安全體系，資料脫敏、加密的能力。其次在資料多活、多地多中心的靈活配製上面，也提供了比較完善的能力，保障了金融行業線上交易中一些高可用的場景。為金融保險等核心業務國產化打下堅實基礎。
PostgreSQL 是一個開源的 RDBMS，開源協議基於 BSB 風格，所以原始碼可以更加靈活的供大家修改，也可以在修改的基礎上進行商業化。
PostgreSQL 是由圖靈獎得主 MichaelStonebraker 主導的一個開源專案，如上圖所示，它已經迭代得比較久了，到現在已經發布到 12 版本，並且一直在持續的迭代，整體處於一個比較活躍的水平。
3. PostgreSQL 發展趨勢
PostgreSQL 在近十年開始受到的大家的關注，首先是因為它的核心功能，包括社群的持續活躍，在過去幾年獲得了持續的進步。上圖是來自 DB-Engines 的統計，根據資料我們可以看到在去年整體大家都有一些退步和增長不太高的情況下 PostgreSQL 的進步是比較明顯的。
下圖中黃色的曲線是 PostgreSQL，我們可以很直觀的看到它發展趨勢是比較良好的。
目前開源的 TBase 版本是基於 PostgreSQL10，我們也在持續的匹配 PostgreSQL 更多的功能，後續也會回饋到開源社群，希望和整體的 PostgreSQL生態有一個良好的結合和互動。
二、開源 TBase 定位及整體架構
1. 開源 TBase 的定位
資料庫按照業務場景主要分為：OLAP、OLTP 和 HTAP。
OLAP 的業務特點是資料量較大，一般是 10PB+，對儲存成本比較敏感。它的併發相對於 OLTP 不會太高，但對複雜查詢可以提供比較好的支援。
OLTP 的資料量相對較小，很多中小型的系統都不會達到 TB 級的資料量，但對事務的要求和查詢請求的要求會比較高，吞吐達到百萬級 TPS 以上。並且 OLTP 對於容災能力要求較高。
國內的國產化資料庫很多會從 OLAP 領域進行切入，從OLTP 角度切入會相對比較難，目前這一塊還是被 IBM 或者Oracle 壟斷的比較嚴重，我們希望儘快在這一塊實現國產化。而 TBase 因為在保險行業有比較長時間的耕耘，在 OLTP 核心業務能力上有比較強的。
另外一個是 HTAP。在之前大部分的業務部署中，大家會把 TP 和 AP 分開，在中間可能有 ETL 或者流複式的技術將兩套系統進行互動。但更理想的情況是可以在一套系統中同時完成兩種業務型別的支援。
當然這個會比較複雜。首先大家可以看到他們的業務特點差別比較大，核心領域的優化方向也是完全不一樣的，或者說技術上差異比較大。
TBase 推出 HTAP 也是從具體的需求出發，實際上 TBase 是更偏向於 TP，同時兼顧了比較好的 AP 的處理能力，在一套系統裡儘量做到比較好的相容。但如果要做更極致效能的話，還是要對HTAP 進行隔離，對使用者提供一種完整的服務能力。
TBase 的角度也是根據需求衍生出來的。騰訊雲最早是做交易系統，後面慢慢的補充了 AP 的分析能力。
這塊面臨的主要的業務場景需求，首先是交易資料可能會大於 1T，分析能力大於 5T，併發能力要求達到 2000 以上，每秒的交易峰值可能會達到 1000 萬。在需要擴充套件能力的情況下，需要對原有的事務能力、分析能力，或者資料重分佈的影響降到最低。同時在事務層面做到一個完備的分散式一致性的資料庫。
同時 TBase 也進行了很多企業級能力的增強，三權分立的安全保障能力、資料治理能力、冷熱資料資料及大小商戶資料的分離等。
前面我們介紹了 TBase 的發展過程，在這過程中我們也希望可以為開源社群進行一些貢獻。
實際上在國內環境中替換核心業務還是比較難，更多的是從分析系統切入，最近幾年才開始有系統切入到核心的交易事務能力上，TBase 也希望通過開源回饋社群，保證大家可以通過 TBase 的 HTAP 能力來填補一些空白，擴充生態的發展。
開源後我們也受到了比較多的關注和使用，其中還包括歐洲航天局的 Gaia Mission 在用我們的系統進行銀河系恆星系統的資料分析，希望有更多的同學或者朋友加入到 TBase 的開發過程中，也希望通過本次介紹，方便大家更好的切入到 TBase 開源社群的互動中。
2. TBase 總體構架
一個叢集是由這幾個部分組成：GTM、Coordinator和 Datanode。其中 GTM 主要負責全域性事務的管控，是提供分散式一致性協議的基石；Coordinator 是使用者業務的訪問入口，對使用者的請求進行分析和下發，具體的計算和資料儲存則是放到了 Datanode 當中。
三、HTAP方面能力介紹
剛才我們講的是 HTAP，下面我們先講一下 OLTP，TBase 在這部分的能力是比較突出的。
如果使用者需要在事務或者併發交易量上有要求的話，就需要一套比較好的分散式事務的系統。具體的需求包括高效能和低成本，在這部分，TBase 相較於傳統的 IBM 或者國外更貴的一體機有較大的優勢。
另外一個需求就是可擴充套件，在節點擴充套件的情況下去近似線性的擴充套件事務處理能力。那要如何達成這個目標？
簡單介紹一下事務的 MVCC 的處理，單機 PostgreSQL 主要是維護一個當前的活躍事務列表，它有一個結構叫 Proc array，相當於每一個使用者的 session 有新的事務請求的話，會在事物列表裡去記錄當前活躍的事務，當需要判斷 tuple 的可見性的話，會在活躍事務列表裡拿一個 Snapshot 去跟儲存上面的 tuple header 中記錄的 XID 資訊進行一個對比，去做 MVCC 的訪問控制。
如果是擴充套件到分散式的情況，一個比較簡單的方式是需要有一箇中心節點。按之前的構架，在 GTM 上面會有一箇中心化的活躍事物列表，來統一的為每一個訪問的請求去分配 Snapshot。
但這個時候就有一個比較大的問題，中心節點會成為瓶頸，GTM 也會有一些問題，比如說快照的尺寸過大或者佔用網路較高。
GTM 如果做一箇中心化的節點的話，實際上存在一個單點瓶頸，每一個請求都要保證它拿到 snapshot 的正確性，這就需要對活躍事務列表進行上鎖，這個在高併發情況下鎖衝突會很大。我們是怎麼解決這個問題的呢？
這實際上也是業界一個通用的問題。目前我們看到網際網路行業的方案，是從 Google Spanner 的方向衍生出來的。
Google Spanner 是一個全球分散式資料庫，可以在各大洲之間提供一致性的資料庫服務能力。它的控制併發技術特點，一是通過 KV 儲存基於全域性時間的多版本併發控制，另外一個是它通過使用成本比較高的 GPS 和全球一致的服務時間戳機制來提供一個 TrueTime API，基於真實時間製作一套提交協議。因為它的整體全球分散式，導致平均誤差會大概在 6 毫秒左右，整體的事務時延是比較高的。
另外，有較多的系統會借鑑 Google Spanner 做事務模型，CockRoachDB 也是其中之一。
另外，Percolator 也是 Google 為搜尋引擎提供的一個比較有效率的資料庫，使用 KV 儲存，基於全域性邏輯時間戳的 MVCC 進行併發控制。它的時間戳由專門的時間戳服務提供，分散式事務第一階段需要對修改記錄加鎖，提交階段結束鎖定；事務提交時間複雜度為 O(N)，N 是記錄數，導致提交的效能會有影響，當然這樣的設計也和系統需求相關。
下面看一下 TBase 在分散式事務上的能力，這部分我們也是在前面的基礎上做了較大改進。
首先我們對 GTM 叢集做了優化，從原始的全域性 XID 改成了分配全域性時間戳GlobalTimeStamp（GTS），GTS 是單調遞增的，我們基於 GTS 設計了一套全新的 MVCC 可見性判斷協議，包括 vacuum 等機制。這樣的設計可以把提交協議從 GTM 的單點瓶頸下放到每一個節點上，減輕壓力，同時通過時間戳日誌複製的方式實現 GTM 節點主備高可用。
這種協議下 GTM 只需要去分配全域性的 GTS，這樣的話單點壓力就會被解決得比較明顯。根據我們的推算， 滕敘 TS85 伺服器每秒大概能處理 1200 萬 TPS，基本能滿足所有分散式的壓力和使用者場景。
我們剛才也提到，在 Percolator 的實現下，需要對 Tuple 上鎖並修改記錄，這樣的話效能是比較差的。而實際上我們對提交協議做了一個優化，在對 Tuple Header 的 GTS 寫入做了延遲處理，事務提交的時候不需要為每一個 Tuple 修改 GTS 資訊，而是把 GTS 的資訊儲存在相應的 GTS Store File 當中，作為事務恢復的保障。
當使用者第一次掃描資料的時候，會從 GTS Store File 中取到狀態，再寫入到 Tuple Header 中，之後的掃描就不需要再去遍歷狀態檔案，從而實現加速訪問，做到事務處理的加速。這樣在整體上，讓資料庫在事務層面保證了比較高效的設計。
關於集中資料分佈的分類情況，有以下三種。
第一種情況是複製表。複製表中的每個儲存節點都有完整的資料副本，適用於變化較少的小表，可以加速關聯查詢。
第二種是 HASH 分佈，這是比較經典的一種方式。簡單來講就是將資料按照分佈列進行 hash，把資料打散在各個儲存節點中，如果 hash key 選擇不當，則可能造成資料傾斜的情況。
第三種是基於 RANGE 的分佈。RANGE 分佈會將資料按照分段打散成小的分片，和 hash 相比分佈上不會特別嚴格，對上層的節點彈性有比較好的支援。但它在計算的時候，相對 hash 的效果不會特別好。
在整體上，TBase 選擇的是複製表和增強的 hash分佈。
下面介紹一下如何看分散式查詢，PushQuery 和 PullData。
最開始早期的一些系統可能會選擇更快速的實現，比如說儲存上是分成多個 DN，然後把資料拉取到 CN 進行計算。
這種情況下優缺點都比較明顯，優點是更高效更快速，缺點是 CN 是一個瓶頸，在網路上壓力比較大。所以我們更傾向於上圖中右邊的方式，把有的資料和計算下放到 DN 結點上。
最基本的情況下，希望所有的計算可以放到 DN 上來進行。DN 在做重分佈的時候，需要跟 DN 間有互動的能力，這個在 TBase V2 之後做了比較多的增強，目前 TBase 可以將計算儘量的分散到 DN 結點上來進行。
上圖介紹的是 SQL Shipping 和 PlanShipping 的區別。
實際上當處理一個 query 或者一個查詢計劃的時候，會有兩種情況。一種是說我直接把 SQL 通過分析發到 DN 上執行，CN只負責結果的收集。這樣的優化效果會比較好，因為不需要在多個節點建立分散式一致性的提交協議，另外在計算資源上效率會更高。我們在 OLTP 領域的一些優化會採用這樣的方式。
另一種情況是在 OLAP 領域，更正規的 PLAN 的分散式。在 CN 上對 query 做一個整體的plan，按照重分佈的情況把計劃分解成不同的計算分片，分散到 DN上進行處理
剛才講到，就是如果能把對 OLTP 推到某單個 DN 上來做的話，效果會比較好。我們舉個簡單的例子。
兩張表的分佈列是 f1，資料列是 f2，若 query 可以寫成分佈鍵的關聯情況，並且採用的是 hash 分佈，就可以把 query 推到不同的 DN 上來做。因為不同 DN 間的資料受到分佈件的約束，不需要做交叉計算或者資料的重分佈。
第二類是有分佈鍵的等值連結，同時還有某一個分佈鍵的具體固定值。
在這種情況下，CN 可以通過 f1 的值判斷具體推到哪個 DN 中去做。
還有一些更復雜的查詢，比如存在子查詢的情況，但方式也是類似的分析方法。
子查詢可能會有一個複雜情況，如果在多層的子查詢中都可以判斷出來跟上層有相同的單一節點分佈情況，query 也可以下發到 DN 中。這種情況下對 OLTP 效能會有比較好的影響，叢集的能力會得到比較好的優化。
針對比較複雜的 query，可能就需要涉及到優化配置的調整。
方式主要分為兩種：規則優化（RBO）和代價優化（CBO）。RBO 主要是通過規則來判斷查詢計劃到底符不符合進行優化，這個是比較早期的一些實現方法，因為計算量相對較小，所以對某些場景比較高效，但明顯的缺點是彈性不足，同時不能用於比較複雜的場景。
實際上更多的這種資料庫使用的是 CBO 的方式。簡單講，CBO 會對所有路徑的進行動態規劃，選擇成本最小的一條作為執行計劃。這種方式的優點是有較好的適用性，能夠適合複雜場景的優化，效能表現較穩定。缺點是實現複雜，需要一定的前置條件，包括統計資訊、代價計算模型構建等。
但這也是不絕對的，兩者沒有誰可以“贏”過對方的說法，更多是需要對二者進行一個結合。TBase 主要是在 CBO 上進行優化，比如在計算一些小表的場景中，不需要進行 redistribution，直接 replication 就可以了。
關於分散式中文 distribution 的一些調整的情況，我們還是打個簡單的比方。兩張表，TBL_A 和 TBL_B。
如果 f1 是分佈列，分佈類等值的情況下會變成 push down，這種情況下可以在 DN 上直接進行計算。
上圖中間的情況中，TBL_A 是分佈鍵，TBL_B 是非分佈鍵。在這種情況下，如果 TBL_B 足夠小，必須要對 TBL_B 進行重分佈，也就是對 TBL_B 進行 replication，這時就會涉及到一些代價的估算。而如果 TBL_B 比較大的話，可能需要對 TBL_B 進行 redistribution。
剛才我們也講到，TBase 在 OLAP 方面也有比較強的能力，這部分的優化思路主要是藉助了計算的並行。計算的全並行能力主要體現在幾個方面。
首先是節點級的並行，因為我們是分散式的資料庫，所以可以有多個節點或者程式進行計算；另外一層是程式級的並行，目前 TBase 沒有改成執行緒模型，所以並行主要體現在程式級模型中，基於 PostgreSQL 程式並行的能力做了一些增強。還有一層是指令集的並行，對指令進行優化，後面也會對這部分進行持續的增強。
那麼 Postgres 的查詢計劃，或者是程式並行的能力是如何實現的呢？最早期我們 follow 的是 PG10，並行能力並不是非常強，只提供了基礎的框架和部分運算元的優化，這是 TBase 當時進行優化的一個點。
在分散式的情況下，很多單機可以進行並行，但在分散式中就不可以進行並行，所以我們希望對這些能力進行一些增強，從而保證更大範圍的一個並行能力。
平行計算其實是一種自底向上推演的方式，比如說底層的一個節點可以並行，那麼如果遞推向上到了某一層不能並行，就可以把下面所有可以並行的地方加一個 Gather Node，把結果從多個程式中進行收集，繼續向上進行規劃。這也是我們希望增強的一個點。
下面我們介紹一些具體的優化。
早期 PG 的 HashJoin 在 outer plan 是可以做並行的，但在 inner 構建 hash table 的情況則不能做並行的。
簡單來說，hashjoin 可以分為幾步。首先是 build hash table，第二步是獲取部分 outer plan 資料，計算雜湊值，並進行匹配。這裡我們將 inner hash table 構建過程也做了並行化處理，保證 Hashjoin 的左右子樹都可以進行並行，並繼續向上層節點推到並行化。
另外一種情況是 AGG（Aggregation）。
很多情況下都是一個兩階段的 Agg，需要在 DN 上做一些 partial agg，然後到上層計劃分片進一步做 final agg。實際上在這種情況下，中間碰到 redistribute 需要先在 DN 進行資料的整合，然後再去做 final 的 Agg。
在有多層子查詢的情況下，每一層都進行計算會導致最後整體的平行計算不會很高。所以我們在 redistribution 也做了一些並行，也就是在 Partial Agg 的情況下可以按照 hash 分佈去發到對應的上層 DN 節點上進行並行。
還有一些資料傳輸方面的優化。
我們提到 redistributio 節點可以進行並行能力的增強，而在資料的接受和傳送上也需要進行優化提升。早期的版本是單條的處理模式，網路的延遲會比較高，效能會不太好，所以我們在這部分進行了一些優化，從而實現比較好的並行執行的能力。
四、開源TBase企業級能力介紹
實際上 TBase 還做了一些企業級能力的增強，後面也持續的會去做一些開源貢獻和優化。
目前開源 Tbase 企業級已經可以實現多地多中心，或者是多活能力的構建，包括安全、管理、審計的能力，TBase 在安全上面有比較高的要求，後面也會持續的貢獻出來。
還有就是在水平擴充套件能力上，TBase 可以做到在使用者感知比較小的情況下進行擴容。擴容在大資料量的情況下是一個普遍的痛點，我們在這方面的能力上也會有一個持續的增強。
此外，TBase 還有自研的分析表以及冷熱資料的分離，也都是有比較好的效果，對於使用者成本的降低，還有資料分佈的靈活性都會有比較好的提升。
TBase 在今年 7 月 13 號開源釋出了 v2.1.0 版本，我們也持續的在開源能力上做著建設，包括多活能力的持續增強、維護性的增強，效能安全持續的升級，包括通過一些企業客戶發現的問題也都會持續的貢獻出來。還包括統計資訊增強以及增強對小表重分佈的優化，也是希望大家可以持續關注 TBase，和我們進行更多的討論和切磋。
五、Q&A
Q：TBase的佈置有哪些要求？
A：大家可以訪問 TBase 的開源版本，上面有具體的使用方法和基於原始碼的構建，還有搭建的流程，都有比較明確的文件。如果大家想嘗試的話，可以使用正常的 X86 伺服器或者本機的 Linux 伺服器就可以做一些簡單的搭建，企業級專案上大家也可以做一些嘗試，保持溝通。
Q：為什麼選擇基於 PostgreSQL 開發呢？
A：實際上大家會面臨 MySQL 和 PostgreSQL 兩個方向上的選擇，我主要介紹我們選擇 PostgreSQL 的原因。
一是 PostgreSQL 的協議會更加友好，在協議的靈活性上會比較好一些，大家可以隨意的對它的程式碼做改動和完整發布。
另外它的核心實現上也比較嚴謹，有自己的獨到之處，持續的也在增強，包括它的迭代速度也是比較快。我們早期一直在跟進，持續的 merge PostgreSQL 的一些 feature，也是伴隨著 PostgreSQL 的成長，我們的核心也做了一個比較快速的迭代。同時我們也在瞭解核心的情況下，做了一些更深入的調優。
Q：DN節點的儲存叢集是基於Raft嗎？多Leader還是單Leader呢？
A：目前我們的 DN 結點沒有用到 Raft 協議，是做的主備複製。我知道有很多新的業務會基於 Raft 的提交協議，或者是用這種複製的協議去做一致性和高可用。但實際上 Raft 的多副本對提交協議還是有一些效能影響的，整體的流程相對於傳統的會有更長的時延，相當於 CAP 原理，C提高了，A會有部分影響。
而我們更傾向於 OLTP 系統，所以在事務上的要求和時延響應的要求是比較高的，於是做了這樣的選擇。
Q：能詳細講講分散式事務的實現流程嗎？怎麼樣保證多機之間的分散式事務，兩階段提交嗎？
A：現在我們基本是 follw 兩階段提交。一個是兩階段提交的控制流程、控制協議，另一個是事務隔離的協議。剛才主要講了 MVCC，在提交協議上基本上兩階段提交的增強版。
由於使用了 GTM，導致它和傳統的單機模式不太一樣，做了一些統一的協調，剛才也著重介紹了。這樣的一個優勢是減輕了 GTM 上的壓力，另外在 prepare 階段會有部分的阻塞情況，但在優化之後影響是非常小的，卻能極大的減輕 GTM 的壓力。
Q：底層的儲存是怎麼同時滿足行存和列存的需求呢？還是按照塊(Tile)連續儲存？
A：我們開源版本的底層儲存主要是行存，後面會在列存和 HTAP 進行持續的增強，進一步提升 HTAP 的能力。等逐步穩定之後，會再考慮迭代開源版本。
Q：最少需要多少伺服器搭建？
A：其實單點搭建也是可以的。一個 DN、一個 CN、一個 GTM 也可以。實際上最好布成兩 DN，可以體驗更多的分散式搭建。實際上我們在企業服務的叢集上已經超過了上千個節點，包括解決 GTM 的單點壓力上，對叢集整體的擴充套件性有比較好的提升，所以從兩個節點到多節點都可以去嘗試一下。
Q：GTM的授時，有采用batch或者pipeline嗎？還有現在Tbase支援的從庫的讀一致性嗎？
A：有的。GTM 的授時我們也做了更多的優化，簡單說可以做一些並行的 GTS 的單調授時，根據現行的規模或者是我們對客戶場景的預估，在 x86伺服器中大概可以達到1200萬QPS的授時的能力。在增強伺服器的情況下，整體的能力是比較強的，基本上不會在這部分產生瓶頸。
Q：tbase有什麼安全保障機制?
A：從業務角度，我們講到了安全隔離，以及有很強的行級安全規則、列級訪問控制以及資料加密、脫敏增強，這些都可以傾向於向一個企業級的資料庫去應用，現在很多企業級服務的能力也在 TBase 裡面，後面我們會根據情況進行進一步的迭代。