背景
在數據上雲的大背景下，隨着網絡和存儲硬件能力的提升，存儲計算分離逐漸成爲了大數據處理的一大趨勢。相比於存儲和計算耦合的架構，存儲計算分離可以帶來許多好處，例如允許獨立擴展計算和存儲、提高資源的利用率、提高業務的靈活性等等。特別是，藉助雲上的基礎設施，存儲可以選擇便宜的對象存儲OSS，計算資源可以按需付費和彈性擴縮容，這些都使得存儲計算分離架構可以很好的發揮雲計算的成本優勢和靈活性。
但是在存儲計算分離的場景下，通過網絡從遠端存儲讀取數據仍然是一個代價較大的操作，往往會帶來性能的損耗。以OSS爲例，OSS數據讀取延時通常較本地磁盤大很多，同時OSS對單個用戶使用的帶寬上限做了限制，這都會對數據分析的延時造成影響。在雲原生數據湖分析（DLA）SQL引擎中，我們通過引入本地緩存機制，將熱數據緩存在本地磁盤，拉近數據和計算的距離，減少從遠端讀取數據帶來的延時和IO限制，實現更小的查詢延時和更高的吞吐。
DLA SQL引擎基於彈性的Presto，採取計算與存儲完全分離的架構，支持對用戶存儲在OSS、HDFS等介質上的各種文件格式進行Adhoc查詢、BI分析、輕量級ETL等數據分析工作。此次推出數據湖分析加速，DLA與開源大規模數據編排系統廠商Alluxio合作，藉助Alluxio提供的緩存加速能力，解決存儲計算分離場景下從遠端讀取數據帶來的性能損耗。未來雙方將繼續在數據湖技術領域開展全方位合作，爲客戶提供一站式、高效的數據湖分析與計算服務。
DLA SQL數據湖分析加速方案
基於Alluxio的緩存加速原理
架構
在DLA SQL引擎中，負責從遠端數據源讀取數據的角色是Worker節點。因此，一個自然的想法就是在Worker節點緩存熱數據，來實現查詢加速的效果。如下圖所示：
這裏主要的挑戰是在大數據量場景下面如何提高緩存的效率，包括：如何快速定位和讀取緩存數據，如何提高緩存命中率，如何快速從遠端加載緩存數據等。爲了解決這些問題，在單機層面，我們使用Alluxio來實現對緩存的管理，藉助Alluxio提供的能力，提高緩存的效率；而在系統層面，使用SOFT_AFFINITY提交策略在worker和數據之間建立對應關係，使得同一段數據（大概率）總是在同一個worker上面讀取，從而提高緩存的命中率。
SOFT_AFFINITY提交策略
Presto默認的split提交策略是NO_PREFERENCE，在這種策略下面，主要考慮的因素是worker的負載，因此某個split會被分到哪個worker上面很大程度上是隨機的。而在緩存的場景裏面則需要考慮“數據本地化”的因素，如果一個split總是被提交到同一個worker上面，對提高緩存效率會很有幫助。
因此，在DLA SQL中，我們使用SOFT_AFFINITY提交策略。在提交Hive的split時，會通過計算split的hash值，儘可能將同一個split提交到同一個worker上面。如下圖所示。
使用SOFT_AFFINITY策略時，split的提交策略是這樣的：
- 通過split的hash值確定split的首選worker和備選worker。
- 如果首選worker空閒，則提交到首選worker。
- 如果首選worker繁忙，則提交到備選worker。
- 如果備選worker也繁忙，則提交到最不繁忙的worker。
如下圖：
這裏面，“繁忙”的判斷根據如下兩個參數來確定：
- node-scheduler.max-splits-per-node參數用來控制每個worker上面最大可以提交多少個split，默認是100。超出這個值則判定這個worker繁忙。
- node-scheduler.max-pending-splits-per-task用來控制每個worker上面最多可以有多少個split處於Pending狀態。超出這個值則判定這個worker繁忙。
通過這樣的判斷，可以兼顧數據本地化和worker的負載，避免因爲split的hash不均勻造成worker之間的負載不平衡，也不會因爲某個worker特別慢而導致查詢整體變慢。
Alluxio緩存管理
在Worker上面，我們基於Alluxio Local Cache來對緩存進行管理。 Local Cache是一個嵌入在Presto進程中的庫，通過接口調用的方式和Presto通信。和使用Alluxio集羣相比，Local Cache模式下Presto調用Alluxio帶來的成本更小，同時Local Cache具備完整的緩存管理的功能，包括緩存的加載、淘汰、元數據管理和監控。此外，Alluxio支持緩存的併發異步寫入，支持緩存的併發讀取，這些都對提高緩存效率有很好的幫助。
Alluxio對外暴露的是一個標準的HDFS接口，因此Cache的管理對Presto是透明的。在這個接口內部，當用戶查詢需要訪問OSS數據源時，如果數據存在於本地緩存中，就會直接從緩存讀取數據，加速查詢；如果沒有命中緩存，就會直接從OSS讀取數據（並異步寫入到本地磁盤）。
DLA中的進一步優化
提高緩存命中率
爲了實現更高的緩存命中率，我們主要做了兩方面的工作：
- 在成本允許的範圍內儘量調大用於緩存加速的磁盤空間。
- 提高數據“本地化”的比例。
前者很好理解，這裏重點介紹後者。
我們分析前面講的SOFT_AFFINITY提交策略就會發現，如果查詢進入“繁忙”的狀態，split就會回退到和NO_PREFERENCE一樣的隨機提交，這種情況下數據“本地化”的比例肯定會降低，因此關鍵是要儘量避免“繁忙”。但是如果簡單調大“繁忙”的閾值，又可能造成worker負載不均勻，cache帶來的性能提升被長尾效應喫掉了。
在DLA中，我們是這樣做的：
- 調大node-scheduler.max-splits-per-node的值，使更多的split可以命中緩存。
- 修改HiveSplit的hash算法，在計算hash值時不僅使用文件名，也使用split在文件中的位置，這樣就可以避免大文件被hash到一個worker上面，split的hash值天然就會有比較均勻的分佈。
提高磁盤吞吐
除了緩存命中率，提高緩存效率的另一個關鍵點是緩存的讀寫速度。在基於磁盤的緩存方案裏面，實現這個目標的一個重要部分就是提高磁盤的吞吐性能。
在DLA中，我們使用高效雲盤來作爲緩存的數據盤。背後的考慮是我們把緩存加速特性作爲CU版的內置產品能力，不額外收取費用，這就要求緩存引入的成本在CU的總成本中佔比要足夠小，所以我們不能使用價格昂貴的SSD盤。從成本出發，使用高效雲盤是必然的選擇，但是這樣就需要解決高效雲盤單盤吞吐低的問題。
我們通過使用多塊盤並在緩存寫入時打散來實現更高的吞吐，這樣就彌補了雲盤吞吐不足的問題。目前DLA中的配置，實測單機讀寫吞吐均可達到接近600MB/s，在降低成本的同時仍然提供了很好的讀寫性能。
性能測試
我們針對社區版本prestodb和DLA做了性能對比測試。社區版本我們選擇了prestodb 0.228版本，並通過複製jar包以及修改配置的方式增加對oss數據源的支持。我們分別對DLA-SQL CU版256核1024GB、512核2048GB、768核3072GB三種規格與同等算力的社區版本集羣進行了對比。
測試的查詢我們選擇TPC-H 1TB數據測試集。由於TPC-H的大部分查詢並不是IO密集型的，所以我們只從中挑選出符合如下兩個標準的查詢來做比較：
- 查詢中包含了對最大的表lineitem的掃描，這樣掃描的數據量足夠大，IO有可能成爲瓶頸。
- 查詢中不涉及多個表的join操作，這樣就不會有大數據量參與計算，因而計算不會先於IO而成爲瓶頸。
按照這兩個標準，我們選擇了對lineitem單個表進行查詢的Q1和Q6，以及lineitem和另一個表進行join操作的Q4、Q12、Q14、Q15、Q17、Q19和Q20。
測試結果如下：
如何使用
目前緩存特性只在CU版提供，新購買的集羣自動開通對oss、hdfs數據源的緩存能力。已有集羣可以聯繫我們升級到最新版本。關於CU的開通和使用可以參考我們的幫助文檔。
總結與展望
緩存加速特性通過將熱數據緩存在本地磁盤，提供更小的查詢延時和更高的吞吐，對IO密集的查詢有很好的加速效果。在雲上普遍計算和存儲分離的場景中，緩存一定還具有更廣闊的應用場景。未來我們會進一步探索緩存在Maxcompute等其他數據源和場景的使用，爲更多類型的數據讀取和計算做加速，提供更好的查詢性能。
本文爲阿里雲原創內容，未經允許不得轉載。