劉華慶 陳墾

摘 要:為了有效保證醫療大數據的可靠性,本文針對醫療工作中的實際情況,設計開發一個基于RS糾刪碼的云存儲容災系統,在Hadoop平臺架構上實現了冷數據掃描技術及RS編碼/解碼,可定期掃描系統并對冷數據進行糾刪碼處理,系統具有良好的容錯性能和存儲效率。實驗分析表明,所搭建的系統運行正常,在編碼單位為16 bits,具有最佳性能。
關鍵詞:云存儲;Hadoop;糾刪碼;數據重構
0 引言
近年來,醫療行業的大數據增長尤為迅速,以超聲檢查為例,過去五年超聲的檢查量增加2倍,CT檢查量增加了3倍,而在未來的五年醫院的數據包括影像的年負荷率將增長40%。實際上,這僅僅是醫院某一個特定的業務環節的數據,如果以醫院全院的業務來計算,醫院每年增長的數據量都是非常巨大的[1]。
然而,如何有效存儲這些醫療大數據,尤其是如何保證有重要價值的醫療數據可靠性的同時降低存儲空間開銷,成為醫療數據云存儲平臺亟待解決的問題。為了保證數據的可靠性,以往的大數據云存儲系統(如典型的云存儲系統Hadoop HDFS[2], Google GFS[3])普遍采用三備份策略,其設計初衷是由于通用商業PC在三副本的情況下可以基本保證不丟失數據,但是Hadoop系統的這種三副本技術本身的容錯能力不高(只能容錯2個節點失效),存儲效率也較低。
1 RS糾刪碼技術簡介
基于有限域GF運算的(n,k)糾刪碼能將n個數據塊編碼為(n+k)個糾刪碼分塊,只要獲取其中任意n個糾刪碼分塊就能恢復所有n個原始數據塊。代表性的RS(n,k)糾刪碼[5]是一種系統性編碼,即編碼后原n個數據塊不變,剩余k個數據塊為原始數據塊計算得來。與多副本技術相比,容錯能力相同條件下糾刪碼技術的存儲效率更高、成本更低;例如,若按照100PB數據(Windows Azure Storage 2012年左右規模),1美元/GB/年,按容錯能力1來計算(若副本技術和糾刪碼各需要2倍和1.5倍存儲空間),則僅存儲開銷糾刪碼每年便可節省52,428,800美元。
2 云存儲容災系統設計與關鍵技術
2.1 云存儲容災系統的總體架構
本文設計基于Hadoop的云存儲容災系統的總體架構圖如圖1所示。本云存儲系統分為兩個部分:第一個部分是云存儲系統的管理層,第二個部分是云存儲系統的服務層。兩個部分相互協作,共同為客戶端上的用戶提供文件上傳、文件下載、文件刪除、文件修改、文件查找等服務,用戶能夠方便地對云存儲系統中的文件進行管理和操作,享受云存儲系統提供的各種服務。下面分別闡述這個兩個部分的主要功能。
(1) 云存儲的管理層由三個服務器組成:第一個是Web Server服務器;第二個是RS Coding Server服務器;第三個是NameNode服務器。三個服務器之間相互協作、相互影響,是云存儲容災系統的基本骨架,在云存儲系統中起著核心作用。
(2) 云存儲系統的服務層由DataNode集群構成。在云存儲容災系統中,所有的文件被拆分為數據塊存放在這些DataNode(數據節點)中,部分文件的數據塊采用三備份存放,其余部分采用RS糾刪碼存放。當一個Datanode啟動時,掃描本地文件系統,生成一個由這些本地文件對應的所有HDFS數據塊的列表,作為報告發送到Namenode,這個報告就是塊狀態報告。云存儲系統的服務層為其管理層提供存儲等服務,其在云存儲系統中不可或缺。
2.2 冷數據掃描判斷技術
在本文的云存儲容災系統中,需要定期地對冷數據進行糾刪碼處理,所以首先需要對冷數據進行判斷。冷數據與文件的兩個屬性(文件修改日期和文件訪問的次數)密切相關。在文件信息表中,云存儲系統中的每個文件都有date(文件修改日期)和number(文件訪問的次數)的屬性。RS Coding Server利用這兩個屬性,并結合冷數據判定算法定期地進行掃描來判斷文件是否為冷數據文件。
3 系統性能分析
我們目前的HDFS集群搭建采用一臺NameNode節點、三臺DataNode節點。同時我們還使用了一臺RS Coding Server服務器和一臺Web服務器。RS Coding Server服務器主要負責冷數據文件編碼和丟失文件的恢復,其上安裝有myelcipse等工具。Web服務器主要負責基于Web模式的后臺程序和安裝數據庫。系統對所存儲的1TB的數據(包括不同大小的醫療文件)進行了全面測試,為了全面考量最主要的兩個編碼參數(即數據塊拆分和基本編碼單位Wbits,文件數據大小對于編碼性能的影響。
4 結束語
本文針對醫療工作中的實際情況,設計開發了一個基于RS糾刪碼的云存儲容災系統,在Hadoop平臺架構上實現了RS編碼/解碼,具有良好的容錯性能和存儲效率。實驗分析表明,所搭建的系統運行正常,在編碼單位W=16bits。
參考文獻
[1] 王珊,王會舉,覃雄派.架構大數據:挑戰,現狀與展望.計算機學報,2011,34(10):1741-1752.
[2] The Hadoop Distributed File System: Architecture and Design. http://hadoop.apache.org/docs/r0.
18.0/hdfs_design.pdf.
[3] Mengdi Wang, Bo Li, Yongxin Zhao, and Geguang Pu. Formalizing Google file system. In ACM PRDC '14, 2014, 190-19.