三種海量醫學圖像存儲技術對比分析

高杰誠 ，楊媛媛

1 中國科學院上海技術物理研究所 醫學影像實驗室，上海市，200083

2 中國科學院大學，北京市，100049

0 引言

隨著計算機和網絡技術的不斷發展，各種數據呈現爆炸式增長。根據IDC的報告顯示，到2020年，全球大數據將比2010年增長22倍，或將達到44 ZB的體量[1]。目前國內的醫學影像云平臺的發展情況是在北京、上海、江蘇等地分別采取了不同的方式來建立區域型醫學影像平臺[2]。然而這些平臺設計不是很完善，整體上醫院還是依靠傳統本地文件存儲（包括本地網絡存儲）的單一化方式來存取醫療數據。傳統的數據存儲方式將病人的電子病歷、檢查檢驗數據以及影像等醫療數據有效快速地集中存儲和讀取，可是相較于如今對大數據特性的要求，本地存儲網絡已經不能夠勝任這個需求[3]。在國外，SwiftStack公司提出了一種用來解決病人醫學數據存檔的解決方案，包含了醫學影像數據和廠商中立歸檔（vendor neutral archives,VNAs），通過基于OpenStack Swift的框架設計的分布式對象存儲系統[4]。此外另一類分布式文件存儲系統Apache Hadoop項目的hadoop distributed file system（HDFS）也被用于海量醫學數據的分析中。不過很多醫學影像數據屬于小文件（如單幅CT圖像512 kB、單幅MR圖像120 kB等），影響了HDFS存取性能。不過目前有些機構對HDFS這一缺陷進行了一些優化，將小文件的訪問效率和存取速度提高了2.7倍[5]。

由于這些存儲醫學圖像的存儲系統之間的對比分析一直未見報道，于是通過實驗室研發的醫學圖像通信與存儲系統（picture archiving and communication systems,PACS）接入這三種存儲系統，從存取速度、部署方式、數據安全和性能等方面進行比較，為海量醫學圖像存儲提供其中一種或多種存儲方案。

1 三種存儲方式簡介

目前對于文件的存儲，主要有三種方式：本地集中文件存儲、分布式文件存儲和分布式對象存儲。在個人的日常生活中，這三種存儲方式中以本地集中文件存儲使用最為普遍。然而，隨著信息時代的不斷發展，各行各業的數據量都呈現指數上漲的趨勢，這種傳統的文件存儲不僅會提高本地存儲的硬件成本，同時還會使得存儲硬件自身的保養、安放變得更為困難。因此，分布式文件存儲和分布式對象存儲就逐漸地被大多數廠商用于存儲數據。

1.1 本地集中文件存儲

本地集中文件存儲主要是將文件都存儲在本地環境中的方式，包括服務器內置硬盤存儲、服務器直連存儲、存儲局域網絡SAN和網絡附加存儲NAS，這類存儲是當前絕大多數醫療數據存儲采用的方法，優點在于在局域網環境下易于分配管理，具有一定的利用率，同時存取時可以借助于內存存儲的優勢達到很好的性能。當文件過于龐大或者是突然要存儲大量的文件時，本地集中文件存儲的性能會急劇下降，這是因為本地集中文件存儲的高性能內存存儲不能即時處理大文件或大量文件，而且自身成本過高；而成本相對較低的硬盤存儲則速度更慢。此外，如果本地集中文件存儲系統在傳輸過程中出現錯誤或者進行文件校驗時，將會受到本地集中文件存儲的文件系統路徑的復雜度的影響[6]，效率降低。

1.2 分布式文件存儲

分布式文件存儲即利用分布式文件系統把多個存儲節點的資源整合成一個集群協同工作，共同對外提供存儲和業務訪問。該存儲方式不僅是存儲設備硬件組合，還包括網絡設備、服務器等硬件和控制軟件、訪問接口及各種對外服務軟件等，具有配置簡單、動態調整、可擴展性、高可靠性等特點。常見的分布式文件存儲以HDFS為代表。

1.3 分布式對象存儲

對象存儲即將文件視為對象存儲。對象化的文件包含了文件自身所包含的數據、元數據以及特定的全局特征值。文件的元數據指文件名、文件大小、創建時間、對象版本等不可更改的數據。和分布式文件存儲相同，分布式對象存儲的可擴展性也非常強。對象存儲設備與本地集中文件存儲和分布式文件存儲設備不同的地方在于，其文件的存儲路徑不會像前兩者那樣層層分級，這樣在存儲的過程中會省去尋找路徑過程中的麻煩和時間損耗。對象存儲扁平化的存儲方式更加易于分布式的架構，從而幫助對象存儲能夠保證文件存儲的穩定性。分布式對象存儲既擁有了網絡附屬存儲（NAS）的分布式特點帶來的穩定性，又擁有了存儲區域網絡（SAN）的高性能高速性能[7-8]。常見的分布式對象存儲有OpenStack Swift等。

2 OpenStack Swift、HDFS存儲原理

2.1 OpenStack Swift存儲原理

OpenStack Swift是Rackspace公司開發的高可用性分布式存儲系統，一開始Swift模塊是用作OpenStack整個系統中Nova模塊的子功能[9]。Swift通過犧牲一定的數據一致性，通過在軟件層級上引入一致性散列（Consistent Hashing）和數據冗余性，保證了其高可用性和可伸縮性。OpenStack Swift支持云端部署和本地部署兩種部署方式，不過由于其扁平化的存儲方式更適合于云端部署。OpenStack Swift的對象傳輸通過RESTful API或者HTTPS協議實現[10]，適合頻繁讀寫海量文件的場景。

（1）一致性散列

面對海量級別的數據對象，Swift通過一致性散列法則將數據尋址的問題解決。通過計算，Swift將這些對象數據均勻分布地放在各個虛擬節點上。Swift放棄了嚴格一致性，而是使用仲裁機制（Quorum）達到最終一致性（Eventual Consistency）。

（2）環數據結構

環數據結構是Swift用來將其系統中的虛擬節點映射到具體的磁盤上的。通過環數據結構，Swift的所有數據模型包含用戶、容器、對象都可以保證其高度的一致性和可用性。

（3）Swift數據模型

如圖1所示，Swift的數據模型為只有三層的層次模型，包含賬戶（Account）、容器（Container）以及對象（Object）三種。賬戶是Swift數據架構的頂層節點。賬戶包含了該賬戶下面的所有容器以及對象的所屬；容器是用來包含所屬對象；對象包含元數據（metadata）和內容（content）[10]。

圖1 Swift的數據結構Fig.1 Data structure of Swift

（4）系統架構

Swift采用了完全對稱的、可擴展的架構，避免了在單點失效時系統數據崩潰的情況。其組件包括：代理服務（Proxy Server）、認證服務（Authentication Server）、緩存服務（Cache Server）、賬戶服務（Account Server）、容器服務（Container Server）、對象服務（Object Server）、復制服務（Replicator）、更新服務（Updater）、審計服務（Auditor）、賬戶清理服務（Account Reaper）[11]。Swift的系統架構，如圖2所示。

圖2 Swift的系統架構Fig.2 Architectural structure of Swift

（5）文件安全

OpenStack Swift針對存儲文件過程的安全問題有自己獨特的解決方案：首先將API、計算節點等核心服務設計成必須要在兩個安全域內同時存在。這樣使得單一的對某個安全域的攻擊無法有效地侵入核心服務[12]。其次在進行對象加密的時候，可以選擇使用加密中間件或者OpenStack Barbican來進行對對象內容、對象元數據和非空對象的實體標簽的根密鑰管理[13]。OpenStack Swift還會對每個數據節點進行復制，這樣如果當中任何一個節點出現故障，其復制節點會通過rsync服務同步到損毀節點中。

2.2 HDFS存儲原理

HDFS是Apache Hadoop項目中用于存儲的分布式文件存儲系統。它在相對低成本的硬件基礎上就能夠搭建一個分布式存儲系統。與傳統的本地文件集中存儲不同的是，HDFS具有高容錯性、高安全性和高數據流通性[14]。HDFS的數據塊傳輸可以通過HDFS提供的Java API實現。通過NFS Gateway組件，HDFS還可以作為客戶端掛載到本地文件系統[15]。

HDFS同樣適合云端部署和本地部署兩種部署方式，不過這兩種部署方式卻由于HDFS本身設計的特性各有優缺點[16]。雖然HDFS最初設計的理念是基于本地數據中心且HDFS的讀取性能非常受本地磁盤的I/O性能或者網速的影響，但HDFS若使用云端部署，相比本地存儲可以直接數據拷貝，云端存儲為了節省存儲開銷需要將數據先進行編碼再進行拷貝[17]，讀寫性能會稍強于本地部署，且通過虛擬化共享存儲層，使得HDFS部署所需的系統安裝等變得更加方便。如今本地I/O和網速性能發展到不再限制HDFS的讀取性能，VMware指出通過vSphere 6上部署4個虛擬機與物理本地存儲進行數據處理速度比較時，虛擬機比物理部署在map-shuffle操作速度上更快[18]。

（1）核心組件

HDFS的系統架構，如圖3所示。HDFS的核心組件包括NameNode和DataNode。NameNode是用來對元數據（metadata）進行操作，如打開、關閉、重命名文件以及路徑等。此外NameNode還可以決定數據塊（block）到DataNode的映射。DataNode是用來存儲數據內容（content）的，它可以對數據的讀寫請求進行操作，同時它還對NameNode的指令進行數據塊的建立、刪除和復制的操作[19]。

圖3 HDFS的系統架構Fig.3 Architectural structure of HDFS

（2）優勢及缺點HDFS依據分布式的架構，可以形成高可用性（high availability，HA）和恢復機制。此外HDFS適合一次寫入、多次讀取、允許追加。這樣的一致性模型有利于提高系統的吞吐量。然而HDFS并不適合小文件存儲：小文件過多會占用NameNode的內存，且會造成尋道時間大于讀寫時間[5]，從而造成性能的浪費。

（3）文件安全

HDFS支持數據庫和文件系統層級的加密，同時如果接入的應用滿足應用層級加密，那么HDFS也可以滿足應用層級加密[20]。此外，在HDFS中存儲和讀取的都是數據塊而不是文件本體，并且一個文件會被分割成多個數據塊。因此在攻擊HDFS時只會獲得意義不明、殘缺的數據塊并且很難將其還原成文件。

HDFS將存儲的數據塊進行復制分配到各個存儲節點中，默認數值為3，這樣可以保證，其中某個存儲節點出現故障導致其數據塊缺損，也能夠通過其他存儲節點中獲得數據塊并且修復該存儲節點。

3 實驗環境和測試結果

3.1 實驗環境

為了測試這三種存儲方式的存取醫療影像的性能，在虛擬機上搭建了三個集群，分別是OpenStack Swift集群、HDFS集群以及本地文件存儲集群。本次實驗所使用的OpenStack Swift版本號為2.18.0，HDFS版本號為3.1.1，Java版本為1.8.0_251，副本數為3，HDFS塊大小為64 MB，內存大小均為4 GB，搭載系統為CentOS 7。本地集中文件存儲由三個硬盤大小為60 GB的節點組成。OpenStack Swift和HDFS則各由一個硬盤大小為25 GB的控制節點和兩個硬盤大小為60 GB的存儲節點組成，其控制節點只參與存儲和讀取命令的調度而不直接參與存儲過程。

3.2 存取速度測試

測試需要考慮到各種類型和大小的醫學圖像，常見的CT圖像（平均大小545 kB）、MR圖像（平均大小182 kB）、DX圖像（平均大小8.29 MB）以及目前興起的PET/CT圖像（平均大小245 kB）均被納入為測試的對象。采用實驗室研發的PACS系統分別接入三種存儲系統環境，各對4 000幅CT圖像、MR圖像、X光圖像和PET/CT圖像進行20次傳輸速度測試，測試基本流程如圖4所示，再通過PACS醫學圖像診斷工作站分別讀取圖像并記錄讀取速度。

圖4 測試流程Fig.4 Test flow chart

經過一輪測試可見，由于測試的醫學圖像數據量較小，本地文件存儲的存儲速度其CT約為1.64 ms/幅，MR約為0.97 ms/幅，DX約為74.79 ms/幅，PET/CT約為0.012 ms/幅；本地文件存儲的讀取速度其CT約為1.04 ms/幅，MR約為1.01 ms/幅，DX約為68.80 ms/幅，PET/CT約為0.013 ms/幅。OpenStack Swift較慢，其讀取速度要比本地文件存儲要慢15.46%。OpenStack Swift的存儲速度CT約為1.95 ms/幅，MR約為0.96 ms/幅，DX約為77.11 ms/幅，PET/CT約為0.010 ms/幅；OpenStack Swift的讀取速度其CT約為1.51 ms/幅，MR約為1.00 ms/幅，DX約為70.21 ms/幅，PET/CT約為0.010 ms/幅。HDFS的讀取速度和本地文件存儲的速度相當甚至略快，CT圖像的存儲速度比本地文件存儲要快28.13%，約為1.28 ms/幅，MR約為0.96 ms/幅，DX約為70.17 ms/幅，PET/CT約為0.009 ms/幅；HDFS的讀取速度其CT約為1.19 ms/幅，MR約為0.92 ms/幅，DX約為61.53 ms/幅，PET/CT約為0.007 ms/幅。這符合HDFS將文件變為數據塊之后存儲速度上升的事實。HDFS是實驗中存取速度最快的存儲系統。

3.3 高可用度測試和成本比較

為了檢驗OpenStack Swift和HDFS的高可用度，還要在一個存儲節點出現故障時進行存取速度測試。本次測試的OpenStack Swift與HDFS集群及上一節實驗配置除了各自關閉其中一個存儲節點之外全部相同。

在減少一個存儲節點之后，OpenStack Swift和HDFS的存儲圖像的速度沒有多少改變，OpenStack Swift的存儲速度CT約為1.95 ms/幅，MR約為0.97 ms/幅，DX約為77.20 ms/幅，PET/CT約為0.010 ms/幅；OpenStack Swift的讀取速度其CT約為1.61 ms/幅，MR約為0.99 ms/幅，DX約為70.01 ms/幅，PET/CT約為0.011 ms/幅。HDFS的存儲速度CT約為1.29 ms/幅，MR約為0.97 ms/幅，DX約為70.44 ms/幅，PET/CT約為0.009 ms/幅；HDFS的讀取速度其CT約為1.24 ms/幅，MR約為0.96 ms/幅，DX約為62.41 ms/幅，PET/CT約為0.007 ms/幅。因此這兩個分布式存儲系統都可以保證高可用性。

從安裝成本考慮，HDFS和OpenStack Swift都可以部署在成本較低的硬件中或者直接進行云部署。從部署時間成本考慮，OpenStack Swift的部署難度高于HDFS，缺少官方的錯誤解決方案和繁瑣的部署步驟使得OpenStack Swift的部署時間成本遠遠高于HDFS，這樣相較之下在解決部署或者運行的時候出現的故障，HDFS的解決速度會快于OpenStack Swift。

4 結束語

海量醫學圖像的三種存儲技術，本地集中文件存儲、分布式文件存儲和分布式對象存儲，在經過存取速度測試之后發現HDFS存取醫學圖像最快，在存儲和讀取單張CT圖像都可以達到毫秒級。顯然在本地集中文件存儲性能發展遇到瓶頸，未來的海量醫學圖像存取在高速高穩定的要求下，分布式存儲系統是相較于本地集中文件存儲的更優解。此外在三個分布式存儲系統中，HDFS經濟成本和時間成本是最低的，因此HDFS最為合適。

在實驗中，還有一些尚未考慮的因素，例如是否可將HDFS進行優化之后再進行文件傳輸測試，因為頻繁地寫入小文件是浪費HDFS性能的表現。HDFS的系統架構如果有了官方進一步的優化，分布式文件存儲系統就可以應用到所有醫療數據的存儲中。此外HDFS可以直接和大數據處理框架MapReduce對接，直接完成大數據存儲處理的流程，這樣更適合將來醫療云計算平臺的搭建。綜上，筆者推薦使用以HDFS為代表的分布式文件存儲系統來作為存儲和讀取醫學圖像首選的存儲系統。