隨著CT(X射線)、MR(核磁共振)等醫學影像設備的迅速發展，拍攝出來的醫學影像清晰度顯著提高,但所占空間也明顯增大[1]。與此同時，重大疾病發生率的增高等因素導致醫學影像數據量增加迅速。目前，一個大型醫院每天將產生50 GB以上的數據，全院總數據量已經達到了30 TB級別，醫生每天都需要頻繁地讀取影像數據來輔助診斷。因此，一個性能良好的醫學影像傳輸及存儲系統顯得格外重要。近年來云計算技術正逐步從理論研究走向實際應用，作為一種新型的體系架構，云計算是一個充分利用信息資源的平臺。對于對應用平臺高要求、且資金受限的醫院來說，云計算有望為其提供一個新的解決方案。

1 系統技術概述
1.1 云計算
    云計算(Cloud computing)融合了分布式并行計算、網絡存儲、負載均衡等多種傳統計算機和網絡技術，以其獨特的擴展性、廉價性及容錯力受到廣泛關注。Hadoop是Apache開發的一個云計算的開源平臺，主要包括分布式文件系統(HDFS)和并行計算框架(MapReduce)。Hadoop集群的規模少則幾臺，多則可上千臺，其存儲與計算能力也隨著規模的擴大而穩步提高。
    HDFS是Hadoop的文件存儲系統，適合于大規模數據集上的應用。HDFS將一個大文件分成若干個數據塊，并創建多份復制保存在多個數據節點集合中，避免發生單點故障。因此利用HDFS能使系統實現：大規模數據存儲、高冗余、輕松擴容、負載均衡[2]等功能。
　    MapReduce是Hadoop在HDFS基礎上的并行計算框架，為用戶提供方便實用的并行編程模式，實現大規模數據的并行計算。MapReduce的主節點根據輸入數據的鍵(key)，通過映射函數(Mapper)將輸入數據映射給不同的從節點進行并行運算,隨后再通過規約函數(Reducer)將各個從節點的運行結果進行歸約合并，形成最終的計算結果[3]。
1.2 DICOM概述
    數字影像和通信標準3.0(DICOM3.0)是由美國放射學會與美國國家電器制造商協會聯合制定的標準，規定了不同的醫療影像設備標準化的數據格式，從而使數字影像更有效率地傳輸和交換。DICOM主要的操作協議有C_STORE、C_FIND、C_MOVE,分別執行存儲、查找與獲取。
2 系統架構
    目前醫院采用PACS來進行醫學影像數據存儲與傳輸。數據讀寫速度和冗余性、系統擴展性、負載均衡等都是設計PACS所要考慮的重要方面。由于當前醫院數據全部存儲于光纖存儲局域網絡(FC-SAN)集中式存儲服務器中，因此在使用PACS過程中尚存以下問題：(1)數據讀寫速度慢。由于資金的限制，醫院將使用頻率較低的數據轉移到二級存儲設備中，導致讀寫效率十分低下。(2)服務器負載重。PACS依靠影像中心服務器和集中式存儲服務器進行數據調度和讀寫，而大量來自工作站的請求對影像中心服務器的處理器性能和存儲服務器的讀寫能力帶來極大的考驗。(3)計算能力差。工作站目前只能在單機環境下進行有限的圖像處理，無法提供大規模運算的服務。(4)不同醫院間數據難以共享。
2.1 架構設計
    為了解決上述問題，本文設計了一種將分布式與集中式存儲相結合的混合式PACS架構。在各醫院園區網內部搭建Hadoop云集群,利用Hadoop集群的HDFS分布式存儲數據,采用MapReduce進行大規模數據計算。系統整體示意圖如圖1所示。

      系統將所有原有的數據移至HDFS,集中式存儲服務器只保留近期數據。而新產生的圖像數據同時保存于集中式存儲服務器和HDFS中。通過這樣的方式節省集中式存儲服務器的空間,解決原二級存儲讀寫速度慢的問題，同時將數據存儲在HDFS中也有利于使用Hadoop的MapReduce框架進行并行計算。在后期系統升級過程中，只需要簡單地增加Hadoop集群的節點數目，即可提升系統存儲容量與計算性能。為了實現不同醫療組織間的資源共享，醫院園區網可以通過防火墻連接公網。對于來自公網上的工作站的請求，防火墻需要先對其進行安全認證和訪問控制，只有符合安全規定的請求才被遞交至影像中心服務器。
    此外，本文開發了SDCMO組件與WDO組件。作為中間件，它們屏蔽底層操作細節，為上層的應用系統提供統一的圖像寫入、讀取和查詢接口。系統架構圖如圖2所示。

2.2 SDCMO組件
    由于每個醫學影像文件不大，而HDFS會為每個文件分配固定的內存空間，因此處理大量的醫學影像文件會造成極大的內存開銷[4]。本文采用文件序列化技術(Sequence File)，將儲存于HDFS的每個DICOM數據映射成鍵值對(Key/Value)的形式。其中Key是DICOM數據文件名，而Value保存DICOM數據內容。每個DICOM數據被視為一條記錄，將每一組DICOM圖像合并成一個包含多條記錄的序列化的文件SDCM(Sequence-DICOM)，從而減少文件數目，節省內存空間，同時還利用了圖像序列之間的相關性進行無損壓縮。
    SDCMO(SDCM Operator)組件提供對SDCM文件操作的方法。主要包括4個部分：(1)SDCM定位器，負責獲取文件位置信息;(2)SDCM寫入器，負責向HDFS寫入SDCM數據;(3)SDCM讀取器，向HDFS讀取SDCM數據;(4)SDCMO Converter負責DICOM與SDCM之間的類型轉換。
2.3 WDO組件
　為了實現不同設備之間數據的透明交換與傳輸，本文開發了適配于DICOM 3.0數據標準的WDO(Web DICOM Operator)組件，該組件能夠解析、響應和封裝來自HTTP的C_STORE,C_MOVE和C_FIND報文，使HDFS能夠在接收存儲、獲取、查找請求報文時可執行相應操作[5]。該組件主要包括6個部分：(1)HTTP請求接收器, 負責接收和發送HTTP報文；(2)釋義器，負責解析HTTP的請求報文，并將其轉換為DICOM 3.0標準的請求；(3)DICOM請求器負責發送和處理DICOM響應報文；(4)STORE封裝器，提供封裝DICOM3.0標準的C_STORE報文的方法；(5)FIND封裝器，提供封裝DICOM3.0標準的C_FIND報文的方法；(6)MOVE封裝器,提供封裝DICOM3.0標準的C_MOVE報文的方法。
2.4 工作流程
2.4.1 圖像寫入流程
    考慮到安全問題，只有園區網內的影像設備和內部工作站有寫入權限。而對于來自公網的外部工作站無權對HDFS和FC-SAN進行寫入操作。圖像寫入流程如下：
    (1)工作站向影像中心服務器發送寫入請求(C_STORE)
報文；
    (2)影像中心服務器根據業務需求的不同選擇文件存儲位置，并修改索引表。若要存儲到HDFS，則執行步驟(3)、步驟(4),若存儲到FC-SAN則執行步驟(5)；
    (3)Hadoop名稱節點創建文件，分配存放數據各分塊的數據節點列表；
    (4)調用SDCMO組件中的數據轉換器,將DICOM文件轉換為SDCM類型，并調用SDCMO組件中的文件寫入器,將文件寫入HDFS的數據節點中，返回寫入成功信息，寫入過程結束。
    (5)直接寫入FC-SAN，寫入過程結束。
    對于需要從FC-SAN遷移備份至HDFS的數據，需遞歸地遍歷源文件夾下的所有子文件夾，不斷執行步驟(3)、步驟(4)執行寫入，完成數據遷移。文件寫入流程圖如圖3所示。

2.4.2 讀取/查詢流程
    文件讀取/查詢流程如下：
    (1)來自公網的外部工作站與醫院園區網關建立SSL連接，發出查詢請求。
    (2)網關的請求接收器與外部建立合法的SSL
連接，接收HTTP請求。
    (3)網關的釋義器將HTTP請求轉化為DICOM3.0標準的C_FIND報文。
    (4)DICOM請求器將C_FIND報文發送給影像中心服務器，影像中心服務器接收C_FIND請求，查找索引表中文件的位置信息。根據文件位置的不同跳至步驟(5)或步驟(6)。
    (5)接收來自FC-SAN的數據，跳至步驟(8)。
    (6)接收來自HDFS的數據名稱節點根據元數據，調度文件分塊所在的數據節點。
    (7)根據名稱節點中元數據的分塊信息，利用SDCMO組件中的文件讀取器得到SDCM數據，使用SDCMO組件中的數據轉換器將SDCM數據轉換為DICOM數據，并調用WDO組件中C_FIND報文的封裝接口FIND,將DICOM數據封裝為DICOM的響應報文。
    (8)釋義器將響應報文轉為HTTP報文。
    (9)將HTTP報文發送給HTTP請求器。
    (10)請求接收器將HTTP報文通過SSL連接發送給外部工作站，讀取過程結束。
    對于來自局域網的內部工作站的請求，由于其已在局域網環境中，且請求報文已經是DICOM3.0格式，只需直接將請求發送給DICOM請求器,并從步驟(4)開始執行即可。文件讀取/查詢流程如圖4所示。

2.4.3 圖像檢索流程
    當工作站需要執行圖像檢索等大規模運算時，執行流程與圖4大體一致，在步驟(4)的過程中還需要利用MapReduce進行特征計算、匹配以獲取檢索結果。
3 實驗測試
3.1系統配置
    在實驗環境中，采用Hadoop集群為基本配置，其中1臺作為HDFS的名稱節點兼MapReduce的主節點，4臺為HDFS的數據節點兼MapReduce的從節點。集群工作站配置一致，使用Intel(R) Core(TM) i3-2310M的CPU，內存2 GB，硬盤500 GB，并在Ubuntu操作系統上搭建Hadoop-1.1.2。
3.2 實驗結果分析
    (1)寫入與讀取測試：從圖5可以看出，HDFS的平均寫入、讀取速度分別為4.72 Mb/s和27 Mb/s,相比原系統FC-SAN的1.5 Mb/s和2.26 Mb/s，讀寫速度有了明顯的提升。
　(2)壓縮比測試：將一個病人產生的大約306 MB的MR圖像數據轉換為SDCM后，數據只有125 MB，壓縮率為40.8%；全系統平均壓縮率為40.6%。而采用SDCM不僅將原有數據進行無損壓縮，同時還將數據轉換為鍵值對的形式，有利于后期利用MapReduce對數據直接進行處理運算，省去了重新格式化數據的時間，提高了運算效率。
　(3)計算測試：由于特征提取是圖像計算的基本步驟，本系統就一個4.2 GB的DICOM數據(10 290個圖像文件)進行全局特征提取計算，以測試系統計算性能。在集群數目為1、2、3、4(集群數目為1時，即為原系統的單機運算模式)各自執行5次測試計算，取各自的平均計算時間。從圖6的實驗結果可以看出，對于較復雜的運算，多節點比單機下運行速度有了明顯的提高。

    云計算是一項新興技術，但目前并未廣泛地應用到醫療機構中。本文首先利用HDFS分布式文件系統與MapReduce計算框架技術設計了一個基于云計算技術的PACS混合架構，為原有PACS提供了一個低成本、易擴展、高效的技術方案；設計和實現了SDCMO組件和WDO組件，并簡述了系統在公網環境下的讀寫流程；然后通過硬件部署的設計討論其可行性；最后在實驗環境中測試了本系統的存儲傳輸、壓縮和計算性能。經測試,系統初步達到了節省存儲空間、提高讀寫效率、提升計算能力的目的，為云計算技術真正應用到醫院信息化建設中提供了理論基礎。
參考文獻
[1] 樊一鳴.云計算技術與區域醫學影像系統結合的探討[J]. 中國衛生信息管理, 2011,8(1)：21-22.
[2] 高林,宋相倩,王潔萍.云計算及其關鍵技術研究[J].微型機與應用, 2011,30(10)：5-7.
[3] 趙凱.基于云存儲的醫院PACS系統存儲設計[J].信息安全與技術, 2012,3(4)：92-93.
[4] 李彭軍,陳光杰，郭文明，等.基于HDFS的區域醫學影像分布式存儲架構設計[J].南方醫科大學學報，2011,31(3):495-498.
[5] LUÍS A,SILVA B. A PACS archive architecture supported  on Cloud services[C].International Journal of Computer Assisted Radiology and Surgery,2011.