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

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

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

TDSQL-A發(fā)展歷程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

未來規(guī)劃

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

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