最佳實踐 | 騰訊HTAP數據庫TBase助力某省核心IT架構升級

數據存儲和處理是一個古老而重要的技術，從遠古時期的結繩記事到古人的文本記事，再到計算機誕生后的各種系統，直到E.F.Codd提出關系模型，人類終于有了一種相對高效而統一的數據處理系統——關系數據庫。

在傳統的關系數據處理系統中，習慣把系統按照業務特點分為在線事務處理系統(OLTP)和在線分析處理(OLAP)，一般意義上OLTP關注實時在線業務，要求低延時，高吞吐量，總體數據量一般不會特別大；而OLAP系統用來處理大規模數據的報表分析，要求低響應時間。兩者因為數據量，查詢請求，業務要求的不用，加上之前技術條件的限制，就分解為兩個獨立的系統，即OLTP系統用來處理在線交易，OLAP系統用來進行報表處理，兩者之間通過ETL工具連接。

一般這個兩套數據庫系統是相互獨立的產品，常見的OLTP產品有IBM DB2，Informix， ORACLE，SQL SERVER，mysql，PostgreSQL等，在OLAP常見的如TeraData，SybaseIQ，GreenPlum，HP VERTICA, SAP HANA，Hadoop大數據平臺等等。在這個架構中，有兩套獨立的數據系統需要維護，增加系統采購的成本和系統運維的成本；同時ETL過程中OLTP到OLAP系統的數據一致性也是一個讓人頭疼的問題。

TBase向我們展示了一種革命性的數據處理架構，把OLTP和OLAP處理進行融合，在一套數據庫系統中同時完成兩種操作，同時降低業務復雜度和業務成本。TBase在某省部門上線運行超過快四年，在客戶的架構升級中扮演了重要的角色，當前在該客戶有快10套TBase系統在運行，集群規模快接近百臺。本文希望借助客戶的實際案例來對TBase的架構進行下解析，增加大家對TBase的了解。

TBase架構特點

TBase分布式無共享(share nothing)分布式數據庫，集群結構如下：

Coordinator：協調節點（簡稱CN），對外提供接口，負責數據的分發和查詢規劃，多個節點位置對等，每個節點都提供相同的數據庫視圖；在功能上CN上只存儲系統的全局元數據，并不存儲實際的業務數據。

Datanode：處理存儲本節點相關的元數據，每個節點還存儲業務數據的分片，簡稱DN。在功能上，DN節點負責完成執行協調節點分發的執行請求。 

GTM：全局事務管理器(Global transaction manager.)，負責管理集群事務信息，同時管理集群的全局對象，比如序列等。
在這個架構下，TBase集群具有下面幾個能力：多活/多主：每個coordinator提供相同的集群視圖，可以從任何一個CN進行寫入，業務無需感知集群拓撲；
讀/寫擴展：數據被分片存儲在了不同的DN，集群的讀/寫能力，隨著集群規模的擴大做而得到提升；

集群寫一致：業務在一個CN節點發生的寫事務會一致性的呈現在其他的CN節點，就像這些事務是本CN節點發生的一樣；

集群結構透明：數據位于不同的數據庫節點中，當查詢數據時，不必關心數據位于具體的節點；TBase的share nothing集群架構方便了業務接入，降低了業務接入的門檻。

TBase 的HTAP能力

HTAP是混合事務和分析處理
Hybrid Transactional/Analytical Processing的簡寫，TBase通過下面這些技術構建了原生的HTAP能力。

事務ACID強保證：

在分布式數據庫中，分布式事務的ACID保證是一個很有挑戰性的工作，但是業務系統在使用數據庫的過程中，往往會依賴數據庫提供的ACID能力來開發他們的業務，因此事務ACID能力的保證也成了分布式數據庫必不可少的能力。先把數據庫理論中的ACID的定義拿出來，熟悉下這些概念：

ACID，指數據庫事務正確執行的四個基本要素的縮寫。包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。一個支持事務（Transaction）的數據庫，必須要具有這四種特性，否則在事務過程（Transaction processing）當中無法保證數據的正確性，交易過程極可能達不到交易方的要求。
詳細解釋下：

原子性（Atomicity）：整個事務中的所有操作，要么全部完成，要么全部不完成，不可能停滯在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。

一致性（Consistency）：事務必須始終保持系統處于一致的狀態，不管在任何給定的時間并發事務有多少。
也就是說：如果事務是并發多個，系統也必須如同串行事務一樣操作。其主要特征是保護性和不變性(Preserving an Invariant)，以轉賬案例為例，假設有五個賬戶，每個賬戶余額是100元，那么五個賬戶總額是500元，如果在這個5個賬戶之間同時發生多個轉賬，無論并發多少個，比如在A與B賬戶之間轉賬5元，在C與D賬戶之間轉賬10元，在B與E之間轉賬15元，五個賬戶總額也應該還是500元，這就是保護性和不變性。

一致性是分布式事務中的重大挑戰，網絡時延和操作系統調度等不確定因素給分布式 事務一致性的保證帶來諸多困難，但是分布式數據必須有一套完整的分布式事務一致性邏輯，否則會帶來災難性的后果。

隔離性（Isolation）：隔離狀態執行事務，使它們好像是系統在給定時間內執行的唯一操作。如果有兩個事務，運行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。這種屬性有時稱為串行化，為了防止事務操作間的混淆，必須串行化或序列化請求，使得在同一時間僅有一個請求用于同一數據。

持久性（Durability）：在事務完成以后，該事務對數據庫所作的更改便持久的保存在數據庫之中，并不會被回滾。

TBase中的事務嚴格遵守事務的ACID，當前支持read committed和repeatable read兩個隔離級別，并提供可擴展的事務吞吐能力。

在事務測試模型TPC-C中有9張表，用來模擬從倉庫中下訂單發貨，庫存狀態查詢，并有一定的回滾比例，每個事務中有5-6條SQL，讀寫混合，測試過程中要求嚴格遵守ACID。在這個模型下TBase的處理能力隨著集群規模的提升近似線性提升，在30臺（24core，64G，1000Mb）規模時可以達到300W tpm。 

Share nothing架構決定了隨著集群規模的增加系統的TPC-C處理能力會進一步的提升，TBase在事務處理中處理能力可以到千萬級QPS。

完整SQL兼容性：

SQL是訪問數據庫的必備工具，在SQL誕生了幾十年后的今天，大量的軟件產品使用SQL進行開發，每個程序員都或多或少的使用到SQL，數據庫對SQL的處理能力直接關系軟件產品的穩定和程序開發的效率。

TBase認為：完整SQL兼容性 = 完美的SQL語法兼容+代價優化器+分布式執行器。因此TBase在設計之初就定下一條設計規則：SQL語法完全兼容SQL2003標準，讓用戶像使用普通數據庫一樣來使用TBase。

因此在TBase中，數據庫開發工程師可以像在之前熟悉的數據庫產品中一樣編寫SQL，不用擔心數據庫產品的變化帶來額外的學習工作量。為業務節省大量的開發工作，降低業務升級的成本。

除了SQL語法兼容性，為了達到高效的分布式執行，TBase有專門為分布式環境設計的基于代價的查詢優化器，與之配合的是專門為分布式環境設計的分布式執行器。

分布式執行器提供了目前已知的所有數據庫算子(operator)支持，包括聚合，窗口函數，cube，存儲過程，自定義函數，觸發器，物化視圖，并行執行等等。

通過這些設計，TBase為業務提供良好了的數據庫使用體驗，大幅降低業務的遷移成本和開發人員的學習成本，提高業務遷移的效率。 

SQL兼容性和性能我們通過TPC-H來測試。TPC-H標準滿足了數據倉庫領域的測試需求。TPC-H中 用 3NF 實現了一個數據倉庫，共包含 8 個基本表， 22 個查詢(Q1~Q22)，其主要評價指標是各個查詢的響應時間，即從提交查詢到結果返回所需時間（越短越好）。其中的查詢主要涉及：多表關聯（超過4張），多表聚合，子查詢等。

下圖是TBase在行存儲模式下TPC-H測試結果和國際知名數據庫倉庫的測試結果對比，從測試結果來看，TBase在所有22個測試用例中都大幅度的領先。

在數據庫語法中，除了SQL標準外，每個數據庫都產品有自己的本地化語義，在本地化語義方面， TBase完整的的兼容PostgreSQL語法，部分兼容Oracle語法。

完整列存儲能力

數據庫的物理文件存儲格式常見的有兩種：按行存儲和按列存儲。下面對每種存儲結構給出一個例子，下表是我們的表結構和定義。

按行存儲格式

按行存儲格式，數據按照邏輯順序相同的方式來來進行文件存儲，一行中的所有列數據按照順序存儲在物理磁盤上，這種格式的好處很明顯，如果同時訪問一行中的多列數據時，一般只需要一次磁盤IO，比較適合OLTP類型的負載。

按列存儲格式

表中的每列數據存儲為一個獨立的磁盤文件，比如例子中，“姓名”，“部門”，“薪酬”，“家庭信息”每列中的數據都為一個獨立的數據文件，這中格式在一次需要訪問表中少數列時相比行存能夠節省大量的磁盤IO，在聚合類場景下尤其高效，因此多用在OLAP類系統中。

行存儲是TBase的基本存儲格式，為了支持高效的OLAP TBase也提供了完整的列存儲能力，業務可以根據自己的需要對寫入數據庫中的數據選擇需要的存儲格式。TBase的列存儲還支持強大的壓縮能力，支持透明壓縮和輕量級壓縮，透明壓縮支持gzip，zstd等壓縮算法，輕量級壓縮算法可以根據數據的特征進行高效壓縮，壓縮比高達400+。

TPC-DS是一套決策支持系統測試基準，主要針對零售行業。提供了99個SQL查詢（SQL 2003），分析數據量大，測試數據與實際商業數據高度相似，同時具有各種業務模型（分析報告型，數據挖掘型等等），主要用來對決策支持系統進行性能性能評測。TBase列存儲的 TPC-DS上運行了1T的工作集合，測試結果如下：

從測試結果來看，TBase在列存儲模式下的TPC-DS能力要遠遠優于業界標桿。

PS：TBase中行表和列表之間可以進行任意關聯查詢，可以進行相互的格式轉換（通過insert into select）。

資源隔離能力：

在HTAP系統中，OLTP和OLAP業務要同時運行，兩者都會消耗巨量的資源都，如果不對資源使用進行隔離必然會造成相互之間的干擾，影像系統的整體穩定性和服務質量。

TBase中的資源隔離方案--節點組的資源隔離方案，如果業務的OLTP和OLAP訪問的是不同的數據，可以使用TBase中的節點組把OLTP業務和OLAP業務在集群中分離為兩個節點組，對與OLTP節點組中的CN設置OLTP優化器，對于與OLAP節點組中的CN設置OLAP優化，從硬件上進行嚴格的分離。

在TBase中每個用戶session都有一個資源配額限制，使用這個配額可以限制用戶session的CPU，內存，網絡等資源，在OLTP和OLAP不存在絕對競爭的場景也可以讓兩者運行在同一個group，使用用戶資源配置來資源進行管控和配置。

TBase資源隔離方式—多副本方式（專利技術），多平面技術，此時用戶數據還是同一份數據，通過副本復制的方式把數據從OLTP系統復制到OLAP系統，同時實現行存儲到列存儲的轉換，通過這種方式從硬件上分離了OLTP和OLAP業務，同時數據庫內部的數據復制可靠性由數據庫內部機制保證，可靠性遠遠高于ETL工具。這種資源隔離技術TBase中的叫多平面技術。

通過上面這些資源隔離技術，TBase實現了HTAP中關鍵的資源隔離技術，可以很好的保證系統的服務質量和改善客戶體驗。

TBase安全解決方案：

得益于TBase常年服務公司內部客戶，  TBase建設了一套很有特色的數據安全系統，可以說TBase是目前市面上安全能力最出色的數據庫產品，這一特性得到內外部客戶的一致認可，并作為安全技術標準寫入到PICC的數據庫安全規范中。

TBase的數據安全系統我們稱之為MLS（multiple level security），這個體系的整體視圖如下：

以三權分立為基礎，消除系統的超級用戶權限。在安全管理規則中增加強制安全規則，支持對表進行矩陣式的權限劃分，在數據訪問層和存儲層進行加密和脫敏控制，防止數據拖庫時發生的數據泄密：

在事后追溯和實時審計中，TBase提供了完整的審計規則和豐富的自定義審計規則來進行支持。通過FGA（細粒度審計），TBase還可以做到數據越權訪問的實時告警，實時防止數據越權訪問。

客戶案例場景：

案例1：TBase協助解決某省匯集庫瓶頸，助力客戶架構升級：
原有系統使用某知名數據庫集群。在支撐數據量到300億數據時，計算和查詢的時候能力已經到達極限，超時宕機的場景頻發，入庫的速率最后只能達到數千/秒的極限值，遠遠無法滿足業務需要。

TBase匯集庫在系統中的位置：

匯集庫在系統中承擔著數據匯集處理的作用，既要對接其他關系數據庫，消息中間件等，還要運行部分核心系統的OLTP業務，并在這兩者數據的基礎上運行模型構建，離線行為分析等OLAP類計算。是一個典型的HTAP系統。

之前的系統之所以遇到瓶頸，很大程度上也是因為業務模型本身計算量大，模型復雜超出了RAC的處理效率。

TBase團隊在分析了業務的特點后，結合TBase的本身能力為業務制訂詳細的解決方案。方案的核心要點是OLTP和OLAP的多平面資源隔離技術，我們為系統的請求詳細的劃分了業務的運行平面，業務的寫入全都集中在主平面，把查詢類的請求根據計算復雜度和實時要求劃分到備用平面和主平面。很好的隔離了實時請求和離線請求。匯集庫TBase CN和DN的部署結構如下圖。

匯集集群當前有節點數近百，存儲數據數百T。120億數據的OLTP類業務1秒內完成處理。 處理性能遠遠超越了之前系統，成本相比卻大幅降低，得到用戶的高度認可！

案例二：物聯網地理信息系統
業務背景：隨著物聯網的到來，很多的傳感器數據需要進行接入，這些數據中都包含共同點，都包含一些點位信息（經度和緯度）。結合這些位置信息和我們已有的地理信息進行關聯分析，可以分析出很有價值的數據，為國民生產生活所用。

這個系統的核心功能是要對地理位置信息進行關聯計算和查詢，這個需要TBase提供的地理信息能力進行支持。

PS：TBase支持最先進的開源地理信息引擎PostGIS，可以提供豐富高效的地理信息處理能力。

該業務系統的部署架構如下：

TBase上游對接接業務傳感器后端的ETL，數據進入集群后先對清洗變換，并把人和位置信息進行關聯形成寬表；在寬表的基礎上進行GIS OLAP分析，輸出我們需要的高價值信息。

目前GIS系統規模：目前5臺機器協調節點+6臺機器Datanode節點主備混合部署。
案例三，某核心OLTP在線核查系統：某省核心服務微信公眾號后臺系統，核心系統結構如下：

業務的核心TBase服務器部署內網，敏感數據部署在這個核心TBase實例中，互聯網部署的一臺應用服務器，運行公眾號相關的業務數據，并通過網絡邊界同步工具把數據同步到業務內網。

總結

TBase構建HTAP能力的過程中團隊小伙伴們突破了一個又一個技術難點，創造了一個又一個“不可能”，回顧這個過程，就想起一句古語“篳路藍縷，以啟山林”！對TBase來說，應該是“篳路藍縷，開拓創新”！

當前TBase服務的外部客戶包括金融，公安，消防，政務，醫療，社保，能源，稅務等行業，外部集群超過30個。在案例中的省份上線運行已經快4年，集群規模從最開始的十幾臺逐漸增長到現在的近百臺，業務系統也有最初的一個增長到現在的快十個，在幫助業務解決痛點的同時，TBase自己也獲得了很多成長的機會，感謝大家對TBase的關注。

推薦閱讀

支撐微信支付的數據庫如何提供超300萬TPCC事務處理能力？