[[401883]]

一、背景

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

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

二、為什么要計算存儲分離

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

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

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

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

三、業界趨勢

1.Redshift

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

2.Snowflake

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

四、AnalyticDB彈性模式

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

1.存儲層

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

2.計算層

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

3.執行計劃

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

4.分區動態重分布

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

• 來自同一個存儲節點的多個分區，盡量打散到不同的計算節點上。

• 同一個查詢內，不同表的相同分區，會被映射到相同的計算節點上。

• 同一個分區，在不同查詢之間，隨機分配到不同的計算節點。

與Snowflake、Redshift不同，計算節點與分區之間沒有固定的映射關系，因為計算節點沒有本地的cache，數據訪問的加速完全依賴于存儲層的SDD、內存cache。這種動態重分布的方式，可以大大緩解分區不均勻、分區內數據傾斜等問題，不會造成固定計算節點的熱點。

5.數據加載優化

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

• 合并網絡連接。如圖三所示，通過合并連接，減少小數據量查詢的網絡交互次數，降低查詢延遲。

• 數據壓縮。batch內基于列存格式進行壓縮，減少網絡帶寬的消耗，有效提升Resharding算子加載吞吐。

• 異步讀取。網絡模塊異步加載，將數據放入buffer中，Resharding算子從buffer中獲取數據，讓CPU、網絡IO充分并行。

6.性能測試

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

測試環境

• 實例1：不分離模式，4組存儲節點，存儲節點負責數據掃描、查詢計算。

• 實例2：彈性模式，4組存儲節點 + 6個計算節點。存儲節點負責數據掃描，計算節點負責查詢計算。兩個實例分別導入tpch 1TB數據作為測試數據集。

測試場景

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

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_order 
from 
        lineitem 
where 
        l_shipdate <= date '1998-12-01' - interval '120' day 
group by 
        l_returnflag, 
        l_linestatus 
order by 
        l_returnflag, 
        l_linestatus; 

測試數據

測試結論

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

五、總結

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