10倍性能提升！DLA SQL推出基于Alluxio的資料湖分析加速功能

背景

在資料上雲的大背景下，随着網絡和存儲硬體能力的提升，存儲計算分離逐漸成為了大資料處理的一大趨勢。相比于存儲和計算耦合的架構，存儲計算分離可以帶來許多好處，例如允許獨立擴充計算和存儲、提高資源的使用率、提高業務的靈活性等等。特别是，借助雲上的基礎設施，存儲可以選擇便宜的對象存儲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的送出政策是這樣的：

1. 通過split的hash值确定split的首選worker和備選worker。
2. 如果首選worker空閑，則送出到首選worker。
3. 如果首選worker繁忙，則送出到備選worker。
4. 如果備選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中，我們是這樣做的：

1. 調大node-scheduler.max-splits-per-node的值，使更多的split可以命中緩存。
2. 修改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密集型的，是以我們隻從中挑選出符合如下兩個标準的查詢來做比較：

1. 查詢中包含了對最大的表lineitem的掃描，這樣掃描的資料量足夠大，IO有可能成為瓶頸。
2. 查詢中不涉及多個表的join操作，這樣就不會有大資料量參與計算，因而計算不會先于IO而成為瓶頸。

按照這兩個标準，我們選擇了對lineitem單個表進行查詢的Q1和Q6，以及lineitem和另一個表進行join操作的Q4、Q12、Q14、Q15、Q17、Q19和Q20。

測試結果如下：

如何使用

目前緩存特性隻在CU版提供，新購買的叢集自動開通對oss、hdfs資料源的緩存能力。已有叢集可以聯系我們更新到最新版本。關于CU的開通和使用可以參考我們的

幫助文檔

。

我們現在還有一進制1000CU時的優惠套餐，歡迎試用。

點選購買套餐

總結與展望

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

使用者福利

現在活動期間，使用者1元首購原價315元的DLA 1000CU時資源包，

歡迎大家關注我們的釘釘群擷取最新的資訊: