騰訊云數(shù)據(jù)庫海量數(shù)據(jù)交互之道

TDSQL-A是在騰訊業(yè)務(wù)場景下誕生的在線分布型OLAP數(shù)據(jù)庫系統(tǒng)，在處理海量數(shù)據(jù)分析業(yè)務(wù)的過程中持續(xù)對產(chǎn)品構(gòu)架進(jìn)行升級調(diào)整，是PG生態(tài)中分析型MPP產(chǎn)品的又一力作。

本文將由騰訊云數(shù)據(jù)庫專家工程師伍鑫老師為大家詳細(xì)介紹TDSQL-A的發(fā)展歷程、技術(shù)架構(gòu)和創(chuàng)新實(shí)踐，以下為分享實(shí)錄：

TDSQL-A發(fā)展歷程

TDSQL-A是一款基于PostgreSQL自主研發(fā)的分布式在線關(guān)系型數(shù)據(jù)庫。是一個(gè)面向海量數(shù)據(jù)實(shí)時(shí)在線分析產(chǎn)品，采用無共享MPP構(gòu)架。面向分析型場景的極致性能優(yōu)化，我們自研了列式存儲(chǔ)，同時(shí)也支持行列混合存儲(chǔ)模式。在數(shù)據(jù)轉(zhuǎn)發(fā)層面上，針對大規(guī)模集群面臨的連接風(fēng)暴問題對集群執(zhí)行/轉(zhuǎn)發(fā)框架做了更深入優(yōu)化，來保證可以支持超過千臺(tái)規(guī)模的集群能力。同時(shí)為加速用戶在數(shù)據(jù)挖掘或分析場景上的時(shí)延，通過多種計(jì)算能力優(yōu)化來達(dá)到給用戶提供更好效果。

在多年的發(fā)展過程中TDSQL-A依托騰訊內(nèi)部業(yè)務(wù)進(jìn)行充分打磨，在內(nèi)部業(yè)務(wù)及外部企業(yè)級用戶場景下都有良好表現(xiàn)，并于2021年5月18日上線騰訊云。

TDSQL-A整體架構(gòu)

首先整體介紹TDSQL-A架構(gòu)。TDSQL-A是一個(gè)多CN入口的MPP分布式集群設(shè)計(jì)，CN節(jié)點(diǎn)作為業(yè)務(wù)訪問入口，每個(gè)節(jié)點(diǎn)是對等的，對外提供一致的用戶元數(shù)據(jù)和視圖訪問，同時(shí)也可以通過多入口分擔(dān)用戶高并發(fā)壓力場景下的連接處理。

因?yàn)槭且粋€(gè)多CN入口，需要一個(gè)全局事務(wù)管理器GTM節(jié)點(diǎn)，進(jìn)行全局事務(wù)管理以及Sequence等全局一致能力的處理節(jié)點(diǎn)。早期GTM在高并發(fā)情況下獲取全局事務(wù)快照會(huì)有性能瓶頸，TDSQL PG版以及TDSQL-A都針對分布式提交協(xié)議做了基于timestamp的改造，解決了全局事務(wù)快照的單點(diǎn)瓶頸問題。TDSQL-A整體不管是行存和列存事務(wù)提交，整體的提交協(xié)議都基于timestamp（GTS）協(xié)議，提供業(yè)界領(lǐng)先的高并發(fā)能力支持。

數(shù)據(jù)存儲(chǔ)和計(jì)算節(jié)點(diǎn)我們稱為Datenode，Datenode節(jié)點(diǎn)經(jīng)過TDSQL-A構(gòu)架優(yōu)化，支持超過1000個(gè)節(jié)點(diǎn)以上的集群部署，支持10PB級別以上的用戶數(shù)據(jù)量。同時(shí)在計(jì)算時(shí)，會(huì)盡可能把所有計(jì)算都通過智能的優(yōu)化器規(guī)劃推到DN節(jié)點(diǎn)上做計(jì)算。

TDSQL-A整體構(gòu)建演進(jìn)。由于用戶數(shù)據(jù)量持續(xù)增大，需要面臨最大挑戰(zhàn)是在大規(guī)模集群下大數(shù)據(jù)訪問量和復(fù)雜查詢場景。例如TPC-DS這類復(fù)雜的用戶場景，它的query是帶有復(fù)雜的子查詢場景及with語句的。在這種情況下多表關(guān)聯(lián)會(huì)比較多，在分布式系統(tǒng)下會(huì)有多層重分布。

按照之前早期構(gòu)架，在執(zhí)行時(shí)碰到RemoteSubplan算子的時(shí)候才會(huì)往下發(fā)整體的下一步查詢計(jì)劃，如果查詢中重分布的層次比較多，每一層DN都會(huì)認(rèn)為自己是一個(gè)發(fā)起者，會(huì)導(dǎo)致大量多層進(jìn)程連接和網(wǎng)絡(luò)連接消耗。

做一個(gè)比較簡單的計(jì)算，如果200個(gè)DN節(jié)點(diǎn)有100個(gè)并發(fā)查詢，每個(gè)查詢是5個(gè)數(shù)據(jù)重分布，計(jì)算將會(huì)有超過10萬個(gè)連接數(shù)。這個(gè)問題在集群規(guī)模達(dá)到上千個(gè)節(jié)點(diǎn)后會(huì)更加嚴(yán)重，這也是整個(gè)MPP在大規(guī)模情況下的通用問題。

而TDSQL-A針對性地做了比較大的改造，首先整體執(zhí)行框架進(jìn)行了重構(gòu)，TDSQL-A查詢計(jì)劃統(tǒng)一在CN上去做規(guī)劃。當(dāng)查詢計(jì)劃生成后，會(huì)根據(jù)Remote Subplan或需要做數(shù)據(jù)重分布這些節(jié)點(diǎn)，對查詢計(jì)劃做一個(gè)劃分。不同層次會(huì)統(tǒng)一由CN節(jié)點(diǎn)到DN節(jié)點(diǎn)去建立相應(yīng)DProcess進(jìn)程，相當(dāng)于有一個(gè)統(tǒng)一的CN協(xié)調(diào)者來管理所有進(jìn)程和連接數(shù)，這樣就會(huì)比較可控地去建立所需最小進(jìn)程數(shù)和相應(yīng)連接。同時(shí)不同進(jìn)程間也可以去進(jìn)行異步啟動(dòng)，加速復(fù)雜查詢的直接效率。

實(shí)際上這里還不夠，雖然進(jìn)程數(shù)比較可控，但同時(shí)連接數(shù)還是一個(gè)問題，例如集群規(guī)模非常大，超過1000個(gè)節(jié)點(diǎn)以后，連接數(shù)膨脹還是很嚴(yán)重。而對于超大規(guī)模集群我們是引入了數(shù)據(jù)轉(zhuǎn)發(fā)節(jié)點(diǎn)。數(shù)據(jù)轉(zhuǎn)發(fā)節(jié)點(diǎn)會(huì)在每臺(tái)物理機(jī)進(jìn)行部署，如果有混布場景也是一個(gè)數(shù)據(jù)轉(zhuǎn)發(fā)節(jié)點(diǎn)，會(huì)負(fù)責(zé)這臺(tái)機(jī)器上所有DN或CN之前的數(shù)據(jù)交互。這樣對于一個(gè)大規(guī)模計(jì)算集群，實(shí)際上網(wǎng)絡(luò)連接數(shù)就會(huì)比較可控，因?yàn)榫W(wǎng)絡(luò)會(huì)走到數(shù)據(jù)轉(zhuǎn)發(fā)節(jié)點(diǎn)上，而機(jī)器上的DN節(jié)點(diǎn)或者CN節(jié)點(diǎn)會(huì)通過共享內(nèi)存和數(shù)據(jù)轉(zhuǎn)發(fā)節(jié)點(diǎn)進(jìn)行交互。這里還有一個(gè)額外優(yōu)化，如果在同一臺(tái)機(jī)器有混布的情況下，相同機(jī)器上的DN交互可以不走網(wǎng)絡(luò)，直接走共享內(nèi)存做一個(gè)直接轉(zhuǎn)發(fā)。

通過數(shù)據(jù)轉(zhuǎn)發(fā)節(jié)點(diǎn)的引入整個(gè)集群規(guī)模就可以有一個(gè)比較線性和擴(kuò)展能力，按照N個(gè)節(jié)點(diǎn)和M層Join來計(jì)算，不管你的產(chǎn)品多復(fù)雜它只有N*（N-1）個(gè)網(wǎng)絡(luò)連接數(shù)，整體由FN節(jié)點(diǎn)去規(guī)劃。很好地去解決MPP場景下，超大規(guī)模集群如何保持高并發(fā)和復(fù)雜查詢場景下網(wǎng)絡(luò)連接問題。

上面介紹改造之后整個(gè)查詢計(jì)劃分片也會(huì)比較明確。包括重分布代價(jià)在內(nèi)，優(yōu)化器會(huì)考慮到分布式場景中數(shù)據(jù)轉(zhuǎn)發(fā)的網(wǎng)絡(luò)開銷，基于代價(jià)模型去做自動(dòng)查詢優(yōu)化。在CN生成查詢計(jì)劃后會(huì)遞歸遍歷整個(gè)執(zhí)行計(jì)劃樹，把整個(gè)查詢計(jì)劃分成多個(gè)Fragment。從上面開始向下看，上面是更靠近CN節(jié)點(diǎn)，就是Fragmentid 1，這里縮寫是FID 1，這樣每次碰到Remote subplan節(jié)點(diǎn)時(shí)相當(dāng)于需要拆分成一個(gè)新的Fragment。同一個(gè)Fragment會(huì)在每一個(gè)參與計(jì)算的DN統(tǒng)一去建立這樣一層進(jìn)程。中間是通過FN節(jié)點(diǎn)去進(jìn)行網(wǎng)絡(luò)傳輸。右邊是一個(gè)比較簡單的標(biāo)準(zhǔn)查詢計(jì)劃兩個(gè)Hash Join，通過不同F(xiàn)ragment去分層的進(jìn)行異步計(jì)算。

這一頁主要介紹通過FN節(jié)點(diǎn)做一個(gè)整體數(shù)據(jù)轉(zhuǎn)發(fā)，當(dāng)有兩個(gè)DN節(jié)點(diǎn)時(shí)，相當(dāng)于同個(gè)Fragment會(huì)在不同DN節(jié)點(diǎn)建立相同進(jìn)程，統(tǒng)一進(jìn)行分布式計(jì)算，這里所有的計(jì)算也都是通過優(yōu)化器去做一個(gè)相應(yīng)的下推。

我們的自研列式存儲(chǔ)，例如用戶有一些星型數(shù)據(jù)模型或者一些表列數(shù)較多而實(shí)際參與計(jì)算的列比較少，這種情況很多都需要列裁剪去做執(zhí)行優(yōu)化，如果沒有列存整體效果會(huì)比較差。通過列存盡可能減少磁盤IO掃描和相關(guān)的計(jì)算層計(jì)算裁剪。這樣整體在海量數(shù)據(jù)下計(jì)算量消耗降低會(huì)比較明顯。其實(shí)做優(yōu)化最高效方法還是通過優(yōu)化執(zhí)行計(jì)劃去做計(jì)算裁剪，第二步才是在必要相同計(jì)算量前提下去進(jìn)行執(zhí)行優(yōu)化，不管是你的算子優(yōu)化，還是機(jī)器資源物理層優(yōu)化。最開始都要從執(zhí)行計(jì)劃角度去做，所以列存是非常重要的。

前面有提到我們的列存表和行存表一樣，都使用了基于timestamp的分布式提交協(xié)議，所以整體行列之間可以保持混合查詢事務(wù)一致性。同時(shí)用戶也可以在同一個(gè)庫或同一個(gè)實(shí)例里，去根據(jù)業(yè)務(wù)場景針對不同特征建立行存表和列存表，可以自動(dòng)在查詢計(jì)劃中選擇更好的access path。

這是自研列式存儲(chǔ)格式的簡單介紹，每一張列式存儲(chǔ)表，都有一張對應(yīng)的元數(shù)據(jù)registry表，去記錄它存儲(chǔ)狀態(tài)和更新的狀態(tài)信息。

我們的物理文件結(jié)構(gòu)最小單元叫Silo，就是一個(gè)谷倉的概念，一個(gè)Silo是一個(gè)數(shù)據(jù)塊列式分布的緊湊排列。這樣一個(gè)Silo里面展開，會(huì)有相應(yīng)的右邊這些信息，除了頭部信息，最上面還會(huì)有一個(gè)checksum保證數(shù)據(jù)校驗(yàn)的正確性，后面有標(biāo)記位去加速數(shù)據(jù)訪問和filter效果以及null bitmap，最后是具體的數(shù)據(jù)。

介紹一下列存儲(chǔ)延遲掃描優(yōu)化，例如有一個(gè)查詢，在同一張表上有多個(gè)Predicate條件，比如10列有3列帶有Predicate。按照常見的做法，這些雖然是列存儲(chǔ)，但需要的這些列還是會(huì)提前掃描去做一個(gè)整體物化，再做一個(gè)Predicate。這種延遲掃描其實(shí)可以做更優(yōu)，因?yàn)樗赡軐蓚€(gè)或三個(gè)Predicate中間層級選擇率比較明顯?？梢韵葤叩谝涣校谝涣袙咄旰笏赡芤呀?jīng)通過Predicate過濾掉很多數(shù)據(jù)，這時(shí)再去掃第二列或第三列時(shí)，或后面其它數(shù)據(jù)列，都可以通過ctid掃后面需要的一些數(shù)據(jù)。如果列比較多或過濾效果比較好，它會(huì)減少掃描的數(shù)據(jù)量。這是基于列存儲(chǔ)不同列的物理文件隔離去做一個(gè)前提，因?yàn)檫@種情況下才能減少真正掃描量，而不是增加reaccess的問題。

上面介紹了每一個(gè)Silo的格式，我們會(huì)盡量放更多的數(shù)據(jù)在一個(gè)Silo里，增加它的數(shù)據(jù)壓縮能力。另外要引入相關(guān)壓縮能力算法提高整體存儲(chǔ)效能，降低用戶存儲(chǔ)成本。

這里有兩層，首先是通用的透明壓縮，透明壓縮會(huì)使用LZ4或Zstd算法，針對特定數(shù)據(jù)類型會(huì)加輕量級壓縮能力。同時(shí)對于不同類型我們也有不同壓縮最優(yōu)推薦，這是具象化到產(chǎn)品里的能力，用戶只需要選擇low、middle，或者是high，例如你希望壓縮low，我們會(huì)自動(dòng)替你選擇相應(yīng)的壓縮算法。

比如整數(shù)類型，如果是low我們用Delta+RLE，middle和high就會(huì)加上Lz4或Zstd類似透明壓縮。而針對Numeric也有深度優(yōu)化，這里是列存壓縮存儲(chǔ)，如果你已經(jīng)選擇壓縮，實(shí)際上它會(huì)自動(dòng)轉(zhuǎn)成int類型。這樣不僅是存儲(chǔ)空間節(jié)省，在你計(jì)算同時(shí)也能很快的做向量化計(jì)算能力。

介紹一下我們基于列存儲(chǔ)和執(zhí)行框架優(yōu)勢去深入挖掘執(zhí)行引擎上的能力。首先是一個(gè)多層級并行能力，在這里分為幾個(gè)層面，一個(gè)是分布式多節(jié)點(diǎn)和多進(jìn)程執(zhí)行能力，這里由FN轉(zhuǎn)發(fā)能力或優(yōu)化器自動(dòng)規(guī)劃能力去決定，當(dāng)然也是由MPP整體構(gòu)架來決定的。中間一層，因?yàn)楝F(xiàn)在代碼整體是基于PG10來做的，但實(shí)際上我們合入了很多更新，例如PG12、PG13里的能力或并行能力，包括優(yōu)化器里針對這些場景，比如說partitoin-wise Join的能力都有引入。

在中間這一層算子的并行計(jì)算能力情況下也會(huì)有比較好的效果，同時(shí)我們自己針對多種場景，比如FN能力在并行過程中遇到的一些問題，做了深入的處理。整體在基于MPP框架，超大規(guī)模MPP框架下同時(shí)對算子級進(jìn)程做了深度優(yōu)化。另外一個(gè)最底層的在SIMD并行指令層面進(jìn)行深入的優(yōu)化。

前面介紹了基于列存我們做了很多深入優(yōu)化，比如前面提到的LateRead延遲掃描能力，實(shí)際上在計(jì)算層我們也有基于列存延遲物化能力，可以理解為統(tǒng)一把列存的特性在計(jì)算層優(yōu)化到極致。

延遲物化這里介紹下，比如一個(gè)query里面有hashjoin，一般的做法是，下面Scan層會(huì)把所有的列或數(shù)據(jù)都掃進(jìn)來，再去做Join計(jì)算，這是一個(gè)通用性場景。實(shí)際上如果在Join選擇率比較好的情況下，對于不參與Join condition的這些列，物理掃描的那些數(shù)據(jù)列可以通過Join之后再去掃描，因?yàn)槭橇写鎯?chǔ)，可以Join之后再把列進(jìn)行補(bǔ)全，這樣Join在選擇率很好的情況下可以減少大量的磁盤IO和網(wǎng)絡(luò)消耗。

這里有一個(gè)簡單計(jì)算，一個(gè)有20億條數(shù)據(jù)選擇率百分之一的join場景，可能會(huì)減少7.4G的無效數(shù)據(jù)傳輸和無效數(shù)據(jù)掃描，這個(gè)效果非常明顯。類似場景下我們做了延遲物化的整體優(yōu)化，在最開始掃描的時(shí)候只需要掃Join condition需要的列去做Join，Join結(jié)束后再把剩下的列數(shù)據(jù)再補(bǔ)全。

TDSQL-A執(zhí)行引擎優(yōu)化

在這里我們深入研究，一個(gè)是執(zhí)行引擎框架，另外是基于優(yōu)化器CBO里自動(dòng)形成延遲物化相關(guān)的執(zhí)行計(jì)劃。如果大家對優(yōu)化器比較熟會(huì)知道在這里PG的代價(jià)模型是很先進(jìn)的，目前是自底向上的動(dòng)態(tài)規(guī)劃過程，相比于一些新的優(yōu)化器使用cascade model，通用優(yōu)化效果其實(shí)各有優(yōu)劣。前面提到并行算子在我們合入了PG12、PG13以后，整個(gè)優(yōu)化器里也引入了并行執(zhí)行CBO能力。延遲物化也是持續(xù)在上面做一個(gè)優(yōu)化，也就是path生成的過程中它是可以通過restriction去算出最開始掃描時(shí)只需要掃的那些列。這樣生成path時(shí)只需要去構(gòu)架一個(gè)輔助信息，去標(biāo)記一下哪些列是需要提前物化，哪些列是可以進(jìn)行延遲物化的。

這里實(shí)際有很多細(xì)化問題，例如延遲物化常見問題，如果有更多算子導(dǎo)致reaccess的場景，效果可能會(huì)下降，這在CBO里都有考慮。例如Hashjoin的落盤情況下以及RemoteSubplan都可能會(huì)有亂序問題，在這里我們都有相應(yīng)的考慮在里面，所以整體會(huì)是一個(gè)基于CBO比較智能的延遲物化能力。

前面多個(gè)點(diǎn)提到了向量化執(zhí)行引擎整體設(shè)計(jì)，向量化和SIMD是一個(gè)更核心方向。在這里我們自研了整套向量化執(zhí)行引擎，可以支持TPC-DS及更復(fù)雜的查詢場景，讓復(fù)雜查詢?nèi)紙?zhí)行在向量化執(zhí)行引擎上面。

在Hash Agg或者表達(dá)式計(jì)算等場景下，我們會(huì)去做針對列存儲(chǔ)和向量化技術(shù)做聯(lián)合優(yōu)化，比如numeric轉(zhuǎn)換成定長類型。同時(shí)還去針對向量化內(nèi)存結(jié)構(gòu)做了深入優(yōu)化，比如說SIMD和向量化效果到底能有多少，其實(shí)和數(shù)據(jù)編排有非常大關(guān)聯(lián)性。更好的數(shù)據(jù)編排以及算子實(shí)現(xiàn)可以減少CPU Cache miss。在這里我們花了比較多的精力在內(nèi)存編排上。這些都是原生在內(nèi)核里去實(shí)現(xiàn)。同時(shí)在算子上也是自己去單獨(dú)拉出一套向量化執(zhí)行引擎算子，在SIMD場景下針對算子細(xì)節(jié)和其他典型場景都有SIMD指令引入，保證在多個(gè)層次上，從數(shù)據(jù)編排的基礎(chǔ)到算子核心，再到SIMD整體都進(jìn)行了深入優(yōu)化。

同時(shí)做為分析型產(chǎn)品，可能更多在交易系統(tǒng)后端鏈路上，需要去接入不同數(shù)據(jù)源保證可以有更多的適應(yīng)性場景，如果沿用原有的Copy模式性能就會(huì)比較差。

所以我們針對分布式MPP場景去做了高速數(shù)據(jù)交互工具TDSQL-TDX，這是借助一個(gè)數(shù)據(jù)服務(wù)器，讓TDX統(tǒng)一去處理DN的數(shù)據(jù)請求，DN去訪問TDX取到切分的數(shù)據(jù)分片，就可以達(dá)到基于DN個(gè)數(shù)并行的進(jìn)行數(shù)據(jù)交互。

另外這個(gè)工具也支持?jǐn)?shù)據(jù)導(dǎo)出，相比傳統(tǒng)用的Copy模式有數(shù)十倍的提升。另外我們也將持續(xù)對TDX工具進(jìn)行優(yōu)化，支持更多生態(tài)。

未來規(guī)劃

前面介紹了很多構(gòu)架升級包括一些細(xì)化能力，當(dāng)然我們還有更多的點(diǎn)可以繼續(xù)深入細(xì)化。例如在SIMD覆蓋場景上增強(qiáng)，深入對列存儲(chǔ)格式編排和向量化執(zhí)行引擎做深度優(yōu)化還有更進(jìn)一步的空間。同時(shí)也希望繼續(xù)可以和PG生態(tài)做一個(gè)持續(xù)融合，比如并行或其它的算子能力，都將持續(xù)融合PG社區(qū)能力，同時(shí)也會(huì)考慮整體把code base去進(jìn)行持續(xù)升級。

最后一個(gè)點(diǎn)是Oracle兼容能力，實(shí)際內(nèi)核能力上TDSQL PostgreSQL版整體Oracle兼容能力是非常強(qiáng)的，我們也會(huì)持續(xù)在相關(guān)能力融合和能力進(jìn)行提升。對于國產(chǎn)MPP或類似Oracle替代場景，因?yàn)镺racle不僅是做為交易型，可能很多廠商都是混合場景，而我們做為一個(gè)MPP也可以支持Oracle兼容能力，可以打開更多的適應(yīng)性場景。