一 前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. master的存儲和讀寫都不會成為瓶頸

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

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

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

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

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

下面我們對每個技術(shù)點做進一步介紹。

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

1 彈性伸縮

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

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

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

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

2 分層存儲

分層存儲的實現(xiàn)如下：

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

3 讀寫流程

寫入流程如下：

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

我們在寫入的時候，是按照bucket對segment上的數(shù)據(jù)做了進一步劃分，這里會帶來小文件的問題。為了解決小文件問題，我們做了下面幾點優(yōu)化：

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

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

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

讀取流程如下：

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

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

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

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

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

4 可見性表

我們在File Metadata中保存了共享存儲文件相關(guān)的信息，它的結(jié)構(gòu)如下：

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

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

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

5 行列混存

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

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

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

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

ORC文件：一個ORC文件中可以包含多個stripe，每一個stripe包含多個row group，每個row group包含固定條記錄，這些記錄按照列進行獨立存儲。

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

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

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

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

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

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

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

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

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

6 本地緩存

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

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

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

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

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

• 短路讀，直接讀共享內(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實現(xiàn)，hash表等數(shù)據(jù)結(jié)構(gòu)，避免多進程架構(gòu)下內(nèi)存膨脹， 精簡的編碼方式，1個內(nèi)存頁16k 對應(yīng) 4byte的管理結(jié)構(gòu);CPU：Local DADI Service在磁盤打滿的時候單核CPU使用20%左右。CPU的使用在SDK這邊，SDK與Local DADI Service通信很少。

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

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

7 向量化執(zhí)行

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

8 有序感知

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

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

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

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

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

9 細(xì)粒度并行

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

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

四 性能結(jié)果

1 擴縮容性能

計算資源擴容(節(jié)點數(shù))2->44->88->1616->128

用時<1min<1min<1min<7min

2 讀寫性能

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

寫性能測試

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

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

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

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

讀性能測試

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

全內(nèi)存

全本地磁盤緩存

一半本地緩存，一半OSS

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

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

五 總結(jié)

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

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

六 后續(xù)計劃

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

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

在云原生升級我們主要有2個重點方向：

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