[[403506]]

一 背景

隨著云時(shí)代的到來(lái)，數(shù)據(jù)庫(kù)也開(kāi)始擁抱云數(shù)據(jù)庫(kù)時(shí)代，各類數(shù)據(jù)庫(kù)系統(tǒng)（OLTP、OLAP、NoSQL等）在各內(nèi)外云平臺(tái)（AWS、Azure、阿里云）百花齊放，有開(kāi)源的MySQL、PostgreSQL、MongoDB，傳統(tǒng)數(shù)據(jù)庫(kù)廠商的SQLServer、Oracle，云廠商自研的Aurora、Redshift、PolarDB、AnalyticDB、AzureSQL等。有些數(shù)據(jù)庫(kù)還處于Cloud Hosting階段，僅僅是將原有架構(gòu)遷移到云主機(jī)上，利用了云的資源。有些數(shù)據(jù)庫(kù)則已經(jīng)進(jìn)入了Cloud Native階段，基于云平臺(tái)IAAS層的基礎(chǔ)設(shè)施，構(gòu)建彈性、serverless、數(shù)據(jù)共享等能力。

本文主要介紹阿里云云原生數(shù)據(jù)倉(cāng)庫(kù)AnalyticDB MySQL版（以下簡(jiǎn)稱AnalyticDB）過(guò)去幾年在彈性方向上的探索和成果。

二 為什么要計(jì)算存儲(chǔ)分離

MPP（Massive Parallel Processing）架構(gòu)為OLAP類數(shù)據(jù)庫(kù)最普遍采用的技術(shù)架構(gòu)。在MPP架構(gòu)下，計(jì)算存儲(chǔ)共享一個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)有自己獨(dú)立的CPU、內(nèi)存、磁盤資源，互相不共享。數(shù)據(jù)經(jīng)過(guò)一定的分區(qū)規(guī)則（hash、random、range），打散到不同的節(jié)點(diǎn)上。處理查詢時(shí)，每個(gè)節(jié)點(diǎn)并行處理各自的數(shù)據(jù)，互相之間沒(méi)有資源爭(zhēng)搶，具備比較好的并行執(zhí)行能力。

這種將存儲(chǔ)資源、計(jì)算資源緊密耦合的架構(gòu)，不太容易滿足云時(shí)代不同場(chǎng)景下的不同workload需求。例如數(shù)據(jù)導(dǎo)入類的任務(wù)，往往需要消耗比較大的IO、網(wǎng)絡(luò)帶寬，而CPU資源消耗不大。而復(fù)雜查詢類任務(wù)往往對(duì)CPU的資源消耗非常大。因此面對(duì)這兩種不同的workload，在選擇資源規(guī)格時(shí)，需要結(jié)合不同的workload分別做不同的類型選擇，也很難用一種資源規(guī)格同時(shí)滿足這兩種類型。因?yàn)闃I(yè)務(wù)不停在發(fā)展，workload也不停在變化，比較難提前做好規(guī)劃。

當(dāng)業(yè)務(wù)發(fā)展，對(duì)CPU資源提出了更高的需求，我們擴(kuò)容集群擴(kuò)充CPU資源時(shí)，也會(huì)引發(fā)數(shù)據(jù)的reshuffle，這會(huì)消耗比較大的網(wǎng)絡(luò)帶寬、以及CPU資源。即便是基于云平臺(tái)構(gòu)建的數(shù)據(jù)倉(cāng)庫(kù)，在查詢低峰期時(shí)，也無(wú)法通過(guò)釋放部分計(jì)算資源降低使用成本，因?yàn)檫@同樣會(huì)引發(fā)數(shù)據(jù)的reshuffle。這種耦合的架構(gòu)，限制了數(shù)據(jù)倉(cāng)庫(kù)的彈性能力。

而通過(guò)分離存儲(chǔ)資源、計(jì)算資源，可以獨(dú)立規(guī)劃存儲(chǔ)、計(jì)算的資源規(guī)格和容量。這樣計(jì)算資源的擴(kuò)容、縮容、釋放，均可以比較快完成，并且不會(huì)帶來(lái)額外的數(shù)據(jù)搬遷的代價(jià)。存儲(chǔ)、計(jì)算也可以更好的結(jié)合各自的特征，選擇更適合自己的資源規(guī)格和設(shè)計(jì)。

三 業(yè)界趨勢(shì)

1 Redshift

作為AWS上最熱門的數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品，Redshift采用的是MPP架構(gòu)，它也一直往彈性方向演進(jìn)。Redshift于2018年11月推出的Elastic resize功能，相比于classic resize，其擴(kuò)縮容時(shí)間大幅下降。在2019年11月進(jìn)一步推出了elastic resize scheduling讓用戶配置擴(kuò)縮容計(jì)劃來(lái)達(dá)到自動(dòng)彈性。此外，Redshift在2019年12月正式推出了RA3形態(tài)，它采用了計(jì)算存儲(chǔ)分離的架構(gòu)，數(shù)據(jù)存儲(chǔ)在S3上，計(jì)算節(jié)點(diǎn)使用高性能SSD作為本地緩存，加速對(duì)數(shù)據(jù)的訪問(wèn)。在這個(gè)架構(gòu)下，計(jì)算存儲(chǔ)可以獨(dú)立彈性，具備較好的彈性能力。

2 Snowflake

Snowflake從誕生的第一天起就采用計(jì)算存儲(chǔ)分離架構(gòu)，作為跨云平臺(tái)的云數(shù)據(jù)倉(cāng)庫(kù)，它的存儲(chǔ)層由對(duì)象存儲(chǔ)構(gòu)成（可以是AWS S3、Azure Blob等），計(jì)算層由virtual warehouse（簡(jiǎn)稱VW）構(gòu)成，每個(gè)用戶可以創(chuàng)建一個(gè)或多個(gè)對(duì)應(yīng)的VW，每個(gè)VW是由若干個(gè)EC2（AWS上的虛擬主機(jī)）組成的集群。這樣可以靈活地根據(jù)不同workload，為不同用戶創(chuàng)建不同規(guī)格的VW，且用戶之間具備非常好的隔離性?；赩W的靈活性，Snowflake支持了VW auto suspend、resume以及auto scale能力，通過(guò)計(jì)算存儲(chǔ)分離帶來(lái)的彈性能力，給用戶帶來(lái)“pay-as-you-go”的使用體驗(yàn)。

四 AnalyticDB彈性模式

與Redshift類似，AnalyticDB最初也是基于傳統(tǒng)的MPP架構(gòu)來(lái)構(gòu)建的。2020年5月，AnalyticDB推出了計(jì)算存儲(chǔ)分離架構(gòu)的彈性模式。AnalyticDB彈性模式分為接入層、計(jì)算層、存儲(chǔ)層，其中接入層兼容了MySQL協(xié)議，包含了權(quán)限控制、優(yōu)化器、元數(shù)據(jù)、查詢調(diào)度等模塊，負(fù)責(zé)數(shù)據(jù)實(shí)時(shí)寫(xiě)入、查詢。

1 存儲(chǔ)層

在彈性架構(gòu)下，存儲(chǔ)層負(fù)責(zé)數(shù)據(jù)的實(shí)時(shí)寫(xiě)入、索引構(gòu)建、數(shù)據(jù)掃描、下推的謂詞計(jì)算（過(guò)濾、列裁剪、分區(qū)裁剪等），不再負(fù)責(zé)查詢的計(jì)算任務(wù)。數(shù)據(jù)在存儲(chǔ)層依然采用MPP的方式組織，數(shù)據(jù)以hash、random的方式在分區(qū)（shard）間均勻打散，以分區(qū)(shard)方式可以非常方便地實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)寫(xiě)入強(qiáng)一致，而在數(shù)據(jù)掃描的時(shí)候可以實(shí)現(xiàn)shard級(jí)的并發(fā)讀以保證并發(fā)。同時(shí)存儲(chǔ)層提供一體化的冷熱分層存儲(chǔ)能力，數(shù)據(jù)可以熱表的方式存在本地SSD、冷表的方式存儲(chǔ)在底層DFS，亦或是以冷熱混合表的形式存放，實(shí)現(xiàn)冷熱數(shù)據(jù)的自動(dòng)遷移，《數(shù)據(jù)倉(cāng)庫(kù)分層存儲(chǔ)技術(shù)揭秘》一文中有詳細(xì)介紹。

2 計(jì)算層

在彈性模式下，計(jì)算層由若干個(gè)計(jì)算節(jié)點(diǎn)組成，計(jì)算節(jié)點(diǎn)負(fù)責(zé)接收接入層下發(fā)的物理執(zhí)行計(jì)劃，并根據(jù)物理執(zhí)行計(jì)劃轉(zhuǎn)換成對(duì)應(yīng)的算子。計(jì)算層采用了vectorized的執(zhí)行模型，算子之間數(shù)據(jù)以pipeline的方式進(jìn)行交互，若干行（一般為幾千行）數(shù)據(jù)組成一個(gè)batch，batch內(nèi)部數(shù)據(jù)以列存的形式組織。此外，計(jì)算層的JIT模塊會(huì)根據(jù)查詢計(jì)劃，動(dòng)態(tài)生成代碼，加速計(jì)算，包括expression計(jì)算、排序、類型比較等。JIT模塊還以計(jì)劃的pattern為key，緩存動(dòng)態(tài)生成的代碼，以此減少交互式查詢下動(dòng)態(tài)生成代碼的代價(jià)。

3 執(zhí)行計(jì)劃

計(jì)算存儲(chǔ)分離架構(gòu)下，計(jì)算層新增了Resharding算子，負(fù)責(zé)從存儲(chǔ)層加載數(shù)據(jù)。數(shù)據(jù)以batch、列存的方式在存儲(chǔ)層與計(jì)算層之間傳遞，單次請(qǐng)求，會(huì)傳輸多個(gè)batch的數(shù)據(jù)，一般不大于32MB。由于存儲(chǔ)層依舊保留了MPP數(shù)據(jù)預(yù)分區(qū)的方式，優(yōu)化器在生成執(zhí)行計(jì)劃的時(shí)候會(huì)根據(jù)這個(gè)分布特征，在join、agg運(yùn)算時(shí)，減少不必要的數(shù)據(jù)repartition。此外，優(yōu)化器也會(huì)判斷查詢中的filter是否可利用存儲(chǔ)層索引，盡量把可被存儲(chǔ)層識(shí)別的filter下推至存儲(chǔ)層利用索引加速過(guò)濾，減少與計(jì)算層之間的數(shù)據(jù)傳輸。而不可被下推的filter依然保留在計(jì)算層進(jìn)行過(guò)濾。

4 分區(qū)動(dòng)態(tài)重分布

Resharding算子與Scan算子之間，分區(qū)（shard）遵循以下原則進(jìn)行重分布：

來(lái)自同一個(gè)存儲(chǔ)節(jié)點(diǎn)的多個(gè)分區(qū)，盡量打散到不同的計(jì)算節(jié)點(diǎn)上。
同一個(gè)查詢內(nèi)，不同表的相同分區(qū)，會(huì)被映射到相同的計(jì)算節(jié)點(diǎn)上。
同一個(gè)分區(qū)，在不同查詢之間，隨機(jī)分配到不同的計(jì)算節(jié)點(diǎn)。
與Snowflake、Redshift不同，計(jì)算節(jié)點(diǎn)與分區(qū)之間沒(méi)有固定的映射關(guān)系，因?yàn)橛?jì)算節(jié)點(diǎn)沒(méi)有本地的cache，數(shù)據(jù)訪問(wèn)的加速完全依賴于存儲(chǔ)層的SDD、內(nèi)存cache。這種動(dòng)態(tài)重分布的方式，可以大大緩解分區(qū)不均勻、分區(qū)內(nèi)數(shù)據(jù)傾斜等問(wèn)題，不會(huì)造成固定計(jì)算節(jié)點(diǎn)的熱點(diǎn)。

5 數(shù)據(jù)加載優(yōu)化

相比較于原有架構(gòu)，計(jì)算存儲(chǔ)分離多了一次遠(yuǎn)程的數(shù)據(jù)訪問(wèn)，這對(duì)查詢的延遲、吞吐會(huì)有比較大的影響。我們做了如下幾個(gè)方面的優(yōu)化：

合并網(wǎng)絡(luò)連接。如圖三所示，通過(guò)合并連接，減少小數(shù)據(jù)量查詢的網(wǎng)絡(luò)交互次數(shù)，降低查詢延遲。
數(shù)據(jù)壓縮。batch內(nèi)基于列存格式進(jìn)行壓縮，減少網(wǎng)絡(luò)帶寬的消耗，有效提升Resharding算子加載吞吐。
異步讀取。網(wǎng)絡(luò)模塊異步加載，將數(shù)據(jù)放入buffer中，Resharding算子從buffer中獲取數(shù)據(jù)，讓CPU、網(wǎng)絡(luò)IO充分并行。

6 性能測(cè)試

本節(jié)將探究計(jì)算存儲(chǔ)分離架構(gòu)對(duì)AnalyticDB大數(shù)據(jù)量分析場(chǎng)景的查詢吞吐影響。

測(cè)試環(huán)境

實(shí)例1：不分離模式，4組存儲(chǔ)節(jié)點(diǎn)，存儲(chǔ)節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)掃描、查詢計(jì)算。
實(shí)例2：彈性模式，4組存儲(chǔ)節(jié)點(diǎn) + 6個(gè)計(jì)算節(jié)點(diǎn)。存儲(chǔ)節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)掃描，計(jì)算節(jié)點(diǎn)負(fù)責(zé)查詢計(jì)算。兩個(gè)實(shí)例分別導(dǎo)入tpch 1TB數(shù)據(jù)作為測(cè)試數(shù)據(jù)集。

測(cè)試場(chǎng)景

我們選取TPCH Q1作為測(cè)試SQL，Q1為單表聚合查詢，具備非常高的收斂度，存儲(chǔ)層與計(jì)算層之間傳輸?shù)臄?shù)據(jù)量約為260GB。我們以單并發(fā)順序執(zhí)行的方式，執(zhí)行TPCH Q1，取查詢的平均執(zhí)行時(shí)間。

select        l_returnflag,        l_linestatus,        sum(l_quantity) as sum_qty,        sum(l_extendedprice) as sum_base_price,        sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,        sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,        avg(l_quantity) as avg_qty,        avg(l_extendedprice) as avg_price,        avg(l_discount) as avg_disc,        count(*) as count_orderfrom        lineitemwhere        l_shipdate <= date '1998-12-01' - interval '120' daygroup by        l_returnflag,        l_linestatusorder by        l_returnflag,        l_linestatus; 

測(cè)試數(shù)據(jù)

測(cè)試結(jié)論

從上面的測(cè)試數(shù)據(jù)可以看到，TPCH Q1在彈性模式的執(zhí)行時(shí)間略好。粗看這個(gè)結(jié)果比較驚訝，計(jì)算存儲(chǔ)分離后，性能更好了。我們可以仔細(xì)分析下，彈性模式與不分離模式具有相同的存儲(chǔ)節(jié)點(diǎn)數(shù)，確保分離模式存儲(chǔ)節(jié)點(diǎn)不會(huì)成為瓶頸。從執(zhí)行時(shí)的資源消耗來(lái)看，分離模式的總資源消耗（19.5% + 97%）是不分離模式（98%）的1.19倍，這多消耗的CPU來(lái)自于網(wǎng)絡(luò)傳輸、序列化、反序列化等。對(duì)于計(jì)算層來(lái)說(shuō)，只要存儲(chǔ)層能夠提供足夠的數(shù)據(jù)吞吐，確保計(jì)算層的CPU能夠打滿，那么計(jì)算存儲(chǔ)分離不會(huì)降低查詢的處理吞吐，當(dāng)然相比于不分離模式，會(huì)多消耗資源。

五 總結(jié)

在AnalyticDB彈性模式的基礎(chǔ)之上，未來(lái)我們會(huì)進(jìn)一步去深耕我們的彈性能力，包括計(jì)算資源池化、按需彈性能力、存儲(chǔ)層基于共享存儲(chǔ)的快速擴(kuò)縮容能力。通過(guò)這些彈性能力，更好滿足客戶對(duì)于云數(shù)據(jù)倉(cāng)庫(kù)的訴求，也進(jìn)一步降低客戶的使用成本。

參考文獻(xiàn)
[1] https://levelup.gitconnected.com/snowflake-vs-redshift-ra3-the-need-for-more-than-just-speed-52e954242715
[2] https://www.snowflake.com/
[3] https://databricks.com/session/taking-advantage-of-a-disaggregated-storage-and-compute-architecture
[4] Dageville B , Cruanes T , Zukowski M , et al. The Snowflake Elastic Data Warehouse.[C]// ACM. ACM, 2016.
[5] Gupta A , Agarwal D , Tan D , et al. Amazon Redshift and the Case for Simpler Data Warehouses[C]// Acm Sigmod International Conference. ACM, 2015.
[6] Vuppalapati M, Miron J, Agarwal R, et al. Building an elastic query engine on disaggregated storage[C]//17th {USENIX} Symposium on Networked Systems Design and Implementation ({NSDI} 20). 2020: 449-462.