簡介：在存儲計算分離的場景下，通過網(wǎng)絡(luò)從遠(yuǎn)端存儲讀取數(shù)據(jù)是一個代價較大的操作，往往會帶來性能的損耗。以O(shè)SS為例，OSS數(shù)據(jù)讀取延時通常較本地磁盤大很多，同時OSS對單個用戶使用的帶寬上限做了限制，這都會對數(shù)據(jù)分析的延時造成影響。在云原生數(shù)據(jù)湖分析（DLA）SQL引擎中，我們通過引入本地緩存機(jī)制，將熱數(shù)據(jù)緩存在本地磁盤，拉近數(shù)據(jù)和計算的距離，減少從遠(yuǎn)端讀取數(shù)據(jù)帶來的延時和IO限制，實現(xiàn)更小的查詢延時和更高的吞吐。

背景

在數(shù)據(jù)上云的大背景下，隨著網(wǎng)絡(luò)和存儲硬件能力的提升，存儲計算分離逐漸成為了大數(shù)據(jù)處理的一大趨勢。相比于存儲和計算耦合的架構(gòu)，存儲計算分離可以帶來許多好處，例如允許獨(dú)立擴(kuò)展計算和存儲、提高資源的利用率、提高業(yè)務(wù)的靈活性等等。特別是，借助云上的基礎(chǔ)設(shè)施，存儲可以選擇便宜的對象存儲OSS，計算資源可以按需付費(fèi)和彈性擴(kuò)縮容，這些都使得存儲計算分離架構(gòu)可以很好的發(fā)揮云計算的成本優(yōu)勢和靈活性。

但是在存儲計算分離的場景下，通過網(wǎng)絡(luò)從遠(yuǎn)端存儲讀取數(shù)據(jù)仍然是一個代價較大的操作，往往會帶來性能的損耗。以O(shè)SS為例，OSS數(shù)據(jù)讀取延時通常較本地磁盤大很多，同時OSS對單個用戶使用的帶寬上限做了限制，這都會對數(shù)據(jù)分析的延時造成影響。在云原生數(shù)據(jù)湖分析（DLA）SQL引擎中，我們通過引入本地緩存機(jī)制，將熱數(shù)據(jù)緩存在本地磁盤，拉近數(shù)據(jù)和計算的距離，減少從遠(yuǎn)端讀取數(shù)據(jù)帶來的延時和IO限制，實現(xiàn)更小的查詢延時和更高的吞吐。

DLA SQL引擎基于彈性的Presto，采取計算與存儲完全分離的架構(gòu)，支持對用戶存儲在OSS、HDFS等介質(zhì)上的各種文件格式進(jìn)行Adhoc查詢、BI分析、輕量級ETL等數(shù)據(jù)分析工作。此次推出數(shù)據(jù)湖分析加速，DLA與開源大規(guī)模數(shù)據(jù)編排系統(tǒng)廠商Alluxio合作，借助Alluxio提供的緩存加速能力，解決存儲計算分離場景下從遠(yuǎn)端讀取數(shù)據(jù)帶來的性能損耗。未來雙方將繼續(xù)在數(shù)據(jù)湖技術(shù)領(lǐng)域開展全方位合作，為客戶提供一站式、高效的數(shù)據(jù)湖分析與計算服務(wù)。

DLA SQL數(shù)據(jù)湖分析加速方案

基于Alluxio的緩存加速原理

架構(gòu)

在DLA SQL引擎中，負(fù)責(zé)從遠(yuǎn)端數(shù)據(jù)源讀取數(shù)據(jù)的角色是Worker節(jié)點(diǎn)。因此，一個自然的想法就是在Worker節(jié)點(diǎn)緩存熱數(shù)據(jù)，來實現(xiàn)查詢加速的效果。如下圖所示：

這里主要的挑戰(zhàn)是在大數(shù)據(jù)量場景下面如何提高緩存的效率，包括：如何快速定位和讀取緩存數(shù)據(jù)，如何提高緩存命中率，如何快速從遠(yuǎn)端加載緩存數(shù)據(jù)等。為了解決這些問題，在單機(jī)層面，我們使用Alluxio來實現(xiàn)對緩存的管理，借助Alluxio提供的能力，提高緩存的效率；而在系統(tǒng)層面，使用SOFT_AFFINITY提交策略在worker和數(shù)據(jù)之間建立對應(yīng)關(guān)系，使得同一段數(shù)據(jù)（大概率）總是在同一個worker上面讀取，從而提高緩存的命中率。

SOFT_AFFINITY提交策略

Presto默認(rèn)的split提交策略是NO_PREFERENCE，在這種策略下面，主要考慮的因素是worker的負(fù)載，因此某個split會被分到哪個worker上面很大程度上是隨機(jī)的。而在緩存的場景里面則需要考慮“數(shù)據(jù)本地化”的因素，如果一個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。

如下圖：

這里面，“繁忙”的判斷根據(jù)如下兩個參數(shù)來確定：

• node-scheduler.max-splits-per-node參數(shù)用來控制每個worker上面最大可以提交多少個split，默認(rèn)是100。超出這個值則判定這個worker繁忙。
• node-scheduler.max-pending-splits-per-task用來控制每個worker上面最多可以有多少個split處于Pending狀態(tài)。超出這個值則判定這個worker繁忙。

通過這樣的判斷，可以兼顧數(shù)據(jù)本地化和worker的負(fù)載，避免因為split的hash不均勻造成worker之間的負(fù)載不平衡，也不會因為某個worker特別慢而導(dǎo)致查詢整體變慢。

Alluxio緩存管理

在Worker上面，我們基于Alluxio Local Cache來對緩存進(jìn)行管理。 Local Cache是一個嵌入在Presto進(jìn)程中的庫，通過接口調(diào)用的方式和Presto通信。和使用Alluxio集群相比，Local Cache模式下Presto調(diào)用Alluxio帶來的成本更小，同時Local Cache具備完整的緩存管理的功能，包括緩存的加載、淘汰、元數(shù)據(jù)管理和監(jiān)控。此外，Alluxio支持緩存的并發(fā)異步寫入，支持緩存的并發(fā)讀取，這些都對提高緩存效率有很好的幫助。
Alluxio對外暴露的是一個標(biāo)準(zhǔn)的HDFS接口，因此Cache的管理對Presto是透明的。在這個接口內(nèi)部，當(dāng)用戶查詢需要訪問OSS數(shù)據(jù)源時，如果數(shù)據(jù)存在于本地緩存中，就會直接從緩存讀取數(shù)據(jù)，加速查詢；如果沒有命中緩存，就會直接從OSS讀取數(shù)據(jù)（并異步寫入到本地磁盤）。

DLA中的進(jìn)一步優(yōu)化

提高緩存命中率

為了實現(xiàn)更高的緩存命中率，我們主要做了兩方面的工作：

• 在成本允許的范圍內(nèi)盡量調(diào)大用于緩存加速的磁盤空間。
• 提高數(shù)據(jù)“本地化”的比例。

前者很好理解，這里重點(diǎn)介紹后者。

我們分析前面講的SOFT_AFFINITY提交策略就會發(fā)現(xiàn)，如果查詢進(jìn)入“繁忙”的狀態(tài)，split就會回退到和NO_PREFERENCE一樣的隨機(jī)提交，這種情況下數(shù)據(jù)“本地化”的比例肯定會降低，因此關(guān)鍵是要盡量避免“繁忙”。但是如果簡單調(diào)大“繁忙”的閾值，又可能造成worker負(fù)載不均勻，cache帶來的性能提升被長尾效應(yīng)吃掉了。
在DLA中，我們是這樣做的：

調(diào)大node-scheduler.max-splits-per-node的值，使更多的split可以命中緩存。

修改HiveSplit的hash算法，在計算hash值時不僅使用文件名，也使用split在文件中的位置，這樣就可以避免大文件被hash到一個worker上面，split的hash值天然就會有比較均勻的分布。

提高磁盤吞吐

除了緩存命中率，提高緩存效率的另一個關(guān)鍵點(diǎn)是緩存的讀寫速度。在基于磁盤的緩存方案里面，實現(xiàn)這個目標(biāo)的一個重要部分就是提高磁盤的吞吐性能。
在DLA中，我們使用高效云盤來作為緩存的數(shù)據(jù)盤。背后的考慮是我們把緩存加速特性作為CU版的內(nèi)置產(chǎn)品能力，不額外收取費(fèi)用，這就要求緩存引入的成本在CU的總成本中占比要足夠小，所以我們不能使用價格昂貴的SSD盤。從成本出發(fā)，使用高效云盤是必然的選擇，但是這樣就需要解決高效云盤單盤吞吐低的問題。
我們通過使用多塊盤并在緩存寫入時打散來實現(xiàn)更高的吞吐，這樣就彌補(bǔ)了云盤吞吐不足的問題。目前DLA中的配置，實測單機(jī)讀寫吞吐均可達(dá)到接近600MB/s，在降低成本的同時仍然提供了很好的讀寫性能。

性能測試

我們針對社區(qū)版本prestodb和DLA做了性能對比測試。社區(qū)版本我們選擇了prestodb 0.228版本，并通過復(fù)制jar包以及修改配置的方式增加對oss數(shù)據(jù)源的支持。我們分別對DLA-SQL CU版256核1024GB、512核2048GB、768核3072GB三種規(guī)格與同等算力的社區(qū)版本集群進(jìn)行了對比。

測試的查詢我們選擇TPC-H 1TB數(shù)據(jù)測試集。由于TPC-H的大部分查詢并不是IO密集型的，所以我們只從中挑選出符合如下兩個標(biāo)準(zhǔn)的查詢來做比較：

查詢中包含了對最大的表lineitem的掃描，這樣掃描的數(shù)據(jù)量足夠大，IO有可能成為瓶頸。

查詢中不涉及多個表的join操作，這樣就不會有大數(shù)據(jù)量參與計算，因而計算不會先于IO而成為瓶頸。

按照這兩個標(biāo)準(zhǔn)，我們選擇了對lineitem單個表進(jìn)行查詢的Q1和Q6，以及l(fā)ineitem和另一個表進(jìn)行join操作的Q4、Q12、Q14、Q15、Q17、Q19和Q20。

測試結(jié)果如下：

如何使用

目前緩存特性只在CU版提供，新購買的集群自動開通對oss、hdfs數(shù)據(jù)源的緩存能力。已有集群可以聯(lián)系我們升級到最新版本。關(guān)于CU的開通和使用可以參考我們的幫助文檔。
我們現(xiàn)在還有一元1000CU時的優(yōu)惠套餐，歡迎試用。點(diǎn)擊購買套餐

總結(jié)與展望

緩存加速特性通過將熱數(shù)據(jù)緩存在本地磁盤，提供更小的查詢延時和更高的吞吐，對IO密集的查詢有很好的加速效果。在云上普遍計算和存儲分離的場景中，緩存一定還具有更廣闊的應(yīng)用場景。未來我們會進(jìn)一步探索緩存在Maxcompute等其他數(shù)據(jù)源和場景的使用，為更多類型的數(shù)據(jù)讀取和計算做加速，提供更好的查詢性能。

用戶福利

現(xiàn)在活動期間，用戶1元首購原價315元的DLA 1000CU時資源包，點(diǎn)擊購買套餐
歡迎大家關(guān)注我們的釘釘群獲取最新的信息:

原文鏈接：https://developer.aliyun.com/article/781291?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的10倍性能提升！DLA SQL推出基于Alluxio的数据湖分析加速功能的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。