這篇博客探討了在數(shù)據(jù)平臺(tái)上使用Alluxio的幾點(diǎn)優(yōu)勢(shì)，主要從如下方面介紹：

1 計(jì)算-存儲(chǔ)解耦架構(gòu)興起的趨勢(shì)

2 Alluxio如何加速計(jì)算-存儲(chǔ)解耦架構(gòu)中數(shù)據(jù)訪問

3 通過運(yùn)行SparkSQL workload展現(xiàn)Alluxio的優(yōu)勢(shì)

動(dòng)機(jī)

計(jì)算-存儲(chǔ)緊耦架構(gòu)是一種在數(shù)據(jù)存儲(chǔ)的節(jié)點(diǎn)上進(jìn)行計(jì)算的架構(gòu)，這種架構(gòu)解決了計(jì)算引擎的數(shù)據(jù)需求，但維持這種緊耦結(jié)合的架構(gòu)需要一定代價(jià)，這往往超出了其帶來的性能提升。隨著云計(jì)算的興起，獨(dú)立擴(kuò)展計(jì)算和存儲(chǔ)的成本和維護(hù)代價(jià)更低。

另外，數(shù)據(jù)已經(jīng)成為一種新型的珍貴資源，所有現(xiàn)代組織都在試圖獲取盡可能多的數(shù)據(jù)，而數(shù)據(jù)存儲(chǔ)階段往往早于發(fā)掘數(shù)據(jù)價(jià)值階段，所以存儲(chǔ)計(jì)算的緊耦合是不切實(shí)際的。計(jì)算-存儲(chǔ)范式的顛倒使很多數(shù)據(jù)平臺(tái)陷入困境，強(qiáng)迫他們?cè)谛阅?，成本和靈活性之間進(jìn)行權(quán)衡。Alluixo解決了這一兩難困境，它提供了一種計(jì)算存儲(chǔ)解耦架構(gòu)，其性能與計(jì)算-存儲(chǔ)緊耦合架構(gòu)相同，并且更加靈活。

[[226316]]

Alluxio是如何發(fā)揮作用的

當(dāng)Alluxio在計(jì)算節(jié)點(diǎn)上或靠近計(jì)算節(jié)點(diǎn)的位置運(yùn)行時(shí)，Alluxio通過提供靠近計(jì)算端的緩存來實(shí)現(xiàn)性能提升。應(yīng)用和計(jì)算框架通過Alluxio發(fā)送請(qǐng)求，Alluxio反過來會(huì)從遠(yuǎn)程存儲(chǔ)系統(tǒng)獲取數(shù)據(jù)。同時(shí)，Alluxio拷貝一份數(shù)據(jù)緩存在Alluxio存儲(chǔ)空間中，這樣數(shù)據(jù)可以在Alluxio節(jié)點(diǎn)的內(nèi)存或持久化存儲(chǔ)介質(zhì)中可用。之后應(yīng)用將直接讀取緩存中的數(shù)據(jù)。這必然可以提升計(jì)算存儲(chǔ)解耦架構(gòu)的性能。然而，Alluxio只處理工作集數(shù)據(jù)，不保存持久化數(shù)據(jù)。因此，Alluxio不需要超大容量存儲(chǔ)，可以在一定大小的存儲(chǔ)空間發(fā)揮作用，而不必考慮數(shù)據(jù)總量。Alluxio還利用多級(jí)緩存和數(shù)據(jù)管理技術(shù)以高效地管理存儲(chǔ)空間。

 Alluxio位于計(jì)算層和存儲(chǔ)層之間，提供數(shù)據(jù)訪問和整合的統(tǒng)一入口。這意味著應(yīng)用可以自由使用任意Alluxio支持的統(tǒng)一接口，例如S3接口或者Hadoop兼容的接口。另外，數(shù)據(jù)可以自動(dòng)在存儲(chǔ)系統(tǒng)和應(yīng)用端進(jìn)行交互，而不管底層存儲(chǔ)系統(tǒng)原本支持的接口。這種概念擴(kuò)展的不僅僅是API的翻譯，底層存儲(chǔ)系統(tǒng)的安全性和一致性等功能也進(jìn)行了抽象并通過Alluxio提供。

在S3和Alluxio之上運(yùn)行SparkSQL

為了示例說明Alluxio為計(jì)算-存儲(chǔ)解耦架構(gòu)帶來的性能提升，我們?cè)赟parkSQL上運(yùn)行TPC-DS 2.4，數(shù)據(jù)存放在S3中。TPC-DS 是一個(gè)實(shí)際的工業(yè)測(cè)試基準(zhǔn)，專門為大數(shù)據(jù)分析查詢所定制。99個(gè)查詢集合順序執(zhí)行，這意味著開始的查詢讀取S3中的冷數(shù)據(jù)，之后將從Alluxio存儲(chǔ)系統(tǒng)中查詢緩存數(shù)據(jù)。實(shí)驗(yàn)在AWS上進(jìn)行，應(yīng)用開源版本的Alluxio 1.7.0和Apache Spark 2.2。集群擁有4 個(gè)r4.4xlarge worker節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)上同時(shí)運(yùn)行Alluxio worker和Spark worker，灰色的S3數(shù)據(jù)代表了TPC-DS查詢存儲(chǔ)在S3中的Parquet數(shù)據(jù)的實(shí)驗(yàn)性能結(jié)果，Alluxio完全不參與數(shù)據(jù)讀寫。藍(lán)色的Alluxio數(shù)據(jù)代表了使用Alluxio后的實(shí)驗(yàn)性能結(jié)果，但Alluxio在實(shí)驗(yàn)開始時(shí)沒有存儲(chǔ)數(shù)據(jù)。隨著查詢進(jìn)行，Alluxio將對(duì)數(shù)據(jù)進(jìn)行緩存，同時(shí)基于數(shù)據(jù)熱度自動(dòng)管理其存儲(chǔ)空間。比如，對(duì)于經(jīng)常訪問的文件，Alluxio為了提升讀數(shù)據(jù)的吞吐量，將拷貝多份數(shù)據(jù)，下表展示了測(cè)試中不同類型的查詢性能結(jié)果，以及應(yīng)用Alluxio對(duì)查詢性能產(chǎn)生的影響。

***個(gè)查詢集合是初始查詢，即直接從S3中讀取冷數(shù)據(jù)。因?yàn)锳lluxio必須從S3中預(yù)先讀取數(shù)據(jù)，所以兩種查詢方式的效果幾乎相同。從Alluxio1.7.0版本開始，Alluxio worker會(huì)通過客戶端數(shù)據(jù)訪問方式智能地異步讀取塊數(shù)據(jù)，所以初始讀取數(shù)據(jù)階段不會(huì)造成較大影響，甚至?xí)嵘樵冃省?/p>

在***情況下，即大多數(shù)數(shù)據(jù)集都存儲(chǔ)在Alluxio中，并且查詢是I/O密集型，Alluxio可以加速查詢速度10倍左右。針對(duì)絕大多數(shù)查詢類型，使用Alluxio后性能都有所提升，例如寬掃描查詢。不使用Alluxio查詢的I/O速度是網(wǎng)絡(luò)通信級(jí)別的，而使用Alluxio后，在S3上進(jìn)行的I/O查詢速率可以接近本地內(nèi)存級(jí)別。在評(píng)估查詢性能時(shí)，查詢?cè)绞艿絀/O瓶頸限制，則引入Alluxio后提升的吞吐量越多。因?yàn)槭褂昧薙3和AWS存儲(chǔ)，網(wǎng)絡(luò)狀態(tài)是理想的，實(shí)驗(yàn)可以充分利用10千兆飽和網(wǎng)絡(luò)連接。在網(wǎng)絡(luò)帶寬或磁盤I/O帶寬更低，數(shù)據(jù)傳輸受限更多的情況，Alluxio會(huì)帶來更大的性能提升。

相反，對(duì)于極度的計(jì)算密集型或shuffer密集型查詢，例如帶有復(fù)雜謂詞的join查詢請(qǐng)求，Alluxio性能提升較少。對(duì)于計(jì)算和I/O都成為部分瓶頸的查詢，Alluxio加速I/O受限的部分，提升的性能在總體實(shí)驗(yàn)結(jié)果中居中。在實(shí)驗(yàn)中，沒有查詢?cè)谑褂肁lluxio后性能下降。

 比較運(yùn)行總耗時(shí)，盡管Alluxio初始沒有加載數(shù)據(jù)，Alluxio還是比直接從S3讀取數(shù)據(jù)快40%。隨著查詢?nèi)蝿?wù)的進(jìn)行，Alluxio根據(jù)數(shù)據(jù)訪問模式和頻率逐漸緩存數(shù)據(jù)。然而，總運(yùn)行耗時(shí)并不能全面描述實(shí)際情況，因?yàn)殚L耗時(shí)查詢會(huì)占很大比重。通過賦予每個(gè)查詢相同的比重，Alluxio可以提高查詢的幾何平均數(shù)接近兩倍！這些結(jié)果反映了Alluxio可以提高所有TPC-DS基準(zhǔn)測(cè)評(píng)中的查詢性能，對(duì)于某些查詢性能甚至能夠提高一個(gè)數(shù)量級(jí)。而且，將Alluxio引入整個(gè)技術(shù)棧不會(huì)對(duì)任何查詢性能產(chǎn)生負(fù)面影響。

結(jié)論

TPC-DS代表了一類采用Alluxio實(shí)現(xiàn)計(jì)算-存儲(chǔ)解耦架構(gòu)而提升性能的工作負(fù)載。通過使用Alluxio，需要不同API的應(yīng)用可以無縫地從解耦開的、并且之前不兼容的存儲(chǔ)系統(tǒng)中訪問傳輸數(shù)據(jù)，而且這種數(shù)據(jù)訪問無需處理性能損失方面的問題。