面向地震數(shù)據(jù)交互分析場(chǎng)景的高效分布式緩存框架

龐 銳,許自龍,朱海偉,陳海洋,邵志東

(中國(guó)石化石油物探技術(shù)研究院有限公司,江蘇南京211103)

隨著“兩寬一高”地震采集技術(shù)的發(fā)展應(yīng)用,采集得到的原始地震勘探數(shù)據(jù)呈指數(shù)級(jí)增長(zhǎng),數(shù)據(jù)規(guī)模越來(lái)越大[1]。對(duì)于大數(shù)據(jù),麥肯錫全球研究院給出的定義是:一種規(guī)模大到在獲取、存儲(chǔ)、管理、分析方面大大超出了傳統(tǒng)數(shù)據(jù)庫(kù)軟件工具能力范圍的數(shù)據(jù)集合[2-3]。以炮集記錄為例,采集覆蓋次數(shù)由幾十次增至幾千次,單炮記錄可超過(guò)萬(wàn)道,數(shù)據(jù)量由10MB增至250MB,每天產(chǎn)生的數(shù)據(jù)量達(dá)到了TB級(jí)別[4]。

采用二維圖形顯示的方式對(duì)單炮記錄進(jìn)行交互分析[5],需要頻繁地在單炮記錄間切換,因此對(duì)實(shí)時(shí)響應(yīng)要求較高,一般希望地震數(shù)據(jù)瀏覽延遲不超過(guò)1s。但在面對(duì)單炮記錄超過(guò)萬(wàn)道的大規(guī)模數(shù)據(jù)時(shí),通常地震數(shù)據(jù)處理軟件由于本身內(nèi)存限制,無(wú)法直接緩存大量單炮記錄,必須反復(fù)從底層物理存儲(chǔ)中讀取數(shù)據(jù),因而數(shù)據(jù)實(shí)時(shí)訪問(wèn)時(shí)間延遲變長(zhǎng),從而導(dǎo)致交互操作出現(xiàn)卡頓,影響交互分析的流暢性,降低了工作效率。

中國(guó)石化自主研發(fā)的大型地震一體化軟件平臺(tái)(π-Frame)是地震數(shù)據(jù)處理的專業(yè)應(yīng)用平臺(tái),目前平臺(tái)底層使用Hadoop分布式文件系統(tǒng)(HDFS)存儲(chǔ)大規(guī)模疊前地震數(shù)據(jù),HDFS是一種具有高可靠性的分布式文件系統(tǒng),能夠存儲(chǔ)PB級(jí)別的大規(guī)模數(shù)據(jù)[6]。在進(jìn)行單炮交互分析時(shí),需要反復(fù)從HDFS底層文件系統(tǒng)中讀取數(shù)據(jù),當(dāng)單炮記錄超過(guò)萬(wàn)道時(shí),讀取一炮記錄的時(shí)間延遲甚至超過(guò)2s,因而交互操作卡頓,降低了用戶體驗(yàn)。

為此,本文針對(duì)大規(guī)模數(shù)據(jù)交互分析的場(chǎng)景,研究設(shè)計(jì)了一套面向地震交互分析專用的高效數(shù)據(jù)緩存框架,利用分布式內(nèi)存技術(shù)預(yù)先緩存關(guān)鍵地震數(shù)據(jù),從而提高數(shù)據(jù)實(shí)時(shí)訪問(wèn)性能,減少交互操作卡頓,提高工作效率。

1 不同存儲(chǔ)系統(tǒng)下地震數(shù)據(jù)讀取性能對(duì)比分析

用于二維圖形顯示的地震數(shù)據(jù)可以抽象為數(shù)據(jù)道的集合。以疊前炮集為例,由多個(gè)單炮記錄組成,單炮記錄由多道采樣數(shù)據(jù)組成。每一道數(shù)據(jù)包含N個(gè)浮點(diǎn)類型的采樣值,這樣的一道數(shù)據(jù)稱之為一個(gè)Trace,由多道相關(guān)數(shù)據(jù)組成的集合稱之為T(mén)raceSet。本文工作的數(shù)據(jù)緩存結(jié)構(gòu)以一個(gè)TraceSet為最小單位來(lái)進(jìn)行,數(shù)據(jù)讀寫(xiě)的最小單位是一個(gè)TraceSet,實(shí)際應(yīng)用中,將炮集、共中心道集、共偏移距道集等統(tǒng)一轉(zhuǎn)換成抽象的二維TraceSet對(duì)象進(jìn)行管理。

HDFS是一種可以運(yùn)行在通用硬件上的分布式文件系統(tǒng),它和早期的分布式文件系統(tǒng)有一些共同點(diǎn),同時(shí),相比其它分布式文件系統(tǒng),它有很多自己的特點(diǎn)。HDFS是一個(gè)高度容錯(cuò)性的系統(tǒng),適合部署在廉價(jià)的機(jī)器上,HDFS能提供高吞吐量的數(shù)據(jù)訪問(wèn),非常適合大規(guī)模數(shù)據(jù)集的應(yīng)用[7-8]。

Alluxio是一種以內(nèi)存為中心的分布式存儲(chǔ)系統(tǒng),提供內(nèi)存級(jí)別的數(shù)據(jù)讀寫(xiě),非常適合多次讀寫(xiě)以及讀寫(xiě)性能要求較高的場(chǎng)景,熱數(shù)據(jù)的讀取速度比磁盤(pán)高一個(gè)量級(jí)[9-10]。

為了對(duì)比HDFS和Alluxio的性能差異,本文針對(duì)單炮數(shù)據(jù)讀取場(chǎng)景,分別評(píng)估了HDFS和Alluxio在同一種讀取方式下的性能差異。測(cè)試數(shù)據(jù)共3000炮,每炮規(guī)模為3000道×6000采樣點(diǎn),總體數(shù)據(jù)的物理大小約為201GB。

本文的不同存儲(chǔ)性能評(píng)估實(shí)驗(yàn)使用的集群共有5個(gè)物理節(jié)點(diǎn),其中1臺(tái)機(jī)器作為主節(jié)點(diǎn)(Alluxio-Master,HDFS-Namenode),3臺(tái)作為從節(jié)點(diǎn)(Alluxio-Worker,HDFS-DataNode),1臺(tái)作為客戶端節(jié)點(diǎn)用于執(zhí)行實(shí)驗(yàn)程序。實(shí)驗(yàn)環(huán)境的軟硬件信息如表1 所示。

表1 不同存儲(chǔ)性能評(píng)估實(shí)驗(yàn)環(huán)境配置

讀取性能測(cè)試結(jié)果如圖1和圖2所示,可以看出:HDFS的讀取耗時(shí)在300～500ms波動(dòng)(圖1);Alluxio的第1次讀取耗時(shí)較長(zhǎng),主要是因?yàn)榈?次讀取需要將數(shù)據(jù)從磁盤(pán)加載到內(nèi)存中,磁盤(pán)IO導(dǎo)致耗時(shí)較長(zhǎng),后續(xù)讀取,由于數(shù)據(jù)已經(jīng)在內(nèi)存中,可以直接從內(nèi)存中讀取,耗時(shí)基本穩(wěn)定在100ms左右,數(shù)據(jù)規(guī)模一旦上升,Alluxio的性能會(huì)更好并且更穩(wěn)定[11-12](圖2)。

圖1 HDFS讀取數(shù)據(jù)耗時(shí)

圖2 Alluxio讀取數(shù)據(jù)耗時(shí)

由上述HDFS和Alluxio的性能評(píng)估實(shí)驗(yàn)可以發(fā)現(xiàn),Alluxio讀取剖面的性能優(yōu)于HDFS。究其原因是因?yàn)?TraceSet存儲(chǔ)在HDFS中時(shí),每讀取一個(gè)Trace都需要尋道一次,導(dǎo)致讀取一個(gè)TraceSet需要尋道多次,磁盤(pán)級(jí)別的多次尋道造成了大量性能開(kāi)銷,導(dǎo)致TraceSet讀取時(shí)間較長(zhǎng),難以滿足交互式場(chǎng)景下的性能需求。

2 高效分布式緩存框架

前文綜合對(duì)比分析了HDFS和Alluxio兩類數(shù)據(jù)存儲(chǔ)框架的數(shù)據(jù)讀取性能,發(fā)現(xiàn)Alluxio更適合TraceSet的讀寫(xiě)。然而,原生Alluxio的數(shù)據(jù)塊會(huì)分布在多個(gè)節(jié)點(diǎn)上,對(duì)于1個(gè)TraceSet,會(huì)出現(xiàn)跨節(jié)點(diǎn)的尋道操作,這會(huì)降低讀取性能。為保證從Alluxio-Worker讀取數(shù)據(jù)的本地性,本文提出在每個(gè)Alluxio-Worker節(jié)點(diǎn)上部署一個(gè)代理服務(wù),用于直接與本地的Alluxio-Worker進(jìn)行數(shù)據(jù)交換,這樣既利用了Alluxio內(nèi)存存儲(chǔ)利于讀寫(xiě)的特性,也降低了多次網(wǎng)絡(luò)傳輸?shù)拈_(kāi)銷。

2.1 系統(tǒng)架構(gòu)

綜上所述,本文提出了一套基于Alluxio的分布式緩存框架,系統(tǒng)架構(gòu)如圖3所示,主要包括3個(gè)模塊:CacheClient,CacheMaster,CacheHandler,圖3中虛線為元數(shù)據(jù)路徑,實(shí)線為數(shù)據(jù)路徑。

圖3 基于Alluxio的分布式緩存框架整體結(jié)構(gòu)

該架構(gòu)基本滿足了分布式緩存框架的重要功能需求,包括:多用戶場(chǎng)景下的可用性、保存所有TraceSet的元數(shù)據(jù)信息、支持覆蓋寫(xiě)、異步加載數(shù)據(jù)、數(shù)據(jù)的負(fù)載均衡等。

2.2 CacheMaster模塊

CacheMaster是整個(gè)分布式緩存框架的核心模塊,負(fù)責(zé)管理整個(gè)框架的數(shù)據(jù)調(diào)度、數(shù)據(jù)管理、狀態(tài)監(jiān)控等功能。具體包括:

1) 將要寫(xiě)入的TraceSet以文件的形式,存儲(chǔ)到分布式緩存框架中;

2) 存儲(chǔ)TraceSet時(shí),會(huì)根據(jù)所有節(jié)點(diǎn)的可用內(nèi)存來(lái)均衡調(diào)度,達(dá)到負(fù)載均衡的效果;

3) 保存所有已存儲(chǔ)的TraceSet的元信息,包括所在節(jié)點(diǎn)、文件大小等;

4) 支持TraceSet的覆蓋寫(xiě),方式為寫(xiě)臨時(shí)文件→刪除舊文件→重命名;

5) 支持?jǐn)?shù)據(jù)生存周期(TTL)策略,到設(shè)定時(shí)間后,內(nèi)存中的數(shù)據(jù)自動(dòng)釋放;

6) 支持監(jiān)控所有存儲(chǔ)節(jié)點(diǎn)的服務(wù)狀態(tài),通過(guò)心跳機(jī)制來(lái)收集存儲(chǔ)節(jié)點(diǎn)的狀態(tài)信息。

2.3 CacheHandler模塊

CacheHandler負(fù)責(zé)具體執(zhí)行分布式緩存框架的讀寫(xiě)功能,需要與Alluxio-Worker部署在同一臺(tái)節(jié)點(diǎn)上,用于直接操作本地的內(nèi)存數(shù)據(jù),包括讀取、寫(xiě)入、刪除、加載等操作,保證本地性。

同時(shí)為了增加系統(tǒng)的可靠性與可擴(kuò)展性,CacheHandler會(huì)主動(dòng)向CacheMaster發(fā)送心跳信息,一方面可用于CacheMaster對(duì)所有CacheHandler服務(wù)狀態(tài)的監(jiān)控;另一方面,當(dāng)系統(tǒng)需要擴(kuò)容時(shí),直接新增一個(gè)CacheHandler服務(wù),可以方便靈活地加入集群中提供服務(wù)。

2.4 CacheClient模塊

CacheClient模塊部署在用戶端,直接向用戶的客戶端提供服務(wù)接口,處理用戶請(qǐng)求,如:數(shù)據(jù)讀取、寫(xiě)入、刪除等。CacheClient目前提供表2所示的6種接口方法。

表2 分布式緩存框架接口方法

2.5 重要功能介紹

當(dāng)前的分布式緩存框架提供的主要功能包括:讀數(shù)據(jù)、預(yù)加載數(shù)據(jù)、寫(xiě)數(shù)據(jù)、覆蓋寫(xiě)數(shù)據(jù)、清除數(shù)據(jù)、讀元數(shù)據(jù)。

2.5.1 讀數(shù)據(jù)功能

讀數(shù)據(jù)功能具體包括兩種。對(duì)于TraceSet的多維數(shù)據(jù)結(jié)構(gòu)體來(lái)說(shuō):支持x方向的全量讀取、間隔讀取;也支持設(shè)置x和y方向的起止范圍。讀數(shù)據(jù)流程如圖4所示,其中①,②,③,④代表4個(gè)步驟:①CacheClient發(fā)起讀請(qǐng)求,從CacheMaster獲取文件所在節(jié)點(diǎn)的信息;②CacheMaster將文件所在節(jié)點(diǎn)的IP返回給CacheClient;③CacheClient拿到IP后直接去對(duì)應(yīng)的節(jié)點(diǎn)請(qǐng)求CacheHandler服務(wù)讀取數(shù)據(jù);④CacheHandler讀取內(nèi)存中的數(shù)據(jù)后返回給CacheClient。

圖4 讀數(shù)據(jù)流程

2.5.2 預(yù)加載數(shù)據(jù)功能

預(yù)加載數(shù)據(jù)功能支持在讀取之前先將指定的數(shù)據(jù)緩存到內(nèi)存中,加載時(shí)支持批量加載,以加速后續(xù)的數(shù)據(jù)讀取。預(yù)加載數(shù)據(jù)流程如圖5所示,其中①,②,③代表3個(gè)步驟:①CacheClient發(fā)起加載請(qǐng)求到CacheMaster,CacheMaster計(jì)算得出可用節(jié)點(diǎn)的IP,同時(shí)記錄TraceSet和IP的映射關(guān)系;②CacheMaster通知對(duì)應(yīng)的CacheHandler加載數(shù)據(jù);③CacheHandler接收到請(qǐng)求后向底層存儲(chǔ)請(qǐng)求讀取數(shù)據(jù),收到底層存儲(chǔ)返回的數(shù)據(jù)后將其寫(xiě)入內(nèi)存中。

圖5 預(yù)加載數(shù)據(jù)流程

2.5.3 寫(xiě)數(shù)據(jù)功能

寫(xiě)數(shù)據(jù)功能支持客戶端在圖形頁(yè)面上選中數(shù)據(jù)后,將數(shù)據(jù)寫(xiě)入到分布式緩存中,下次讀取時(shí)直接從內(nèi)存中讀取,從而縮短讀取時(shí)間。寫(xiě)數(shù)據(jù)流程如圖6所示,其中①,②,③代表3個(gè)步驟:①CacheClient向CacheMaster發(fā)起寫(xiě)請(qǐng)求,CacheMaster計(jì)算可用IP,記錄TraceSet和IP的映射關(guān)系;②CacheMaster返回IP地址給CacheClient;③CacheClient得到IP后將數(shù)據(jù)發(fā)送到對(duì)應(yīng)的CacheHandler服務(wù)上,CacheHandler再將數(shù)據(jù)寫(xiě)入內(nèi)存中。

圖6 寫(xiě)數(shù)據(jù)流程

2.6 特性介紹

2.6.1 負(fù)載均衡

負(fù)載均衡的原則是讓TraceSet數(shù)據(jù)集盡可能地均勻分布在多個(gè)存儲(chǔ)節(jié)點(diǎn)上,目的是為了降低單個(gè)節(jié)點(diǎn)的讀寫(xiě)壓力,這樣讀寫(xiě)性能會(huì)更好。如果系統(tǒng)的負(fù)載不均衡,首先會(huì)造成多個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)存儲(chǔ)量大小不同,部分節(jié)點(diǎn)壓力過(guò)大;其次會(huì)造成部分節(jié)點(diǎn)內(nèi)存空間不足而頻繁出錯(cuò),造成系統(tǒng)可用性和穩(wěn)定性下降。因此負(fù)載均衡在分布式系統(tǒng)中是非常必要的。

當(dāng)前分布式緩存框架實(shí)現(xiàn)負(fù)載均衡策略的具體流程為:CacheClient發(fā)起寫(xiě)請(qǐng)求到CacheMaster,CacheMaster計(jì)算出當(dāng)前剩余內(nèi)存最大的節(jié)點(diǎn)IP,將IP返回給CacheClient,CacheClient得到IP后將數(shù)據(jù)發(fā)送到對(duì)應(yīng)的CacheHandler,CacheHandler接收到數(shù)據(jù)后將數(shù)據(jù)寫(xiě)入本地的Alluxio-Worker中。

2.6.2 多級(jí)數(shù)據(jù)TTL策略

數(shù)據(jù)TTL的用途是到期后自動(dòng)刪除分布式緩存中的文件,其目標(biāo)主要是減輕集群壓力。如果沒(méi)有TTL策略,用戶也沒(méi)有及時(shí)刪除一些不用的數(shù)據(jù),就會(huì)造成系統(tǒng)內(nèi)存中大量無(wú)用數(shù)據(jù)的堆積,浪費(fèi)資源,并且大量無(wú)用文件或目錄也會(huì)占用系統(tǒng)的元數(shù)據(jù)空間,對(duì)系統(tǒng)性能有一定的影響。

分布式數(shù)據(jù)緩存的TTL包括兩級(jí):一是針對(duì)單個(gè)文件的TTL,二是針對(duì)所有空目錄的TTL。如要用到被刪除文件,可以重新加載。其具體的流程為:CacheMaster根據(jù)配置的TTL來(lái)定期刪除文件,策略是以最近一次使用開(kāi)始計(jì)時(shí),到期后自動(dòng)刪除元數(shù)據(jù)以及Alluxio-Worker中的數(shù)據(jù),用戶目錄下的文件因?yàn)門(mén)TL策略被刪除后,則該用戶的所有空目錄也會(huì)被刪除。

2.6.3 節(jié)點(diǎn)狀態(tài)監(jiān)控

在一個(gè)分布式系統(tǒng)中,主節(jié)點(diǎn)一般需要監(jiān)控所有從節(jié)點(diǎn)的狀態(tài),如果沒(méi)有監(jiān)控機(jī)制,就會(huì)出現(xiàn)如下問(wèn)題:當(dāng)某個(gè)從節(jié)點(diǎn)由于網(wǎng)絡(luò)或硬件故障導(dǎo)致無(wú)法正常提供服務(wù)時(shí),主節(jié)點(diǎn)仍然繼續(xù)向這個(gè)節(jié)點(diǎn)進(jìn)行數(shù)據(jù)讀寫(xiě),從而造成讀寫(xiě)失敗。

在當(dāng)前分布式緩存框架中,CacheHandler會(huì)定時(shí)通過(guò)心跳信息向CacheMaster上報(bào)自己的狀態(tài),然后CacheMaster也會(huì)定期檢查所有的狀態(tài)信息,根據(jù)一定的規(guī)則來(lái)判斷CacheHandler是否失效。具體的流程為:所有CacheHandler會(huì)通過(guò)心跳定期向CacheMaster上報(bào)狀態(tài)信息,CacheMaster會(huì)定時(shí)輪詢每個(gè)CacheHandler上報(bào)的狀態(tài)信息,如果發(fā)現(xiàn)某個(gè)CacheHandler最近一次上報(bào)時(shí)間超過(guò)設(shè)置的超時(shí)閾值,則認(rèn)為該節(jié)點(diǎn)失效,然后將不再?gòu)脑摴?jié)點(diǎn)讀寫(xiě)數(shù)據(jù)。

2.6.4 元數(shù)據(jù)備份

元數(shù)據(jù)的備份可以有效防止主節(jié)點(diǎn)即CacheMaster的失效而導(dǎo)致元數(shù)據(jù)丟失的錯(cuò)誤。

本文實(shí)現(xiàn)方式是CacheMaster會(huì)定期將內(nèi)存中的元數(shù)據(jù)序列化到磁盤(pán)上,在CacheMaster失效后,下次重啟時(shí),會(huì)自動(dòng)反序列化備份文件,恢復(fù)元數(shù)據(jù)。其具體流程為:CacheMaster接收CacheClient的操作請(qǐng)求,保存元數(shù)據(jù)到內(nèi)存映射中,定期序列化元數(shù)據(jù)到文件中,防止由于CacheMaster的失效而導(dǎo)致元數(shù)據(jù)丟失,CacheMaster重啟時(shí)會(huì)自動(dòng)反序列化元數(shù)據(jù)到內(nèi)存中,繼續(xù)提供服務(wù)。

2.6.5 靈活擴(kuò)展性

當(dāng)前分布式緩存框架具有一定的靈活擴(kuò)展性,可以根據(jù)數(shù)據(jù)量的不斷增加而動(dòng)態(tài)擴(kuò)充節(jié)點(diǎn),并且可以在不重啟服務(wù)的情況下完成。當(dāng)前框架下,CacheHandler采用主動(dòng)上報(bào)的機(jī)制來(lái)注冊(cè)自己,具體流程為:每個(gè)CacheHandler啟動(dòng)時(shí),都會(huì)主動(dòng)通過(guò)心跳信息向CacheMaster上報(bào)自己的狀態(tài)信息,CacheMaster中維護(hù)有一個(gè)所有可用從節(jié)點(diǎn)的列表,接收到CacheHandler的心跳后就將該CacheHandler加入到可用列表,完成擴(kuò)容。

3 分布式緩存框架與地震處理軟件平臺(tái)的對(duì)接

中國(guó)石化自主研發(fā)的大型地震一體化軟件平臺(tái)(π-Frame)是處理地震數(shù)據(jù)的專業(yè)應(yīng)用平臺(tái),目前π-Frame平臺(tái)底層使用HDFS來(lái)存儲(chǔ)大規(guī)模疊前數(shù)據(jù),通過(guò)平臺(tái)提供的IOService數(shù)據(jù)訪問(wèn)接口訪問(wèn)平臺(tái)管理的地震數(shù)據(jù),如圖7所示。

圖7 π-Frame平臺(tái)數(shù)據(jù)讀取示意

為了驗(yàn)證基于Alluxio的分布式緩存框架的有效性,將其與π-Frame平臺(tái)進(jìn)行初步對(duì)接集成,交互應(yīng)用通過(guò)分布式緩存框架獲取數(shù)據(jù),緩存框架通過(guò)IOService到底層存儲(chǔ)獲取數(shù)據(jù),π-Frame平臺(tái)集成分布式緩存框架(層次調(diào)用關(guān)系)如圖8所示。

圖8 π-Frame平臺(tái)集成分布式緩存框架示意

面向地震數(shù)據(jù)的交互應(yīng)用場(chǎng)景,整體按數(shù)據(jù)存儲(chǔ)大小分為3個(gè)層級(jí)(圖9)。

1) 應(yīng)用層:內(nèi)存有限,僅管理當(dāng)前使用的地震數(shù)據(jù);

2) 分布式內(nèi)存層:利用分布式內(nèi)存的大容量?jī)?yōu)勢(shì),緩存于當(dāng)前操作相關(guān)的更大范圍的地震數(shù)據(jù);

3) 平臺(tái)物理存儲(chǔ)層:存儲(chǔ)全部地震數(shù)據(jù)。

圖9 數(shù)據(jù)存儲(chǔ)層級(jí)

4 實(shí)驗(yàn)

4.1 實(shí)驗(yàn)環(huán)境

本文搭建的分布式緩存框架實(shí)驗(yàn)環(huán)境與表1一致,只是在主節(jié)點(diǎn)增加CacheMaster服務(wù)(Alluxio-Master,HDFS-Namenode,CacheMaster),在從節(jié)點(diǎn)增加CacheHandler(Alluxio-Worker,HDFS-DataNode,CacheHandler),客戶端節(jié)點(diǎn)用于部署CacheClient服務(wù)。分布式緩存框架實(shí)驗(yàn)環(huán)境配置如表3所示。

表3 分布式緩存框架實(shí)驗(yàn)環(huán)境配置

4.2 分布式緩存框架性能實(shí)驗(yàn)

分別對(duì)Alluxio原生的性能和TraceSet不同的分布策略下的性能進(jìn)行對(duì)比,一個(gè)TraceSet總共包含1×104道(每道6000采樣點(diǎn))數(shù)據(jù),分別測(cè)試了一次讀取其中的500道(12MB)、1000道(23MB)、2000道(46MB)、4000道(92MB)的性能。

4.2.1 Alluxio原生性能對(duì)比實(shí)驗(yàn)

在Alluxio原生情況下,對(duì)比Alluxio-Worker節(jié)點(diǎn)本地讀取和非本地讀取兩種方式的讀取性能。讀取方式如圖10所示,其中,本地讀取是指客戶端與存放數(shù)據(jù)的Alluxio-Worker在同一節(jié)點(diǎn),數(shù)據(jù)讀取時(shí)直接在節(jié)點(diǎn)內(nèi)部流動(dòng),省去了網(wǎng)絡(luò)傳輸耗時(shí);非本地讀取是指客戶端與存放數(shù)據(jù)的Alluxio-Worker不在同一節(jié)點(diǎn),數(shù)據(jù)讀取時(shí)在節(jié)點(diǎn)間流動(dòng),讀取性能會(huì)受帶寬和RPC(Remote Procedure Call)調(diào)用次數(shù)等因素影響。

圖10 本地讀取與非本地讀取示意

圖11展示了本地讀取與非本地讀取的性能對(duì)比結(jié)果,可以看出,在讀取1個(gè)TraceSet時(shí),本地讀取的性能比非本地讀取的性能好很多,甚至可以達(dá)到7倍的加速比,性能最優(yōu)時(shí)可以在102ms內(nèi)完成數(shù)據(jù)讀取。但在實(shí)際集群的部署應(yīng)用中,客戶端和要讀取的數(shù)據(jù)一般不會(huì)在同一節(jié)點(diǎn),難以做到本地讀取。在使用Alluxio原生的情況下,數(shù)據(jù)讀取如圖11中非本地讀取所示,讀取4000道數(shù)據(jù)需要1354ms,頻繁交互時(shí)會(huì)有一定時(shí)間延遲。

圖11 本地讀取與非本地讀取性能對(duì)比結(jié)果

4.2.2 并行強(qiáng)擴(kuò)展性實(shí)驗(yàn)

將10個(gè)TraceSet分別放在一個(gè)節(jié)點(diǎn)和平均分布在3個(gè)節(jié)點(diǎn)來(lái)進(jìn)行并行強(qiáng)擴(kuò)展性的性能對(duì)比,結(jié)果如圖12 所示,可以看出,在并發(fā)同時(shí)讀取10個(gè)TraceSet的測(cè)試條件下,TraceSet分布在3個(gè)節(jié)點(diǎn)時(shí),其性能比集中在一個(gè)節(jié)點(diǎn)上好,最快可以達(dá)到2.4倍的加速比,性能最優(yōu)時(shí)可以在302ms內(nèi)完成10個(gè)TraceSet的并發(fā)同時(shí)讀取,可以滿足交互式場(chǎng)景的性能需求。

圖12 并行強(qiáng)擴(kuò)展性的性能

基于Alluxio的分布式緩存框架可以提供較好的訪問(wèn)速度,滿足交互式操作的性能需求。此外,數(shù)據(jù)盡可能地均勻分布對(duì)讀取性能有一定的提升,在數(shù)據(jù)規(guī)模不變的情況下,增加服務(wù)節(jié)點(diǎn)數(shù)可以提升讀取性能。

4.2.3 并行弱擴(kuò)展性實(shí)驗(yàn)

同時(shí)增大數(shù)據(jù)規(guī)模和服務(wù)節(jié)點(diǎn)數(shù),考察數(shù)據(jù)的讀取性能變化。我們測(cè)試了3個(gè)TraceSet在1個(gè)節(jié)點(diǎn)以及9個(gè)TraceSet分布在3個(gè)節(jié)點(diǎn)時(shí)的性能,結(jié)果如圖13所示,可以看出,采用這2種方式讀取同樣大小的數(shù)據(jù),性能變化不大,其中的差異主要是因?yàn)椴捎枚鄠€(gè)節(jié)點(diǎn)時(shí)需要將數(shù)據(jù)從多個(gè)節(jié)點(diǎn)傳輸?shù)娇蛻舳?增加了一些網(wǎng)絡(luò)傳輸消耗?？梢缘贸鼋Y(jié)論:當(dāng)數(shù)據(jù)規(guī)模隨著服務(wù)節(jié)點(diǎn)數(shù)等比增大時(shí),緩存框架的讀取性能基本不變。

圖13 并行弱擴(kuò)展性的性能

4.3 正確性實(shí)驗(yàn)

采用分布式緩存框架和π-Frame平臺(tái)改進(jìn)前底層接口兩種方式讀取較大數(shù)據(jù)規(guī)模的TraceSet,讀取的數(shù)據(jù)分別如圖14a和圖14b所示,可以看出,分布式緩存框架的數(shù)據(jù)讀取是正確的。

圖14 兩種方式讀取大規(guī)模數(shù)據(jù)正確性對(duì)比(3360道×6000采樣點(diǎn))a 分布式緩存接口; b 平臺(tái)底層接口

4.4 生產(chǎn)環(huán)境性能對(duì)比實(shí)驗(yàn)

在本緩存框架的設(shè)計(jì)中,將炮集、共中心點(diǎn)道集、共偏移距道集等統(tǒng)一抽象為二維的TraceSet進(jìn)行管理,內(nèi)存緩存框架在進(jìn)行緩存時(shí),不區(qū)分TraceSet的專業(yè)含義,緩存效率提升主要和TraceSet的大小有關(guān)。TraceSet包含的數(shù)據(jù)規(guī)模越大,則緩存后的數(shù)據(jù)訪問(wèn)性能提升越大。

在進(jìn)行實(shí)際生產(chǎn)環(huán)境性能對(duì)比實(shí)驗(yàn)時(shí),工區(qū)中存放的最大規(guī)模TraceSet為炮集,每個(gè)TraceSet總道數(shù)最多只有8067道,每道采樣點(diǎn)為7001,8067道×7001采樣點(diǎn)×4B=215MB。在4.2節(jié)分布式緩存框架性能實(shí)驗(yàn)中,使用的數(shù)據(jù)規(guī)模是每個(gè)TraceSet為10000道×6000采樣點(diǎn)×4B=218MB,與上述215MB的TraceSet基本相同,所以可以認(rèn)為使用該炮集數(shù)據(jù)進(jìn)行實(shí)驗(yàn),實(shí)驗(yàn)結(jié)果是可靠的。

4.4.1 讀數(shù)據(jù)性能測(cè)試

測(cè)試不同數(shù)據(jù)規(guī)模TraceSet的讀性能,測(cè)試數(shù)據(jù)分別為:16MB(2880道×1500采樣點(diǎn))、92MB(6912道×3501采樣點(diǎn))、215MB(8067道×7001采樣點(diǎn))。在保證了分布式緩存框架數(shù)據(jù)讀取正確的前提下,測(cè)試結(jié)果如圖15所示。

圖15 分布式緩存的讀性能

由圖15可以看出,不同數(shù)據(jù)規(guī)模下,分布式緩存框架讀取優(yōu)于從平臺(tái)IOService底層接口直接讀取,且性能提升了至少30%。

4.4.2 寫(xiě)數(shù)據(jù)性能測(cè)試

測(cè)試不同數(shù)據(jù)規(guī)模TraceSet的寫(xiě)性能,測(cè)試數(shù)據(jù)分別為:91MB(4000道×6000采樣點(diǎn))、160MB(7000道×6000采樣點(diǎn))、228MB(10000道×6000采樣點(diǎn)),測(cè)試結(jié)果如圖16所示。

圖16 分布式緩存的寫(xiě)性能

從圖16可以看出,分布式緩存的寫(xiě)性能優(yōu)于平臺(tái)IOService原生接口的寫(xiě)性能,寫(xiě)大數(shù)據(jù)規(guī)模的TraceSet時(shí)有較好的性能提升,寫(xiě)小數(shù)據(jù)規(guī)模的TraceSet時(shí)性能在500 ms左右,能夠滿足交互式操作需求。

分布式緩存的使用對(duì)π-Frame平臺(tái)現(xiàn)有架構(gòu)的改動(dòng)很少,而且可以快速靈活地部署。經(jīng)過(guò)對(duì)比測(cè)試,分布式緩存的讀寫(xiě)性能優(yōu)于IOService,并且在一定的場(chǎng)景下能達(dá)到1倍的加速比,對(duì)提升交互式場(chǎng)景的響應(yīng)效果較好。

在本緩存框架的設(shè)計(jì)中,外部訪問(wèn)需要炮集、共中心點(diǎn)道集、共偏移距道集等數(shù)據(jù)時(shí),統(tǒng)一轉(zhuǎn)換為對(duì)TraceSet的獲取,系統(tǒng)立刻自動(dòng)去服務(wù)后臺(tái)查詢,如果TraceSet已經(jīng)在緩存中,立即從緩存中返回?cái)?shù)據(jù),如果TraceSet不在緩存中,則后臺(tái)服務(wù)自動(dòng)將其先加載到緩存中,再返回給外部。當(dāng)緩存容量足夠大時(shí),通過(guò)加大預(yù)加載TraceSet數(shù)量,緩存直接獲取率可以接近100%。

5 結(jié)論

分布式技術(shù)在地震數(shù)據(jù)處理計(jì)算方面已經(jīng)取得很好的應(yīng)用效果,但在地震軟件系統(tǒng)交互方面的應(yīng)用研究還處于探索階段。本文針對(duì)大規(guī)模地震數(shù)據(jù)交互分析場(chǎng)景,引入分布式緩存技術(shù),提出了一套針對(duì)地震數(shù)據(jù)交互的分布式緩存框架,提升了交互過(guò)程中的數(shù)據(jù)實(shí)時(shí)訪問(wèn)效率。通過(guò)實(shí)驗(yàn)分析對(duì)比,得出以下結(jié)論:

1) 該緩存框架可以有效提升交互場(chǎng)景下大規(guī)模地震數(shù)據(jù)的讀寫(xiě)速度,滿足交互分析應(yīng)用的實(shí)時(shí)性能需求;

2) 該緩存框架利用分布式大內(nèi)存優(yōu)勢(shì),可以解決運(yùn)行地震交互軟件的機(jī)器內(nèi)存有限,無(wú)法存放大規(guī)模、多種類地震數(shù)據(jù)的問(wèn)題;

3) 通過(guò)地震一體化專業(yè)軟件平臺(tái)(π-Frame)驗(yàn)證了分布式緩存框架的可行性和有效性,認(rèn)為在其它類似軟件的大數(shù)據(jù)交互場(chǎng)景下,分布式緩存框架也可以高效地讀取地震數(shù)據(jù),在專業(yè)領(lǐng)域應(yīng)用中具有一定的通用性。

本文設(shè)計(jì)的分布式緩存框架提供了一個(gè)高效的數(shù)據(jù)共享、交換機(jī)制。在交互應(yīng)用之外,下一步研究方向是如何與地震數(shù)據(jù)批處理場(chǎng)景結(jié)合,在處理作業(yè)運(yùn)行期間,通過(guò)分布式緩存技術(shù)在作業(yè)和質(zhì)控界面間進(jìn)行中間數(shù)據(jù)的共享交換,實(shí)現(xiàn)處理過(guò)程中間結(jié)果的實(shí)時(shí)質(zhì)控分析。