IO的優化一般由如下幾個方面：

• 根據業務場景使用壓縮率更高的演算法，在IO和CPU直接做平衡，例如使用 ZSTD
• 更少的數據讀取，例如在分析場景使用列式存儲
• 提高IO速度,硬體方面可以從 RAM,SSD,OPTANE 等硬體加速，網卡則可以使用雙萬兆網卡
• 提高數據讀取的本地性，減少網路IO
• 分散式計算中使用RDMA技術，大幅減少額外開銷
• 其他

1.2 計算&存儲分離

（1）混合部署

一般來說，為了獲取更好的數據本地性，我們會將 datanode 與 nodemanager 混合部署，這就意味著相同的一塊硬碟需要同時承擔 HDFS讀寫 / Spark中間數據(shuffle)讀寫等負載，任務運行時間在一定程度上是不可控的，同時也會影響計算效率。

（2）分離部署

缺點：

• 不存在數據本地性，所有分析數據需要從遠程獲取

優點：

• 計算/存儲節點不需要強耦合（不會僅僅因為存儲空間不足而擴容計算節點）
• 考慮到雲服務商能力的不斷增強，甚至可以考慮業務高峰動態擴容
• Spark on k8s 等趨勢，可以快速部署

可以發現，分離部署的性能瓶頸主要存在於沒有數據本地性，所有的數據都要從遠程存儲讀取。這種場景下可以嘗試將 Alluxio 與 計算節點混合部署，同時將遠程存儲掛載在Alluxio上。熱數據第一次從遠程讀取後，可以在本地進行備份（RAM/SSD/HDD），下一次讀取將可以從 local 或者 local remote 直接讀取。再配合LRU或LFU等策略，不斷地將熱數據置換到上層存儲，冷數據則逐漸不存儲在計算節點。

二、測試

2.1 環境

• Alluxio 1.8.1
• Spark 2.4.0
• CDH 5.15
• Spark-SQL-Perf

nodemanager / alluxio / datanode 混合部署，Alluxio 每個節點分配10G內存，單副本緩存，hdfs 使用3副本。

2.2 理論性能提升

在沒有其餘任務干擾的情況下，HDFS 數據本地性應是 Alluxio 的3倍左右，Alluxio 沒有命中本地數據的讀取速度是 HDFS 的 2.5 倍左右。

2.3 Scan

對 24GBparquet.snappy數據進行單欄位 filter

Alluxio數據本地性5%，HDFS 數據本地性 16.5%

2.4 Presto

Presto 本地沒有部署 Alluxio (所有數據通過網路傳輸)

• 6 Presto worker
• -xmx 20GB
• query.max.memory=100GB
• query.max-memory-per-node=5GB

結果

相同SQL，連續執行5次

（1）千萬級表

tableA 1.2G (2千萬)

（2）億級表

tableB 900G (45億)

2.5 TPC-DS

為模擬真實環境，在任務高峰期同時運行兩任務，運行時可能會受其他任務影響，影響因素主要是磁碟IO和網路IO。

使用Spark-SQL-Perf 使用工具進行測試

• executor.nums 40
• executor.cores 3
• executor.memory 8g
• executor.memoryOverhead 2g

結果

前11個查詢耗時對比

在所有的99個查詢中

• HDFS 平均運行時間：40.6s
• Alluxio 平均運行時間: 28.3s

三、總結

• Scan ，Alluxio 提升 2.5x
• Presto ，Alluxio 提升 2x
• TPC-DS ，Alluxio 平均提升 1.4x
• Alluxio 多次測試結果比較穩定，HDFS的波動則比較大，參考 Presto 測試結果

在整個測試中，Alluxio 使用單副本緩存，本地命中率並不高（5%），讀取速度主要取決於網路IO。HDFS 雖然有三備份，不過數據從磁碟讀取時可能會受到其他任務的干擾，因此速度不太穩定。

四、落地相關

Alluxio 的落地非常依賴場景，否則優化效果並不明顯（無法發揮內存讀取的優勢）。

1. 存儲計算分離
2. 有明顯熱表/熱數據
3. 多數據中心訪問加速
4. 相同數據被單應用多次訪問
5. 數據並發訪問

展望Alluxio 2.0，下個版本的 Alluxio 有很多重大的更新，可以持續關注。

推薦閱讀：