基于Alluxio提升大數(shù)據(jù)系統(tǒng)性能與穩(wěn)定性

1、基于Alluxio提升Spark和HadoopHDFS的系統(tǒng)性能與穩(wěn)定性技術創(chuàng)新，變革未來內(nèi)容Alluxio基本原理回顧與最新特性介紹基于Alluxio的Spark DataFrame/RDD性能調(diào)優(yōu)基于Alluxio提升HDFS集群的性能和SLA穩(wěn)定性總結BIG DATA ECOSYSTEM YesterdayBIG DATA ECOSYSTEM Today4BIG DATA ECOSYSTEM Issue5BIG DATA ECOSYSTEM With Alluxio6BIG DATA ECOSYSTEM With Alluxio7Alluxio是什么Alluxio是世界上第一個以內(nèi)存為中

2、心 (memory-centric)的虛擬的分布式存儲系統(tǒng)。Alluxio介于計算框架和現(xiàn)有的存儲系統(tǒng)之間， 為大數(shù)據(jù)軟件棧帶來了顯著的性能提升。Alluxio的發(fā)展2012年12月，Alluxio（Tachyon）發(fā)布了第一個版本0.1.02017年1月，Alluxio的最新發(fā)布版本為1.4Alluxio的發(fā)展自2013年4月開源以來，已有超過100個組織機構的400多貢獻者參 與到Alluxio的開發(fā)中。包括阿里巴巴，Alluxio，百度，卡內(nèi)基梅隆 大學，IBM，Intel，南京大學，Red Hat，UC Berkeley和Yahoo?；钴S的開源社區(qū)Popular Open Source

3、 Projects Growth關于南大PASALab和我的貢獻情況INDUSTRY ADOPTION121314Alluxio整體架構Master-WorkerMaster管理全部元數(shù)據(jù)監(jiān)控各個Worker狀態(tài)Worker管理本地MEM、SSD和HDDClient向用戶和應用提供訪問接口向Master和Worker發(fā)送請求Under File System用于備份Under File SystemMasterClient Worker1MEM SSD HDDnode 1Worker3MEM SSD HDDnode 3Worker2MEM SSD HDDnode 2Alluxio文件組織元數(shù)據(jù)

4、為Inode Tree形式樹狀結構文件和目錄都為一個Inode文件屬性構成Inode的基本信息：id、名稱、長度、創(chuàng)建/修改時間等塊信息備份信息/Dir0/Dir1/Dir2/File1File0name : File1 List : Block0, Block1, . checkPointPath : hdfs:/xxx:yyy/zzz.Alluxio讀寫行為使用讀寫類型控制數(shù)據(jù)的存儲層位置ReadType - 控制讀數(shù)據(jù)時的行為WriteType - 控制寫數(shù)據(jù)時的行為類型取值含義讀類型ReadTypeCACHE_PROMOTE（默認）如果讀取的數(shù)據(jù)塊在Worker上時，該數(shù)據(jù)塊被移動到W

5、orker的最高層。如果該數(shù)據(jù)塊不在本地Worker中，那么就將一個副本添加到本地Worker中。CACHE如果該數(shù)據(jù)塊不在本地Worker中，那么就將一個副本添加到本地Worker中。NO_CACHE不會創(chuàng)建副本。寫類型WriteTypeCACHE_THROUGH數(shù)據(jù)被同步地寫入到Worker和底層存儲系統(tǒng)。MUST_CACHE（默認）數(shù)據(jù)被同步地寫入到Worker，但不會寫入底層存儲系統(tǒng)。THROUGH數(shù)據(jù)被同步地寫入到底層存儲系統(tǒng)，但不會寫入Worker。ASYNC_THROUGH數(shù)據(jù)被同步地寫入到Worker，并異步地寫入底層存儲系統(tǒng)。Alluxio容錯機制Master支持使用ZooK

6、eeper啟動多個Master日 志 Journal : EditLog + ImageWorker由Master監(jiān)控，失效時自動重啟備份Checkpoint & 世系關系 Lineage命令行接口運行方式bin/alluxio fs commandcatchmodcopyFromLocalcopyToLocalfileInfols路徑表示alluxio:/:/支持通配符 *，如：bin/alluxio fs rm /data/2014*mkdirmvrmtouchmountunmount文件系統(tǒng)API以Java API的方式提供Alluxio的訪問接口創(chuàng)建、寫文件FileSystem fs

7、= FileSystem.Factory.get(); AlluxioURI path = new AlluxioURI(/myFile); FileOutStream out = fs.createFile(path); out.write(.);out.close();讀文件FileSystem fs = FileSystem.Factory.get(); AlluxioURI path = new AlluxioURI(/myFile); FileInStream in = fs.openFile(path); in.read(.);in.close();最新版本Java API Doc

8、（/documentation/master/api/java/）兼容現(xiàn)有的Hadoop FileSystem接口在MapReduce、Spark等作業(yè)中以“alluxio:/”代替“hdfs:/”Alluxio-FUSE能夠在Linux的本地文件系統(tǒng)中掛載Alluxio利用Linux libfuse功能包掛載為Linux本地文件系統(tǒng)中的一個目錄方便快捷的使用方式$ alluxio-fuse.sh mount 像使用本地文件系統(tǒng)一樣使用支持的操作openreadlseekwriteKernelUserspacecat /tmp/alluxio-fileglibcVFSFUSENFSExt4.g

9、libclibfuseAlluxio鍵值存儲庫APIAlluxio的鍵值（key-value）存儲功能創(chuàng)建一個鍵值存儲庫并且把鍵值對放入其中鍵值對放入存儲后是不可變的鍵值存儲庫完整保存后，打開并使用該鍵值存儲庫API樣例KeyValueSystem kvs = KeyValueSystem.Factory().create();KeyValueStoreWriter writer = kvs.createStore(new AlluxioURI(alluxio:/path/my-kvstore); writer.put(100, foo);writer.put(200, bar); write

10、r.close();KeyValueStoreReader reader = kvs.openStore( new AlluxioURI(alluxio:/path/kvstore/);reader.get(100);reader.get(“300”);/null reader.close();Alluxio KV Storebatch put K1 get 2 V1foo分層存儲為什么需要多級存儲？內(nèi)存大小有限兩個概念StorageTier存儲層，對應存儲介質，如內(nèi)存、SSD、硬盤StorageDir數(shù)據(jù)塊存放在Alluxio Worker的本地目錄，通常對應一塊磁盤設備一個StorageT

11、ier包含一個或多個StorageDir數(shù)據(jù)塊管理Allocator- 選擇分配哪個StorageDir里的空間GreedyAllocator、MaxFreeAllocator、RoundRobinAllocatorEvictor- 選擇撤銷哪個StorageDir里的哪些數(shù)據(jù)塊GreedyEvictor、LRUEvictor、LRFUEvictor、PartialLRUEvictor統(tǒng)一命名空間統(tǒng)一命名空間能夠將多個數(shù)據(jù)源中的數(shù)據(jù)掛載到Alluxio中多個數(shù)據(jù)源使用統(tǒng)一的命名空間用戶使用統(tǒng)一路徑訪問統(tǒng)一命名空間的適用場景將數(shù)據(jù)遷移至Alluxio將數(shù)據(jù)從原先基于磁盤的存儲遷移至Alluxio

12、，利用內(nèi)存加速在應用中使用統(tǒng)一路徑訪問Alluxio和底層存儲系統(tǒng)管理不同數(shù)據(jù)源中的數(shù)據(jù)將數(shù)據(jù)從不同數(shù)據(jù)源遷移至Alluxio，利用內(nèi)存加速在應用中使用統(tǒng)一路徑訪問不同數(shù)據(jù)源中的數(shù)據(jù)實現(xiàn)不同數(shù)據(jù)源之間的數(shù)據(jù)共享與計算框架相結合使用Alluxio作為計算框架的存儲系統(tǒng)Spark、Hadoop MapReduce、FlinkH20、Impala、不需改動現(xiàn)有應用源碼存儲路徑 “hdfs:/ip:port/xxx” - “alluxio:/ip:port/xxx”Zeppelin默認集成Alluxio，使用Alluxio作為解釋器安全性安全認證Alluxio能夠識別訪問用戶的身份，這是訪問權限以及加

13、密等其他安 全特性的基礎當用戶（客戶端）連接Alluxio（服務端）時，需要特定的用戶、密 碼或其他認證方式訪問權限控制以文件為粒度進行訪問權限控制類似POSIX標準的訪問權限模型用戶權限、用戶組權限、其他用戶權限讀r、寫w、執(zhí)行xWeb界面Master WebUI例Worker WebUI例技術特點小結Co-located compute and data with memory-speed access to dataVirtualized different storage systems under a unified namespaceScale-out architectureFi

14、le system API, software only系統(tǒng)優(yōu)勢小結UnificationNew workflows across any data in any storage systemPerformanceOrders of magnitude improvement in run timeFlexibilityChoice in compute and storage grow each independently, buy only what is neededAlluxio 1.4版本的重要新特性介紹優(yōu)化Alluxio底層對象存儲API優(yōu)化的對象存儲連接器Alluxio 1.4.

15、0在對象存儲上的小文件和小規(guī)模讀取的性能方面有了 重大改進。改進UFS API提升了對象存儲中獲取元數(shù)據(jù)的性能。簡化的對象存儲集成如今集成新的對象存儲只需要原先實現(xiàn)的方法中的一半即可。在源代碼行數(shù)方面，現(xiàn)在僅需要不到400行代碼即可完成新的對象存 儲的集成，不到原來的一半。Alluxio 1.4版本的重要新特性介紹文件系統(tǒng)原生REST接口新引入的REST接口提供了同Alluxio native Java API的對等性，其 目的是促進非Java環(huán)境與Alluxio的交互。REST接口通過Alluxio代理進程實現(xiàn)，該進程使用一個內(nèi)部Alluxio Java客戶端代理REST接口和Alluxio

16、服務器之間的通信為了獲得最佳性能，推薦將Alluxio代理與Alluxio服務進程放在一起。這 可以讓非java應用以內(nèi)存級的速度訪問Alluxio中的數(shù)據(jù)，同時最小化Alluxio代理和Alluxio服務之間額外網(wǎng)絡的開銷。Alluxio 1.4版本的重要新特性介紹數(shù)據(jù)包流（Packet Streaming）Alluxio 1.4.0引入了一種新的網(wǎng)絡傳輸協(xié)議，旨在充分利用Alluxio組件之間的可用網(wǎng)絡帶寬在標準網(wǎng)絡中高達2倍的IO性能改進，以及在高延遲吞吐量產(chǎn)品環(huán)境下取 得更好的結果減少了網(wǎng)絡傳輸期間使用的緩存，并且依賴于使用連續(xù)流傳輸協(xié)議取 代數(shù)據(jù)傳輸中的請求-響應協(xié)議通過使用這種方法

17、，能確保網(wǎng)絡管道持續(xù)飽和，因為我們不需要 發(fā)送周期性的額外數(shù)據(jù)請求Alluxio 1.4版本的重要新特性介紹支持Apache Hive（Contributed By PASALab）將Apache Hive集成運行在Alluxio上,具體看使用文檔 (/docs/master/en/Running-Hive- with-Alluxio.html)提升了與基于YARN的應用的集成工作支持在用戶/權限打開的模式下將YARN的應用運行在Alluxio上Alluxio 1.4版本的重要新特性介紹提升了Alluxio Master中的鎖管理機制使得基于MapReduce的計算框架能夠有更高并發(fā)的元數(shù)據(jù)操

18、作性能對緩慢底層文件系統(tǒng)進行元數(shù)據(jù)操作（例如在云存儲中進行重命名） 的性能能夠提升1個數(shù)量級左右指定層級寫操作用戶能夠將數(shù)據(jù)顯式地寫到Alluxio存儲層級中的指定層，而不是原 先默認的最頂層內(nèi)容Alluxio基本原理回顧與1.4的最新特性介紹基于Alluxio的Spark DataFrame性能調(diào)優(yōu)基于Alluxio提升HDFS集群的性能和SLA穩(wěn)定性總結實驗環(huán)境Spark 2.0.0 + Alluxio 1.2.0Single worker: Amazon r3.2xlarge（61 GB MEM, 8- core CPU）Comparisons:AlluxioSpark Storage

19、Level: MEMORY_ONLYSpark Storage Level: MEMORY_ONLY_SERSpark Storage Level: DISK_ONLY19232502001501005000104050Time seconds2030DataFrame Size GBREADING CACHED DATAFRAME (PARQUET)Alluxio (textFile) MEMORY_ONLY_SERDISK_ONLY MEMORY_ONLY24050200250AlluxioNo Alluxio100150Time seconds新場景：READ 50 GB DATAFRA

20、ME(SSD)250250500125015001750AlluxioNo Alluxio7501000Time seconds新場景：READ 50 GB DATAFRAME(S3)10 x average speedup, 17x peak speedup內(nèi)容Alluxio基本原理回顧與1.4的最新特性介紹基于Alluxio的Spark DataFrame/RDD性能調(diào)優(yōu)基于Alluxio提升HDFS集群的性能和SLA穩(wěn)定性總結使用Alluxio提升HDFS集群的性能和SLA穩(wěn)定性Alluxio可以給與HDFS共同部署的計算集群的兩 大好處提升高達10倍的性能提升性能的高可預測性使得SLA（service-level agreement服務級 別協(xié)議）很容易滿足例：作業(yè)運行時間的變化范圍從100秒以上縮短至2秒場景 1周作業(yè)和月作業(yè)都是IO密集型結論：Alluxio對這兩種作業(yè)的性能提升都很明顯。在不使用Alluxio的