騰訊云基于Alluxio優(yōu)化計算存儲分離架構(gòu)的最佳實踐

導(dǎo)語|隨著企業(yè)大數(shù)據(jù)規(guī)模和應(yīng)用的增長和發(fā)展，計算與存儲分離的架構(gòu)漸漸成為主流，它解決了計算量和存儲量不匹配問題，實現(xiàn)了算力的按需使用，但也引來了一些新的問題。騰訊云EMR團(tuán)隊與Alluxio社區(qū)合作，探索出了開箱即用的計算存儲分離優(yōu)化版本，大幅優(yōu)化網(wǎng)絡(luò)帶寬，帶寬削峰20%-50%，節(jié)省總帶寬10%-50%，同時能在IO密集型場景提升性能5%-40%，下面就讓我們來一探究竟。

一、當(dāng)前大數(shù)據(jù)挑戰(zhàn)

近年來，隨著大數(shù)據(jù)規(guī)模的增長，以及大數(shù)據(jù)應(yīng)用的發(fā)展，大數(shù)據(jù)技術(shù)的架構(gòu)也在持續(xù)演進(jìn)。早期的技術(shù)架構(gòu)是計算資源和存儲資源高度融合，計算和存儲資源一體化存在以下明顯的挑戰(zhàn)：

1.數(shù)據(jù)孤島

如今，企業(yè)擁有PB級數(shù)據(jù)已經(jīng)成為常態(tài)，EB級數(shù)據(jù)時代也將很快到來。企業(yè)需要面向結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)、實時數(shù)據(jù)等多種類型的數(shù)據(jù)提供高擴(kuò)展且統(tǒng)一的數(shù)據(jù)管理和數(shù)據(jù)存儲能力。

2.剛性擴(kuò)容

在數(shù)據(jù)空間持續(xù)增長的背景下，大數(shù)據(jù)應(yīng)用場景不斷增加，對企業(yè)算力的需求也在加劇提升。而同時，新品發(fā)布、熱點(diǎn)事件等帶來的業(yè)務(wù)浪涌，也需要企業(yè)大數(shù)據(jù)系統(tǒng)擁有極致的彈性能力。

3.利用率低

大數(shù)據(jù)行業(yè)技術(shù)棧迭代迅速，企業(yè)自行構(gòu)建IDC中心和自行部署軟件，一次性投資大，且折舊成本高，運(yùn)營運(yùn)維負(fù)擔(dān)沉重。

4.作業(yè)擁塞

隨著業(yè)務(wù)的發(fā)展，在數(shù)據(jù)量巨大的背景下，單次分析作業(yè)常需要讀取TB-PB級的數(shù)據(jù)，多任務(wù)并發(fā)下，極易出現(xiàn)作業(yè)擁塞。

面對以上挑戰(zhàn)，傳統(tǒng)的以私有數(shù)據(jù)中心為基礎(chǔ)的存算一體大數(shù)據(jù)架構(gòu)，已無法滿足企業(yè)海量數(shù)據(jù)分析的需求。業(yè)界知名分析機(jī)構(gòu)IDC在最新的報告中明確指出：企業(yè)上云已成必然趨勢。因此，在公有云上部署更靈活高效的大數(shù)據(jù)分析平臺，將成為企業(yè)的必然選擇。

二、騰訊云彈性MapReduce(EMR)

目前越來越多的企業(yè)開始選擇使用計算和存儲分離的架構(gòu)，以應(yīng)對更低成本的要求，和兼顧資源擴(kuò)展的靈活性。

傳統(tǒng)計算存儲一體架構(gòu)

計算存儲分離架構(gòu)

目前騰訊云彈性MapReduce(EMR)[1]支持了三種存儲系統(tǒng)：EMR-HDFS、EMR-COS[2]、EMR-CHDFS[3]，其中EMR-COS和EMR-CHDFS在EMR中都是開箱即用的原生支持計算存儲分離的方案，其具體應(yīng)用場景及特點(diǎn)如下：

元數(shù)據(jù)操作效率高，能夠與HDFS相當(dāng)，能夠有效規(guī)避COS文件系統(tǒng)元數(shù)據(jù)操作耗時以及高頻訪問下可能引發(fā)不穩(wěn)定的問題。但在實際使用場景中，因為可能存在多個數(shù)據(jù)存儲源管理復(fù)雜，部分業(yè)務(wù)場景對數(shù)據(jù)源的IO訪問密集造成網(wǎng)絡(luò)壓力大，訪問不穩(wěn)定等問題。所以我們基于Alluxio進(jìn)一步優(yōu)化計算和存儲架構(gòu)，更好的滿足業(yè)務(wù)應(yīng)用上的需求。

三、基于Alluxio優(yōu)化計算存儲分離架構(gòu)

傳統(tǒng)計算存儲分離，解決了計算量和存儲量不匹配問題，實現(xiàn)了算力的按需使用，大幅節(jié)省了運(yùn)維規(guī)劃時間以及閑置的算力成本。但直接使用計算存儲分離架構(gòu)，也引入了新的問題：

·在IO密集型的場景下，網(wǎng)絡(luò)帶寬會成為瓶頸,可能導(dǎo)致計算&存儲資源利用不充分；

·數(shù)據(jù)本地化不夠，導(dǎo)致很多shuffle過程的重復(fù)計算，造成部分浪費(fèi)計算資源的浪費(fèi)；

·可能存在多種甚至異構(gòu)的存儲源，增加了管理難度。

為此，騰訊云EMR團(tuán)隊與Alluxio社區(qū)合作，引入最新alluxio2.3.0 Release版本進(jìn)行深度優(yōu)化，推出開箱即用的計算存儲分離優(yōu)化版本：EMR2.5.0/EMR3.1.0/EMR-TianQiong-1.0，解決上述問題。

1.提供內(nèi)存級I/O能力

Alluxio能夠用作分布式共享緩存服務(wù)，這樣與Alluxio通信的計算應(yīng)用程序可以透明地緩存頻繁訪問的數(shù)據(jù)（尤其是從遠(yuǎn)程位置），以提供內(nèi)存級I/O吞吐率。此外，Alluxio的層次化存儲機(jī)制能夠充分利用內(nèi)存、固態(tài)硬盤或者磁盤，降低具有彈性擴(kuò)張?zhí)匦缘臄?shù)據(jù)驅(qū)動型應(yīng)用的成本開銷。

2.提高數(shù)據(jù)本地性

利用Alluxio提供的分布式緩存服務(wù)，在部署Alluxio數(shù)據(jù)節(jié)點(diǎn)(Alluxio-Worker)時和計算節(jié)點(diǎn)部署在一起，可以直接從數(shù)據(jù)節(jié)點(diǎn)中以內(nèi)存級IO速度檢索讀取數(shù)據(jù)，而不是從底層云存儲或?qū)ο蟠鎯χ袡z索讀取，提高了數(shù)據(jù)本地性。

3.簡化云存儲和對象存儲接入

與傳統(tǒng)文件系統(tǒng)相比，云存儲系統(tǒng)和對象存儲系統(tǒng)使用不同的語義，這些語義對性能的影響也不同于傳統(tǒng)文件系統(tǒng)。在云存儲和對象存儲系統(tǒng)上進(jìn)行常見的文件系統(tǒng)操作（如列出目錄和重命名）通常會導(dǎo)致顯著的性能開銷。當(dāng)訪問云存儲中的數(shù)據(jù)時，應(yīng)用程序沒有節(jié)點(diǎn)級數(shù)據(jù)本地性或跨應(yīng)用程序緩存。

4.簡化數(shù)據(jù)管理

Alluxio提供對多數(shù)據(jù)源的單點(diǎn)訪問。除了連接不同類型的數(shù)據(jù)源之外，Alluxio還允許用戶同時連接同一存儲系統(tǒng)的不同版本，如多個版本的HDFS以及云上COS/CHDFS，只需基于EMR配套的簡單配置下發(fā)和管理管理功能。

在引入Alluxio后，EMR基于Alluxio的存算分離的整體架構(gòu)變成了：

這樣，EMR的計算引擎(Spark，MapReduce，Presto等)就可以統(tǒng)一通過Alluxio來提升性能，降低網(wǎng)絡(luò)峰值帶寬，以及簡化數(shù)據(jù)管理。

四、性能評估及調(diào)優(yōu)

為了分析理解使用Alluxio存儲在主流查詢引擎Spark性能上差異，我們使用大數(shù)據(jù)壓測工具TPC-DS進(jìn)行了一些性能壓測。我們使用的環(huán)境及配置如下：

·EMR版本：EMR-2.5.0；

·選擇組件：zookeeper-3.6.1,hadoop-2.8.5,hive-2.3.7,spark_hadoop2.8-3.0.0,tez-0.9.2,alluxio-2.3.0,knox-1.2.0；

·壓測配置，使用了1個EMR的Master節(jié)點(diǎn)和25個CORE節(jié)點(diǎn)，具體如下：

1.帶寬評估

從壓測結(jié)果可以看到，能大幅優(yōu)化計算存儲分離網(wǎng)絡(luò)帶寬，節(jié)省峰值帶寬(削峰)20%-50%，節(jié)省總帶寬(10%-50%)。

2.查詢性能評估

從壓測結(jié)果可以看到,在大部分場景下能優(yōu)化性能，特別是IO密集型，優(yōu)化性能5%-40%。

3.性能調(diào)優(yōu)及專項優(yōu)化

為了更好滿足計算存儲分離場景，EMR團(tuán)隊針對Alluxio做了專項調(diào)優(yōu)，具體包括：

（1）數(shù)據(jù)本地性

為了更好滿足數(shù)據(jù)本地，EMR在部署Alluxio時，在core節(jié)點(diǎn)把a(bǔ)lluxio-worker同計算節(jié)點(diǎn)部署在一起，這樣yarn等計算服務(wù)節(jié)點(diǎn)可以在同一個節(jié)點(diǎn)中與alluxio-worker節(jié)點(diǎn)通信，大量提升了效率。

另一方面，結(jié)合alluxio已經(jīng)提供的讀寫策略，結(jié)合存算分離場景優(yōu)化了block.read.location.policy，writetype.default等策略，讓alluxio的緩存能力更好滿足本地性。

（2）元數(shù)據(jù)優(yōu)化

Alluxio基于Presto實現(xiàn)了Catalog Service，并且實現(xiàn)了計算框架端的Connector，Alluxio可以感知并管理結(jié)構(gòu)化數(shù)據(jù)的元數(shù)據(jù)，大大簡化表級別的使用成本。同時，騰訊內(nèi)部在大規(guī)模使用Alluxio時，我們發(fā)現(xiàn)Alluxio本身的inode元數(shù)據(jù)也面臨著膨脹的風(fēng)險。為此結(jié)合Alluxio提供的Catalog Service和Path緩存能力，優(yōu)化了path.caching.thread和path.cache.capacity等策略。

更多meta具體優(yōu)化可參考，社區(qū)meta優(yōu)化[4]及catalog介紹[5]。

（3）Java GC的影響

Alluxio作為Java的進(jìn)程，其GC的經(jīng)常影響其性能表現(xiàn)，為此，EMR團(tuán)隊引入了Tencent Kona，經(jīng)過了內(nèi)部大數(shù)據(jù)和AI等業(yè)務(wù)場景的驗證，為JAVA生態(tài)提供專業(yè)持續(xù)的保障。Kona在GC線程調(diào)度優(yōu)化，物理內(nèi)存釋放優(yōu)化等方面有優(yōu)秀表現(xiàn)，更多功能特性可見：Kona JDK[6]。

上述的這些能力和優(yōu)化，在存算分離場景下，騰訊云EMR產(chǎn)品針對這種場景都已經(jīng)直接提供了開箱即用的能力，直接在騰訊云EMR產(chǎn)品購買頁創(chuàng)建，或者在已有支持了alluxio的EMR版本上安裝，即可達(dá)到性能評估中效果。

五、總結(jié)

從上述的壓測結(jié)果看到，一方面有效的降低了帶寬峰值和總帶寬，從而降低帶寬成本，加速訪問；另一方面，IO密集型場景下的性能也有不少提升，能更好的支持IO密集型場景下的業(yè)務(wù)。此次基于Alluxio的優(yōu)化，讓騰訊云彈性MapReduce(EMR)產(chǎn)品更好的支持存儲計算分離架構(gòu)，為用戶更好的滿足業(yè)務(wù)需求的同時，降低成本，且保持資源擴(kuò)展的靈活性。

參考資料：

[1]騰訊云彈性MapReduce(EMR):https://intl.cloud.tencent.com/zh/product/emr

[2]騰訊云COS：https://cloud.tencent.com/product/cos/details

[3]騰訊云云HDFS(CHDFS)：https://cloud.tencent.com/document/product/1105

[4]meta優(yōu)化：https://docs.alluxio.io/ee/user/stable/en/operation/Performance-Tuning.html

[5]catalog介紹：https://docs.alluxio.io/os/user/stable/cn/core-services/Catalog.html

[6]Kona JDK：https://cloud.tencent.com/document/product/589/50714