魏占辰，黃秋蘭 ，孫功星，劉曉宇，王 軼

1.中國(guó)科學(xué)院 高能物理研究所，北京 100049

2.中國(guó)科學(xué)院大學(xué)，北京 100049

1 引言

隨著信息技術(shù)的發(fā)展，與人類生產(chǎn)、生活密切相關(guān)的數(shù)據(jù)呈現(xiàn)爆炸式的增長(zhǎng)，大數(shù)據(jù)逐漸成為推動(dòng)技術(shù)變革和時(shí)代發(fā)展的關(guān)鍵。數(shù)據(jù)量的增長(zhǎng)使數(shù)據(jù)處理和存儲(chǔ)技術(shù)得到蓬勃發(fā)展，如何高速訪問并統(tǒng)一管理數(shù)據(jù)，成為數(shù)據(jù)分析師和軟件工程師首要解決的問題，因此Alluxio[1]應(yīng)運(yùn)而生。

Alluxio 是一個(gè)新興的、以內(nèi)存為中心的分布式存儲(chǔ)系統(tǒng)，面向大數(shù)據(jù)生態(tài)圈，被設(shè)計(jì)成為計(jì)算程序訪問內(nèi)存數(shù)據(jù)以及底層存儲(chǔ)系統(tǒng)數(shù)據(jù)的統(tǒng)一接口[2]。Alluxio能夠與多種底層存儲(chǔ)系統(tǒng)（例如HDFS、GlusterFS、Ceph）和計(jì)算框架（例如Hadoop MapReduce、Spark）兼容，使大數(shù)據(jù)應(yīng)用得到極大的性能提升。因此Alluxio在互聯(lián)網(wǎng)領(lǐng)域中得到了廣泛的應(yīng)用，引起了科研人員的極大興趣。目前，Alluxio 的研究?jī)?nèi)容主要集中在Alluxio 的 應(yīng) 用[3-5]、提 高 Alluxio 的 可 用 性[6]和 改 進(jìn)Alluxio的緩存策略[7]等方面。

與HDFS設(shè)計(jì)理念一致，Alluxio簡(jiǎn)化了文件系統(tǒng)實(shí)現(xiàn)，提供Java 接口支持文件的隨機(jī)讀取和順序?qū)懭耄恢С治募碾S機(jī)寫入[8]。但在某些大數(shù)據(jù)應(yīng)用中，尤其是科學(xué)計(jì)算等數(shù)據(jù)分析應(yīng)用通常需要支持隨機(jī)讀寫（例如高能物理中廣泛使用的ROOT 框架[9]）。由于科學(xué)計(jì)算歷史久遠(yuǎn)，部分代碼難以快速修改適應(yīng)Alluxio 數(shù)據(jù)訪問接口。雖然Alluxio 支持通過FUSE 掛載到根文件系統(tǒng)上，但掛載后的文件系統(tǒng)仍不支持隨機(jī)寫入[10]，并且FUSE本身性能較差，嚴(yán)重制約了讀寫性能。因此在這些領(lǐng)域，Alluxio的應(yīng)用受到了一定限制。另外，傳統(tǒng)的基于Java 數(shù)據(jù)流接口無法靈活利用現(xiàn)有的新式高性能數(shù)據(jù)訪問技術(shù)（例如內(nèi)存映射、Java NIO等），仍有較大性能提升空間。

本文針對(duì)Alluxio 不支持?jǐn)?shù)據(jù)隨機(jī)寫入的問題，在現(xiàn)有數(shù)據(jù)訪問模式基礎(chǔ)上，提出一種新的Alluxio 數(shù)據(jù)隨機(jī)訪問機(jī)制。該機(jī)制能夠使傳統(tǒng)程序適應(yīng)新的存儲(chǔ)系統(tǒng)，用戶也可以利用該機(jī)制在數(shù)據(jù)分析時(shí)靈活使用各類數(shù)據(jù)訪問技術(shù)，從而提高數(shù)據(jù)讀寫時(shí)的效率。

2 相關(guān)研究情況介紹

Alluxio采用了主-從式架構(gòu)，架構(gòu)如圖1所示，主節(jié)點(diǎn)AlluxioMaster 管理文件系統(tǒng)的元數(shù)據(jù)，包括文件基本信息、數(shù)據(jù)塊及副本情況、工作節(jié)點(diǎn)情況等；從節(jié)點(diǎn)AlluxioWorker 管理本機(jī)實(shí)際存儲(chǔ)的數(shù)據(jù)塊副本，監(jiān)控存儲(chǔ)空間大小，按照一定策略調(diào)整副本，同時(shí)也負(fù)責(zé)與底層存儲(chǔ)系統(tǒng)的數(shù)據(jù)傳輸。Alluxio可映射底層存儲(chǔ)系統(tǒng)的文件結(jié)構(gòu)，管理底層存儲(chǔ)系統(tǒng)的數(shù)據(jù)，使用Alluxio接口讀取數(shù)據(jù)時(shí)能夠在Alluxio 中自動(dòng)緩存一份數(shù)據(jù)。Alluxio 使用了動(dòng)態(tài)副本機(jī)制，其副本數(shù)量隨著分布式系統(tǒng)中數(shù)據(jù)訪問情況和節(jié)點(diǎn)存儲(chǔ)空間情況動(dòng)態(tài)增加或減少。

圖1 Alluxio文件系統(tǒng)結(jié)構(gòu)圖

Alluxio 提供基于Java 語言的數(shù)據(jù)訪問接口，文件數(shù)據(jù)被抽象為數(shù)據(jù)流，Alluxio 的文件管理單位為數(shù)據(jù)塊（Block），讀寫過程如圖2、圖3所示，具體步驟在圖中以序號(hào)標(biāo)出，其中虛線箭頭表示各組件間的指令交互，實(shí)線箭頭表示數(shù)據(jù)交互。在讀取數(shù)據(jù)時(shí)，客戶端首先向AlluxioMaster請(qǐng)求文件元數(shù)據(jù)，通過元數(shù)據(jù)可獲知文件的位置以及副本情況。如果該文件在本地有副本數(shù)據(jù)（即本地?cái)?shù)據(jù)塊命中），則直接打開該文件進(jìn)行讀寫；如果不存在本地副本數(shù)據(jù)，則通過本地AlluxioWorker 向有副本的節(jié)點(diǎn)或底層存儲(chǔ)系統(tǒng)請(qǐng)求數(shù)據(jù)（即遠(yuǎn)程數(shù)據(jù)塊命中或底層存儲(chǔ)系統(tǒng)數(shù)據(jù)塊命中），并在本地創(chuàng)建一個(gè)副本，讀取數(shù)據(jù)的同時(shí)向本地副本寫入相應(yīng)數(shù)據(jù)。當(dāng)寫入數(shù)據(jù)時(shí)，客戶端通過本地AlluxioWorker 創(chuàng)建一個(gè)副本，并直接向其寫入數(shù)據(jù)，根據(jù)寫入策略，AlluxioWorker還將決定是否向底層存儲(chǔ)系統(tǒng)寫入該數(shù)據(jù)，以及以同步還是異步方式向底層存儲(chǔ)系統(tǒng)寫入數(shù)據(jù)。若Alluxio-Worker發(fā)現(xiàn)本地存儲(chǔ)空間不足，則會(huì)按照一定策略清除部分副本數(shù)據(jù)，以滿足新副本的寫入所需的存儲(chǔ)空間。如果在數(shù)據(jù)讀寫過程中，客戶端所在節(jié)點(diǎn)沒有本地AlluxioWorker，則所有數(shù)據(jù)傳輸均通過網(wǎng)絡(luò)向相關(guān)節(jié)點(diǎn)通信，并且不會(huì)在本地創(chuàng)建任何副本。

圖2 Alluxio標(biāo)準(zhǔn)數(shù)據(jù)讀取流程圖

圖3 Alluxio標(biāo)準(zhǔn)數(shù)據(jù)寫入流程圖

3 Alluxio隨機(jī)讀寫機(jī)制的設(shè)計(jì)與實(shí)現(xiàn)

當(dāng)Alluxio 客戶端和AlluxioWorker 不在同一節(jié)點(diǎn)時(shí)，數(shù)據(jù)訪問完全通過網(wǎng)絡(luò)，失去了使用內(nèi)存緩存數(shù)據(jù)的優(yōu)勢(shì)，因此在使用本文的Alluxio隨機(jī)讀寫機(jī)制時(shí)，需要保證Alluxio客戶端運(yùn)行在Alluxio集群內(nèi)。由于數(shù)據(jù)隨機(jī)讀寫的場(chǎng)景大多需要保證文件完整、不被拆分，同時(shí)為保證隨機(jī)讀寫應(yīng)用場(chǎng)景和Alluxio場(chǎng)景下文件含義的一致性，本文僅討論一個(gè)文件只包含一個(gè)數(shù)據(jù)塊的情況下的數(shù)據(jù)隨機(jī)讀寫。

本文提出的Alluxio隨機(jī)讀寫機(jī)制是在原有的數(shù)據(jù)訪問基礎(chǔ)上實(shí)現(xiàn)的，通過改變副本數(shù)據(jù)創(chuàng)建、緩存的時(shí)機(jī)，將對(duì)Alluxio 文件系統(tǒng)中的文件讀寫轉(zhuǎn)化為對(duì)本地緩存數(shù)據(jù)塊的讀寫。在使用Alluxio隨機(jī)讀寫時(shí)需要兩步：（1）獲得Alluxio文件及數(shù)據(jù)塊與本地緩存的數(shù)據(jù)塊映射關(guān)系，本文設(shè)計(jì)了AlluxioService模塊完成該功能；（2）執(zhí)行計(jì)算任務(wù)的用戶程序完成對(duì)本地?cái)?shù)據(jù)塊的訪問。由于數(shù)據(jù)塊在本地以文件形式存儲(chǔ)在ramfs 或tmpfs文件系統(tǒng)中，因此可以選擇通過read、write等系統(tǒng)調(diào)用進(jìn)行文件讀寫或者使用內(nèi)存映射技術(shù)訪問文件數(shù)據(jù)，從而獲得隨機(jī)讀寫的支持、更好的訪問效率和更大的靈活性。

3.1 數(shù)據(jù)寫入過程

Alluxio 的數(shù)據(jù)寫入過程分為文件創(chuàng)建、數(shù)據(jù)塊申請(qǐng)、數(shù)據(jù)寫入、數(shù)據(jù)塊提交、文件關(guān)閉等幾個(gè)過程，如圖4所示，詳細(xì)步驟以序號(hào)標(biāo)出，虛線箭頭表示指令交互，實(shí)線箭頭表示數(shù)據(jù)交互。在寫入文件時(shí)，AlluxioService首先會(huì)向AlluxioMaster 發(fā)送文件創(chuàng)建請(qǐng)求（FileCreate-Request），在Alluxio 文件系統(tǒng)的名字空間中加入該文件，并收到AlluxioMaster返回的URIStatus對(duì)象（文件元數(shù)據(jù)）。然后AlluxioService 向AlluxioMaster 為該文件請(qǐng)求分配一個(gè)新的數(shù)據(jù)塊，獲得該數(shù)據(jù)塊ID，并向本地AlluxioWorker 發(fā)送創(chuàng)建本地?cái)?shù)據(jù)塊請(qǐng)求（LocalBlock-CreateRequest），AlluxioWorker 負(fù)責(zé)為該數(shù)據(jù)塊預(yù)留足夠的存儲(chǔ)空間，返回響應(yīng)（LocalBlockCreateResponse），響應(yīng)信息中包含了數(shù)據(jù)塊的本地臨時(shí)存儲(chǔ)路徑。通過該路徑，用戶程序通過本地文件系統(tǒng)對(duì)該文件進(jìn)行隨機(jī)數(shù)據(jù)寫入。在數(shù)據(jù)寫入完成后，AlluxioService向Alluxio-Worker 發(fā)送數(shù)據(jù)塊完成請(qǐng)求（LocalBlockCompleteRequest）關(guān)閉數(shù)據(jù)塊，AlluxioWorker將其移動(dòng)到固定存儲(chǔ)位置，并向AlluxioMaster注冊(cè)提交該數(shù)據(jù)塊信息。在所有數(shù)據(jù)塊提交完成后，AlluxioService 向AlluxioMaster發(fā)送關(guān)閉文件請(qǐng)求（FileCompleteRequest），AlluxioMaster 更新該文件的元數(shù)據(jù)，此時(shí)該文件的所有數(shù)據(jù)及元數(shù)據(jù)信息都可以在Alluxio中訪問。

圖4 Alluxio數(shù)據(jù)隨機(jī)寫流程圖

3.2 數(shù)據(jù)讀取過程

Alluxio 的數(shù)據(jù)讀取過程為獲得本地?cái)?shù)據(jù)塊的路徑進(jìn)行文件讀寫，若所訪問文件沒有本地?cái)?shù)據(jù)塊時(shí)，則先完成本地?cái)?shù)據(jù)塊的緩存。首先AlluxioService向Alluxio-Master請(qǐng)求文件的元數(shù)據(jù)信息，得到URIStatus對(duì)象，該對(duì)象中包含了該文件的所有數(shù)據(jù)塊ID。通過數(shù)據(jù)塊ID，AlluxioService 再向 AlluxioMaster 請(qǐng)求某個(gè)數(shù)據(jù)塊的基本信息，得到BlockInfo對(duì)象，該對(duì)象中包含了該數(shù)據(jù)塊的所有位置情況。根據(jù)數(shù)據(jù)塊存儲(chǔ)位置情況，有本地?cái)?shù)據(jù)塊命中、遠(yuǎn)程數(shù)據(jù)塊命中、底層存儲(chǔ)系統(tǒng)數(shù)據(jù)塊命中三種不同的處理方式。

3.2.1 本地?cái)?shù)據(jù)塊命中

當(dāng)數(shù)據(jù)塊位置信息中包含本地的AlluxioWorker時(shí)，表明本節(jié)點(diǎn)上緩存了該數(shù)據(jù)塊。AlluxioService 通過向本地AlluxioWorker 發(fā)送打開本地?cái)?shù)據(jù)塊請(qǐng)求（LocalBlockOpenRequest），得到響應(yīng)（LocalBlockOpen-Response），其中包含該數(shù)據(jù)塊對(duì)應(yīng)的本地文件路徑，用戶程序由此讀取本地文件系統(tǒng)中的數(shù)據(jù)，如圖5 所示，各步驟以序號(hào)標(biāo)出，虛線箭頭表示指令交互，實(shí)線箭頭表示數(shù)據(jù)交互。

3.2.2 遠(yuǎn)程數(shù)據(jù)塊命中

圖5 本地?cái)?shù)據(jù)塊命中數(shù)據(jù)讀取流程圖

當(dāng)數(shù)據(jù)塊位置信息不為空，但不包含本地的Alluxio-Worker 時(shí)，表明可通過網(wǎng)絡(luò)將該數(shù)據(jù)塊從其他Alluxio-Worker 緩存至本地。AlluxioService以數(shù)據(jù)寫入的方式創(chuàng)建一個(gè)本地?cái)?shù)據(jù)塊，隨機(jī)選擇一個(gè)存有該數(shù)據(jù)塊副本的AlluxioWorker 請(qǐng)求數(shù)據(jù)寫入本地，然后與本地?cái)?shù)據(jù)塊命中時(shí)的方式一致，獲得本地?cái)?shù)據(jù)塊的存儲(chǔ)路徑，具體過程如圖6 所示，各步驟順序以序號(hào)在圖中標(biāo)出，虛線箭頭表示指令交互，實(shí)線箭頭表示數(shù)據(jù)交互。

圖6 遠(yuǎn)程數(shù)據(jù)塊命中數(shù)據(jù)讀取流程圖

3.2.3底層存儲(chǔ)系統(tǒng)數(shù)據(jù)塊命中

當(dāng)數(shù)據(jù)塊位置信息為空時(shí)，表明數(shù)據(jù)位于底層存儲(chǔ)系統(tǒng)中。此時(shí)AlluxioService以數(shù)據(jù)寫入的方式創(chuàng)建一個(gè)本地?cái)?shù)據(jù)塊，通知AlluxioWorker 從底層存儲(chǔ)系統(tǒng)讀取數(shù)據(jù)并寫入該數(shù)據(jù)塊中，然后與本地?cái)?shù)據(jù)塊命中時(shí)的方式一致，獲得本地?cái)?shù)據(jù)塊的存儲(chǔ)路徑，詳細(xì)過程如圖7所示，各步驟順序以序號(hào)形式標(biāo)出，其中虛線箭頭為指令交互，實(shí)線箭頭為數(shù)據(jù)交互。

3.3 高效讀寫本地?cái)?shù)據(jù)塊文件

為進(jìn)一步提高數(shù)據(jù)的訪問性能，本文在提供本地?cái)?shù)據(jù)訪問時(shí)引入了內(nèi)存映射技術(shù)，從而獲得更好的訪問效率。

圖7 底層存儲(chǔ)系統(tǒng)數(shù)據(jù)塊命中數(shù)據(jù)讀取流程圖

3.3.1內(nèi)存映射技術(shù)概述

內(nèi)存映射[11]是操作系統(tǒng)內(nèi)核提供的將文件內(nèi)容映射到進(jìn)程線性地址空間的技術(shù)，是POSIX 標(biāo)準(zhǔn)接口之一，對(duì)應(yīng)系統(tǒng)調(diào)用為“mmap”。內(nèi)存映射技術(shù)主要用于提高IO性能，操作系統(tǒng)使用該技術(shù)加載進(jìn)程及動(dòng)態(tài)庫，用戶也可以使用該技術(shù)進(jìn)行高效的進(jìn)程間數(shù)據(jù)共享。

3.3.2與文件讀寫接口對(duì)比

為減少對(duì)磁盤等低速存儲(chǔ)設(shè)備的反復(fù)讀寫，保護(hù)設(shè)備，提升IO 性能，Linux 內(nèi)核使用了頁緩存機(jī)制在內(nèi)存中保存訪問過的文件數(shù)據(jù)（除DirectIO 模式外）。由于頁緩存在內(nèi)核地址空間中，因此會(huì)有額外的一次數(shù)據(jù)拷貝。內(nèi)存映射技術(shù)將文件的讀寫轉(zhuǎn)換為內(nèi)存地址空間的訪問，無需額外的系統(tǒng)調(diào)用（如read、write等），減少了數(shù)據(jù)拷貝次數(shù)[12]，因而比傳統(tǒng)文件讀寫更高效。

當(dāng)用戶進(jìn)程在順序讀取文件時(shí)，內(nèi)核會(huì)根據(jù)一次讀取數(shù)據(jù)的大小預(yù)讀數(shù)據(jù)到頁緩存中，以提高讀取性能。當(dāng)使用內(nèi)存映射技術(shù)時(shí)，雖然內(nèi)核將文件數(shù)據(jù)直接映射到了進(jìn)程地址空間中，但該段空間是不包含任何頁的線性區(qū)，訪問數(shù)據(jù)時(shí)會(huì)首先觸發(fā)缺頁中斷，中斷處理程序“請(qǐng)求調(diào)頁”并讀入數(shù)據(jù)之后，才能夠完成訪問[13]。隨著硬件技術(shù)的發(fā)展，缺頁中斷的處理開銷已經(jīng)大于內(nèi)存數(shù)據(jù)拷貝。因此，在順序讀取文件時(shí)通過合理的讀取方法，read調(diào)用能夠獲得比內(nèi)存映射更好的性能（在4.1小節(jié)可得到驗(yàn)證）。

3.4 Alluxio隨機(jī)讀寫機(jī)制的特點(diǎn)分析

基于以上的分析，Alluxio 新式隨機(jī)讀寫機(jī)制能夠?yàn)橛脩魩砀咝院捅憬菪?，使用戶在集群環(huán)境中充分利用內(nèi)存加速計(jì)算性能。除此以外，新式接口還保證了以下特性。

（1）完全數(shù)據(jù)本地化：通過預(yù)先緩存的策略，新式接口保證了任何讀寫情況下的數(shù)據(jù)本地化，使依賴于本地文件系統(tǒng)路徑的傳統(tǒng)數(shù)據(jù)分析程序得以運(yùn)行。用戶能夠便捷地將原有算法或程序移植到Hadoop、Spark等分布式平臺(tái)中，從而快速實(shí)現(xiàn)文件級(jí)并行化。

（2）可靠性：新式接口完全依賴于原有的數(shù)據(jù)訪問機(jī)制，并未打破Alluxio 的數(shù)據(jù)訪問流程，因此使用新的機(jī)制成功完成的數(shù)據(jù)讀寫過程不會(huì)帶來新的可靠性問題。

（3）容錯(cuò)性：如果在讀取本地?cái)?shù)據(jù)過程中發(fā)生異常，不會(huì)對(duì)數(shù)據(jù)和Alluxio系統(tǒng)造成任何影響。如果在寫入本地?cái)?shù)據(jù)時(shí)發(fā)生異常，則會(huì)通知用戶程序進(jìn)行數(shù)據(jù)重寫，AlluxioWorker會(huì)定期清理未正確關(guān)閉的數(shù)據(jù)塊。在讀取遠(yuǎn)程數(shù)據(jù)及底層存儲(chǔ)系統(tǒng)數(shù)據(jù)時(shí)需要先在本地進(jìn)行數(shù)據(jù)緩存，發(fā)生異常時(shí)，處理方法與數(shù)據(jù)本地寫入時(shí)一致。

圖8 數(shù)據(jù)本地化寫入性能對(duì)比圖

4 實(shí)驗(yàn)測(cè)試及結(jié)果分析

本文提出的Alluxio數(shù)據(jù)隨機(jī)讀寫機(jī)制是在Alluxio 1.6.1版本基礎(chǔ)上實(shí)現(xiàn)。經(jīng)過進(jìn)一步調(diào)研，新式數(shù)據(jù)讀寫機(jī)制依賴的原有數(shù)據(jù)訪問機(jī)制在更新版本的Alluxio中沒有變化，因此能夠適配更新版本的Alluxio。

本文的實(shí)驗(yàn)環(huán)境是一個(gè)5 節(jié)點(diǎn)組成的集群，包括1個(gè) AlluxioMaster 節(jié)點(diǎn)和 4 個(gè) AlluxioWorker 節(jié)點(diǎn)。為方便測(cè)試Alluxio集群運(yùn)行情況，還部署了Hadoop-2.7.5和Spark-2.4.0，共4 TB的HDFS存儲(chǔ)空間，使用Spark自帶的Standalone模式進(jìn)行任務(wù)調(diào)度。AlluxioMaster、NameNode和 Standalone Master 部署于主節(jié)點(diǎn)上，AlluxioWorker、DataNode 和Standalone Worker 部署于從節(jié)點(diǎn)上，各個(gè)節(jié)點(diǎn)的軟硬件情況如表1所示。

圖9 數(shù)據(jù)本地化讀取性能對(duì)比圖

表1 測(cè)試集群軟硬件環(huán)境

為驗(yàn)證Alluxio 新式數(shù)據(jù)隨機(jī)讀寫接口的性能，本文在測(cè)試環(huán)境中對(duì)其進(jìn)行了測(cè)試，內(nèi)容包括：Alluxio新式接口的讀寫性能、集群作業(yè)讀寫性能測(cè)試和Alluxio在實(shí)際應(yīng)用中的性能測(cè)試。

4.1 讀寫性能測(cè)試

本文通過測(cè)試讀寫不同大小文件時(shí)的數(shù)據(jù)吞吐量，對(duì)比Alluxio原生接口和新式接口讀寫數(shù)據(jù)的性能。測(cè)試過程分為數(shù)據(jù)寫入和讀取兩部分，由于數(shù)據(jù)寫入過程為完全本地化的，而數(shù)據(jù)讀取有本地化和非本地化兩種情況，因此測(cè)試過程分為本地化寫入、本地化讀取和非本地化讀取進(jìn)行，測(cè)試情況如圖8、圖9、圖10所示。

由圖中可知，在數(shù)據(jù)本地化寫入時(shí)，使用新式接口通過文件系統(tǒng)寫入數(shù)據(jù)和Alluxio原生接口寫入數(shù)據(jù)時(shí)的性能基本一致，而使用新式接口以內(nèi)存映射方式寫入數(shù)據(jù)時(shí)，可獲得約138.6%～247.6%的性能提升。在數(shù)據(jù)本地化讀取時(shí)，使用新式接口可獲得約12.4%～16.6%的性能提升。在數(shù)據(jù)非本地化讀取時(shí)，由于新式接口先要將數(shù)據(jù)完整緩存至本地才能讀取，因此整體性能比原生接口下降了6.2%～11.2%。

4.2 模擬集群作業(yè)測(cè)試

為測(cè)試Alluxio原生接口和新式接口在集群中的整體讀寫性能，本文在Spark 上實(shí)現(xiàn)了一個(gè)簡(jiǎn)單測(cè)試用例模擬集群作業(yè)讀寫。測(cè)試文件為大小1 GB的二進(jìn)制隨機(jī)數(shù)據(jù)文件。模擬讀測(cè)試為讀取該文件數(shù)據(jù)，對(duì)數(shù)據(jù)求余并按余數(shù)統(tǒng)計(jì)隨機(jī)數(shù)的出現(xiàn)次數(shù)。模擬寫測(cè)試是使用隨機(jī)數(shù)生成器生成該文件。圖11和圖12為各項(xiàng)測(cè)試的性能對(duì)比，并行任務(wù)數(shù)與作業(yè)處理的文件數(shù)一致，以單個(gè)任務(wù)的平均執(zhí)行時(shí)間評(píng)估性能。

圖11 集群作業(yè)讀取性能測(cè)試圖

圖12 集群作業(yè)寫入性能測(cè)試圖

由圖中可知，使用本文提出的Alluxio 數(shù)據(jù)隨機(jī)訪問接口，不僅能夠滿足數(shù)據(jù)的讀寫需求，還能夠進(jìn)一步提升計(jì)算性能。在使用新式接口讀取數(shù)據(jù)時(shí)，通過本地文件系統(tǒng)訪問數(shù)據(jù)的性能提升了約2%～4%，使用內(nèi)存映射訪問數(shù)據(jù)的性能提升了約22～26 倍。在使用新式接口寫入數(shù)據(jù)時(shí)，通過本地文件系統(tǒng)訪問數(shù)據(jù)的性能提升了約32.8%～39.2%，使用內(nèi)存映射訪問數(shù)據(jù)的性能提升了約8～9倍。

4.3 實(shí)際應(yīng)用測(cè)試

高能物理計(jì)算是典型的數(shù)據(jù)密集型計(jì)算，通常采用計(jì)算和存儲(chǔ)分離的模式[14]，由計(jì)算節(jié)點(diǎn)構(gòu)成計(jì)算集群，通過高速網(wǎng)絡(luò)從存儲(chǔ)系統(tǒng)中訪問數(shù)據(jù)，存儲(chǔ)系統(tǒng)通常采用高性能分布式文件系統(tǒng)如Lustre 和GlusterFS，掛載到計(jì)算集群中，使各個(gè)節(jié)點(diǎn)的文件系統(tǒng)結(jié)構(gòu)一致。作業(yè)調(diào)度系統(tǒng)對(duì)用戶提交的作業(yè)進(jìn)行統(tǒng)一調(diào)度和管理，為保證作業(yè)高吞吐量，調(diào)度系統(tǒng)對(duì)作業(yè)所用計(jì)算資源進(jìn)行了限制。計(jì)算、存儲(chǔ)分離的模式在高并發(fā)場(chǎng)景下，網(wǎng)絡(luò)的性能和擁塞程度成為計(jì)算的瓶頸，因此高能所也在探索基于Hadoop計(jì)算與存儲(chǔ)結(jié)合的高能物理計(jì)算模式[15]。

實(shí)際應(yīng)用測(cè)試選用了高能天體物理中的高海拔宇宙線實(shí)驗(yàn)（Large High Altitude Air Shower Observatory，LHAASO）[16]數(shù)據(jù)觸發(fā)判選軟件進(jìn)行測(cè)試，每個(gè)源文件大小約為1 GB，包含約4 000 萬個(gè)物理事例，該程序需要在這些事例中篩選出可能有物理意義的事例。數(shù)據(jù)處理過程受傳統(tǒng)計(jì)算集群的資源限制被劃分為5 個(gè)步驟，對(duì)應(yīng)5 個(gè)數(shù)據(jù)處理子程序，子程序之間的中間數(shù)據(jù)通過文件進(jìn)行傳遞。

本實(shí)驗(yàn)在原有軟件基礎(chǔ)上使用了Spark實(shí)現(xiàn)了文件級(jí)并行的分布式LHAASO 數(shù)據(jù)觸發(fā)判選程序，測(cè)試過程對(duì)比了使用Alluxio、HDFS 和Lustre 存儲(chǔ)中間數(shù)據(jù)情況下的性能，如圖13所示，并行任務(wù)數(shù)與作業(yè)處理的文件數(shù)一致，以單個(gè)任務(wù)的平均執(zhí)行時(shí)間評(píng)估性能。

圖13 高能物理作業(yè)性能測(cè)試對(duì)比圖

由圖中可知，在實(shí)際的高能物理作業(yè)中，使用Alluxio 能夠有效提升作業(yè)整體的性能。與使用HDFS存儲(chǔ)中間數(shù)據(jù)相比，使用Alluxio 能夠提升17.7%～192.0%的性能；與Lustre 相比，使用Alluxio 能夠提升115.2%～490.0%的性能。

5 結(jié)束語

本文針對(duì)Alluxio不能滿足特殊場(chǎng)景下的數(shù)據(jù)隨機(jī)訪問，以及Alluxio 原生接口不能完全發(fā)揮內(nèi)存性能的問題，深入研究了Alluxio的數(shù)據(jù)讀寫過程，提出了一種新的高性能數(shù)據(jù)訪問方法。通過改變數(shù)據(jù)訪問和緩存的時(shí)機(jī)，將對(duì)Alluxio 中的文件訪問轉(zhuǎn)化為對(duì)本地內(nèi)存文件系統(tǒng)中的文件訪問，并在此基礎(chǔ)上使用內(nèi)存映射技術(shù)提供更高性能的數(shù)據(jù)讀寫接口，從而實(shí)現(xiàn)了數(shù)據(jù)的隨機(jī)訪問和高性能讀寫。在數(shù)據(jù)讀寫測(cè)試和實(shí)際應(yīng)用測(cè)試中，該方法在保證數(shù)據(jù)隨機(jī)訪問的正確性同時(shí)，取得了很好的性能提升。Alluxio的高性能數(shù)據(jù)隨機(jī)訪問接口對(duì)于在以高能物理為代表的科學(xué)大數(shù)據(jù)應(yīng)用中的使用和推廣具有重要意義。