基于Hadoop的云架構(gòu)區(qū)域PACS存儲方案設(shè)計

1.中國人民解放軍第一八一醫(yī)院 信息科，廣西 桂林 541002；

2.南方醫(yī)科大學 生物醫(yī)學工程學院，廣東 廣州 510515

基于Hadoop的云架構(gòu)區(qū)域PACS存儲方案設(shè)計

唐穎1，劉國慶2

1.中國人民解放軍第一八一醫(yī)院 信息科，廣西 桂林 541002；

2.南方醫(yī)科大學 生物醫(yī)學工程學院，廣東 廣州 510515

云存儲為區(qū)域圖片存檔及通訊系統(tǒng)（PACS）的影像文件存儲問題提供了有效的解決方案。本文在分析區(qū)域PACS存儲需求以及目前存儲現(xiàn)狀的基礎(chǔ)上，構(gòu)建一個以Hadoop為基礎(chǔ)的云存儲服務架構(gòu)。針對區(qū)域PACS影像文件類型較為單一的特點，設(shè)計了兩套存儲方案并開發(fā)了一套中間件加以測試。測試結(jié)果表明，隨著DataNode節(jié)點增多，存儲性能近似線性增加；為了盡快讀取并顯示影像，存儲文件不宜過大，以每個文件不超過64MB為宜。

HIS；PACS；云存儲；云計算；區(qū)域PACS

0 前言

《中共中央、國務院關(guān)于深化醫(yī)藥衛(wèi)生體制改革的意見》明確指出[1]：“建立分工明確、信息互通、資源共享、協(xié)調(diào)互動的公共衛(wèi)生服務體系。”在全國區(qū)域化醫(yī)療衛(wèi)生改革進程中，區(qū)域圖片存檔及通訊系統(tǒng)（PACS）是比較重要的一環(huán)。區(qū)域PACS指以區(qū)域網(wǎng)絡(luò)平臺為基礎(chǔ)，以區(qū)域內(nèi)中心醫(yī)院或大醫(yī)院為核心，建立跨醫(yī)院和醫(yī)療機構(gòu)的醫(yī)學影像信息交換平臺，實現(xiàn)區(qū)域內(nèi)醫(yī)學影像數(shù)據(jù)與信息的共享。但目前離這個目標仍然有相當一段距離，其中遇到最大的障礙就是醫(yī)學影像文件的存儲問題。

1 區(qū)域PACS對存儲的要求

1.1 存儲特點

PACS存儲主要是指圖像文件的存儲，其特點：① 數(shù)據(jù)量大，增長速度快，如301醫(yī)院的放射科每天的影像壓縮后也有40多GB，1年約10TB[2]；② 圖像文件通訊格式為DICOM、文件尺寸較大；③ 數(shù)據(jù)保存時間長，醫(yī)學影像一般要求能存儲15年；④ 可分級存儲，近期訪問量大的數(shù)據(jù)采用在線存儲，遠期訪問量小的數(shù)據(jù)采用近線或離線存儲；⑤ 可通過歸檔管理功能，實現(xiàn)容災保護。

針對這些特點，區(qū)域PACS設(shè)計應該采用多數(shù)據(jù)中心的模式，以保證提供多個存儲節(jié)點的數(shù)據(jù)服務。

1.2 存儲現(xiàn)狀

目前，各醫(yī)院的PACS一般都遵循DICOM標準，而在存儲方面則各行其便，沒有統(tǒng)一規(guī)范。當醫(yī)院的業(yè)務發(fā)展越來越大，以及面向區(qū)域化后，這些PACS就會面臨下面的問題：① 存儲可擴展性差，多數(shù)醫(yī)院的PACS存儲架構(gòu)很難長期支持，每過一定時間就要進行擴容操作，而且擴容后文件查詢搜索等性能相應降低；② 區(qū)域共享困難，各醫(yī)院的PACS之間要建立數(shù)據(jù)共享，只能建立各自的存儲接口來實現(xiàn)，這種數(shù)據(jù)傳輸方式是應用層面的，它的改動會導致各PACS相應變動，造成升級維護困難；③ 安全性不佳，存儲數(shù)據(jù)的備份措施不足，很容易因硬盤故障等原因?qū)е掠跋駭?shù)據(jù)的大量丟失，甚至無法恢復。

PACS提供商主要專注于應用層面，存儲層面專業(yè)性不夠。要解決上述問題，只有建立統(tǒng)一的存儲平臺才能得以解決。從云計算發(fā)展而來的云存儲[3]是一個很好的解決方案。

2 基于云存儲的區(qū)域PACS架構(gòu)設(shè)計

2.1 云存儲優(yōu)勢

區(qū)域PACS平臺建設(shè)可以按混合云的方式進行，即在區(qū)域PACS平臺內(nèi)部，每個醫(yī)院的數(shù)據(jù)中心均作為云存儲的一個單元，它們聯(lián)合組成區(qū)域PACS平臺的私有云存儲，主要用來存放近期數(shù)據(jù)。遠期數(shù)據(jù)可存放在商業(yè)云存儲中，同時在各數(shù)據(jù)的本地做好備份。私有云存儲以高速網(wǎng)絡(luò)進行建設(shè)，如虛擬私人網(wǎng)絡(luò)（VPN）專線[4]，以保證近期數(shù)據(jù)讀取的傳輸速度；遠期數(shù)據(jù)存放在商業(yè)云存儲中，即使公有網(wǎng)絡(luò)速度較慢，數(shù)據(jù)讀取速度也能接受。

采用云存儲的諸多優(yōu)勢：

（1）成本優(yōu)勢。醫(yī)院只需購買保存近期影像文件的設(shè)備，遠期的歸檔數(shù)據(jù)放在商業(yè)云存儲中，不需要投入大量資金購買足夠的存儲設(shè)備、軟件建設(shè)和人力成本投入。

（2）管理優(yōu)勢。云存儲提供商負責存儲設(shè)備的運轉(zhuǎn)、維護、升級及日常管理工作，醫(yī)院節(jié)省了相關(guān)投入。

（3）擴展優(yōu)勢。云存儲的并行架構(gòu)原理決定了其擴展方便性，用戶只需購買空間，不用考慮空間的擴展與升級。

（4）訪問優(yōu)勢。對于使用云存儲的區(qū)域PACS系統(tǒng)，當用戶在區(qū)域外登錄系統(tǒng)時，與訪問網(wǎng)站一樣方便，這個特性對于移動智能終端用戶很有用。目前很多三甲醫(yī)院在推廣使用IPAD、手機等智能終端進行臨床診斷等醫(yī)務操作。對于采用云存儲的PACS來說，從電腦到智能終端的移植將會變得非常容易、成本低。

（5）定制優(yōu)勢。不同醫(yī)院對于存儲的需求各有區(qū)別，在配置問題既要滿足性能與安全要求，又要節(jié)省成本。云存儲服務商會根據(jù)區(qū)域PACS的需求情況以及項目的預算，提供合適的存儲解決方案。因此云存儲產(chǎn)品不僅提供了空間本身，還根據(jù)需求給出了一個量身定制的解決方案。

2.2 Hadoop簡介

Hadoop是由Apache基金會開發(fā)的開源的分布式系統(tǒng)基礎(chǔ)架構(gòu)[5]，既是用戶不了解底層細節(jié)的情況，也可以開發(fā)分布式程序。Hadoop平臺可運行在普通的PC機群上，極大地降低了研究開發(fā)成本。Hadoop框架中最核心的設(shè)計是HDFS（Hadoop Distributed File System）、MapReduce和HBase。

HDFS是Google的分布式文件系統(tǒng)（Google File System， GFS）的開源實現(xiàn)。其特點：容錯性高，可在低廉的硬件上進行部署；數(shù)據(jù)傳輸速度高，對于數(shù)據(jù)集大的應用程序特別適合；訪問可擴展性好，只需簡單地在集群里添加節(jié)點就能實現(xiàn)客戶端同時訪問數(shù)量多的情況；操作方便，同樣有傳統(tǒng)文件操作，如文件的創(chuàng)建、刪除、重命名等；HDFS數(shù)據(jù)塊的大小默認為64 MB，適合處理和存儲大文件，但對小文件不適合。

HDFS是主從結(jié)構(gòu)的體系框架，一個HDFS集群通常由一個NameNode節(jié)點與多個DataNode節(jié)點組成。NameNode節(jié)點是主服務器，其功能有管理客戶端訪問、管理數(shù)據(jù)元和文件塊、管理命名空間、監(jiān)聽請求和處理請求、心跳檢測等。而各DataNode節(jié)點則負責數(shù)據(jù)塊的讀寫，向NameNode報告節(jié)點狀態(tài)，執(zhí)行數(shù)據(jù)的流水線復制等存儲管理工作。

MapReduce是由Map和Reduce函數(shù)組成的一種簡化的并行計算模型，分別進行任務的分解和對結(jié)果的匯總。其原理是將待處理的數(shù)據(jù)集分解成多個子數(shù)據(jù)集，且每一子數(shù)據(jù)集都可并行處理。開發(fā)人員的主要工作是實現(xiàn) Map 和Reduce 函數(shù)，而不必去考慮一些底層細節(jié)，如容錯處理、負載平衡、網(wǎng)絡(luò)通信等，因此開發(fā)非常方便容易。

HBase是一個開源的、基于列存儲模型的分布式數(shù)據(jù)庫，是Google的Bigtable分布式數(shù)據(jù)庫的開源實現(xiàn)，它面向列，可伸縮性、可靠性高，性能好，其文件存儲系統(tǒng)是Hadoop HDFS，利用此技術(shù)可在普通PC機上建立大規(guī)模結(jié)構(gòu)化存儲集群。

以這些核心支柱為基礎(chǔ)的Hadoop，能夠?qū)Υ罅繑?shù)據(jù)進行分布式處理。其高可靠性體現(xiàn)在它保存的數(shù)據(jù)有多個副本，確保能夠針對失敗的節(jié)點重新分布處理，這也使其具有高容錯性。由于以并行的方式工作，處理速度大大加快，因此具有高效性。其可伸縮性則是由于它可方便增加節(jié)點，能夠處理 PB 級數(shù)據(jù)。此外，Hadoop的建設(shè)成本低，以Hadoop建立區(qū)域PACS的云存儲是非常適合的。

2.3 系統(tǒng)架構(gòu)設(shè)計

目前區(qū)域PACS和大型醫(yī)院全院PACS通常采用集中式存儲，存儲架構(gòu)大多采用“在線-近線-離線”三級存儲模式[6]，這種模式常用直連式存儲，存儲設(shè)備直接與主機相連接，容量擴充不方便，維護升級困難。另外，區(qū)域PACS數(shù)據(jù)是PB級的，要保證所有數(shù)據(jù)的存儲被高速實時訪問，目前技術(shù)下，直連式存儲顯然滿足不了這要求，即使是SAN(存儲區(qū)域網(wǎng)絡(luò))和NAS(網(wǎng)絡(luò)連接式存儲)也難以實現(xiàn)。目前的架構(gòu)下，遠期影像數(shù)據(jù)一般是以離線方式，通過光盤庫或磁帶庫的方式保存，實時訪問困難，系統(tǒng)可用性差。產(chǎn)生這些問題的根源主要是采用了集中式存儲架構(gòu)。

針對上述問題，采用私有云存儲與商業(yè)云存儲相結(jié)合的方式，更改區(qū)域PACS架構(gòu)，將集中式存儲改為分布式存儲，去除“離線”部分，將“在線-近線-離線”三級存儲架構(gòu)更改為“在線-歸檔”二級存儲架構(gòu)。“離線”存儲，可以有效提高系統(tǒng)的可用性。這樣既可滿足PB級存儲容量的需求，也可實現(xiàn)原來“離線”數(shù)據(jù)的實時訪問，提升系統(tǒng)可用性。

區(qū)域PACS的云存儲系統(tǒng)以Hadoop為基礎(chǔ)架構(gòu)，整個框架由基于HDFS的物理層、用于處理和存儲影像數(shù)據(jù)服務的中間層、調(diào)用這些服務的接口層以及具體的應用層組成，見圖1。物理層，即存儲設(shè)備具有海量的存儲容量，存儲架構(gòu)為HDFS，通過HDFS實現(xiàn)負載均衡、數(shù)據(jù)備份等功能，并向外提供統(tǒng)一的存儲訪問接口。中間層實現(xiàn)影像數(shù)據(jù)的存儲與讀取，該功能通過訪問物理層的HDFS提供的接口實現(xiàn)。接口層在中間層的基礎(chǔ)上做進一步的功能封裝，使開發(fā)編程更容易。應用層則利用接口層提供的功能接口，編寫分布式的并行處理應用程序。

圖1 云存儲架構(gòu)示意圖

2.4 基于HDFS的文件處理

DICOM圖像通常都是小文件，較大的文件如DR、CR一般是在10 M字節(jié)左右，而CT、MR文件則只有幾百K字節(jié)大小。由于HDFS文件系統(tǒng)里默認的數(shù)據(jù)塊大小是64 M字節(jié)，存放的小文件太多，將消耗大量HDFS主節(jié)點NameNode內(nèi)存，從而降低整個集群性能[7-8]。另外，由于每個文件會被復制3份，過多的小文件會使性能降低，因此需要建立一個處理小文件的抽象層，對每個病人采集到的圖像文件進行處理。對于云存儲中小文件存儲與訪問問題，可通過自適應文件系統(tǒng)進行優(yōu)化[9]。針對區(qū)域PACS影像文件類型較為單一的特點，提出了兩個解決方案進行研究。

第一個方案是將每幅圖像看作一幀，把一次檢查的所有圖像合并成一個序列圖像文件。在DICOM文件中，圖像數(shù)據(jù)保存在Pixel Data數(shù)據(jù)元素中，它的值域中保存的像素數(shù)據(jù)可以是原始數(shù)據(jù)，也可以是經(jīng)過封裝的。封裝的像素數(shù)據(jù)的值是由分割開的多個像素數(shù)據(jù)流組成，以此來表示多幀的圖像[10]。此方案要等文件下載完后才能顯示，而不是醫(yī)生所習慣的邊下載邊顯示，當病人一次檢查的圖像很多時(如CT圖像，可達上千張)，圖像文件總大小達幾百M甚至G數(shù)量級，下載時間稍長會讓醫(yī)生覺得難以忍受。

第二個方案是分組壓縮。將病人的圖像文件按其序列（Series_no）號及編號（Instance_no）的順序進行分組，每一組的文件總大小為64 M左右，然后分別將每一組文件壓縮成一個壓縮文件進行存儲，這樣在下載的時候，下載一組就解壓并顯示，以實現(xiàn)邊下載邊顯示圖像的功能。此方案的優(yōu)點還在于它對圖像的壓縮式無損，壓縮后文件通常不到原來文件總大小的1/2，明顯地減少了網(wǎng)絡(luò)傳輸時間。

為實現(xiàn)并測試這兩個方案的功能，設(shè)計了一套DICOM文件讀寫中間件，封裝了底層操作細節(jié)，實現(xiàn)DICOM文件的查詢、讀取和寫入等功能，并為應用層提供統(tǒng)一的接口，可根據(jù)配置選擇方案1或方案2。

3 云存儲測試及分析

3.1 測試方法

測試云架構(gòu)下的文件寫入與讀取速度，以及它們與DataNode節(jié)點數(shù)的關(guān)系；同時測試方案1與方案2環(huán)境下，不同大小影像文件的下載并顯示效果。

硬件環(huán)境：采用1臺服務器(華碩 Z8NAD6，CPU：Intel Xeon E5504；內(nèi)存：8GB DDR3）與普通PC機5臺(聯(lián)想啟天M488E，CPU：E2180 2.0GHz，內(nèi)存1GB)進行模擬研究。普通PC機運行DataNode，網(wǎng)絡(luò)是內(nèi)部局域網(wǎng)、100M網(wǎng)口。其中，服務器的功能是：接收從設(shè)備或醫(yī)生工作站傳來的DICOM文件；在病人少的閑時階段（晚上時間，可以自行設(shè)定），利用前述的中間件處理當天接收的DICOM文件，并發(fā)送到云存儲；接收醫(yī)生工作站下載DICOM文件請求，如果本地有該文件，則從本地發(fā)送到醫(yī)生工作站，如果本地沒有，則從云存儲查詢并下載文件，發(fā)送到醫(yī)生工作站。

系統(tǒng)軟件環(huán)境：服務器操作系統(tǒng)Windows2008，數(shù)據(jù)庫用Oracle10g，云存儲文件系統(tǒng)是Hadoop-HDFS 0.20.1，在每一臺機上均安裝并配置JDK環(huán)境（版本1.6）。

3.2 測試結(jié)果及分析

測試不同DataNode的讀寫速度、測試結(jié)果，見表1。

表1 文件讀寫速度(MB/s)

從測試結(jié)果可以看出，隨著DataNode節(jié)點數(shù)增加，讀取速度相應增加，基本是與Client數(shù)量線性相關(guān)的。這是由于Hadoop中的數(shù)據(jù)塊是盡可能均勻分布在各DataNode節(jié)點中的，讀取文件時可以聚合各DataNode節(jié)點的網(wǎng)絡(luò)帶寬，隨著DataNode數(shù)量的增大，其總帶寬也大大增加。

從測試結(jié)果也可看出，Hadoop的寫入速度明顯差于讀取速度，這與HDFS的工作原理有關(guān)，因為寫入一個文件要同時做3個備份。但隨著DataNode節(jié)點數(shù)量的增加，寫入速率也相應增大，基本上與DataNode節(jié)點成線性關(guān)系。

以某病人的CT檢查為例，共有2185幅圖像，文件總大小為1.15 G。在方案1中，生成了一個1.16 G大小的DICOM序列圖像文件；在方案2中，生成了53個壓縮文件，每個文件大小在17～25 MB，平均21.7 MB。測試過程中記錄所有壓縮文件的寫入/讀取總時間，再分別求平均值。測試結(jié)果見表2（方案2的數(shù)據(jù)中，斜杠“/”前面是所有壓縮文件的總讀取時間，后面是每個壓縮文件的平均讀取時間)。

表2 讀取時間(s)

從表2可看出，隨著DataNode節(jié)點數(shù)增加，處理時間大大縮短，這與前面結(jié)果一致。方案2的總處理時間均比方案1長，這是因為方案1只需1次網(wǎng)絡(luò)連接請求，而方案2則需53次。但在方案1中，醫(yī)生至少需要17.3 s才能看到圖像，而方案2中，最多需2.3 s就能看到圖像，最少僅0.3 s就能看到。

另外，在方案2中，壓縮文件平均大小為21.7 MB，離HDFS默認的64 MB數(shù)據(jù)塊大小有不小差距，這仍會在一定程度上增加NameNode服務器內(nèi)存消耗，因此壓縮處理算法需要改進，將判斷壓縮前的文件總大小不超過64 MB，改為判斷壓縮處理后的文件大小不超過64 MB，這需要在后續(xù)研究中改進。

4 結(jié)束語

云存儲是目前的一個應用研究熱點。云存儲服務為區(qū)域PACS影像文件的存儲問題提供了有效的解決方案，有效解決了構(gòu)建區(qū)域醫(yī)學影像數(shù)據(jù)中心的成本高、可擴展性差、傳輸帶寬不足、離線數(shù)據(jù)可用性差等問題，同時減低了投入，節(jié)約成本。本文構(gòu)建了一個以Hadoop架構(gòu)為基礎(chǔ)的云存儲服務系統(tǒng)，針對HDFS不適合CT、MRI等小文件的存儲的問題，開發(fā)了一套中間件，用于將小文件合并為大文件，使其適應HDFS的存儲特點。測試結(jié)果表明，以Hadoop為基礎(chǔ)架構(gòu)的云存儲平臺隨著DataNode節(jié)點增多，性能近似線性增加。同時還研究了文件大小對于客戶端讀取并顯示圖像效果的影響，結(jié)果表明單純地將病人一次檢查圖像合并為一個大文件是不可取的，應當考慮到網(wǎng)絡(luò)下載速度以及診斷醫(yī)生觀感，每個文件以不超過64MB為宜。下一步的研究工作是對中間件功能進一步完善，并研究區(qū)域PACS云存儲系統(tǒng)的數(shù)據(jù)安全與加密機制，確保醫(yī)院及病人的相關(guān)隱私及數(shù)據(jù)安全。

[1] 新華社．中共中央國務院關(guān)于深化醫(yī)藥衛(wèi)生體制改革的意見[EB/OL]．(2009-04-08)[2013-05-20]．http://www．gov．cn/ test/2009-04/08/content_1280069．htm．

[2] 楊文燕．PACS存儲管理亟待優(yōu)化[EB/OL]．(2009-06-18)[2013-05-20]．http://www．chinaehc．cn/index．php?option=com_content& view=article&id=947．

[3] 張建勛,古志民,鄭超．云計算研究進展綜述[J]．計算機應用研究,2010,27(2):429-433．

[4] 丁靖宇,樂嘉錦,金耀輝．基于VPN實現(xiàn)企業(yè)虛擬私有云的體系架構(gòu)[J]．計算機應用與軟件,2011,28(8):212-215．

[5] Tom White．hadoop:the definitive guide[M]．南京:東南大學出版社,2011．

[6] 李彭軍,陳光杰,郭文明．基于HDFS的區(qū)域醫(yī)學影像分布式存儲架構(gòu)設(shè)計[J]．南方醫(yī)科大學學報,2011,31(3):495-498．

[7] Tom White．The small files problem[EB/OL]．(2009-02-02)[2013-05-20]．http://www．cloudera．com/blog/2009/02/the-small-files-problem/．

[8] 袁玉,崔超遠,烏云,等．單機下Hadoop小文件處理性能分析[J]．計算機工程與應用,2013,49(3): 57-60．

[9] 李建國,袁平鵬．一種基于分布式開放資源管理服務的“云存儲”(ppStore)方案研究[J]．計算機應用與軟件,2011,28(10):208-210．

[10] 李卓,陳鵬,吳玲達．基于DICOM的數(shù)據(jù)組織及醫(yī)學圖像序列提取方法研究[J]．計算機工程與應用,2005,(8):221-223．

storage Design of Regional PACs Based on Cloud Architecture of Hadoop

TANG Ying1, LIU Guo-qing2
1. Department of Information, 181thHospital of PLA, Guilin Guangxi 541002, China
2. Department of Biomedical Engineering, Southern Medical University, Guangzhou Guangdong 510515, China

Cloud storage offers an effective solution for storage problems of regional PACS (Picture Archiving & Communication System) image file. On the basis of analyzing regional PACS storage needs as well as the storage situation, a Hadoop-based cloud storage architecture was built. To improve degraded performance resulting from large quantity of small files storage, this paper designed two sets of storage solutions and developed a set of middleware. A test platform of Hadoop-based cloud storage was built and the results showed that: as DataNode nodes increased, the storage performance increased linearly; storage file should not be too large for image reading and displaying as soon as possible, each file should be kept within 64MB.

HIS; PACS; cloud storage ; cloud computing; regional PACS

TP391

A

10.3969/j.issn.1674-1633.2013.08.017

1674-1633(2013)08-0047-04

2013-05-20

2013-07-15

廣東省科技計劃項目（2010B060100047）。

本文作者：唐穎，副主任技師。

劉國慶，博士。

作者郵箱：lieut@163．com