[[403506]]

一 背景

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

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

二 為什么要計算存儲分離

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

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

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

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

三 業(yè)界趨勢

1 Redshift

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

2 Snowflake

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

四 AnalyticDB彈性模式

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

1 存儲層

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

2 計算層

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

3 執(zhí)行計劃

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

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

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

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

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

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

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

6 性能測試

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

測試環(huán)境

實例1：不分離模式，4組存儲節(jié)點，存儲節(jié)點負責數(shù)據(jù)掃描、查詢計算。
實例2：彈性模式，4組存儲節(jié)點 + 6個計算節(jié)點。存儲節(jié)點負責數(shù)據(jù)掃描，計算節(jié)點負責查詢計算。兩個實例分別導入tpch 1TB數(shù)據(jù)作為測試數(shù)據(jù)集。

測試場景

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

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; 

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

測試結論

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

五 總結

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

參考文獻
[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.