簡介： 隨着雲時代的到來，數據庫也開始擁抱雲數據庫時代，各類數據庫系統在各內外雲平台百花齊放，有開源的MySQL、PostgreSQL、MongoDB，傳統數據庫廠商的SQLServer、Oracle，雲廠商自研的Aurora、Redshift、PolarDB、AnalyticDB、AzureSQL等
作者 | 尚春
來源 | 阿里技術公眾號
一 背景
隨着雲時代的到來，數據庫也開始擁抱雲數據庫時代，各類數據庫系統（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彈性模式的基礎之上，未來我們會進一步去深耕我們的彈性能力，包括計算資源池化、按需彈性能力、存儲層基於共享存儲的快速擴縮容能力。通過這些彈性能力，更好滿足客戶對於雲數據倉庫的訴求，也進一步降低客戶的使用成本。
參考文獻[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.
本文為阿里雲原創內容，未經允許不得轉載。