作者 | 尚春
來源 | 阿裡技術公衆号
一 背景
随着雲時代的到來，資料庫也開始擁抱雲資料庫時代，各類資料庫系統（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彈性模式的基礎之上，未來我們會進一步去深耕我們的彈性能力，包括計算資源池化、按需彈性能力、存儲層基于共享存儲的快速擴縮容能力。通過這些彈性能力，更好滿足客戶對于雲資料倉庫的訴求，也進一步降低客戶的使用成本。
關于我們
AnalyticDB MySQL是阿裡巴巴自主研發，經過超大規模以及核心業務驗證的PB級實時OLAP資料倉庫。AnalyticDB MySQL彈性分析團隊緻力打造雲原生的計算引擎，提供極緻的彈性、性能體驗，包括了在離線一體化、超大規模、向量化模型、JIT等技術。歡迎投遞履歷到 [email protected]，期待與你共同打造世界一流的雲原生資料倉庫。
工作地：北京、杭州、深圳
參考文獻
[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.
免費領取電子書
《雲原生消息隊列Apache RocketMQ》
消息服務作為應用的通信基礎設施，是微服務架構應用的核心依賴，通過消息服務能夠讓使用者很容易架構出分布式的、高性能的、彈性的應用程式。傳統的消息中間件如何持續進化為雲原生的消息服務？本書将為你詳細解答。
掃碼加阿裡妹好友，回複“雲消息”擷取吧~(若掃碼無效，可直接添加alimei4、alimei5、alimei6、alimei7)