鐘鍵 游小娟
摘要:該文將研究移動(dòng)終端大數(shù)據(jù)的文件存儲(chǔ)技術(shù),以電子郵件和短彩信消息文件的存儲(chǔ)為實(shí)例,提出了一種在移動(dòng)終端大數(shù)據(jù)環(huán)境下的消息文件存儲(chǔ)和操作的算法,實(shí)現(xiàn)精確控制讀寫數(shù)據(jù)正確位置,避免了重寫所有數(shù)據(jù),極大減少IO操作負(fù)擔(dān),提升移動(dòng)終端大數(shù)據(jù)讀寫操作性能。
關(guān)鍵詞:移動(dòng)終端;數(shù)據(jù)存儲(chǔ)
中圖分類號(hào):TP3? ? ? ? ?文獻(xiàn)標(biāo)識(shí)碼:A
文章編號(hào):1009-3044(2021)30-0037-03
開放科學(xué)(資源服務(wù))標(biāo)識(shí)碼(OSID):
互聯(lián)網(wǎng)數(shù)據(jù)中心(IDC)報(bào)告指出,2012 年全球已經(jīng)開始進(jìn)入大數(shù)據(jù)時(shí)代,并在2013 年全面引爆大數(shù)據(jù)。大數(shù)據(jù),最具有代表性的是其“4V”的特點(diǎn):Volume-數(shù)據(jù)規(guī)模大;Velocity-數(shù)據(jù)的產(chǎn)生速度很快,處理速度快;Variety-多樣性,包括各種不同的類型和編碼格式,數(shù)據(jù)類型繁多;Veracity-真實(shí)性,只有真準(zhǔn)確的數(shù)據(jù)才使得對(duì)數(shù)據(jù)的分析有意義。在移動(dòng)互聯(lián)大數(shù)據(jù)時(shí)代,用戶要求有更好的網(wǎng)絡(luò)體驗(yàn),基本需求是能在任意時(shí)間、任意地點(diǎn)通過(guò)移動(dòng)指端移動(dòng)終端接入網(wǎng)絡(luò),既是移動(dòng)大數(shù)據(jù)的產(chǎn)生者,又是移動(dòng)大數(shù)據(jù)的使用者,因此大數(shù)據(jù)服務(wù)一方面將推動(dòng)管道技術(shù)演進(jìn),另一方面也推動(dòng)移動(dòng)終端的技術(shù)演進(jìn)。
1移動(dòng)大數(shù)據(jù)的特性
移動(dòng)互聯(lián)大數(shù)據(jù)導(dǎo)致移動(dòng)終端從功能型移動(dòng)終端向智能型移動(dòng)終端。作為移動(dòng)大數(shù)據(jù)的重要輸入輸出者,用戶通過(guò)智能移動(dòng)終端使用移動(dòng)應(yīng)用程序,產(chǎn)生各種與用戶消費(fèi)、出行以及娛樂(lè)等與生活密切相關(guān)的海量數(shù)據(jù),這些海量數(shù)據(jù)如果完全存儲(chǔ)在中心服務(wù)器上,會(huì)導(dǎo)致中心服務(wù)器負(fù)載過(guò)大,網(wǎng)絡(luò)交互過(guò)于頻繁,因此利用智能移動(dòng)終端進(jìn)行數(shù)據(jù)存儲(chǔ)及性能優(yōu)化,不僅能夠減輕中心服務(wù)器端的數(shù)據(jù)存儲(chǔ)及運(yùn)算負(fù)擔(dān),還能充分發(fā)揮智能移動(dòng)終端的硬件性能,特別是在離線情況下,通過(guò)緩存在智能移動(dòng)終端的應(yīng)用數(shù)據(jù),仍能為用戶及時(shí)地提供部分應(yīng)用服務(wù)。移動(dòng)互聯(lián)大數(shù)據(jù)具有以下特性:
1.1 時(shí)空性
智能移動(dòng)終端都具備GPS定位功能,因此數(shù)據(jù)的時(shí)空特性是移動(dòng)大數(shù)據(jù)固有的鮮明特征。即使智能移動(dòng)終端關(guān)閉了GPS定位服務(wù)功能,仍然可以通過(guò)基站位置粗略地推斷出用戶的位置。多維時(shí)空數(shù)據(jù)包含用戶行動(dòng)信息,在基于位置服務(wù)的智能打車、智能駕駛、網(wǎng)絡(luò)商城、游戲、社交網(wǎng)絡(luò)等各種應(yīng)用中具有廣泛的潛力。
1.2 個(gè)人定制性
從智能移動(dòng)終端產(chǎn)生的數(shù)據(jù)始終包含用戶身份信息。這些數(shù)據(jù)通常具有高度個(gè)人定制性。通過(guò)對(duì)這些包含個(gè)人信息的移動(dòng)大數(shù)據(jù)進(jìn)行分析和預(yù)測(cè),預(yù)測(cè)出用戶的個(gè)人行為偏好和習(xí)慣,通過(guò)專業(yè)的推薦系統(tǒng),為每個(gè)用戶提供精準(zhǔn)的個(gè)人定制化服務(wù)。如瀏覽器個(gè)性推薦功能,網(wǎng)上購(gòu)物個(gè)性推薦服務(wù)等。當(dāng)然,任何事物都具有雙面性,如果移動(dòng)數(shù)據(jù)保密性不夠,導(dǎo)致用戶個(gè)人信息泄露,將在很大程度上侵犯用戶的隱私并導(dǎo)致用戶的生命財(cái)產(chǎn)受到侵害,因此數(shù)據(jù)安全性和保密性值得引起重視。
1.3 實(shí)時(shí)性
移動(dòng)互聯(lián)網(wǎng)的一個(gè)典型需求是應(yīng)用程序服務(wù)端需要實(shí)時(shí)地向用戶提供數(shù)據(jù)交互和服務(wù),即數(shù)據(jù)必須具有實(shí)時(shí)性。如網(wǎng)絡(luò)游戲、社交通訊、智能打車、金融 等應(yīng)用程序,如果不能實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)交互,不僅影響用戶體驗(yàn),而且會(huì)造成用戶的信息交流的延誤和財(cái)產(chǎn)損失。然而,移動(dòng)應(yīng)用服務(wù)器端如果承擔(dān)所有數(shù)據(jù)的存儲(chǔ)、處理和分發(fā),受硬件設(shè)備計(jì)算能力、存儲(chǔ)空間和網(wǎng)絡(luò)帶寬的限制,難以滿足海量數(shù)據(jù)的實(shí)時(shí)交互需求。因此,充分利用智能移動(dòng)終端的計(jì)算能力和存儲(chǔ)空間,存儲(chǔ)一部分移動(dòng)數(shù)據(jù),減輕服務(wù)器端和網(wǎng)絡(luò)帶寬的負(fù)載,是一種可行且高效的解決方案。
2主流大數(shù)據(jù)框架和技術(shù)
為了存儲(chǔ)和處理海量大數(shù)據(jù),很多企業(yè)和高校開發(fā)了多種大數(shù)據(jù)處理框架和平臺(tái),主流的框架和技術(shù)包括:MapReduce、GFS、BigTable、Spark和Hadoop等技術(shù)。
2.1 Hadoop框架
Hadoop是一個(gè)包含開源代碼的分布式文件系統(tǒng)和一個(gè)并行處理的MapReduce框架。HDFS為海量數(shù)據(jù)提供存儲(chǔ)服務(wù),而MapReduce則為海量數(shù)據(jù)提供計(jì)算引擎。HDFS設(shè)計(jì)思想有以下幾點(diǎn):1)在數(shù)據(jù)中心,硬件異常應(yīng)被視作常態(tài);2)流式數(shù)據(jù)訪問(wèn):滿足批處理而不是交互式處理需求;3)HDFS設(shè)計(jì)的重點(diǎn)是支持大文件;4)HDFS提供的訪問(wèn)模型是一次寫入多次讀取的簡(jiǎn)單數(shù)據(jù)一致性模型;5)移動(dòng)計(jì)算優(yōu)于移動(dòng)數(shù)據(jù):讀取和計(jì)算采取就近原則;6)兼容各種硬件和軟件平臺(tái)。HDFS有其缺陷,不適合的場(chǎng)景包括:1)大量小文件;2)低延遲數(shù)據(jù)訪問(wèn);3)多用戶寫入。
2.2 分布式文件系統(tǒng)HDFS
其中,HDFS為海量數(shù)據(jù)提供存儲(chǔ)服務(wù),而MapReduce則為海量數(shù)據(jù)提供計(jì)算引擎。HDFS設(shè)計(jì)思想有以下幾點(diǎn):1)在數(shù)據(jù)中心,硬件異常應(yīng)被視作常態(tài);2)流式數(shù)據(jù)訪問(wèn):滿足批處理而不是交互式處理需求;3)HDFS設(shè)計(jì)的重點(diǎn)是支持大文件;4)HDFS提供的訪問(wèn)模型是一次寫入多次讀取的簡(jiǎn)單數(shù)據(jù)一致性模型;5)移動(dòng)計(jì)算優(yōu)于移動(dòng)數(shù)據(jù):讀取和計(jì)算采取就近原則;6)兼容各種硬件和軟件平臺(tái)。HDFS有其缺陷,不適合的場(chǎng)景包括:1)大量小文件;2)低延遲數(shù)據(jù)訪問(wèn);3)多用戶寫入。
2.3 MapReduce模型
MapReduce是Google公司的核心計(jì)算模型,它將復(fù)雜的運(yùn)行于大規(guī)模集群上的并行計(jì)算過(guò)程高度地抽象到兩個(gè)函數(shù):Map和Reduce。這兩個(gè)函數(shù)由用戶負(fù)責(zé)實(shí)現(xiàn),功能是按一定的映射規(guī)則將輸入的
MapReduce的目標(biāo)是解決海量數(shù)據(jù)的并行計(jì)算問(wèn)題。它屏蔽了分布式計(jì)算框架的細(xì)節(jié),將計(jì)算高度抽象成map和reduce兩函數(shù),其中map對(duì)數(shù)據(jù)集上的獨(dú)立元素進(jìn)行指定的操作,生成鍵-值對(duì)形式中間結(jié)果。reduce則對(duì)中間結(jié)果中相同“鍵”的所有“值”進(jìn)行合并,以得到最終結(jié)果。
2.4 Spark框架
Spark是在2009年由加州大學(xué)伯克利分校的AMPLab開發(fā),提供了一個(gè)全面、統(tǒng)一的框架,用于大數(shù)據(jù)處理的需求。Spark的架構(gòu)中的基本組件包括:Cluster Manager、Worker、Driver、Executor、SparkContext、RDD、DAG Scheduler、TaskScheduler以及SparkEnv。Spark的運(yùn)行流程如下:
1)構(gòu)建Spark Application的運(yùn)行環(huán)境,啟動(dòng)SparkContext;
2)SparkContext向資源管理器(可以是Standalone,Mesos,Yarn)申請(qǐng)運(yùn)行Executor資源,并啟動(dòng)StandaloneExecutorbackend;
3)Executor向SparkContext申請(qǐng)Task;
4)SparkContext將應(yīng)用程序分發(fā)給Executor;
5)SparkContext構(gòu)建成DAG圖,將DAG圖分解成Stage、將Taskset發(fā)送給Task Scheduler,最后由Task Scheduler將Task發(fā)送給Executor運(yùn)行;
6)Task在Executor上運(yùn)行,運(yùn)行完釋放所有資源。
Spark與Hadoop相比,有如下差異:1)Spark與Hadoop有兩個(gè)核心模塊,分布式存儲(chǔ)模塊HDFS和分布式計(jì)算模塊MapReduce;2)Spark本身并沒有提供分布式文件系統(tǒng),因此Spark的分析大多依賴于Hadoop的分布式文件系統(tǒng)HDFS;3)相比于MapReduce,Spark的速度更快并且提供的功能更加豐富。
盡管國(guó)內(nèi)外學(xué)者在服務(wù)器端大數(shù)據(jù)存儲(chǔ)、大數(shù)據(jù)處理、數(shù)據(jù)集共享方面開展了一些研究,并取得了很多研究成果,但是基于移動(dòng)終端的數(shù)據(jù)存儲(chǔ),特別是基于移動(dòng)終端的大數(shù)據(jù)存儲(chǔ)及優(yōu)化問(wèn)題,迄今未見有相關(guān)報(bào)道。
本文將研究移動(dòng)終端大數(shù)據(jù)的文件存儲(chǔ)技術(shù),以電子郵件和短彩信消息的文件存儲(chǔ)為實(shí)例,提出了一種移動(dòng)終端大數(shù)據(jù)環(huán)境下的索引文件偏移量存儲(chǔ)算法,實(shí)現(xiàn)精確控制讀寫數(shù)據(jù)正確位置,避免了重寫所有數(shù)據(jù),極大減少IO操作負(fù)擔(dān),提升移動(dòng)終端大數(shù)據(jù)讀寫操作性能,提出移動(dòng)終端大數(shù)據(jù)環(huán)境下多級(jí)索引存儲(chǔ)算法,移動(dòng)終端具體數(shù)據(jù)和相對(duì)位置分離即索引頭和位置關(guān)系分開存儲(chǔ),實(shí)現(xiàn)移動(dòng)終端環(huán)境下大數(shù)據(jù)存儲(chǔ)索引有序。構(gòu)建一個(gè)移動(dòng)終端通用、高性能、可推廣存儲(chǔ)模型,充分發(fā)揮移動(dòng)終端性能,有效減輕服務(wù)端數(shù)據(jù)存儲(chǔ)、運(yùn)算負(fù)擔(dān),降低移動(dòng)終端和服務(wù)器端不必要的數(shù)據(jù)交互。
3消息文件的存儲(chǔ)設(shè)計(jì)
移動(dòng)終端大數(shù)據(jù)環(huán)境下,移動(dòng)終端中一個(gè)消息文件不能是一維扁平的存儲(chǔ),因?yàn)檫@樣會(huì)極大降低海量消息文件的操作性能。因此,我們將消息文件的結(jié)構(gòu)設(shè)計(jì)成三種組成部分,包括消息體、消息頭和消息頭索引,如圖1所示。其中:
1)消息體:包括消息的具體內(nèi)容,該部分?jǐn)?shù)據(jù)量較大不需要頻繁操作和訪問(wèn)。
2)消息頭:包括各種消息的頭信息:如主題,發(fā)件人,收件人,時(shí)間等內(nèi)容,這部分被劃分出來(lái)的依據(jù)為,該項(xiàng)內(nèi)容會(huì)被頻繁使用,比如消息列表需要展現(xiàn)該部分?jǐn)?shù)據(jù),并且需要列表告訴滑動(dòng),就要求獲取數(shù)據(jù)迅速。
3)消息頭索引:該部分為最高層結(jié)構(gòu),提取出了各個(gè)消息之間的相對(duì)位置,維護(hù)了各種位置序列。
3.1 消息管理方法
移動(dòng)終端大數(shù)據(jù)環(huán)境下,消息文件管理主要通過(guò)系統(tǒng)中維護(hù)的幾條鏈表實(shí)現(xiàn),包括:索引頭鏈表、消息頭鏈表和空閑消息頭鏈表,如圖2所示。
其中,索引頭鏈表維護(hù)消息的前后順序,比如:時(shí)間,狀態(tài)順序等,序列化為索引頭文件;消息頭鏈表維護(hù)著有效消息的頭結(jié)點(diǎn),空閑消息頭鏈表維護(hù)著無(wú)效消息的頭結(jié)點(diǎn),兩條鏈表序列化為消息頭文件,如果需要?jiǎng)h除一條消息,則從消息頭鏈表中移除一個(gè)結(jié)點(diǎn),放入空閑消息頭鏈表,如果增加一條消息,則首先在空閑消息頭鏈表中尋找是否有空閑結(jié)點(diǎn),若找到轉(zhuǎn)化為有效結(jié)點(diǎn)并加入有效消息頭鏈表中。
3.2消息鏈表管理方法
由于消息包含不同狀態(tài),并且對(duì)應(yīng)著不同的業(yè)務(wù)邏輯,因此會(huì)產(chǎn)生大量鏈表管理起來(lái)非常麻煩,因此消息鏈表也需要管理起來(lái),這里使用單例模式維護(hù)唯一鏈表指針,并使用工廠模式進(jìn)行管理,用戶只需輸入key值便能得到對(duì)應(yīng)鏈表頭指針,無(wú)須知道構(gòu)造細(xì)節(jié)。而各鏈表常駐內(nèi)存,使用惰性初始化,當(dāng)?shù)谝淮伪皇褂脮r(shí)進(jìn)行初始化。
由于消息模塊箱子較多,消息數(shù)量也較多,一直常駐內(nèi)存對(duì)于某些內(nèi)存較小低端機(jī)負(fù)擔(dān)較大,因此也需要定期置換出部分不使用的鏈表以釋放內(nèi)存。
3.3 鏈表管理置換算法—LRU算法
LRU(Least Recently Used)即最近最久未使用頁(yè)面置換算法,算法的思路就是認(rèn)為最久未使用鏈表為最不常用的鏈表,因此優(yōu)先級(jí)最低將其置換出去,從而換入新的鏈表進(jìn)入。
在這里我們的具體算法為:(1)將所有鏈表頭指針存于一個(gè)鏈表管理器中(使用鏈表實(shí)現(xiàn));(2)每次新請(qǐng)求對(duì)應(yīng)key值的鏈表頭,則先在管理鏈表中尋找是否存在,若存在直接返回,若不存在則添加入對(duì)應(yīng)Key值的鏈表頭入該鏈表管理器中;(3)添加新鏈表時(shí)候需要檢查是否超過(guò)管理器最大上限,若超過(guò)最大上限,則置換出鏈表管理器末尾最后一個(gè)最老鏈表,并釋放掉該鏈表頭指針指向的整條鏈表。
3.4海量消息文件存儲(chǔ)的操作原理
海量消息文件存儲(chǔ)中,包括幾個(gè)重要操作的原理及流程,如:消息增加、消息刪除、消息加載等。
1) 消息新增管理
對(duì)于新增消息需要找到合適的位置插入且生成有效id號(hào),首先尋找對(duì)應(yīng)的空閑消息頭鏈表是否有空閑結(jié)點(diǎn),若有則摘取一個(gè)轉(zhuǎn)到有效鏈表中,并在對(duì)應(yīng)位置寫入消息記錄,若無(wú)則獲得鏈表最大結(jié)點(diǎn)數(shù)加1后得到新的id號(hào),然后把生成的新結(jié)點(diǎn)添加到鏈表恰當(dāng)位置處,具體流程如圖3所示。
2) 海量消息文件刪除的原理
對(duì)于刪除操作并不真正將消息記錄從文件系統(tǒng)中直接清除掉,而是在對(duì)應(yīng)記錄中寫入無(wú)效標(biāo)示,這樣只需要找到適當(dāng)位置寫入少量字節(jié)即可。
看起來(lái)每刪除一條消息,仿佛在索引文件上挖一個(gè)坑,然后用空閑鏈表idleList將這些坑串聯(lián)起來(lái),如果新來(lái)一條消息,就優(yōu)先把這樣的坑分給它。
3) 消息裝載原理
消息文件的裝載過(guò)程即為一個(gè)反序列化過(guò)程,從文件系統(tǒng)讀取各種數(shù)據(jù)和關(guān)系,轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)供上層使用的過(guò)程。
此為存儲(chǔ)的一個(gè)反過(guò)程,讀取分為有序讀取和無(wú)序讀取,如果無(wú)序讀取只需要加載索引文件,而讀取有序消息索引則需要首先讀取索引頭文件,獲得索引頭結(jié)點(diǎn),再查詢索引結(jié)點(diǎn)組裝成完整的索引結(jié)點(diǎn)信息。
4結(jié)論
向單個(gè)智能移動(dòng)終端存儲(chǔ)分別存儲(chǔ)1000和5000條消息,每存儲(chǔ)一條打印出該條消息存儲(chǔ)消耗時(shí)間,這樣可橫向可以比較隨著消息的增多,性能衰減情況,縱向可以比較新舊兩種方式的效率。采用本文提出的文件存儲(chǔ)操作方法,與整個(gè)消息文件存儲(chǔ)的方法進(jìn)行比對(duì),結(jié)果本文提出的文件存儲(chǔ)操作方法在總體時(shí)間消耗比后者低,并且操作效率與測(cè)試數(shù)據(jù)規(guī)模的相關(guān)性低,而第二種方式會(huì)隨著數(shù)據(jù)規(guī)模增加,效率急劇衰減。
新方案由于實(shí)現(xiàn)了性能對(duì)數(shù)據(jù)規(guī)模的依賴相關(guān)性,因此在時(shí)間消耗上不會(huì)隨著數(shù)據(jù)規(guī)模增加而增加,提升了還是消息文件的存儲(chǔ)和操作性能。但其仍存在一些待改進(jìn)的地方,如在文件系統(tǒng)中增刪消息會(huì)在多個(gè)文件中讀寫,因此如果在中途發(fā)生意外就容易形成數(shù)據(jù)破壞,而這多個(gè)操作是原子的,需要事務(wù)來(lái)保證,因此在設(shè)計(jì)的時(shí)候需要加入對(duì)事務(wù)的考慮,若一個(gè)事務(wù)未來(lái)完成,需要進(jìn)行回滾處理。移動(dòng)互聯(lián)大數(shù)據(jù)環(huán)境下,移動(dòng)終端數(shù)據(jù)急劇增長(zhǎng),導(dǎo)致網(wǎng)絡(luò)出現(xiàn)延遲和丟包現(xiàn)象,服務(wù)器?端超負(fù)荷運(yùn)行。研究移動(dòng)終端大數(shù)據(jù)存儲(chǔ),可提升移動(dòng)軟件應(yīng)用性能及用戶體驗(yàn)質(zhì)量移動(dòng),降低服務(wù)器端存儲(chǔ)和運(yùn)算數(shù)據(jù)量,充分發(fā)揮移動(dòng)終端硬件性能。因此,如何存儲(chǔ)這些數(shù)量驟升的移動(dòng)終端數(shù)據(jù)將成為企業(yè)和學(xué)術(shù)界的研究熱點(diǎn)。
參考文獻(xiàn)
[1] 陳博,顧旻霞.移動(dòng)終端HTML5Web應(yīng)用技術(shù)與標(biāo)準(zhǔn)[J].電信網(wǎng)技術(shù),2012(5):5-9.
[2] Ghemawat S,Gobioff H,Leung S T.The Google file system[C]//Proceedings of the nineteenth ACM symposium on Operating systems principles - SOSP '03.October 19-22,2003.Bolton Landing,NY,USA.New York:ACM Press,2003:29-43.
[3] ZhongL Z,WangB Z,WangZ Y,et al.Research and application of massive data processing technology[C]//20138th International Conference on Computer Science & Education.April26-28,2013,Colombo,SriLanka.IEEE,2013:829-833.
[4] Kaushik R T,Bhandarkar M,Nahrstedt K.Evaluation and analysis of GreenHDFS:a self-adaptive,energy-conserving variant of the hadoop distributed file system[C]//2010 IEEE SecondInternational Conference on Cloud Computing Technology and Science.November30 - December3,2010,Indianapolis,IN,USA.IEEE,2010:274-287.
【通聯(lián)編輯:朱寶貴】