乾貨帖 | TDSQL-A核心架構揭秘

5月18日，騰訊雲首款分散式分析型資料庫TDSQL-A正式釋出公有云版本。
TDSQL-A作為領先的分析型資料庫，是騰訊首款分散式分析型資料庫，採用全並行無共享架構，具有自研列式儲存引擎，支援行列混合儲存，適應於海量OLAP關聯分析查詢場景。它能夠支援2000臺物理伺服器以上的叢集規模，儲存容量能達到單資料庫例項百P級。
TDSQL-A具備強大的海量資料實時分析能力，並全面相容PostgreSQL語法、高度相容Oracle語法，同時具備高安全、高可用、超大規模叢集支援和完整事務能力等產品特性，可為企業使用者需求提供高效、低成本的資料分析解決方案。
其中，TDSQL-A完整的分散式事務處理能力，可實時保障系統多平面資料全域性讀一致性、可靠性；支援多級容災以及多維度資源隔離，還提供強大的多級安全體系，提供完善的企業級管理能力，為使用者提供容災、備份、恢復、監控、安全、審計等全套解決方案。同時TDSQL-A提供彈性擴縮容能力，適用於 GB-PB 級的海量 OLAP 場景，是市場領先的企業級分析型資料庫引擎產品。
TDSQL-A有這麼多吸引人的特性，這些特性具體是如何保證完備、優雅地解決以上這些需求問題的呢？以下是騰訊雲資料庫技術總監李躍森老師對TDSQL-A產品核心架構的分享。
一、TDSQL-A場景定位

TDSQL-A是騰訊基於PostgreSQL自主研發的分散式線上關係型資料倉儲，業務場景針對於線上資料分析。
TDSQL-A是植根於騰訊內部業務發展起來的分散式資料庫，最早的時候我們是用TDSQL-PG來做一些大資料平臺小規模的資料分析。隨著業務的發展，我們發現單機的資料庫逐漸不能滿足業務的需要，我們就萌生了要開發分散式資料庫的想法。最早我們服務了微信支付，而隨著業務的發展，我們逐步自主研發了列儲存，來增進TDSQL 分析型能力。
同時，隨著騰訊雲業務的擴充，TDSQL-A也逐步走向服務外部客戶的過程中，積累了大量優秀案例實踐。
二、TDSQL-A核心技術架構

TDSQL-A整體架構和PostgreSQL的整體架構相比，是既緊緊地跟隨生態，同時有深度定製改造。

如上圖，曲線部分是TDSQL-A資料庫的核心，分為幾個部分：
第一是上層的GTM事務管理器，它主要是負責全域性事務的管理，協調機群的事務，同時管理叢集的全體物件。右上角是協調節點，它是業務訪問入口。協調節點模組是水平對等的，也就是說業務連線到任何一個協調節點上，都能夠獲得到一致的資料庫檢視。
第二是下方的資料節點。資料節點也是實際儲存資料的節點，每個資料節點只會儲存資料的分片，而資料節點之間加在一起會形成一個完整的資料檢視。
而資料節點和協調節點之間是叢集的資料互動匯流排。叢集資料互動匯流排在TDSQL-PG和TDSQL-A之間是存在差異的——兩者在系統內名字上來講都叫叢集互動匯流排，但是在這兩個不同的產品形態下，其實現邏輯完全不同——在TDSQL-A裡面透過基於物理網路卡的資料互動彙集器，並透過完整的網路連線的複用來完成這個工作。叢集互動匯流排的目的是把叢集內部節點連線在一起，從而完成整個查詢互動。
最後，左側描述的是資料庫核心的運維管控系統。資料庫在執行的時候需要一個運維管控系統來支撐運營，包括運維管理、實時監控、實時告警、安全審計和資料治理等等。
2.1 TDSQL-A自研行列混合儲存能力
下面介紹TDSQL-A全自研的行列混合的儲存能力。

資料庫的儲存有兩種方式，一個是按行儲存、一個是按列儲存：
按行儲存表：每行資料儲存所有列、一次磁碟IO可以訪問一行中所有列、適合OLTP場景。
按列儲存表：每列單獨儲存，多個列邏輯組成一行；一次磁碟IO只包含一列資料；方便做資料壓縮；適合OLAP場景。
TDSQL-A支援按列儲存和按行儲存兩種方式來建表，同時在列表和行表之間，使用者不用感知到下層的表是透過行表還是列表來建，行表和列表之間可以進行無縫的互操作——包括相互關聯、相互交換資料，完全不需要感知到底下的儲存邏輯。
除了操作的便利性之外，行表和列表之間混合查詢還能保持完整的事務一致性，也就是說在查詢執行的同時，整個事務（ACID）的能力也得到完整的保證。
2.2 TDSQL-A列儲存壓縮能力
列存模組，我們介紹列儲存壓縮能力。
TDSQL-A的列儲存壓縮分為兩種：
第一種是輕量式壓縮。輕量式壓縮方式首先感知到資料的具體內容，從而針對資料的特點來選用不同的壓縮辦法提高壓縮比，降低業務的成本，當前我們支援RLE的壓縮方式。
第二種是透明壓縮。這種壓縮方式是直接使用包括zstd和gzip直接進行壓縮，這種壓縮對資料的儲存內容沒有明確的要求，可以對任何的資訊進行壓縮。透過資料壓縮，可以把資料的體積大幅度減少，一方面減少使用者的使用成本，另一方面可以在大量查詢分析的時候減少IO訪問量，提升我們的查詢效率。
2.3 TDSQL-A執行引擎：延遲物化原理

在儲存層之上，是資料庫的執行引擎。執行引擎模組中，大規模的查詢分析場景下的資料交換以及IO、網路開銷是非常大的關注點，因為其對系統效能以及整體擴充套件性都有很大影響。
TDSQL-A在調研了業界的技術趨勢和技術的發展方向之後，在引擎裡引入了延遲物化。相對於延遲物化，就是一般常見的提前物化。提前物化指的就是查詢執行器再去執行掃描的時候——這裡簡單理解這些查詢裡面包括Scan、Join、Project等。
這裡舉一個例子，一個場景中有兩張表——tbl_a和tbl_b，兩張表上都有f1和f2兩列，分佈列都是f1。按照tbl_a的f1列與tbl_b的非分佈列f2來進行關聯——此時左邊是提前物化的計算方法， Project需要返回tbl_b的f1，進行Join關聯的時候需要tbl_b的f2，所以在對tbl_b進行Scan的時候，就會把tbl_b的f1和f2都物化出來。所謂的物化，是把兩個列在檔案裡面讀出來，在記憶體裡形成一個虛擬的記錄元組，然後往上傳輸。實際上可以看一下，在最上層往裡面投資料的時候，只投影了tbl_b的f1。在這個過程中，如果中間Join關聯的過濾比例很高，比如說只有1%是滿足要求的，這裡面有很多tbl_b的f1列資料是沒有必要傳輸進來的。

可見，提前物化造成對網路頻寬的浪費：
JOIN的選擇率等於0.01
TBL_B中有20億條記錄
JOIN有20億 * (1 – 0.01) * sizeof(TBL_B .f1) = 7.4GB的無效資料傳輸。
這個現象是在OLAP場景下常見的開銷，因為OLAP做各種複雜查詢時很多是寬表，而且查詢時大多數時候只會訪問寬表裡面極少數列，這個時候如果遇到了比較典型的選擇率很低、投影率很少的情況，開銷就變得不能忽視。
TDSQL-A延遲物化技術就是針對剛才的問題提出的最佳化方案。TDSQL-A延遲物化查詢計劃會在下層進行Scan的時候，針對Join中不需要的目標列只往上層傳遞物理元組的位置資訊到上層節點。只有等上層節點完成Join關聯後，才會去把滿足條件的記錄的位置資訊記錄下來，在投影階段再到下層拉取需要的資料資訊，進而透到外面。

透過測試證明，這種方式可以大幅度地節省CPU的計算開銷和網路IO、磁碟IO的開銷。

延遲物化對效能提升的效果：當測試的場景是20節點、20臺節點、1TB的資料，選擇率是10%，投影率是60%，兩表進行Join。可以明顯地發現，時間消耗相比是提前物化的五分之一，網路頻寬的佔用只有提前物化的一半。假設把表Join個數從兩個變成三個，消耗的時間則是其30%，網路佔用比接近40%——也就是說節省了60%的網路佔用。
因此，測試結果證明這對於IO和網路開銷有非常明顯的節省。而透過這兩個開銷的節省，可以進一步影響到效能的提升。

此外我們專門做了一個複雜Join的測試：選擇率是1%、投影率是100%；兩表的Join，橫座標是100GB到1TB。從上面兩表的Join可以看出，表越大到1TB的時候，相比開源的GP有5.2倍效能的提升；假設把兩張表變成三張表，則有18倍效能提升。可見，隨著查詢變得複雜、表變得越大，在延遲物化的場景下對效能的提升越明顯。
2.4TDSQL-A全新設計的非同步執行器解耦控制和資料互動
最初我們目標是讓TDSQL—A支援數千臺伺服器叢集規模。支撐數千臺伺服器的規模，存在一些必須要去跨越的障礙，其中一個障礙就是網路連線數過多。

為了解決上連線數過高的問題，TDSQL-A全新設計了非同步執行器。TDSQL-A的執行器是全新自研設計的執行器，主要有兩個特點：第一個是非同步執行；第二個是控制邏輯和資料傳輸邏輯分離。

具體來說，系統在查詢最佳化階段的時候會生成統一的執行計劃、統一執行需要的資源，這是TDSQL-A的控制邏輯。同時系統把整個網路通訊進行了抽象，抽象成下面藍色的Router——Router主要是負責機群內部的資料查收。不同的程式之間，比如兩層Join或者三層Join，不同層級的程式之間是完全非同步執行的，並透過推送資料的方式來完成資料互動。假設有N個節點，有M層join，則一共有M×N個程式。

在對執行器進行非同步化和控制資料分層的基礎上，TDSQL-A又對資料互動邏輯進行完整實現，這就是資料互動匯流排（Forward Node）。它主要是負責節點間的資料互動。可以認為它是我們叢集的邏輯網路卡。

FN透過共享記憶體和CN、DN進行資料互動——當然也存在本地的邏輯互動，假設資料需要從本地內部進行互動，可以不走網路而直接在記憶體裡面完成互動，進一步提升效能。
啟用了FN之後，假設有N個節點，M×Join不管有多複雜，連線個數都是隻有（N-1）×S——這個“S”是一個正整數，這意味著每臺伺服器和其他伺服器建N個連線，一般來說會乘2，這樣就可以把整個叢集內部的網路連線完全抽象和簡化。伺服器與伺服器之間建立的連線個數變成近似於和叢集規模相關的一個很小的數值：假設我們有2000臺伺服器，這個值也只會在4000左右。
現在很多業務場景下業務都會要求讀多寫少——非常複雜的查詢的讀多寫少，比如最多有五六張20億條的表進行關聯，同時有數十個、甚至更多併發發生。這種情況將對資料庫的計算資源帶來極大的挑戰。一般而言，在不具備這個技術之前，一般做法是每當計算資源不足，就多建一個新的資料庫叢集來儲存完整的資料，在新建副本上透過擴容的方式實現冗餘資料的重新查詢。這種方式存在很大的問題——建一個新的資料庫，資料一致性是非常大的挑戰。擴容的時候規模變得很大，同時每新建一個資料庫叢集，就需要容災、備份等所有的資源都同時擴充套件，這導致的結果是資料庫整體的開銷更大、成本更高。
針對這個問題，TDSQL-A設計推出了多平面方案。
2.5 TDSQL-A的多平面能力提供一致的讀擴充套件性

所謂的多平面：一個平面對應一個完整的資料副本，完整的資料副本可以提供完整的一致性讀擴充套件服務——讀擴充套件可以是單條的查詢，也可以是複雜的OLAP的關聯查詢，透過這種方式TDSQL-A可以提供成本低廉的讀擴充套件服務。
在TDSQL-A整個架構體系當中，多平面技術可在資料庫叢集內部保證各個平面之間資料一致性，同時也能保證各個平面在讀取時資料事務的一致性。
2.6 TDSQL-A如何做到高效能運算—全並行能力

對資料庫來說最關鍵的一點的無疑是高效能運算。以下介紹TDSQL-A在高速平行計算方面的工作。
在海量資料的實時分析場景下，我們一定要充分去發揮、充分壓榨資源才能達到最好的效果。這個方式，在TDSQL-A裡面叫全並行能力。
TDSQL-A全並行分為三個層級：
第一層節點級並行。所謂節點級的並行是，系統拿到一個查詢之後，會把查詢分發給各個不同的DN，透過DN之間分片區的查詢來完成節點級並行；
第二是執行器拿到分配後把運算元並行化，即儘量使用允許更多CPU資源來完成查詢工作，透過多CPU方式提升查詢的效率；
第三層是指令層面，包括對於CPU的特殊指令、SMD指令等，透過簡單的算術運算或者求值，以及透過指定值的最佳化和並行來提升查詢效率。
總結而言，全平行計算是系統榨乾硬體潛力的必經之路，是做複雜查詢、實時線上查詢的必經之路。

除了高效能運算，隨著行業對OLAP技術深入研究，近年來向量化也越來越受到關注。在TDSQL-A系統，也實現了向量化能力：資料量越大，列儲存場景下向量化結果越明顯，最好的結果是列儲存向量化執行時間會達到列儲存非向量化的二分之一、行儲存時間的八分之一左右。向量化也是在列儲存引擎裡實現實時線上分析的必經之路之一。
三、結語

當前，是TDSQL-A的新起點，未來TDSQL-A整體規劃分兩部分：一方面是陸續將目前基於PG10的版本，merge到PG11、PG12、PG13等更高版本，持續地跟進社群版本豐富的特性來提升使用者的體驗，為客戶創造更多價值。另一方面，TDSQL-A希望透過引入新硬體，來提升產品競爭力，為客戶提供更好的服務。