雲資料倉庫的未來趨勢：計算儲存分離

一 背景

隨著雲時代的到來，資料庫也開始擁抱雲資料庫時代，各類資料庫系統（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_orderfrom lineitemwhere l_shipdate <= date '1998-12-01' - interval '120' daygroup by l_returnflag, l_linestatusorder by l_returnflag, l_linestatus;

測試資料

測試結論

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

五 總結

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

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

作者 | 尚春

本文為阿里雲原創內容，未經允許不得轉載。