國產開源數據庫：騰訊雲TBase在分佈式HTAP領域的探索與實踐

​導語 | TBase 是騰訊TEG數據平臺團隊在開源 PostgreSQL 的基礎上研發的企業級分佈式 HTAP 數據庫系統，可在同一數據庫集羣中同時爲客戶提供強一致高併發的分佈式在線事務能力以及高性能的數據在線分析能力。本文是對騰訊 TBase 專家工程師伍鑫在雲＋社區沙龍 online 的分享整理，將爲你們帶來騰訊雲 TBase 在分佈式 HTAP 領域的探索與實踐。

 

點擊視頻查看完整直播回放

 

1、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生態有一個良好的結合和互動。

 

2、開源 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 當中。

 

3、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 節點能夠進行並行能力的加強，而在數據的接受和發送上也須要進行優化提高。早期的版本是單條的處理模式，網絡的延遲會比較高，性能會不太好，因此咱們在這部分進行了一些優化，從而實現比較好的並行執行的能力。

 

4、開源TBase企業級能力介紹

 

實際上 TBase 還作了一些企業級能力的加強，後面也持續的會去作一些開源貢獻和優化。

 

目前開源 Tbase 企業級已經能夠實現多地多中心，或者是多活能力的構建，包括安全、管理、審計的能力，TBase 在安全上面有比較高的要求，後面也會持續的貢獻出來。

 

還有就是在水平擴展能力上，TBase 能夠作到在用戶感知比較小的狀況下進行擴容。擴容在大數據量的狀況下是一個廣泛的痛點，咱們在這方面的能力上也會有一個持續的加強。

 

此外，TBase 還有自研的分析表以及冷熱數據的分離，也都是有比較好的效果，對於用戶成本的下降，還有數據分佈的靈活性都會有比較好的提高。

 

TBase 在今年 7 月 13 號開源發佈了 v2.1.0 版本，咱們也持續的在開源能力上作着建設，包括多活能力的持續加強、維護性的加強，性能安全持續的升級，包括經過一些企業客戶發現的問題也都會持續的貢獻出來。還包括統計信息加強以及加強對小表重分佈的優化，也是但願你們能夠持續關注 TBase，和咱們進行更多的討論和切磋。

 

5、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 裏面，後面咱們會根據狀況進行進一步的迭代。