守護客戶數據價值：企業級NewSQL HTAP分佈式雲TBase架構詳解

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

做者：jasonys，隸屬於騰訊技術工程事業羣數據平臺部，負責TBase數據的技術研發和架構設計，有超過10年的數據庫內核開發設計經驗，完成多種數據庫的架構設計和開發。

2017年PGXZ更名爲TBase，以發佈會的方式正式對外進行了發佈，通過團隊小夥伴們的努力，TBase V1版本到目前在公司外部市場上的客戶包括了政務，公安，消防，電信，金融等行業的十幾家客戶。TBase以其功能強大，運行穩定，和強大的互聯網基因獲得客戶的廣泛承認。在和外部客戶的接觸中，聽到了不少讚美的聲音，也有很多但願TBase可以解決客戶更多痛點的指望。

2017年中TBase團隊結合客戶的需求和數據庫技術的最新發展趨勢，通過至關長時間的規劃和討論，在PostgreSQL最新版本V10.0的基礎上規劃了TBase V2版本，但願可以表明騰訊最新最強的數據庫技術，來知足客戶的需求，解決客戶業務運行中的痛點。

在接下來的8個多月裏，數平小夥伴們夜以繼日，終於完成TBase V2核心的開發，這個凝結了數平小夥伴們數百個晝夜辛勤工做的版本終於要和你們見面了，很高興能能在這裏給同窗們介紹TBase V2的核心概念和架構。

TBase V2核心概念

TBase V2的重要的技術特性和概念，主要包括如下幾個方面：

企業級：企業級特性包含如下幾個方面：

• 用戶友好的事務特性：業務無需關注數據庫的事務特性，數據庫內核支持完整的分佈式事務，保證事務的ACID。
• 用戶友好的數據庫特性：主鍵，外鍵，序列，約束，分區表，存儲過程，觸發器，子查詢等企業級的特性完整支持。
• 用戶友好的SQL接口：當前TBase V2可以兼容SQL2003標準，同時還可以兼容常見的ORACLE語法，能夠方便ORACLE深度用戶的遷移，當前在外部已經有ORACLE遷移的案例。
• 用戶友好的分佈式查詢能力：良好的分佈式查詢支持能力，數據庫內核可以高效的處理分佈式JOIN。

NewSQL數據庫：相對傳統的數據庫產品，TBase可以作到高效的在線線性擴容，在集羣規模發生變化的時候不會影響到業務的運行。

HTAP能力： Hybrid Transactional/Analytical Processing，即事務和分析混合處理技術，這個技術要求原本資源訴求矛盾的兩種業務類型在同一個數據庫中完成處理。TBase V2通過專門的設計完美的作到了HTAP，同時具有了高效的OLAP能力和海量的OLTP處理能力。

下面是咱們測試的事務測試模型TPCC的benchmark測試結果，系統在每分鐘完成的事務量超過310萬，更大規模集羣的測試還在進行中，從當前的架構設計來看，在硬件容許的狀況下，系統的事務吞吐量會隨着集羣規模準線性提高：

下面這張圖展現了TBase在行存儲模式下和業界MPP數據倉庫標杆在OLAP測試集合TPCH 1Tbenchmark下的對比狀況：

經過這張圖能夠直觀的看到TBase的OLAP分析能力，TBase在22個用例中每一個用例的耗時都優於咱們的競品，部分用例耗時大幅度的超過對方。

經過HTAP技術，業務能夠在單一的TBase集羣中同時處理OLTP類交易和OLAP類分析。經過HTAP，能夠大幅度的減小業務系統的複雜度，下降運維成本。

高數據安全：

在和客戶交流的過程當中，多個行業的客戶都提到了數據安全的訴求，TBase團隊結合客戶的需求和業界先進的數據庫安全解決方案設計了TBase V2的數據安全體系。這個體系主要包含如下幾個方面：

• 三權分立：把數據庫系統dba的角色分解爲三個相互獨立的角色，安全管理員，審計管理員，數據管理員，這個三個角色之間相互制約，消除出系統中的上帝權限，從系統角色設計上了解決了數據安全問題。
• 強制安全規則：結合業界先進的數據庫安全解決方案，TBase V2提出了強制安全規則解決方案，經過安全管理員制定的強制安全規則，可也作到行級可見和列級可見，進而限制用戶看到的數據，對不一樣的用戶作到權限的行列混合控制，有效的杜絕數據越權查看，保證關鍵數據的安全性。
• 透明數據脫敏管理：對於金融，安全等對數據安全有特殊要求行業，常常會有數據脫敏的訴求，可是現有的解決方案不少都須要有業務的參與，要求業務深度的參與，有必定的門檻。TBase針對這個痛點進行了專門的設計，作到業務的透明脫敏，業務只須要根據本身的業務規則結合TBase的脫敏語法，設計業務邏輯。TBase內部就能夠作到數據的脫敏，同時結合上面提到的強制安全規則，安全管理員能夠作到指定數據脫敏的針對用戶，最終達到高安全級別的用戶看到的是非脫敏的數據，低安全級別的用戶看到的是脫敏後的數據。
• 審計能力：在與客戶交流的過程當中，衆多客戶都提到了數據庫審計的訴求，TBase V2在設計的過程當中，結合業界標杆的審計標準設計了本身的審計系統，在內核中實現了審計的核心功能，作到在兼顧高精準的審計粒度的同時還能保證系統的性能。同時針對一些業務中遇到的問題，設計專門的解決方案，作到審計結果的實時通知。

多租戶能力：

TBase提供集羣級和集羣用戶級兩個級別的多租戶能力。經過集羣級的多租戶能力，能夠幫助業務快速的創建一個數據庫私有云，幫助客戶快速提供基於TBase的DRDS服務。集羣級的多租戶能力架構以下圖：

除此以外，TBase數據庫集羣內部還提供基於節點組node group的集羣內多租戶解決方案，作到數據庫集羣內部的業務和資源隔離，多個業務在Tbase內部相互隔離的運行。下圖APP1，APP2，APP3同時在一個數據庫集羣內部運行，相互之間經過group進行隔離，互不影響。

TBase產品架構

上面整體上介紹了TBase V2的技術特性，第一次接觸TBase的同窗仍是有點不明因此，爲了方便小夥伴們的理解後面的內容，這裏把TBase總體架構介紹下。V1和V2在總體架構上是相似的:

集羣中有三種節點類型，各自承擔不一樣的功能，經過網絡鏈接成爲一個系統。這三中節點類型分別是：

• Coordinator：協調節點，對外提供接口，負責數據的分發和查詢規劃，多個節點位置對等，每一個節點都提供相同的數據庫試圖；在功能上CN上只存儲系統的全局元數據，並不存儲實際的業務數據。
• Datanode：處理存儲本節點相關的元數據，每一個節點還存儲數據的一個分片。在功能上，DN節點負責完成執行協調節點分發的執行請求。
• GTM:全局事務管理器(Global transactionmanager.)，負責管理集羣事務信息，同時管理集羣的全局對象，好比序列，除此以外GTM上不提供其餘的功能。

經過上面的架構，TBase提供了一個具備友好接口的數據庫集羣。這個數據庫集羣架構上具備以下優勢：

• 寫可擴展 (Write-scalable)：能夠部署多個CN，而且同時向這些節點發出寫操做。
• 多主節點 (Multi-master )：系統的每一個CN節點均可以發起寫入操做，並均可以提供統一完整一致的數據庫視圖；
• 數據自動同步（Synchronous)：對於業務來講，在一個CN節點的寫入操做會馬上呈如今其餘的CN節點上；
• 數據透明（Transparent）：是指數據雖然存在於不一樣的DN節點中，業務在經過CN查詢數據庫時，仍是能夠像使用普通的數據庫同樣編寫SQL語句，沒必要關心數據位於具體的節點，TBase數據庫內核自動完成SQL的調度執行，並保證事務特性。

TBase V2特性詳解

V2 OLAP能力提高：

說到OLAP能力的提高，首先要講下TBaseV1和V2在處理OLAP類請求時的差別，V1和V2在處理OLAP請求時的差異主要有執行方式和DN節點之間是否相互通訊兩個方面：

執行方式：V1中執行OLAP類請求時CN下發到DN的是SQL語句，DN負責SQL語句的規劃和執行，而後向CN上報結果，CN完成結果的彙總。V2中，CN收集集羣的統計信息，對OLAP類的查詢規劃集羣級的分佈式查詢計劃，並下發到各個DN上進行執行，也就是說CN下發的是執行計劃，DN只負責執行而已。

DN之間是否交換數據：V1中，DN之間相互沒有通訊通道，沒法進行數據交換。V2版本在DN節點之間創建了高效數據交換通道，能夠高效在DN節點之間交換數據。

差別以下圖所示：

在V2 OLAP框架的基礎上，咱們開發了一整套完整高效的多線程數據傳輸機制，在運行OLAP查詢時，這套框架保證數據能夠高效的在節點之間完成同步，大幅的提高OLAP處理效率。

在算法層面，基於PG10具有的多核並行執行能力，咱們在集羣環境下系統性的從新設計了經常使用的JOIN，AGGRATE算法，得以充分發揮現有硬件的性能，在一樣的集羣規模下，測試OLAP benchmark TPCH 1T，在行存儲模型下，平均性能超過業界標杆2到5倍。

OLTP能力優化提高：

GTM是TBase集羣中負責處理事務信息的模塊，它的處理能力直接決定了系統的事務吞吐量。並且GTM是系統中惟一的單點，它的處理上限直接影響到系統處理能力的天花板。

爲此咱們對GTM進行了專門的優化和設計。主要集中在如下四個方面：

• 網絡帶寬的優化，取消系統的集羣快照，改成邏輯時鐘來判斷事務的集羣可見性，大幅減小對GTM的網絡帶寬的佔用，同時還下降了GTM的CPU佔用。
• CPU使用率的優化，經過線程資源複用的方式大大，減小GTM的線程數據，減小系統調度CPU佔用率，大幅的提高GTM的處理效率。
• 系統鎖的優化，在系統吞吐量達到百萬級時GTM原來使用的系統互斥鎖佔用了絕大多的CPU，咱們編寫了用戶態的互斥鎖，使得CPU使用率只有原來的十分之一，提高了系統的處理能力上限。
• 免鎖隊列的使用，使用免鎖隊列取代原來的帶鎖隊列，減小系統的鎖使用，大幅提高系統的處理效率。

除此以外咱們還提出了具備專利的分佈式事務一致性技術，來保證在全分佈式環境下的事務一致性。經過上面的這些優化，TBase單機羣的TPCC事務處理能力獲得大幅度的提高，並且處理能力會隨着集羣規模準線性提高。下面是咱們在60臺集羣規模下測試的tpcc結果，最大吞吐量達到310W每分鐘，此時系統DN,CN資源吃緊，可是GTM資源仍有至關多的剩餘，所以隨着集羣規模的增長，系統的吞吐量還能夠繼續提高。

TBase V2 HTAP處理能力：

在講TBase的HTAP能力以前，先分析下當前市面上主流分佈式數據庫架構在HTAP方面的能力，咱們這裏不討論諸如Exadata，HANA之類的一體機解決方案。

首先講下在互聯網公司常見的sharding分佈式架構：

這種架構經過物理上的分庫分表把多個單機數據庫實例使用中間件提供統一的數據庫訪問接口，達到分佈式數據庫的效果。這種架構在處理簡單的SQL請求時具有必定的競爭力，可是對於處理複雜的分佈式join和子查詢等複雜SQL每每力不從心，所以不太擅長從事HTAP類的業務處理。

第二種架構，經典的MPP架構，典型的產品是PivotalGreenplum，這種架構中只有一個單Master節點，使用主用數據節點提供查詢服務，該架構爲OLAP而生，由於單Master的問題，系統的處理能力受限於master的處理能力，並且系統鎖最小粒度爲表級，直接影響到事務的處理能力，這種架構只適合用來處理OLAP類業務，不適合處理OLTP類業務。

上面講了sharenothing的架構，後面分析下share everything架構，這個架構以下：

典型的產品有Sybase IQ，Oracle RAC。Sybase IQ做爲一款經典的數據倉庫產品，曾經風靡一時，如今數倉的不少概念和解決方案在Sybase IQ中都能找到實現，因爲在設計之初就定位爲一個數據倉庫產品，所以架構上沒有考慮處理事務類請求，只能用來處理OLAP類請求。

對於ORACLE RAC，做爲當前仍是很火的數據庫產品，在處理OLAP和OLTP請求方面都有不錯的表現，可是由於自己以及配套硬件昂貴的價格和擴容時複雜而冗長的流程，被不少的客戶抱怨。

分析完了業界的解決方案，基本得出一個結論，咱們須要一個能夠同時高效處理OLTP和OLAP業務，並且兼顧易用性和低成本的HTAP分佈式解決方案，現有的解決方案很難知足咱們的須要。除了基本的能力，還有一個須要注意的問題是，OLTP類請求關注時延和吞吐量，而OLAP關注時延，二者由於關注點的不一樣在資源使用模型上徹底不一樣，於是如何在同一個集羣內部同時高效處理這兩種業務並很好的作到資源隔離成爲一個棘手的問題。

TBase團隊在綜合考慮了以上的各類因素後，仔細的設計了TBase的HTAP解決方案，總體架構以下：

TBase把HTAP分爲兩種場景：

CASE 1，OLAP和OLTP訪問不一樣的業務數據，在這個場景下，咱們可使用TBase的group隔離技術，在自然知足物理隔離的基礎上讓TBase分別發揮高效的OLAP和海量OLTP能力。

CASE 2，OLAP和OLTP訪問相同的數據，在一樣一份數據上須要同時進行OLTP和OLAP兩種操做，並且還須要同時保證二者的效率。此時爲了達成資源的隔離，TBase使用DN主機運行OLTP業務，使用專門的OLAP備DN節點運行OLAP業務，達整天然的資源隔離的效果。

TBase安全架構介紹

TBase團隊在和客戶交流的過程當中，多個行業的客戶都對數據安全提出了訴求，TBase針對業務的痛點並結合數據庫行業領先的數據庫理念設計了TBase的安全體系。

TBase數據安全體系以數據庫三權分離爲基礎，把傳統DBA的權限分解爲安全管理員，審計管理員，數據管理員。在安全規則領域針對安全管理員增長了安全規則和數據透明脫敏規則，在審計方面結合業界審計標準和業務的場景須要，增長了對象審計，用戶審計，以及細粒度審計。除此以外的數據管理員則履行以前DBA的數據管理和數據庫運維職能。

下面對這幾個部分進行下介紹。

安全架構之--TBase三權分立：

TBase的安全體系分爲如下幾個層次，首先在系統的角色上進行了分解，把備受詬病的DBA超級權限進行了分解，分爲了安全管理員，審計管理員，數據管理員，這個作法業界叫作「三權分立」，以下圖：

這個三個角色能夠對應到美國的三權分立的政治體制：

安全管理員（立法權）：

• 制定強制安全訪問策略。

• 強制安全訪問策略由安全員獨立完成。

• 系統全部用戶都要遵照強制安全訪問策略。

審計管理員（司法權）：

• 系統全部操做都被記錄，包括安全員，管理員的操做。

• 審計策略由審計管理員單獨制定。

• 審計員自己的操做也會強制記錄，不可修改。

數據管理員（行政權）：

• 具有自主訪問控制權。

• 不可干預審計員和安全員的動做

經過這三個角色的劃分，從根本上杜絕了系統的安全死角，安全管理員負責總體安全規則的制定，經過這種方式來約束系統中的全部角色。審計管理員負責指定審計規則，審計系統中包括審計管理員在內的全部角色，作到系統全部操做的可追溯。而數據管理員則負責數據庫的平常運維。三者之間相互約束，相互監督。

TBase安全架構之—強制訪問規則：

強制訪問規則聽起來有點抽象，我這裏拿一個具體的例子來說，一個公司的員工信息以下表：

對於公司的董事長來講，咱們給他的安全規則是看到系統的全部的數據，所以他看到這張表裏面的數據是這樣的，完整的數據並且沒有通過處理：

安全規則規定工程部總經理只能看到工程部本身員工的相關數據，由於薪酬和員工私人信息是高安全級別數據限制對他開放，所以他看到的這張表的數據是這樣的：

對於工程部員工張三來講，系統經過訪問規則限制他只能看到本身的數據，所以他在系統中經過select看到的數據是這個樣子：

這裏張三能夠看到本身的薪酬數據。

TBase提供了完整的安全規則SQL命令來讓安全管理員能夠很方便的定義安全規則，經過這些安全規則就能夠作到數據行列混合訪問控制。

TBase安全架構之—透明數據加密和脫敏：

常常有客戶會給咱們提安全相關的問題，一個問題是：數據業務託管在某個服務商那裏，表中的有些列的內容不想讓服務商看到，可是服務商爲了運維他們的業務又須要知道表結構，問咱們有沒有很好的技術手段來解決這個問題。另一個常見的問題是：若是數據庫文件被人拖走了，咱們如何保證數據的安全性。針對這一類的需求咱們設計了TBase的透明加密和脫敏系統，來全放方位保證用戶數據的安全性。

針對這些數據安全類的需求，TBase設計了數據的透明加密和透明脫敏特性。透明加密和透明脫敏功能能夠單獨使用也能夠組合使用。區別和原理以下：

透明加密：主要是預防數據文件泄漏後發生的數據泄漏，所以咱們在存儲層的文件中存儲的是加密後的數據，對與上層業務訪問來講，業務讀取到的都是明文。

透明脫敏：透明脫敏是強制訪問規則的一部分，所以脫敏規則是針對具體的數據庫角色創建的。對於受權用戶來講，能夠正常的讀寫數據庫表中的數據，對於非受權用戶來講，他只能看到數據脫敏後的結果，這樣能夠有效的防止非受權被非法讀取。

透明加密+透明脫敏：這種方式下，在磁盤上存儲的是密文，能夠防止數據文件泄漏後用戶數據的泄漏，同時還經過強制安全規則來避免非受權的數據訪問，作到存儲層和業務層兩個緯度的數據安全。

這裏還拿上面的數據作爲例子，假如透明脫敏安全規則約束薪酬，我的信息，家庭住址，年齡四個列對DBA進行數據透明脫敏，那麼DBA在查詢這張表時，看到的數據就是這樣的：

從圖中能夠看到，脫敏後的數據都被顯示成了系統默認值，DBA是不能看到這個列的值，並且也沒有其餘的辦法來試探這個列的真實值。

TBase安全架構之—審計：

結合業界先進的解決方案和作法，咱們把TBase的審計分爲如下幾種：

• SQL審計：對特定的SQL語句進行審計，與具體的對象沒有關係。只針對具體的SQL類型。語法格式以下：

sql_statement_shortcut即SQL審計的內容，這裏重點介紹下，ALL包含了下表的審計項，基本上是DDL statements。下面是審計statement列表。

• 對象審計，審計指定對象的指定SQL類型，也就是在指定對象上細化上面的審計狀況。動做以下圖。

TBase的審計採用獨特的設計架構，審計運行的過程當中，對系統的性能影響很小。細粒度審計，這種審計方式比較靈活，能夠對數據設置過濾條件，若是知足條件的數據被訪問了就會觸發審計動做，審計動做能夠是系統的標準動做，也能夠是用戶的自定義動做，好比告警，發短信，發郵件之類的。

TBase的審計採用獨特的設計架構，審計運行的過程當中，對系統的性能影響很小。

TBase V2d多租戶能力

TBase做爲一個企業級的分佈式數據庫，還提供了企業經常用到的多租戶能力，讓客戶能夠在一個數據庫環境運行多個業務，TBase負責多個租戶之間的隔離，作到業務之間的相互無影響。

TBase的多租戶總體架構以下：

TBase的多租戶管理分爲三個層級，最底層是資源管理層，這一層管理基礎的物理機，並對物力進行資源切片和池化以及各個分片之間的隔離，同時還負責對上層的資源分配和釋放。

第二層是租戶管理層，這一層負責租戶內部的權限管理，每一個租戶內部都有一個完整的三權分立體系，每一個租戶能夠對應多個項目，每一個項目對應一個集羣，集羣對物理資源的存放位置不感知。每一個租戶只能夠看到本身相關的項目和集羣。

最上面一層是系統管理，這一層負責租戶和集羣的建立，並管理整個平臺的資源分配和釋放，這一層能夠看到整個平臺的租戶和集羣，以及物理機的狀態信息。

在系統提供的集羣級多租戶外，在單個TBase集羣內部，還提供了基於節點組的集羣內部多租戶解決方案能力。例如以下圖：

在一個數據庫集羣內部，三個APP業務使用不一樣的節點組和各自單獨的CN來作到資源的隔離，完美的實現集羣內部的多租戶。

經過上面兩種解決方案，業務能夠根據本身的須要搭建合適的多租戶環境，快速部署業務。

TBase V2 在線彈性擴容：

對於一個分佈式系統來講，彈性擴容是一個剛性的訴求，TBase在這一塊也不含糊，TBase V1時引入shardmap以及shard表，經過shard表TBase能夠提供在線線性擴容能力。

在V1內核中中shard記錄按照分配的順序存儲，有可能一樣shardid的記錄並無連續存儲，擴容業務流程爲了完成擴容過程，對底層進行了很多的適配，流程較冗長。

V2內核在存儲層引入了shard聚簇的概念，也就是shardid相同的記錄在底層連續存儲，大大簡化上層業務流程的設計，同時大幅的提高了擴容的效率。

TBase V2 分區表：

TBaseV1中咱們引入了集羣分區表，這個分區表的性能相比社區的分區表，性能在OLTP場景下提高了1-3個數量級，尤爲在子表數量衆多的時候性能提高尤其明顯。總體結構以下：

社區的性能對比：

在這個架構中：

Coordinator: 負責縱向分表，不感知表分區(橫向分表)的邏輯。

DataNode：負責橫向分表，根據分表字段將一張邏輯表劃分爲多張物理表。

TBaseV2也具有這個性能優異的內置分區表功能。然而，除此以外V2還從PG 10.0繼承了社區的RANGE和LIST分區，經過新增長的這兩個分區類型，業務在創建分區表時有了更豐富的選擇。

TBase V2 的其餘新特性：

• Hash索引支持Crash Safe：

PG10在這個版本中正式引入了Hashindex的XLOG機制，也就是說咱們能夠放心的使用Hash索引了，對於等值查詢和IN等操做，有了一個相比btree更優的選擇。

• 表達式高效運算：

PG10中爲了支持JIT，把表達式的計算方法從以前的傳統執行器換成了展開執行，表達式的執行效率相比以前大大提高。團隊專門作過一個比較，咱們把典型的表達式運算作了一個JIT DEMO和PG10的內核表達式展開進行了性能比較，發現PG10的測試結果並不比JIT生成的程序性能差。

• 多核擴展性加強：

事務擴展性：PG從9.6開始陸續推出了多個OLTP事務增前特性，包括XLOG並行落盤優化和系統快照機制優化，從咱們團隊測試的狀況來看，從24核的服務器到96核服務器，事務吞吐量能夠作到準線性的提高。也就是說在TBase V2下，不管是24核的常見服務器，仍是更多核的高端服務器，TBase均可以充分的發揮設備的潛力，把資源充分利用起來。

多核並行執行：PG9.6開始引入並行執行框架，到PG10已經能夠作到aggregate，hash join，merge，seqscan，bitmap scan等算子的並行優化。在這些並行能力的支撐下，TBase V2對於海量數據的OLAP分析類操做更是如魚得水。

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/dev...

歡迎你們前往騰訊雲+社區或關注雲加社區微信公衆號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~