移動(dòng)終端海量數(shù)據(jù)存儲(chǔ)技術(shù)研究

鐘鍵 游小娟

摘要：該文將研究移動(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ī)則將輸入的對(duì)轉(zhuǎn)換成另一個(gè)或一批對(duì)輸出。MapReduce的基本運(yùn)行流程包括：1）作業(yè)啟動(dòng);2）作業(yè)初始化;3）作業(yè)、任務(wù)調(diào)度;4）Map任務(wù)執(zhí)行;5）shuffle;Reduce任務(wù)執(zhí)行;7）作業(yè)完成。MapReduce作為分布式并行計(jì)算框架，主要由JobClient、JobTracker、TaskTracker等組件構(gòu)成。核心設(shè)計(jì)思想：分而治之、分合結(jié)合、銜接有序、就近處理、可靠容錯(cuò)。

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)編輯：朱寶貴】