Alluxio數據隨機訪問方法的研究

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

1.中國科學院 高能物理研究所，北京 100049

2.中國科學院大學，北京 100049

1 引言

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

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

與HDFS設計理念一致，Alluxio簡化了文件系統實現，提供Java 接口支持文件的隨機讀取和順序寫入，不支持文件的隨機寫入[8]。但在某些大數據應用中，尤其是科學計算等數據分析應用通常需要支持隨機讀寫（例如高能物理中廣泛使用的ROOT 框架[9]）。由于科學計算歷史久遠，部分代碼難以快速修改適應Alluxio 數據訪問接口。雖然Alluxio 支持通過FUSE 掛載到根文件系統上，但掛載后的文件系統仍不支持隨機寫入[10]，并且FUSE本身性能較差，嚴重制約了讀寫性能。因此在這些領域，Alluxio的應用受到了一定限制。另外，傳統的基于Java 數據流接口無法靈活利用現有的新式高性能數據訪問技術（例如內存映射、Java NIO等），仍有較大性能提升空間。

本文針對Alluxio 不支持數據隨機寫入的問題，在現有數據訪問模式基礎上，提出一種新的Alluxio 數據隨機訪問機制。該機制能夠使傳統程序適應新的存儲系統，用戶也可以利用該機制在數據分析時靈活使用各類數據訪問技術，從而提高數據讀寫時的效率。

2 相關研究情況介紹

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

圖1 Alluxio文件系統結構圖

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

圖2 Alluxio標準數據讀取流程圖

圖3 Alluxio標準數據寫入流程圖

3 Alluxio隨機讀寫機制的設計與實現

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

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

3.1 數據寫入過程

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

圖4 Alluxio數據隨機寫流程圖

3.2 數據讀取過程

Alluxio 的數據讀取過程為獲得本地數據塊的路徑進行文件讀寫，若所訪問文件沒有本地數據塊時，則先完成本地數據塊的緩存。首先AlluxioService向Alluxio-Master請求文件的元數據信息，得到URIStatus對象，該對象中包含了該文件的所有數據塊ID。通過數據塊ID，AlluxioService 再向 AlluxioMaster 請求某個數據塊的基本信息，得到BlockInfo對象，該對象中包含了該數據塊的所有位置情況。根據數據塊存儲位置情況，有本地數據塊命中、遠程數據塊命中、底層存儲系統數據塊命中三種不同的處理方式。

3.2.1 本地數據塊命中

當數據塊位置信息中包含本地的AlluxioWorker時，表明本節(jié)點上緩存了該數據塊。AlluxioService 通過向本地AlluxioWorker 發(fā)送打開本地數據塊請求（LocalBlockOpenRequest），得到響應（LocalBlockOpen-Response），其中包含該數據塊對應的本地文件路徑，用戶程序由此讀取本地文件系統中的數據，如圖5 所示，各步驟以序號標出，虛線箭頭表示指令交互，實線箭頭表示數據交互。

3.2.2 遠程數據塊命中

圖5 本地數據塊命中數據讀取流程圖

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

圖6 遠程數據塊命中數據讀取流程圖

3.2.3底層存儲系統數據塊命中

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

3.3 高效讀寫本地數據塊文件

為進一步提高數據的訪問性能，本文在提供本地數據訪問時引入了內存映射技術，從而獲得更好的訪問效率。

圖7 底層存儲系統數據塊命中數據讀取流程圖

3.3.1內存映射技術概述

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

3.3.2與文件讀寫接口對比

為減少對磁盤等低速存儲設備的反復讀寫，保護設備，提升IO 性能，Linux 內核使用了頁緩存機制在內存中保存訪問過的文件數據（除DirectIO 模式外）。由于頁緩存在內核地址空間中，因此會有額外的一次數據拷貝。內存映射技術將文件的讀寫轉換為內存地址空間的訪問，無需額外的系統調用（如read、write等），減少了數據拷貝次數[12]，因而比傳統文件讀寫更高效。

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

3.4 Alluxio隨機讀寫機制的特點分析

基于以上的分析，Alluxio 新式隨機讀寫機制能夠為用戶帶來高效性和便捷性，使用戶在集群環(huán)境中充分利用內存加速計算性能。除此以外，新式接口還保證了以下特性。

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

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

（3）容錯性：如果在讀取本地數據過程中發(fā)生異常，不會對數據和Alluxio系統造成任何影響。如果在寫入本地數據時發(fā)生異常，則會通知用戶程序進行數據重寫，AlluxioWorker會定期清理未正確關閉的數據塊。在讀取遠程數據及底層存儲系統數據時需要先在本地進行數據緩存，發(fā)生異常時，處理方法與數據本地寫入時一致。

圖8 數據本地化寫入性能對比圖

4 實驗測試及結果分析

本文提出的Alluxio數據隨機讀寫機制是在Alluxio 1.6.1版本基礎上實現。經過進一步調研，新式數據讀寫機制依賴的原有數據訪問機制在更新版本的Alluxio中沒有變化，因此能夠適配更新版本的Alluxio。

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

圖9 數據本地化讀取性能對比圖

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

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

4.1 讀寫性能測試

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

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

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

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

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

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

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

4.3 實際應用測試

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

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

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

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

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

5 結束語

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