一 前言

Garner預(yù)測(cè)，到2022年，所有數(shù)據(jù)庫(kù)中有75%將部署或遷移至云平臺(tái)。另外一家權(quán)威機(jī)構(gòu)IDC也預(yù)測(cè)，在2025年，超過50%的數(shù)據(jù)庫(kù)將部署在公有云上，而中國(guó)則會(huì)達(dá)到驚人的70%以上。云數(shù)據(jù)庫(kù)經(jīng)過多年發(fā)展，經(jīng)歷從Cloud-Hosted (云托管)到 Cloud Native(云原生)模式的轉(zhuǎn)變。

Cloud-Hosted：基于市場(chǎng)和業(yè)界的云需求，大部分廠商選擇了云托管作為演進(jìn)的第一步。這種模式將不再需要用戶線下自建IDC，而是依托于云提供商的標(biāo)準(zhǔn)化資源將數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行移植并提供高度托管，從而解放了用戶對(duì)底層硬件的管理成本和靈計(jì)劃資源的約束。

Cloud-Native：然而隨著更多的業(yè)務(wù)向云上遷移，底層計(jì)算和存儲(chǔ)一體的資源綁定，導(dǎo)致用戶在使用的過程中依然需要考量不必要的資源浪費(fèi)，如計(jì)算資源增加會(huì)要求存儲(chǔ)關(guān)聯(lián)增加，導(dǎo)致無效成本。用戶開始期望云資源能夠?qū)?shù)據(jù)倉(cāng)庫(kù)進(jìn)行更為細(xì)粒度的資源拆解，即對(duì)計(jì)算，存儲(chǔ)的能力進(jìn)行解耦并拆分成可售賣單元，以滿足業(yè)務(wù)的資源編排。到這里，云原生的最大化價(jià)值才被真正凸顯，我們不在著重于打造存算平衡的數(shù)據(jù)倉(cāng)庫(kù)，而是面向用戶業(yè)務(wù)，允許存在大規(guī)模的計(jì)算或存儲(chǔ)傾斜，將業(yè)務(wù)所需要的資源進(jìn)行獨(dú)立部署，并按照最小單位進(jìn)行售賣。這一刻我們真正的進(jìn)入了數(shù)據(jù)倉(cāng)庫(kù)云原生時(shí)代。

阿里云在2021云棲大會(huì)上，預(yù)告了全新云原生架構(gòu)的數(shù)據(jù)倉(cāng)庫(kù)【1】。本文介紹了云原生數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品AnalyticDB PostgreSQL(以下簡(jiǎn)稱ADB PG)從Cloud-Hosted到Cloud-Native的演進(jìn)探索，探討為了實(shí)現(xiàn)真正的資源池化和靈活售賣的底層設(shè)計(jì)和思考，涵蓋內(nèi)容包括產(chǎn)品的架構(gòu)設(shè)計(jì)，關(guān)鍵技術(shù)，性能結(jié)果，效果實(shí)現(xiàn)和后續(xù)計(jì)劃幾方面。(全文閱讀時(shí)長(zhǎng)約為10分鐘)

二 ADB PG云原生架構(gòu)

為了讓用戶可以快速的適配到云數(shù)據(jù)倉(cāng)庫(kù)，目前我們采用的是云上MPP架構(gòu)的設(shè)計(jì)理念，將協(xié)調(diào)節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)進(jìn)行獨(dú)立部署，但承載于單個(gè)ECS上，實(shí)現(xiàn)了計(jì)算節(jié)點(diǎn)存儲(chǔ)計(jì)算一體的部署設(shè)計(jì)，該設(shè)計(jì)由于設(shè)計(jì)架構(gòu)和客戶側(cè)自建高度適配，可快速并無損的將數(shù)倉(cāng)業(yè)務(wù)遷移至云上，對(duì)于早期的云適配非常友好且滿足了資源可平行擴(kuò)展的主要訴求。隨著云原生的進(jìn)一步演進(jìn)，我們提供了全新的存算分離架構(gòu)，將產(chǎn)品進(jìn)一步拆分為服務(wù)層、計(jì)算層和共享存儲(chǔ)層，架構(gòu)圖如下：

Master協(xié)調(diào)節(jié)點(diǎn)：保存全局的schema信息，并實(shí)現(xiàn)了全局事務(wù)管理;行存引擎：用來保存元數(shù)據(jù)信息，這里的元數(shù)據(jù)信息主要指共享存儲(chǔ)文件的可見性信息，包括兩個(gè)部分：

• 一個(gè)是文件與表的關(guān)系
• 另外一個(gè)是被刪除的數(shù)據(jù)的delete bitmap

基于行存我們可以繼承PG的本地事務(wù)能力，在增刪改查的同時(shí)，與PG的事務(wù)能力完全兼容;

本地緩存：通過引入存儲(chǔ)團(tuán)隊(duì)的DADI來實(shí)現(xiàn)高性能的本地緩存，DADI全稱是Alibaba Cloud Data Accelerator for Disaggregated Infrastructure，相比開源產(chǎn)品，性能有數(shù)量級(jí)的提升;

共享存儲(chǔ)：我們借鑒了ClickHouse的一些關(guān)鍵設(shè)計(jì)，在存儲(chǔ)層實(shí)現(xiàn)了一個(gè)基于MergeTree的行列混存，此外我們對(duì)共享存儲(chǔ)基于文件接口做了一層統(tǒng)一訪問接口，同時(shí)高度適配了OSS和HDFS 兩種形態(tài)的分布式文件系統(tǒng);

當(dāng)我們?cè)诩軜?gòu)設(shè)計(jì)的時(shí)候，和同樣源自Greenplum的HAWQ對(duì)比，HAWQ把元數(shù)據(jù)都保存在master，在每次寫的時(shí)候，把修改的元數(shù)據(jù)帶到master來更新，讀的時(shí)候，先從master讀取需要的元數(shù)據(jù)，然后在執(zhí)行計(jì)劃里面把元數(shù)據(jù)都帶上，這樣segment就能拿到對(duì)應(yīng)的元數(shù)據(jù)， 同時(shí)segment可以完全無狀態(tài)。但是這個(gè)設(shè)計(jì)會(huì)帶來2個(gè)核心問題：

1. 元數(shù)據(jù)膨脹導(dǎo)致master成為瓶頸。

2. 受限于元數(shù)據(jù)的性能，無法支持高并發(fā)的實(shí)時(shí)寫入。而我們不這樣設(shè)計(jì)做的原因是我們希望在未來能夠支持高并發(fā)的任務(wù)，ADB PG大概花了2年多的時(shí)間，將Greenplum的單點(diǎn)master架構(gòu)拓展為multi-master，核心是為了解決高并發(fā)實(shí)時(shí)寫入的問題，如果把元數(shù)據(jù)都保存在master上會(huì)帶來如問題：1. master上面的元數(shù)據(jù)存儲(chǔ)和訪問容易形成單點(diǎn)瓶頸2. 需要對(duì)ADB PG的執(zhí)行層做大量的重構(gòu)，實(shí)現(xiàn)在執(zhí)行計(jì)劃里面把元數(shù)據(jù)都帶上，這會(huì)急劇的增加查詢計(jì)劃本身的帶寬，這個(gè)對(duì)于高并發(fā)的小查詢非常不友好。所以我們改進(jìn)了架構(gòu)，將元數(shù)據(jù)分散到segment，規(guī)避并實(shí)現(xiàn)了：

1. master的存儲(chǔ)和讀寫都不會(huì)成為瓶頸

2. 無需對(duì)執(zhí)行層做重構(gòu)，將元數(shù)據(jù)分散減少單次查詢的帶寬壓力。

3. 將segment上的元數(shù)據(jù)放到分布式kv上，解決擴(kuò)縮容的元數(shù)據(jù)搬遷問題。

共享存儲(chǔ)使用OSS的原因在于，隨著單個(gè)用戶業(yè)務(wù)數(shù)據(jù)不斷增長(zhǎng)，需要一個(gè)可持續(xù)發(fā)展的存儲(chǔ)方案，而OSS的低存儲(chǔ)成本，高可用性和數(shù)據(jù)持久性是最好的選擇。

使用OSS的另外一個(gè)好處在于按需付費(fèi)，用戶不需要預(yù)制存儲(chǔ)空間大小，存了多少數(shù)據(jù)，付多少錢，數(shù)據(jù)刪除后即不再收費(fèi);ESSD云盤通常需要根據(jù)數(shù)據(jù)計(jì)算存儲(chǔ)水位，無法做到將存儲(chǔ)資源真正的按需供應(yīng)，而且無法自動(dòng)縮容，這些都違背了我們?cè)圃脑O(shè)計(jì)理念。但同時(shí)OSS的劣勢(shì)在于RT:

為了解決OSS的RT問題，我們?yōu)橛?jì)算節(jié)點(diǎn)配置了一定比例的本地盤，用來做訪問加速。此外，我們?cè)O(shè)計(jì)了一個(gè)高性能的行列混存，借鑒了ClickHouse mergetree存儲(chǔ)的核心思想，以有序?yàn)楹诵?，文件?nèi)絕對(duì)有序，文件與文件大致相對(duì)有序，通過merge的異步操作，實(shí)現(xiàn)文件和并和排序，基于有序，我們?cè)谖募?nèi)設(shè)計(jì)了3層的統(tǒng)計(jì)信息，并做了大量的IO裁剪優(yōu)化。

下面我們對(duì)每個(gè)技術(shù)點(diǎn)做進(jìn)一步介紹。

三 關(guān)鍵技術(shù)

1 彈性伸縮

為了實(shí)現(xiàn)快速的彈性伸縮，我們的方式是數(shù)據(jù)在共享存儲(chǔ)上hash bucket來組織，擴(kuò)縮容后通過一致性hash把計(jì)算節(jié)點(diǎn)和bucket做重新映射，為了解決bucket與segment分配的均勻性，并降低擴(kuò)縮容后cache失效的影響，我們對(duì)傳統(tǒng)的一致性hash算法做了改進(jìn)，支持?jǐn)U縮容時(shí)的動(dòng)態(tài)映射。

把數(shù)據(jù)根據(jù)hash bucket分成多個(gè)分片，按分片粒度在擴(kuò)縮容的重新映射對(duì)象存儲(chǔ)上的數(shù)據(jù)。如果擴(kuò)容計(jì)算節(jié)點(diǎn)超過分片個(gè)數(shù)的時(shí)候，只能重分布數(shù)據(jù)。為了解決這個(gè)問題，我們支持hash bucket可以后臺(tái)分裂和合并，避免重新分布數(shù)據(jù)。

上述是擴(kuò)縮容時(shí)“數(shù)據(jù)”的重現(xiàn)映射，而描述數(shù)據(jù)文件可見性的元數(shù)據(jù)，由于保存在行表中，我們還是使用了Greenplum的數(shù)據(jù)重分布策略，不同的是，為了加速元數(shù)據(jù)的重分布，我們做了并行化分布等優(yōu)化。我們以擴(kuò)容為例進(jìn)一步細(xì)化擴(kuò)容的流程：

結(jié)合ECS資源池化，網(wǎng)卡并行加載和docker鏡像預(yù)熱等技術(shù)，16節(jié)點(diǎn)內(nèi)端到端的耗時(shí)接近1分鐘。

2 分層存儲(chǔ)

分層存儲(chǔ)的實(shí)現(xiàn)如下：

如上圖所示，我們把存儲(chǔ)的資源分成3層，包括內(nèi)存、本地盤和共享存儲(chǔ)。內(nèi)存：主要負(fù)責(zé)行存訪問加速，并負(fù)責(zé)文件統(tǒng)計(jì)信息的緩存;本地盤：作為行存的持久化存儲(chǔ)，并作為遠(yuǎn)端共享存儲(chǔ)的本地加速器;遠(yuǎn)端的共享存儲(chǔ)：作為數(shù)據(jù)的持久化存儲(chǔ)。

3 讀寫流程

寫入流程如下：

• 用戶寫入數(shù)據(jù)通過數(shù)據(jù)攢批直接寫入OSS，同時(shí)會(huì)在本地磁盤上記錄一條元數(shù)據(jù)。這條元數(shù)據(jù)記錄了，文件和數(shù)據(jù)表的對(duì)應(yīng)關(guān)系。元數(shù)據(jù)使用PG的行存表實(shí)現(xiàn)，我們通過file metadata表來保存這個(gè)信息。
• 更新或者刪除的時(shí)候，我們不需要直接修改OSS上面的數(shù)據(jù)，我們通過標(biāo)記刪除來實(shí)現(xiàn)，標(biāo)記刪除的信息也是保存在本地行存表中，我們通過visibility bitmap來存這個(gè)信息。標(biāo)記刪除會(huì)導(dǎo)致讀的性能下降，我們通過后臺(tái)merge來應(yīng)用刪除信息到文件，減少刪除帶來的讀性能影響。

我們?cè)趯懭氲臅r(shí)候，是按照bucket對(duì)segment上的數(shù)據(jù)做了進(jìn)一步劃分，這里會(huì)帶來小文件的問題。為了解決小文件問題，我們做了下面幾點(diǎn)優(yōu)化：

1. Group flush：一批寫入的數(shù)據(jù)，可以通過group flush寫到同一個(gè)OSS文件，我們的OSS文件采用了ORC格式，不同bucket寫入到對(duì)應(yīng)strip;

2. 流水線異步并行：編碼攢批，排序是典型的cpu密集型任務(wù)，上傳到oss是典型的網(wǎng)絡(luò)IO密集型任務(wù)，我們會(huì)把這2種任務(wù)類型并行起來，在上傳oss的任務(wù)作為異步任務(wù)執(zhí)行，同時(shí)對(duì)下一批數(shù)據(jù)編碼排序，加快寫入性能。

因?yàn)檫h(yuǎn)端持久化存儲(chǔ)提供了12個(gè)9的持久性，所以只有保存元數(shù)據(jù)的行存才有WAL日志和雙副本來保證可靠性，數(shù)據(jù)本身寫穿到共享存儲(chǔ)，無需WAL日志和多副本,由于減少了WAL日志和WAL日志的主備同步，又通過異步并行和攢批，在批量寫入場(chǎng)景，我們寫入性能做到了基本與ECS彈性存儲(chǔ)版本性能持平。

讀取流程如下：

• 我們通過讀取file metadata表，得到需要掃描的OSS文件。
• 根據(jù)OSS文件去讀取對(duì)應(yīng)文件。
• 讀到的文件通過元數(shù)據(jù)表visibility bitmap過濾掉已經(jīng)被刪除的數(shù)據(jù)。

為了解決讀OSS帶來的延遲，我們也引入了DADI幫忙我們實(shí)現(xiàn)緩存管理和封裝了共享文件的訪問，讀文件的時(shí)候，首先會(huì)判斷是否本地有緩存，如果有則直接從本地磁盤讀，沒有才會(huì)去 OSS讀，讀到后會(huì)緩存在本地。寫的時(shí)候會(huì)直寫OSS，并回寫本地磁盤，回寫是一個(gè)異步操作。對(duì)于本地緩存數(shù)據(jù)的淘汰我們也通過DADI來管理，他會(huì)根據(jù)LRU/LFU策略來自動(dòng)淘汰冷數(shù)據(jù)。

由于事務(wù)是使用PG的行存實(shí)現(xiàn)，所以與ADB PG的事務(wù)完全兼容，帶來的問題是，我們?cè)跀U(kuò)縮容的時(shí)候需要重新分布這部分?jǐn)?shù)據(jù)，我們重新設(shè)計(jì)了這塊數(shù)據(jù)的重分布機(jī)制，通過預(yù)分區(qū)，并行拷貝，點(diǎn)對(duì)點(diǎn)拷貝等技術(shù)，極大縮短了擴(kuò)縮容時(shí)間。

總結(jié)一下性能優(yōu)化點(diǎn)：? 通過本地行存表實(shí)現(xiàn)事務(wù)ACID，支持?jǐn)?shù)據(jù)塊級(jí)別的并發(fā);

•  通過Batch和流水線并行化提高寫入吞吐;
• 基于DADI實(shí)現(xiàn)內(nèi)存、本地SSD多級(jí)緩存加速訪問。

4 可見性表

我們?cè)贔ile Metadata中保存了共享存儲(chǔ)文件相關(guān)的信息，它的結(jié)構(gòu)如下：

Hash bucket：是為了在擴(kuò)縮容的時(shí)候搬遷數(shù)據(jù)的時(shí)候，能夠按照bucket來掃描，查詢的時(shí)候，也是一個(gè)bucket跟著一個(gè)bucket;Level：是merge tree的層次，0層代表實(shí)時(shí)寫入的數(shù)據(jù)，這部分?jǐn)?shù)據(jù)在合并的時(shí)候有更高的權(quán)重;Physical file id：是文件對(duì)應(yīng)的id，64字節(jié)是因?yàn)樗辉倥csegment關(guān)聯(lián)，不再只需要保證segment內(nèi)table的唯一性，需要全局唯一;Stripe id：是因?yàn)橐粋€(gè)oss文件可以包含多個(gè)bucket 的文件，以stripe為單位，方便在segment一次寫入的多個(gè)bucket合并到一個(gè)oss文件中。避免oss小文件，導(dǎo)致性能下降，和oss小文件爆炸;Total count：是文件行數(shù)，這也是后臺(tái)合并的一個(gè)權(quán)重，越大合并的權(quán)重越低 。

Visibility bitmap記錄了被刪除的文件信息

Start_row對(duì)應(yīng)32k對(duì)應(yīng)一個(gè)delete bitmap。這個(gè)32000 4k，行存使用的32k的page可以保存7條記錄。Delete count是被刪除的數(shù)量。我們無需訪問oss，可以直接得到需要merge的文件，避免訪問oss帶來的延遲，另外oss對(duì)于訪問的吞吐也有限額，避免頻繁訪問導(dǎo)致觸發(fā)oss的限流。

5 行列混存

Mergetree的結(jié)構(gòu)如上圖左側(cè)所示，核心是通過后臺(tái)merge的方式，把小文件merge成有序的大文件，并且在merge的時(shí)候，我們可以對(duì)數(shù)據(jù)重排，例如數(shù)據(jù)的有序特性做更多的優(yōu)化，參考后續(xù)的有序感知優(yōu)化。與leveldb的不同在于：

1. 0層實(shí)時(shí)寫入的會(huì)做合并，不同bucket的文件會(huì)合并成大文件，不同bucket會(huì)落到對(duì)應(yīng)的stripe;

2. Merge會(huì)跨層把符合merge的文件做多路歸并，文件內(nèi)嚴(yán)格有序，但是文件間大致有序，層數(shù)越高，文件越大，文件間的overlap越小。

每個(gè)文件我們使用了行列混存的格式，右側(cè)為行列混存的具體的存儲(chǔ)格式，我們是在ORC的基礎(chǔ)上做了大量?jī)?yōu)化。

ORC文件：一個(gè)ORC文件中可以包含多個(gè)stripe，每一個(gè)stripe包含多個(gè)row group，每個(gè)row group包含固定條記錄，這些記錄按照列進(jìn)行獨(dú)立存儲(chǔ)。

Postscript：包括文件的描述信息PostScript、文件meta信息(包括整個(gè)文件的統(tǒng)計(jì)信息，數(shù)據(jù)字典等)、所有stripe的信息和文件schema信息。

stripe：stripe是對(duì)行的切分，組行形成一個(gè)stripe，每次讀取文件是以行組為單位的，保存了每一列的索引和數(shù)據(jù)。它由index data，row data和stripe footer組成。

File footer：保存stripe的位置、每一個(gè)列的在該stripe的統(tǒng)計(jì)信息以及所有的stream類型和位置。

Index data：保存了row group級(jí)別的統(tǒng)計(jì)信息。

Data stream：一個(gè)stream表示文件中一段有效的數(shù)據(jù)，包括索引和數(shù)據(jù)兩類。索引stream保存每一個(gè)row group的位置和統(tǒng)計(jì)信息，數(shù)據(jù)stream包括多種類型的數(shù)據(jù)，具體需要哪幾種是由該列類型和編碼方式?jīng)Q定，下面以integer和string 2種類型舉例說明：

對(duì)于一個(gè)Integer字段，會(huì)同時(shí)使用一個(gè)比特流和整形流。比特流用于標(biāo)識(shí)某個(gè)值是否為null，整形流用于保存該整形字段非空記錄的整數(shù)值。

String類型字段，ORC writer在開始時(shí)會(huì)檢查該字段值中不同的內(nèi)容數(shù)占非空記錄總數(shù)的百分比不超過0.8的話，就使用字典編碼，字段值會(huì)保存在一個(gè)比特流，一個(gè)字節(jié)流及兩個(gè)整形流中。比特流也是用于標(biāo)識(shí)null值的，字節(jié)流用于存儲(chǔ)字典值，一個(gè)整形流用于存儲(chǔ)字典中每個(gè)詞條的長(zhǎng)度，另一個(gè)整形流用于記錄字段值。如果不能用字典編碼，ORC writer會(huì)知道這個(gè)字段的重復(fù)值太少，用字典編碼效率不高，ORC writer會(huì)使用一個(gè)字節(jié)流保存String字段的值，然后用一個(gè)整形流來保存每個(gè)字段的字節(jié)長(zhǎng)度。

在ORC文件中保存了三個(gè)層級(jí)的統(tǒng)計(jì)信息，分別為文件級(jí)別、stripe級(jí)別和row group級(jí)別。而提升存儲(chǔ)性能的核心是減少IO，我們基于ORC的統(tǒng)計(jì)信息和索引實(shí)現(xiàn)各種下推，幫助我們實(shí)現(xiàn)IO裁剪。例如Projection下推，我們只會(huì)掃描需要物化的列。Agg下推中，我們會(huì)直接把需要的min，max，sum，unique從統(tǒng)計(jì)信息或者索引中讀取即可返回，避免了對(duì)data stream的解壓。對(duì)于predicate，我們還支持把filter下推，通過統(tǒng)計(jì)信息直接做過濾，直接跳過不符合的條件的stripe，我們支持各種操作符，以及in/not in，以及表達(dá)式的等價(jià)轉(zhuǎn)換。

此外我們針對(duì)存儲(chǔ)格式對(duì)性能還做了下面的優(yōu)化：1. 零拷貝：為了把ORC的數(shù)據(jù)類型轉(zhuǎn)換成PG數(shù)據(jù)類型，我們對(duì)于定長(zhǎng)類型的做值拷貝，變長(zhǎng)類型直接轉(zhuǎn)換成PG的datum做指針引用。2. Batch Scan：面向column采用batch scan，替代逐行訪問而是先掃完一列，再掃下一列，這樣對(duì)CPU cache更加友好。3. 支持Seek read：方便過濾命中情況下的跳轉(zhuǎn)。

6 本地緩存

DADI幫助我們實(shí)現(xiàn)2個(gè)能力，一個(gè)是高效的緩存管理，另外一個(gè)是統(tǒng)一存儲(chǔ)訪問。在了解DADI之前，我們可以首先看一下，DADI與開源解決方案從RT與throughput 2個(gè)維度做了對(duì)比測(cè)試：

從中看到，DADI相比開源解決方案alluxio在內(nèi)存命中的場(chǎng)景RT上有數(shù)量級(jí)的提升，在throughput上也有明顯的優(yōu)勢(shì)。在命中磁盤的場(chǎng)景，也有明顯的性能優(yōu)勢(shì)，在部分分析場(chǎng)景下，我們會(huì)頻繁但是少量讀取文件統(tǒng)計(jì)信息，這些統(tǒng)計(jì)信息我們會(huì)緩存在本地，這個(gè)優(yōu)勢(shì)帶來整體性能的較大提升。

DADI在緩存命中場(chǎng)景下的性能優(yōu)勢(shì)，可以參考下面的架構(gòu)：

DADI SDK：通過標(biāo)準(zhǔn)讀寫接口訪問存儲(chǔ)，通過緩存是否命中，選擇短路讀(short circuit read)，還是IPC進(jìn)程通信訪問Local DADI Service，或者訪問遠(yuǎn)端的DADI Service，對(duì)應(yīng)分布式緩存服務(wù)，作為lib庫(kù)嵌入ADB PG的讀寫進(jìn)程;Cache Instance：管理本地緩存，緩存文件抽象成虛擬塊設(shè)備來訪問，數(shù)據(jù)在memory和本次磁盤的冷熱以block為單位管理。

這里的核心設(shè)計(jì)在于：

• 短路讀，直接讀共享內(nèi)存，避免通過IPC讀;
• 緩存是否命中的數(shù)據(jù)結(jié)構(gòu)，也是在共享內(nèi)存里面。通過reference count，結(jié)合robust mutex來保證共享內(nèi)存數(shù)據(jù)的多線程安全;
• 磁盤讀，100us，+ 27us約等于磁盤讀本身rt，IPC走shm通信，沒有使用本地socket通信。

4. 極低的資源使用。內(nèi)存：DADI Service使用的內(nèi)存在100~200M，原因在于基于共享內(nèi)存的IPC實(shí)現(xiàn)，hash表等數(shù)據(jù)結(jié)構(gòu)，避免多進(jìn)程架構(gòu)下內(nèi)存膨脹， 精簡(jiǎn)的編碼方式，1個(gè)內(nèi)存頁(yè)16k 對(duì)應(yīng) 4byte的管理結(jié)構(gòu);CPU：Local DADI Service在磁盤打滿的時(shí)候單核CPU使用20%左右。CPU的使用在SDK這邊，SDK與Local DADI Service通信很少。

此外為了更好的發(fā)揮DADI在命中內(nèi)存的優(yōu)勢(shì)，我們結(jié)合行列混存做了以下優(yōu)化：

• 緩存優(yōu)先級(jí)支持統(tǒng)計(jì)信息高優(yōu)先級(jí)，常駐內(nèi)存，索引信息常駐本地磁盤。支持維度表數(shù)據(jù)高優(yōu)先級(jí)緩存在本地。
•  細(xì)粒度緩存策略為了避免大表冷數(shù)據(jù)訪問，導(dǎo)致本地?zé)釘?shù)據(jù)被全部替換，大表使用專有緩存區(qū)。
• 文件異步預(yù)取根據(jù)查詢情況，把解析的數(shù)據(jù)文件，預(yù)先讀取到本地，這個(gè)過程不影響當(dāng)前文件的讀寫，并且是異步的。

7 向量化執(zhí)行

ADB PG云原生版本也同樣支持向量化執(zhí)行引擎，核心還是通過攢批的方式提高數(shù)據(jù)在CPU cache的命中率，通過codegen減少函數(shù)調(diào)用次數(shù)，減少?gòu)?fù)雜計(jì)算指令跳轉(zhuǎn)，通過SIMD指令加速計(jì)算，通過內(nèi)存池管理，降低算子間的內(nèi)存拷貝，更多信息可以參考【3】。

8 有序感知

數(shù)據(jù)的有序主要用在2個(gè)方面，基于有序的IO裁剪，另外一個(gè)是盡量減少計(jì)算過程中的排序，IO裁剪在行列混存以及有較多的討論，這里主要討論第二點(diǎn)，這里我們做的主要工作有：

• 消除多余sorting操作。如果data本身有序，且滿足排序要求，則不需要加sort操作。
• 最小化需要排序的列。例如希望對(duì){c1,c2,..cn}排序，如果有謂詞c1=5，則order簡(jiǎn)化成{c2,..cn}，避免排序多一個(gè)字段。
• order下推。在初始化階段，降意向排序操作盡量下推。

我們通過下列方法來生成sort scan的算子，查詢SQL解析生成AST后，會(huì)根據(jù)一系列啟發(fā)式規(guī)則做變換生成物理執(zhí)行計(jì)劃：

• 首先針對(duì)不同算子的有序性需求，例如(join/group by/distinct/order by),建立算子的interesting order(即這個(gè)算子期望的有序輸入)。
• 其次在sort scan的過程中所生成的interesting order，會(huì)盡可能下推到下層算子中(sort-ahead)，以盡早滿足order屬性要求。
• 如果一個(gè)算子具有多個(gè)interesting order，會(huì)嘗試將他們合并，這樣一個(gè)排序就可以滿足多個(gè)order屬性的需求。

此外就是sort scan算子的實(shí)現(xiàn)，存儲(chǔ)層面只能保證文件內(nèi)嚴(yán)格有序，文件的大致有序，我們通過多路歸并的算法來實(shí)現(xiàn)。這里的問題在于sort scan的多路歸并需要一條條讀取數(shù)據(jù)，與向量化的batch scan與文件的批量讀沖突，我們通過CBO來選主最優(yōu)的執(zhí)行計(jì)劃。

9 細(xì)粒度并行

ADB PG是MPP架構(gòu)，能夠充分發(fā)揮節(jié)點(diǎn)間并行計(jì)算能力，云原生版本由于對(duì)數(shù)據(jù)按bucket做了切分，能幫助我們?cè)诠?jié)點(diǎn)內(nèi)實(shí)現(xiàn)更細(xì)粒度的并行，我們以join為例說明：

左邊是沒有節(jié)點(diǎn)內(nèi)并行的join的執(zhí)行計(jì)劃，會(huì)起2個(gè)進(jìn)程，一個(gè)做hash join的build，另外一個(gè)做probe，右邊是節(jié)點(diǎn)內(nèi)做了并行，我們會(huì)根據(jù)segment所分配的bucket來做并行，例如上圖每個(gè)bucket的數(shù)據(jù)都可以并行的去做計(jì)算，由于數(shù)據(jù)是按照bucket做的劃分，join key是分布健的時(shí)候，節(jié)點(diǎn)內(nèi)并行也能完美命中l(wèi)ocal join的優(yōu)化。

四 性能結(jié)果

1 擴(kuò)縮容性能

計(jì)算資源擴(kuò)容(節(jié)點(diǎn)數(shù))2->44->88->1616->128

用時(shí)<1min<1min<1min<7min

2 讀寫性能

為了測(cè)試性能，我們使用了4*4C規(guī)格的實(shí)例，ADB PG的新版云原生與存儲(chǔ)彈性版本做了性能對(duì)比測(cè)試。

寫性能測(cè)試

測(cè)試表選用scale factor = 500的TPC-H lineitem表。通過同時(shí)執(zhí)行不同并發(fā)數(shù)的copy命令，測(cè)得命令執(zhí)行時(shí)間，用總數(shù)據(jù)量除以命令執(zhí)行時(shí)間，得到吞吐量。

在單并發(fā)下新版本與存儲(chǔ)彈性版本的性能差不多，主要在于資源都沒有滿;

在4并發(fā)下新版本的吞吐是存儲(chǔ)彈性的2倍，原因在于使用lineitem表都定義了sort key，新版本在寫入數(shù)據(jù)無需寫WAL日志，另外攢批加上流水線并行相比彈性存儲(chǔ)版本先寫入，再merge，merge的時(shí)候也需要寫額外的WAL有一定優(yōu)勢(shì);

在8并發(fā)下新版本與4并發(fā)差不多，主要由于4C 4并發(fā)已經(jīng)把CPU用滿，所以再提升并發(fā)也沒有提升。

讀性能測(cè)試

為了全面的測(cè)試讀性能，我們針對(duì)3種場(chǎng)景做了測(cè)試：全內(nèi)存：使用的是TPCH sf為10的數(shù)據(jù)集，會(huì)生成10G的測(cè)試數(shù)據(jù)集。全本地磁盤緩存：使用的是TPCH sf為500的數(shù)據(jù)集，會(huì)生成500GB的測(cè)試數(shù)據(jù)集。一半緩存，一半OSS：使用的是TPCH sf為2000的數(shù)據(jù)集，會(huì)生成2000GB的測(cè)試數(shù)據(jù)集。(本地磁盤緩存960GB)測(cè)試結(jié)果如下(縱軸為RT單位ms)

全內(nèi)存

全本地磁盤緩存

一半本地緩存，一半OSS

從上述測(cè)試結(jié)果來看：

• 云原生版本對(duì)比老的彈性存儲(chǔ)版本均有1倍多的性能提升，原因在于細(xì)粒度并行帶來的加速效果;
• 對(duì)于TPCH這種計(jì)算密集型的作業(yè)，即使數(shù)據(jù)一半緩存，一半OSS性能也不錯(cuò)，sf 2000數(shù)據(jù)量是sf 500的4倍，rt增加到原來的2.8倍，主要原因在于4*4C規(guī)格的實(shí)例沒有到OSS的帶寬瓶頸，另外由于本身讀取的預(yù)取等優(yōu)化。

五 總結(jié)

AnalyticDB PostgreSQL新版云原生是充分的將物理資源進(jìn)行了池化，將存儲(chǔ)和計(jì)算能力單元化進(jìn)行分配，實(shí)現(xiàn)靈活的部署。這個(gè)特性為使用者提供極致的性價(jià)比，做到了算力的最優(yōu)分配，同時(shí)降低用戶使用的門檻，讓用戶專注于業(yè)務(wù)而無需將大量精力放在算力和存儲(chǔ)的規(guī)劃上，實(shí)現(xiàn)體驗(yàn)升級(jí)。

• 通過存儲(chǔ)計(jì)算分離，用戶可以根據(jù)業(yè)務(wù)負(fù)載模型，輕松適配計(jì)算密集型或存儲(chǔ)密集型，存儲(chǔ)并按使用計(jì)費(fèi)，避免存儲(chǔ)計(jì)算一體僵化而造成的資源浪費(fèi);
• 動(dòng)態(tài)的適配業(yè)務(wù)負(fù)載波峰和波谷，云原生MPP架構(gòu)計(jì)算側(cè)使用了shared-nothing架構(gòu)，支持秒級(jí)的彈性伸縮能力，而共享存儲(chǔ)使得底層存儲(chǔ)獨(dú)立不受計(jì)算的影響。這降低了用戶早期的規(guī)格選型的門檻，預(yù)留了后期根據(jù)業(yè)務(wù)的動(dòng)態(tài)調(diào)整靈活性;
• 在存儲(chǔ)計(jì)算分離基礎(chǔ)上，提供了數(shù)據(jù)共享能力，這真正打破了物理機(jī)的邊界，讓云上的數(shù)據(jù)真正的流動(dòng)了起來。例如數(shù)據(jù)的跨實(shí)例實(shí)時(shí)共享，可支持一存多讀的使用模式，打破了傳統(tǒng)數(shù)倉(cāng)實(shí)例之間數(shù)據(jù)訪問需要先導(dǎo)入，再訪問的孤島，簡(jiǎn)化操作，提高效率，降低成本。

六 后續(xù)計(jì)劃

在上述存儲(chǔ)分離的架構(gòu)上，我們后續(xù)主要有3個(gè)大的方向：

• 能力補(bǔ)齊，這塊主要是補(bǔ)齊當(dāng)前版本的一些限制，例如Primary key，索引，物化視圖，補(bǔ)齊寫入的能力;
• 性能持續(xù)優(yōu)化，主要優(yōu)化緩存沒有命中場(chǎng)景;
• 云原生架構(gòu)持續(xù)升級(jí)，這塊主要是在當(dāng)前存儲(chǔ)計(jì)算分離架構(gòu)下，進(jìn)一步提升用戶體驗(yàn);

在云原生升級(jí)我們主要有2個(gè)重點(diǎn)方向：

• 存算分離往Serverless再進(jìn)一步，擴(kuò)縮容無感。會(huì)進(jìn)一步把元數(shù)據(jù)和狀態(tài)也從計(jì)算節(jié)點(diǎn)剝離到服務(wù)層，把segment做成無狀態(tài)的，這樣的好處在于擴(kuò)縮容能做到用戶無感，另外一個(gè)好處在于segment無狀態(tài)有利于提高系統(tǒng)高可用能力，當(dāng)前我們還是通過主備模式提供高可用，當(dāng)有節(jié)點(diǎn)故障的時(shí)候，主備切換緩存失效性能會(huì)急劇下降，segment無狀態(tài)后我們會(huì)直接將它提出集群，通過“縮容”的方式繼續(xù)提高服務(wù)。
• 應(yīng)用跨實(shí)例的數(shù)據(jù)共享。此外對(duì)于分析型業(yè)務(wù)，數(shù)據(jù)規(guī)模大，以TB起步，傳統(tǒng)數(shù)倉(cāng)采用煙囪式架構(gòu)，數(shù)據(jù)冗余，數(shù)據(jù)同步代價(jià)高的問題，我們希望提供跨實(shí)例的數(shù)據(jù)共享能力，重構(gòu)數(shù)倉(cāng)架構(gòu)。

云原生版本將于2022年2月正式商業(yè)化發(fā)布，想要更多信息可以訪問產(chǎn)品網(wǎng)站https://www.aliyun.com/product/gpdb

七 引用資料

【1】 http://click.aliyun.com/m/1000307639/

【2】 https://developer.aliyun.com/article/838806?groupCode=analyticdb4postgresql&share_source=wechat_qr

【3】 https://developer.aliyun.com/article/783182