移動終端海量數據存儲技術研究

鐘鍵 游小娟

摘要：該文將研究移動終端大數據的文件存儲技術，以電子郵件和短彩信消息文件的存儲為實例，提出了一種在移動終端大數據環境下的消息文件存儲和操作的算法，實現精確控制讀寫數據正確位置，避免了重寫所有數據，極大減少IO操作負擔，提升移動終端大數據讀寫操作性能。

關鍵詞：移動終端;數據存儲

中圖分類號：TP3? ? ? ? ?文獻標識碼：A

文章編號：1009-3044（2021）30-0037-03

開放科學（資源服務）標識碼（OSID）：

互聯網數據中心（IDC）報告指出，2012 年全球已經開始進入大數據時代，并在2013 年全面引爆大數據。大數據，最具有代表性的是其“4V”的特點：Volume-數據規模大;Velocity-數據的產生速度很快，處理速度快;Variety-多樣性，包括各種不同的類型和編碼格式，數據類型繁多;Veracity-真實性，只有真準確的數據才使得對數據的分析有意義。在移動互聯大數據時代，用戶要求有更好的網絡體驗，基本需求是能在任意時間、任意地點通過移動指端移動終端接入網絡，既是移動大數據的產生者，又是移動大數據的使用者，因此大數據服務一方面將推動管道技術演進，另一方面也推動移動終端的技術演進。

1移動大數據的特性

移動互聯大數據導致移動終端從功能型移動終端向智能型移動終端。作為移動大數據的重要輸入輸出者，用戶通過智能移動終端使用移動應用程序，產生各種與用戶消費、出行以及娛樂等與生活密切相關的海量數據，這些海量數據如果完全存儲在中心服務器上，會導致中心服務器負載過大，網絡交互過于頻繁，因此利用智能移動終端進行數據存儲及性能優化，不僅能夠減輕中心服務器端的數據存儲及運算負擔，還能充分發揮智能移動終端的硬件性能，特別是在離線情況下，通過緩存在智能移動終端的應用數據，仍能為用戶及時地提供部分應用服務。移動互聯大數據具有以下特性：

1.1 時空性

智能移動終端都具備GPS定位功能，因此數據的時空特性是移動大數據固有的鮮明特征。即使智能移動終端關閉了GPS定位服務功能，仍然可以通過基站位置粗略地推斷出用戶的位置。多維時空數據包含用戶行動信息，在基于位置服務的智能打車、智能駕駛、網絡商城、游戲、社交網絡等各種應用中具有廣泛的潛力。

1.2 個人定制性

從智能移動終端產生的數據始終包含用戶身份信息。這些數據通常具有高度個人定制性。通過對這些包含個人信息的移動大數據進行分析和預測，預測出用戶的個人行為偏好和習慣，通過專業的推薦系統，為每個用戶提供精準的個人定制化服務。如瀏覽器個性推薦功能，網上購物個性推薦服務等。當然，任何事物都具有雙面性，如果移動數據保密性不夠，導致用戶個人信息泄露，將在很大程度上侵犯用戶的隱私并導致用戶的生命財產受到侵害，因此數據安全性和保密性值得引起重視。

1.3 實時性

移動互聯網的一個典型需求是應用程序服務端需要實時地向用戶提供數據交互和服務，即數據必須具有實時性。如網絡游戲、社交通訊、智能打車、金融 等應用程序，如果不能實現數據的實時交互，不僅影響用戶體驗，而且會造成用戶的信息交流的延誤和財產損失。然而，移動應用服務器端如果承擔所有數據的存儲、處理和分發，受硬件設備計算能力、存儲空間和網絡帶寬的限制，難以滿足海量數據的實時交互需求。因此，充分利用智能移動終端的計算能力和存儲空間，存儲一部分移動數據，減輕服務器端和網絡帶寬的負載，是一種可行且高效的解決方案。

2主流大數據框架和技術

為了存儲和處理海量大數據，很多企業和高校開發了多種大數據處理框架和平臺，主流的框架和技術包括：MapReduce、GFS、BigTable、Spark和Hadoop等技術。

2.1 Hadoop框架

Hadoop是一個包含開源代碼的分布式文件系統和一個并行處理的MapReduce框架。HDFS為海量數據提供存儲服務，而MapReduce則為海量數據提供計算引擎。HDFS設計思想有以下幾點：1）在數據中心，硬件異常應被視作常態;2）流式數據訪問：滿足批處理而不是交互式處理需求;3）HDFS設計的重點是支持大文件;4）HDFS提供的訪問模型是一次寫入多次讀取的簡單數據一致性模型;5）移動計算優于移動數據：讀取和計算采取就近原則;6）兼容各種硬件和軟件平臺。HDFS有其缺陷，不適合的場景包括：1）大量小文件;2）低延遲數據訪問;3）多用戶寫入。

2.2 分布式文件系統HDFS

其中，HDFS為海量數據提供存儲服務，而MapReduce則為海量數據提供計算引擎。HDFS設計思想有以下幾點：1）在數據中心，硬件異常應被視作常態;2）流式數據訪問：滿足批處理而不是交互式處理需求;3）HDFS設計的重點是支持大文件;4）HDFS提供的訪問模型是一次寫入多次讀取的簡單數據一致性模型;5）移動計算優于移動數據：讀取和計算采取就近原則;6）兼容各種硬件和軟件平臺。HDFS有其缺陷，不適合的場景包括：1）大量小文件;2）低延遲數據訪問;3）多用戶寫入。

2.3 MapReduce模型

MapReduce是Google公司的核心計算模型，它將復雜的運行于大規模集群上的并行計算過程高度地抽象到兩個函數：Map和Reduce。這兩個函數由用戶負責實現，功能是按一定的映射規則將輸入的對轉換成另一個或一批對輸出。MapReduce的基本運行流程包括：1）作業啟動;2）作業初始化;3）作業、任務調度;4）Map任務執行;5）shuffle;Reduce任務執行;7）作業完成。MapReduce作為分布式并行計算框架，主要由JobClient、JobTracker、TaskTracker等組件構成。核心設計思想：分而治之、分合結合、銜接有序、就近處理、可靠容錯。

MapReduce的目標是解決海量數據的并行計算問題。它屏蔽了分布式計算框架的細節，將計算高度抽象成map和reduce兩函數，其中map對數據集上的獨立元素進行指定的操作，生成鍵-值對形式中間結果。reduce則對中間結果中相同“鍵”的所有“值”進行合并，以得到最終結果。

2.4 Spark框架

Spark是在2009年由加州大學伯克利分校的AMPLab開發，提供了一個全面、統一的框架，用于大數據處理的需求。Spark的架構中的基本組件包括：Cluster Manager、Worker、Driver、Executor、SparkContext、RDD、DAG Scheduler、TaskScheduler以及SparkEnv。Spark的運行流程如下：

1）構建Spark Application的運行環境，啟動SparkContext;

2）SparkContext向資源管理器（可以是Standalone，Mesos，Yarn）申請運行Executor資源，并啟動StandaloneExecutorbackend;

3）Executor向SparkContext申請Task;

4）SparkContext將應用程序分發給Executor;

5）SparkContext構建成DAG圖，將DAG圖分解成Stage、將Taskset發送給Task Scheduler，最后由Task Scheduler將Task發送給Executor運行;

6）Task在Executor上運行，運行完釋放所有資源。

Spark與Hadoop相比，有如下差異：1）Spark與Hadoop有兩個核心模塊，分布式存儲模塊HDFS和分布式計算模塊MapReduce;2）Spark本身并沒有提供分布式文件系統，因此Spark的分析大多依賴于Hadoop的分布式文件系統HDFS;3）相比于MapReduce，Spark的速度更快并且提供的功能更加豐富。

盡管國內外學者在服務器端大數據存儲、大數據處理、數據集共享方面開展了一些研究，并取得了很多研究成果，但是基于移動終端的數據存儲，特別是基于移動終端的大數據存儲及優化問題，迄今未見有相關報道。

本文將研究移動終端大數據的文件存儲技術，以電子郵件和短彩信消息的文件存儲為實例，提出了一種移動終端大數據環境下的索引文件偏移量存儲算法，實現精確控制讀寫數據正確位置，避免了重寫所有數據，極大減少IO操作負擔，提升移動終端大數據讀寫操作性能，提出移動終端大數據環境下多級索引存儲算法，移動終端具體數據和相對位置分離即索引頭和位置關系分開存儲，實現移動終端環境下大數據存儲索引有序。構建一個移動終端通用、高性能、可推廣存儲模型，充分發揮移動終端性能，有效減輕服務端數據存儲、運算負擔，降低移動終端和服務器端不必要的數據交互。

3消息文件的存儲設計

移動終端大數據環境下，移動終端中一個消息文件不能是一維扁平的存儲，因為這樣會極大降低海量消息文件的操作性能。因此，我們將消息文件的結構設計成三種組成部分，包括消息體、消息頭和消息頭索引，如圖1所示。其中：

1）消息體：包括消息的具體內容，該部分數據量較大不需要頻繁操作和訪問。

2）消息頭：包括各種消息的頭信息：如主題，發件人，收件人，時間等內容，這部分被劃分出來的依據為，該項內容會被頻繁使用，比如消息列表需要展現該部分數據，并且需要列表告訴滑動，就要求獲取數據迅速。

3）消息頭索引：該部分為最高層結構，提取出了各個消息之間的相對位置，維護了各種位置序列。

3.1 消息管理方法

移動終端大數據環境下，消息文件管理主要通過系統中維護的幾條鏈表實現，包括：索引頭鏈表、消息頭鏈表和空閑消息頭鏈表，如圖2所示。

其中，索引頭鏈表維護消息的前后順序，比如：時間，狀態順序等，序列化為索引頭文件;消息頭鏈表維護著有效消息的頭結點，空閑消息頭鏈表維護著無效消息的頭結點，兩條鏈表序列化為消息頭文件，如果需要刪除一條消息，則從消息頭鏈表中移除一個結點，放入空閑消息頭鏈表，如果增加一條消息，則首先在空閑消息頭鏈表中尋找是否有空閑結點，若找到轉化為有效結點并加入有效消息頭鏈表中。

3.2消息鏈表管理方法

由于消息包含不同狀態，并且對應著不同的業務邏輯，因此會產生大量鏈表管理起來非常麻煩，因此消息鏈表也需要管理起來，這里使用單例模式維護唯一鏈表指針，并使用工廠模式進行管理，用戶只需輸入key值便能得到對應鏈表頭指針，無須知道構造細節。而各鏈表常駐內存，使用惰性初始化，當第一次被使用時進行初始化。

由于消息模塊箱子較多，消息數量也較多，一直常駐內存對于某些內存較小低端機負擔較大，因此也需要定期置換出部分不使用的鏈表以釋放內存。

3.3 鏈表管理置換算法—LRU算法

LRU（Least Recently Used）即最近最久未使用頁面置換算法，算法的思路就是認為最久未使用鏈表為最不常用的鏈表，因此優先級最低將其置換出去，從而換入新的鏈表進入。

在這里我們的具體算法為：（1）將所有鏈表頭指針存于一個鏈表管理器中（使用鏈表實現）;（2）每次新請求對應key值的鏈表頭，則先在管理鏈表中尋找是否存在，若存在直接返回，若不存在則添加入對應Key值的鏈表頭入該鏈表管理器中;（3）添加新鏈表時候需要檢查是否超過管理器最大上限，若超過最大上限，則置換出鏈表管理器末尾最后一個最老鏈表，并釋放掉該鏈表頭指針指向的整條鏈表。

3.4海量消息文件存儲的操作原理

海量消息文件存儲中，包括幾個重要操作的原理及流程，如：消息增加、消息刪除、消息加載等。

1） 消息新增管理

對于新增消息需要找到合適的位置插入且生成有效id號，首先尋找對應的空閑消息頭鏈表是否有空閑結點，若有則摘取一個轉到有效鏈表中，并在對應位置寫入消息記錄，若無則獲得鏈表最大結點數加1后得到新的id號，然后把生成的新結點添加到鏈表恰當位置處，具體流程如圖3所示。

2） 海量消息文件刪除的原理

對于刪除操作并不真正將消息記錄從文件系統中直接清除掉，而是在對應記錄中寫入無效標示，這樣只需要找到適當位置寫入少量字節即可。

看起來每刪除一條消息，仿佛在索引文件上挖一個坑，然后用空閑鏈表idleList將這些坑串聯起來，如果新來一條消息，就優先把這樣的坑分給它。

3） 消息裝載原理

消息文件的裝載過程即為一個反序列化過程，從文件系統讀取各種數據和關系，轉化為數據結構供上層使用的過程。

此為存儲的一個反過程，讀取分為有序讀取和無序讀取，如果無序讀取只需要加載索引文件，而讀取有序消息索引則需要首先讀取索引頭文件，獲得索引頭結點，再查詢索引結點組裝成完整的索引結點信息。

4結論

向單個智能移動終端存儲分別存儲1000和5000條消息，每存儲一條打印出該條消息存儲消耗時間，這樣可橫向可以比較隨著消息的增多，性能衰減情況，縱向可以比較新舊兩種方式的效率。采用本文提出的文件存儲操作方法，與整個消息文件存儲的方法進行比對，結果本文提出的文件存儲操作方法在總體時間消耗比后者低，并且操作效率與測試數據規模的相關性低，而第二種方式會隨著數據規模增加，效率急劇衰減。

新方案由于實現了性能對數據規模的依賴相關性，因此在時間消耗上不會隨著數據規模增加而增加，提升了還是消息文件的存儲和操作性能。但其仍存在一些待改進的地方，如在文件系統中增刪消息會在多個文件中讀寫，因此如果在中途發生意外就容易形成數據破壞，而這多個操作是原子的，需要事務來保證，因此在設計的時候需要加入對事務的考慮，若一個事務未來完成，需要進行回滾處理。移動互聯大數據環境下，移動終端數據急劇增長，導致網絡出現延遲和丟包現象，服務器?端超負荷運行。研究移動終端大數據存儲，可提升移動軟件應用性能及用戶體驗質量移動，降低服務器端存儲和運算數據量，充分發揮移動終端硬件性能。因此，如何存儲這些數量驟升的移動終端數據將成為企業和學術界的研究熱點。

參考文獻

[1] 陳博，顧旻霞.移動終端HTML5Web應用技術與標準[J].電信網技術，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.

【通聯編輯：朱寶貴】