APP
5月18日，騰訊云首款分布式分析型數(shù)據(jù)庫TDSQL-A正式發(fā)布公有云版本。
TDSQL-A作為領先的分析型數(shù)據(jù)庫，是騰訊首款分布式分析型數(shù)據(jù)庫，采用全并行無共享架構，具有自研列式存儲引擎，支持行列混合存儲，適應于海量OLAP關聯(lián)分析查詢場景。它能夠支持2000臺物理服務器以上的集群規(guī)模，存儲容量能達到單數(shù)據(jù)庫實例百P級。
**TDSQL-A具備強大的海量數(shù)據(jù)實時分析能力，并全面兼容PostgreSQL語法、高度兼容Oracle語法，同時具備高安全、高可用、超大規(guī)模集群支持和完整事務能力等產(chǎn)品特性，可為企業(yè)用戶需求提供高效、低成本的數(shù)據(jù)分析解決方案。**
其中，TDSQL-A完整的分布式事務處理能力，可實時保障系統(tǒng)多平面數(shù)據(jù)全局讀一致性、可靠性；支持多級容災以及多維度資源隔離，還提供強大的多級安全體系，提供完善的企業(yè)級管理能力，為用戶提供容災、備份、恢復、監(jiān)控、安全、審計等全套解決方案。同時TDSQL-A提供彈性擴縮容能力，適用于 GB-PB 級的海量 OLAP 場景，是市場領先的企業(yè)級分析型數(shù)據(jù)庫引擎產(chǎn)品。
TDSQL-A有這么多吸引人的特性，這些特性具體是如何保證完備、優(yōu)雅地解決以上這些需求問題的呢？以下是騰訊云數(shù)據(jù)庫技術總監(jiān)李躍森老師對TDSQL-A產(chǎn)品核心架構的分享。
# 一、TDSQL-A場景定位
**TDSQL-A是騰訊基于PostgreSQL自主研發(fā)的分布式在線關系型數(shù)據(jù)倉庫，業(yè)務場景針對于在線數(shù)據(jù)分析。**
TDSQL-A是植根于騰訊內(nèi)部業(yè)務發(fā)展起來的分布式數(shù)據(jù)庫，最早的時候我們是用TDSQL-PG來做一些大數(shù)據(jù)平臺小規(guī)模的數(shù)據(jù)分析。隨著業(yè)務的發(fā)展，我們發(fā)現(xiàn)單機的數(shù)據(jù)庫逐漸不能滿足業(yè)務的需要，我們就萌生了要開發(fā)分布式數(shù)據(jù)庫的想法。最早我們服務了微信支付，而隨著業(yè)務的發(fā)展，我們逐步自主研發(fā)了列存儲，來增進TDSQL 分析型能力。
同時，隨著騰訊云業(yè)務的拓展，TDSQL-A也逐步走向服務外部客戶的過程中，積累了大量優(yōu)秀案例實踐。
# 二、TDSQL-A核心技術架構
TDSQL-A整體架構和PostgreSQL的整體架構相比，是既緊緊地跟隨生態(tài)，同時有深度定制改造。
**TDSQL-A數(shù)據(jù)庫的內(nèi)核，分為幾個部分：**
第一是上層的GTM事務管理器，它主要是負責全局事務的管理，協(xié)調(diào)機群的事務，同時管理集群的全體對象。右上角是協(xié)調(diào)節(jié)點，它是業(yè)務訪問入口。協(xié)調(diào)節(jié)點模塊是水平對等的，也就是說業(yè)務連接到任何一個協(xié)調(diào)節(jié)點上，都能夠獲得到一致的數(shù)據(jù)庫視圖。
第二是下方的數(shù)據(jù)節(jié)點。數(shù)據(jù)節(jié)點也是實際存儲數(shù)據(jù)的節(jié)點，每個數(shù)據(jù)節(jié)點只會存儲數(shù)據(jù)的分片，而數(shù)據(jù)節(jié)點之間加在一起會形成一個完整的數(shù)據(jù)視圖。
而數(shù)據(jù)節(jié)點和協(xié)調(diào)節(jié)點之間是集群的數(shù)據(jù)交互總線。集群數(shù)據(jù)交互總線在TDSQL-PG和TDSQL-A之間是存在差異的——兩者在系統(tǒng)內(nèi)名字上來講都叫集群交互總線，但是在這兩個不同的產(chǎn)品形態(tài)下，其實現(xiàn)邏輯完全不同——在TDSQL-A里面通過基于物理網(wǎng)卡的數(shù)據(jù)交互匯集器，并通過完整的網(wǎng)絡連接的復用來完成這個工作。集群交互總線的目的是把集群內(nèi)部節(jié)點連接在一起，從而完成整個查詢交互。
最后，左側描述的是數(shù)據(jù)庫內(nèi)核的運維管控系統(tǒng)。數(shù)據(jù)庫在運行的時候需要一個運維管控系統(tǒng)來支撐運營，包括運維管理、實時監(jiān)控、實時告警、安全審計和數(shù)據(jù)治理等等。
**2.1 TDSQL-A自研行列混合存儲能力**
下面介紹TDSQL-A全自研的行列混合的存儲能力。
數(shù)據(jù)庫的存儲有兩種方式，一個是按行存儲、一個是按列存儲：
按行存儲表：每行數(shù)據(jù)存儲所有列、一次磁盤IO可以訪問一行中所有列、適合OLTP場景。
按列存儲表：每列單獨存儲，多個列邏輯組成一行；一次磁盤IO只包含一列數(shù)據(jù)；方便做數(shù)據(jù)壓縮；適合OLAP場景。
TDSQL-A支持按列存儲和按行存儲兩種方式來建表，同時在列表和行表之間，用戶不用感知到下層的表是通過行表還是列表來建，行表和列表之間可以進行無縫的互操作——包括相互關聯(lián)、相互交換數(shù)據(jù)，完全不需要感知到底下的存儲邏輯。
除了操作的便利性之外，行表和列表之間混合查詢還能保持完整的事務一致性，也就是說在查詢運行的同時，整個事務（ACID）的能力也得到完整的保證。
**2.2 ?TDSQL-A列存儲壓縮能力**
列存模塊，我們介紹列存儲壓縮能力。
TDSQL-A的列存儲壓縮分為兩種：
第一種是輕量式壓縮。輕量式壓縮方式首先感知到數(shù)據(jù)的具體內(nèi)容，從而針對數(shù)據(jù)的特點來選用不同的壓縮辦法提高壓縮比，降低業(yè)務的成本，當前我們支持RLE的壓縮方式。
第二種是透明壓縮。這種壓縮方式是直接使用包括zstd和gzip直接進行壓縮，這種壓縮對數(shù)據(jù)的存儲內(nèi)容沒有明確的要求，可以對任何的信息進行壓縮。通過數(shù)據(jù)壓縮，可以把數(shù)據(jù)的體積大幅度減少，一方面減少用戶的使用成本，另一方面可以在大量查詢分析的時候減少IO訪問量，提升我們的查詢效率。
**2.3 ?TDSQL-A執(zhí)行引擎：延遲物化原理**
在存儲層之上，是數(shù)據(jù)庫的執(zhí)行引擎。執(zhí)行引擎模塊中，大規(guī)模的查詢分析場景下的數(shù)據(jù)交換以及IO、網(wǎng)絡開銷是非常大的關注點，因為其對系統(tǒng)性能以及整體擴展性都有很大影響。
TDSQL-A在調(diào)研了業(yè)界的技術趨勢和技術的發(fā)展方向之后，在引擎里引入了延遲物化。相對于延遲物化，就是一般常見的提前物化。提前物化指的就是查詢執(zhí)行器再去執(zhí)行掃描的時候——這里簡單理解這些查詢里面包括Scan、Join、Project等。
這里舉一個例子，一個場景中有兩張表——tbl_a和tbl_b，兩張表上都有f1和f2兩列，分布列都是f1。按照tbl_a的f1列與tbl_b的非分布列f2來進行關聯(lián)——此時左邊是提前物化的計算方法， Project需要返回tbl_b的f1，進行Join關聯(lián)的時候需要tbl_b的f2，所以在對tbl_b進行Scan的時候，就會把tbl_b的f1和f2都物化出來。所謂的物化，是把兩個列在文件里面讀出來，在內(nèi)存里形成一個虛擬的記錄元組，然后往上傳輸。實際上可以看一下，在最上層往里面投數(shù)據(jù)的時候，只投影了tbl_b的f1。在這個過程中，如果中間Join關聯(lián)的過濾比例很高，比如說只有1%是滿足要求的，這里面有很多tbl_b的f1列數(shù)據(jù)是沒有必要傳輸進來的。
**可見，提前物化造成對網(wǎng)絡帶寬的浪費：**
JOIN的選擇率等于0.01
TBL_B中有20億條記錄
JOIN有20億 * (1 – 0.01) * sizeof(TBL_B .f1) = 7.4GB的無效數(shù)據(jù)傳輸。
這個現(xiàn)象是在OLAP場景下常見的開銷，因為OLAP做各種復雜查詢時很多是寬表，而且查詢時大多數(shù)時候只會訪問寬表里面極少數(shù)列，這個時候如果遇到了比較典型的選擇率很低、投影率很少的情況，開銷就變得不能忽視。
TDSQL-A延遲物化技術就是針對剛才的問題提出的優(yōu)化方案。TDSQL-A延遲物化查詢計劃會在下層進行Scan的時候，針對Join中不需要的目標列只往上層傳遞物理元組的位置信息到上層節(jié)點。只有等上層節(jié)點完成Join關聯(lián)后，才會去把滿足條件的記錄的位置信息記錄下來，在投影階段再到下層拉取需要的數(shù)據(jù)信息，進而透到外面。
通過測試證明，這種方式可以大幅度地節(jié)省CPU的計算開銷和網(wǎng)絡IO、磁盤IO的開銷。
延遲物化對性能提升的效果：當測試的場景是20節(jié)點、20臺節(jié)點、1TB的數(shù)據(jù)，選擇率是10%，投影率是60%，兩表進行Join?？梢悦黠@地發(fā)現(xiàn)，時間消耗相比是提前物化的五分之一，網(wǎng)絡帶寬的占用只有提前物化的一半。假設把表Join個數(shù)從兩個變成三個，消耗的時間則是其30%，網(wǎng)絡占用比接近40%——也就是說節(jié)省了60%的網(wǎng)絡占用。
因此，測試結果證明這對于IO和網(wǎng)絡開銷有非常明顯的節(jié)省。而通過這兩個開銷的節(jié)省，可以進一步影響到性能的提升。
此外我們專門做了一個復雜Join的測試：選擇率是1%、投影率是100%；兩表的Join，橫坐標是100GB到1TB。從上面兩表的Join可以看出，表越大到1TB的時候，相比開源的GP有5.2倍性能的提升；假設把兩張表變成三張表，則有18倍性能提升。可見，隨著查詢變得復雜、表變得越大，在延遲物化的場景下對性能的提升越明顯。
**2.4TDSQL-A全新設計的異步執(zhí)行器解耦控制和數(shù)據(jù)交互**
最初我們目標是讓TDSQL—A支持數(shù)千臺服務器集群規(guī)模。支撐數(shù)千臺服務器的規(guī)模，存在一些必須要去跨越的障礙，其中一個障礙就是網(wǎng)絡連接數(shù)過多。
為了解決上連接數(shù)過高的問題，TDSQL-A全新設計了異步執(zhí)行器。TDSQL-A的執(zhí)行器是全新自研設計的執(zhí)行器，主要有兩個特點：第一個是異步執(zhí)行；第二個是控制邏輯和數(shù)據(jù)傳輸邏輯分離。
具體來說，系統(tǒng)在查詢優(yōu)化階段的時候會生成統(tǒng)一的執(zhí)行計劃、統(tǒng)一執(zhí)行需要的資源，這是TDSQL-A的控制邏輯。同時系統(tǒng)把整個網(wǎng)絡通信進行了抽象，抽象成下面藍色的Router——Router主要是負責機群內(nèi)部的數(shù)據(jù)查收。不同的進程之間，比如兩層Join或者三層Join，不同層級的進程之間是完全異步執(zhí)行的，并通過推送數(shù)據(jù)的方式來完成數(shù)據(jù)交互。假設有N個節(jié)點，有M層join，則一共有M×N個進程。
在對執(zhí)行器進行異步化和控制數(shù)據(jù)分層的基礎上，TDSQL-A又對數(shù)據(jù)交互邏輯進行完整實現(xiàn)，這就是數(shù)據(jù)交互總線（Forward Node）。它主要是負責節(jié)點間的數(shù)據(jù)交互?？梢哉J為它是我們集群的邏輯網(wǎng)卡。
FN通過共享內(nèi)存和CN、DN進行數(shù)據(jù)交互——當然也存在本地的邏輯交互，假設數(shù)據(jù)需要從本地內(nèi)部進行交互，可以不走網(wǎng)絡而直接在內(nèi)存里面完成交互，進一步提升性能。
啟用了FN之后，假設有N個節(jié)點，M×Join不管有多復雜，連接個數(shù)都是只有（N-1）×S——這個“S”是一個正整數(shù)，這意味著每臺服務器和其他服務器建N個連接，一般來說會乘2，這樣就可以把整個集群內(nèi)部的網(wǎng)絡連接完全抽象和簡化。服務器與服務器之間建立的連接個數(shù)變成近似于和集群規(guī)模相關的一個很小的數(shù)值：假設我們有2000臺服務器，這個值也只會在4000左右。
現(xiàn)在很多業(yè)務場景下業(yè)務都會要求讀多寫少——非常復雜的查詢的讀多寫少，比如最多有五六張20億條的表進行關聯(lián)，同時有數(shù)十個、甚至更多并發(fā)發(fā)生。這種情況將對數(shù)據(jù)庫的計算資源帶來極大的挑戰(zhàn)。一般而言，在不具備這個技術之前，一般做法是每當計算資源不足，就多建一個新的數(shù)據(jù)庫集群來保存完整的數(shù)據(jù)，在新建副本上通過擴容的方式實現(xiàn)冗余數(shù)據(jù)的重新查詢。這種方式存在很大的問題——建一個新的數(shù)據(jù)庫，數(shù)據(jù)一致性是非常大的挑戰(zhàn)。擴容的時候規(guī)模變得很大，同時每新建一個數(shù)據(jù)庫集群，就需要容災、備份等所有的資源都同時擴展，這導致的結果是數(shù)據(jù)庫整體的開銷更大、成本更高。
針對這個問題，TDSQL-A設計推出了多平面方案。
**2.5 TDSQL-A的多平面能力提供一致的讀擴展性**
所謂的多平面：一個平面對應一個完整的數(shù)據(jù)副本，完整的數(shù)據(jù)副本可以提供完整的一致性讀擴展服務——讀擴展可以是單條的查詢，也可以是復雜的OLAP的關聯(lián)查詢，通過這種方式TDSQL-A可以提供成本低廉的讀擴展服務。
在TDSQL-A整個架構體系當中，多平面技術可在數(shù)據(jù)庫集群內(nèi)部保證各個平面之間數(shù)據(jù)一致性，同時也能保證各個平面在讀取時數(shù)據(jù)事務的一致性。
**2.6 TDSQL-A如何做到高性能計算—全并行能力**
對數(shù)據(jù)庫來說最關鍵的一點的無疑是高性能計算。以下介紹TDSQL-A在高速并行計算方面的工作。
在海量數(shù)據(jù)的實時分析場景下，我們一定要充分去發(fā)揮、充分壓榨資源才能達到最好的效果。這個方式，在TDSQL-A里面叫全并行能力。
**TDSQL-A全并行分為三個層級：**
**第一層節(jié)點級并行。**所謂節(jié)點級的并行是，系統(tǒng)拿到一個查詢之后，會把查詢分發(fā)給各個不同的DN，通過DN之間分片區(qū)的查詢來完成節(jié)點級并行；
**第二是執(zhí)行器拿到分配后把算子并行化，即盡量使用允許更多CPU資源來完成查詢工作，通過多CPU方式提升查詢的效率；**
**第三層是指令層面**，包括對于CPU的特殊指令、SMD指令等，通過簡單的算術運算或者求值，以及通過指定值的優(yōu)化和并行來提升查詢效率。
總結而言，全并行計算是系統(tǒng)榨干硬件潛力的必經(jīng)之路，是做復雜查詢、實時在線查詢的必經(jīng)之路。
除了高性能計算，隨著行業(yè)對OLAP技術深入研究，近年來向量化也越來越受到關注。在TDSQL-A系統(tǒng)，也實現(xiàn)了向量化能力：數(shù)據(jù)量越大，列存儲場景下向量化結果越明顯，最好的結果是列存儲向量化運行時間會達到列存儲非向量化的二分之一、行存儲時間的八分之一左右。向量化也是在列存儲引擎里實現(xiàn)實時在線分析的必經(jīng)之路之一。
# 三、結語
當前，是TDSQL-A的新起點，未來TDSQL-A整體規(guī)劃分兩部分：一方面是陸續(xù)將目前基于PG10的版本，merge到PG11、PG12、PG13等更高版本，持續(xù)地跟進社區(qū)版本豐富的特性來提升用戶的體驗，為客戶創(chuàng)造更多價值。另一方面，TDSQL-A希望通過引入新硬件，來提升產(chǎn)品競爭力，為客戶提供更好的服務。
?
本文摘自 ：https://blog.51cto.com/u
