摘要：構(gòu)建區(qū)域醫(yī)學(xué)影像協(xié)作平臺是均衡醫(yī)療資源、提高基層醫(yī)院診療水平、降低醫(yī)療費用的有效途徑，但是構(gòu)建區(qū)域化影像平臺在技術(shù)和成本上還存在巨大的挑戰(zhàn)。本文詳細分析了傳統(tǒng)集中式存儲和HDFS（Hadoop Distributed File System）分布式存儲系統(tǒng)的優(yōu)缺點，設(shè)計了一種適合HDFS特點的S-DICOM文件格式，以及集中式存儲（FC SAN）和分布式存儲（HDFS集群）結(jié)合的統(tǒng)一存儲架構(gòu)，開發(fā)了一套SDFO（S-DICOM File Operator）中間件，為上層的PACS應(yīng)用組件提供透明的存儲訪問接口。測試結(jié)果表明此架構(gòu)可以滿足海量醫(yī)學(xué)影像資料的快速存取和處理需求。

　　隨著X線機、CT、磁共振等大型影像設(shè)備在臨床上的廣泛應(yīng)用，影像檢查已成為臨床診斷最重要的依據(jù)之一。但是昂貴的影像設(shè)備和重復(fù)的影像檢查也成為醫(yī)院和病人醫(yī)療支出的重要部分。同時，影像診斷難度大、操作復(fù)雜度高、專業(yè)性強，基層醫(yī)院極其缺乏優(yōu)秀的影像診斷人才。醫(yī)療設(shè)備和人才的不均衡，也是造成目前“看病難、看病貴”的重要原因。構(gòu)建區(qū)域一體化的醫(yī)療協(xié)作平臺，是均衡醫(yī)療資源、提高基層醫(yī)院診療水平、實現(xiàn)“有序醫(yī)療”的重要途徑。其中區(qū)域醫(yī)學(xué)影像協(xié)作平臺的構(gòu)建，是區(qū)域醫(yī)療協(xié)作的重要組成部分，但是構(gòu)建區(qū)域化的醫(yī)學(xué)影像協(xié)作平臺在技術(shù)和成本上還存在著巨大的挑戰(zhàn)。

　　1 構(gòu)建區(qū)域醫(yī)學(xué)影像協(xié)作平臺面臨的挑戰(zhàn)

　　數(shù)字醫(yī)學(xué)影像技術(shù)目前已有成熟的國際標準，即DICOM 3.0，遵照其標準建設(shè)的 PACS 系統(tǒng)也已從單機、科室逐步發(fā)展到全院、區(qū)域。目前國內(nèi)許多大型三甲醫(yī)院已開展全院PACS應(yīng)用，實現(xiàn)了醫(yī)院無膠片化。PACS系統(tǒng)區(qū)域化將是下一階段政府衛(wèi)生部門和醫(yī)療機構(gòu)的主要研究目標，但是構(gòu)建大型區(qū)域醫(yī)學(xué)影像中心和協(xié)作平臺目前還面臨巨大的挑戰(zhàn)。

　　1.1 建設(shè)費用高

　　PACS 的數(shù)據(jù)量遠遠大于 HIS、LIS 等其它醫(yī)療系統(tǒng)，區(qū)域醫(yī)學(xué)影像數(shù)據(jù)達到數(shù)百TB甚至PB級，采用傳統(tǒng)存儲架構(gòu)（如FC SAN/iSCSI等）費用極高。

　　1.2 傳輸帶寬存在瓶頸

　　即使是高性能的FC SAN，其網(wǎng)絡(luò)帶寬和處理能力也難以達到PB級數(shù)據(jù)的快速處理和傳輸要求。

　　1.3 可用性受限

　　大型醫(yī)院PACS系統(tǒng)常用“在線-近線-離線”的存儲模式，離線數(shù)據(jù)大多存儲在磁帶庫中，其可用性較差，數(shù)據(jù)不能實時獲取。

　　1.4 缺乏一體化的應(yīng)用平臺

　　目前的醫(yī)學(xué)影像協(xié)作，如遠程影像會診基本采用“點對點”的模式，缺乏一體化、跨平臺、高可用的區(qū)域醫(yī)學(xué)影像協(xié)同應(yīng)用軟件。隨著云計算技術(shù)的飛速發(fā)展，為構(gòu)建低成本、高可用、高性能的區(qū)域醫(yī)學(xué)影像協(xié)作平臺提供了一條有效的途徑。云計算是Google率先提出來的一種新的技術(shù)和運營模式，從應(yīng)用范圍來看，云計算可分為公有云、私有云和混合云。從服務(wù)模式來看，云計算可分為 IaaS、SaaS和PaaS。區(qū)域醫(yī)學(xué)影像云計算平臺屬于混合云的范疇，我們承擔(dān)的課題就是研究通過醫(yī)療集團內(nèi)部醫(yī)院之間的高速城域網(wǎng)、醫(yī)保網(wǎng)、電子政務(wù)外網(wǎng)、互聯(lián)網(wǎng)等傳輸介質(zhì)，為各類醫(yī)療機構(gòu)提供SaaS模式的醫(yī)學(xué)影像協(xié)作應(yīng)用系統(tǒng)，包括Web DICOM終端、影像會診、影像轉(zhuǎn)診、遠程教育、數(shù)字膠片代存等服務(wù)。而高性能、高可靠的海量圖像存儲系統(tǒng)將是醫(yī)學(xué)影像云計算平臺的基礎(chǔ)和關(guān)鍵，本文主要介紹一種基于Hadoop 平臺的分布式存儲和傳統(tǒng)集中式存儲（FCSAN）相結(jié)合的存儲架構(gòu)的設(shè)計和實現(xiàn)。

　　2 Hadoop 平臺簡介

　　Hadoop是目前應(yīng)用最廣泛的開源分布式存儲和計算平臺之一。它是根據(jù)Google的GFS分布式文件系統(tǒng)和Map/Reduce分布式計算技術(shù)而開發(fā)的開源平臺，其設(shè)計目標是在普通的硬件平臺上構(gòu)建大容量、高性能、高可靠的分布式存儲和分布式計算架構(gòu)。Hadoop目前已在Yahoo、Facebook、亞馬遜、百度、中移動等公司取得了廣泛應(yīng)用。其中Yahoo、FaceBook等公司已構(gòu)建了數(shù)千至數(shù)萬臺普通服務(wù)器組成的大型Hadoop應(yīng)用集群，F(xiàn)aceBook上存儲的圖像數(shù)據(jù)量目前已超過1 PB即1024 TB）。

　　2.1 Hadoop集群的特點和適用性

　　Hadoop HDFS分布式文件系統(tǒng)具有如下特點：（1）非常適合海量數(shù)據(jù)的存儲和處理；（2）可擴展性高，只需簡單添加服務(wù)器數(shù)量，即可實現(xiàn)存儲容量和計算能力的線性增長；（3）數(shù)據(jù)冗余度高，缺省每份數(shù)據(jù)在3臺服務(wù)器上保留備份；（4）適合“流式”訪問，即一次寫入，多次讀取，數(shù)據(jù)寫入后極少修改，這非常適合醫(yī)學(xué)影像文件的特點；（5）除了數(shù)據(jù)存儲能力外，Hadoop MapReduce分布式計算框架還可充分利用各服務(wù)器CPU的計算資源，便于后期開展基于海量醫(yī)學(xué)影像數(shù)據(jù)的圖像融合、圖像內(nèi)容檢索、三維重建等數(shù)據(jù)密集型計算。

　　2.2 存在的問題

　　Hadoop在構(gòu)建醫(yī)學(xué)影像存儲系統(tǒng)時還存在以下問題：1）Hadoop的設(shè)計理念是針對大文件進行優(yōu)化的，其默認的數(shù)據(jù)塊大小為64 MB，而醫(yī)學(xué)影像資料中常見的CT、MRI 的圖像大小大多為 512 KB 左右，一次拍攝產(chǎn)生的圖像數(shù)量大約為100 ~200幅，如果直接將這些大量的小文件存儲在HDFS文件系統(tǒng)中，過多的小文件將導(dǎo)致HDFS的主節(jié)點NameNode內(nèi)存消耗過大，降低整個集群的性能。2）HDFS的設(shè)計理念不適合實時應(yīng)用，在數(shù)據(jù)寫入的過程中，每個數(shù)據(jù)塊需復(fù)制3份，其寫入性能大大低于讀取性能，因此不太適合需要快速獲取圖像資料并撰寫診斷報告的PACS實時應(yīng)用。

　　3 系統(tǒng)設(shè)計

　　針對上述問題，我們設(shè)計了一種適合Hadoop平臺的序列DICOM文件格式（S-DICOM），以及一套傳統(tǒng)的集中存儲和HDFS分布式文件系統(tǒng)相結(jié)合的S-DICOM文件存儲架構(gòu)。

　　3.1 S-DICOM文件格式

　　CT、MRI等DICOM文件大小雖然只有512 KB左右，但是病人的每個部位的檢查通常都有100~200張圖片，這樣每個病人每次檢查的數(shù)據(jù)量也將達到50~100MB。而另一種常見的醫(yī)學(xué)影像設(shè)備X線機（CR、DR），其單幅圖像的數(shù)據(jù)量約為8~20 MB，每次檢查拍攝的圖片一般為2~4幅，其總數(shù)據(jù)量也滿足HDFS文件系統(tǒng)的要求。因此，將一個病人一次檢查的所有圖像合并成一個文件，再存儲到HDFS中是比較合理的。我們采用了Hadoop的SequenceFile文件格式，將每個DICOM文件轉(zhuǎn)化成健值對（key/value）的形式，然后合并成一個單獨的S-DICOM文件，其中key為原DICOM文件名，value為DICOM文件內(nèi)容，文件格式（圖1）。

　　3.2 混合式存儲架構(gòu)

　　單純的HDFS分布式文件系統(tǒng)不適合實時應(yīng)用，但是具備低成本、高可擴展、高性能、高可靠的特點，傳統(tǒng)的集中存儲（FC SAN）則非常適合小文件的快速寫。因此，結(jié)合兩者的優(yōu)點我們設(shè)計了一套混合式存儲模式，其核心是SDFO（S-DICOM File Operator）中間件，主要用于屏蔽底層操作細節(jié)，為上層的SaaS模式醫(yī)學(xué)影像應(yīng)用系統(tǒng)和DICOM應(yīng)用組件提供統(tǒng)一的圖像查詢、讀取和寫入接口。SDFO的核心主要由SDFO Lo-cator、SDFO Reader、SDFO Writer、SDFO Converter、SDFO Client 五個部分組成。SDFO Locator 用于檢索DICOM 文件的存儲位置，SDFO Reader 用于讀取 DI-COM 文件，SDFO Writer 負責(zé)將從影像設(shè)備獲取的圖像寫入集中存儲（FC SAN），SDFO Converter負責(zé)定時將FC SAN中的DICOM圖像轉(zhuǎn)換為S-DICOM格式，合并后存儲到HDFS中。其系統(tǒng)框架（圖2）。

　　醫(yī)院PACS系統(tǒng)中存儲的圖像，超過3個月后，其訪問量將大大下降，因此我們將3個月內(nèi)的DICOM文件以其原始文件格式存儲在FC SAN中，超過3個月的圖像則定時轉(zhuǎn)換成S-DICOM格式，存儲到HDFS中（也可根據(jù)需要設(shè)置存儲超期時間）。利用Hadoop HDFS的線性擴展能力，我們可以將傳統(tǒng)PACS的“在線-近線-離線”模式簡化為“在線-近線”模式，解決離線數(shù)據(jù)可用性差的問題。

　　3.2.1 圖像讀取流程

　　 SDFO 從 Hadoop HDFS 集群和FC SAN中檢索和讀取圖像的流程（圖3）。

　　（1）從DICOM Locator獲取圖像存放的路徑，如果圖像存放在FC SAN中，則跳至第6步；

　　（2）從HDFS的NameNode獲取文件數(shù)據(jù)塊所在的DataNodes位置；

　　（3）調(diào)用SDFO的read方法，開始獲取圖像；

　　（4）從HDFS的DataNode 1獲取第一個數(shù)據(jù)塊，以此類推至其它的數(shù)據(jù)塊，此步驟可以并行操作；

　　（5）從HDFS的DataNode n中獲取最后一個數(shù)據(jù)塊，將所有的數(shù)據(jù)塊合并成完整的文件，關(guān)閉HDFS數(shù)據(jù)流，并將其轉(zhuǎn)換成標準的DICOM圖像；

　　（6）存放在FC SAN中的DICOM文件直接通過JAVA的本地文件系統(tǒng)接口讀取。

　　3.2.2 圖像寫入流程 　　

　　SDFO 中間件中DICOM 文件的寫入方式與傳統(tǒng)的文件寫入方式相同，直接通過JAVA本地文件系統(tǒng)接口寫入FC SAN。

　　3.2.3 圖像轉(zhuǎn)換流程

　　圖像轉(zhuǎn)換流程定時將FC SAN中的 DICOM 文件合并成 S-DICOM 文件，存入 HDFS中。其轉(zhuǎn)換流程（圖4）。

　　（1）調(diào)用JAVA的本地文件系統(tǒng)接口，循環(huán)獲取FCSAN 中某個文件夾下的文件列表（每個病人每次檢查的所有圖像存放在一個單獨的文件夾中），將每個DI-COM文件轉(zhuǎn)化成一個健值對（key/value），將key/vlaue健值對順序?qū)懭胍粋€單獨的S-DICOM文件數(shù)據(jù)流；

　　（2）調(diào)用DistributeFileSystem的create方法，通過NameNode的RPC接口創(chuàng)建文件，并獲取用于存放數(shù)據(jù)塊的DataNodes列表；

　　（3）調(diào)用FSDataOutputStream，將S-DICOM文件轉(zhuǎn)換成內(nèi)部的數(shù)據(jù)隊列，將數(shù)據(jù)寫入第一個DataNode；

　　（4）數(shù)據(jù)塊寫入成功后，第一個DataNode將寫入的數(shù)據(jù)塊復(fù)制到第二個DataNode，依次類推至第三個DataNode。

　　（5）按相反的順序，第三個DataNode寫入成功后，依次向第二個和第一個DataNode返回ack packet，確認數(shù)據(jù)寫入成功；

　　（6）循環(huán)寫入所有的數(shù)據(jù)塊后，調(diào)用close方法關(guān)閉FSDataOutputStream；

　　（7）向NameNode發(fā)送complete指令，確認文件寫入完成，更新NameNode的元數(shù)據(jù)；

　　（8）向DICOM Locator寫入DICOM文件的存儲路徑。

　　4 應(yīng)用測試效果

　　4.1 軟硬件配置

　　我們目前已搭建了20臺服務(wù)器組成的Hadoop集群。CPU：Intel Xeon E5504；內(nèi)存：8 GB DDR3；網(wǎng)卡：兩塊1000 Mbps以太網(wǎng)卡；硬盤：4塊1 TB SATA。存儲空間共計80 TB，按照Hadoop缺省配置，每個數(shù)據(jù)塊在3臺不同的服務(wù)器上保存副本，因此實際存儲容量約為27 TB。每臺服務(wù)器均接入千兆匯聚層交換機，匯聚層交換機萬兆上聯(lián)。操作系統(tǒng)：64位CentOS 5.4；Java環(huán)境：JDK 1.6.0-b09；Hadoop平臺：Hadoop 0.20.2。

　　4.2 測試結(jié)果

　　DICOM圖像的寫入以及3個月內(nèi)圖像的讀取均是直接通過FC SAN完成的，其性能與普通的PACS環(huán)境區(qū)別不大，因此我們主要測試讀取3個月以前的S-DI-COM 圖像以及將 DICOM 圖像合并轉(zhuǎn)換成 S-DICOM圖像的性能。Hadoop支持分布式讀寫，我們分別測試了1~5個SDFO Client的情況下，S-DICOM讀取和轉(zhuǎn)換的性能如下表所示（單位：MB/s）：

　　從測試結(jié)果可以看出SDFO的讀性能基本是與Client 數(shù)量線性相關(guān)的，這是由于 Hadoop 中的數(shù)據(jù)塊是均勻分布在各DataNode中的，讀取文件時可以聚合各DataNode的網(wǎng)絡(luò)帶寬，隨著DataNode數(shù)量的增大，其聚合的總帶寬將遠遠超過傳統(tǒng)的FC SAN傳輸速率。根據(jù)測試情況來看，客戶端同時讀取和轉(zhuǎn)換一個病人一次檢查的S-DICOM文件時間約為1~2 s左右，這樣的延時對PACS系統(tǒng)的操作是可以忽略的。

　　從測試結(jié)果也可看出Hadoop的寫入性能不佳，單個Client寫入HDFS的速率只能達到10 MB/s左右，這是由于HDFS寫入文件時需要同時寫入3個副本相關(guān)。

　　但隨著SDFO Client數(shù)量的增加，寫入速率也相應(yīng)增大，當SDFO Client數(shù)量為5時，總寫入速率約為33MB/s。一個大型三甲醫(yī)院PACS系統(tǒng)每天產(chǎn)生的圖像數(shù)據(jù)量約為20 GB左右，全部轉(zhuǎn)換成S-DICOM文件耗時約10 min，對于擁有較多醫(yī)院的區(qū)域，可以通過增加SDFO客戶端數(shù)量的方式，近似線性地提高轉(zhuǎn)換和存儲性能，在每天的夜間空閑時段進行數(shù)據(jù)轉(zhuǎn)換任務(wù)也是可以接受的。

　　5 總結(jié)與展望

　　Hadoop平臺是構(gòu)建超大規(guī)模數(shù)據(jù)集群，實現(xiàn)存儲聚合和數(shù)據(jù)密集型分布式計算的優(yōu)秀平臺，它可以有效解決構(gòu)建區(qū)域醫(yī)學(xué)影像數(shù)據(jù)中心的成本高、可擴展性差、傳輸帶寬不足、離線數(shù)據(jù)可用性差的問題。但是Hadoop HDFS也存在不適合CT、MRI等小文件的存儲及實時應(yīng)用的問題。為此我們設(shè)計了一種S-DICOM文件格式，使其適應(yīng)HDFS的特點，同時通過傳統(tǒng)的集中式存儲（FC SAN）和分布式存儲（HDFS集群）組合的存儲架構(gòu)，開發(fā)了一套SDFO中間件，為上層的PACS應(yīng)用組件提供透明的DICOM文件訪問接口。該系統(tǒng)在測試平臺上取得了比較滿意的效果，能滿足大型區(qū)域醫(yī)學(xué)影像中心的功能和性能要求。今后我們將在此基礎(chǔ)上開展進一步的研究工作：1）進一步提高系統(tǒng)的安全性，完善應(yīng)用系統(tǒng)、存儲架構(gòu)和網(wǎng)絡(luò)拓撲等方面的加密和授權(quán)機制，確保病人的隱私和數(shù)據(jù)安全；2）充分利用Hadoop集群的分布式計算能力，開發(fā)基于MapReduce算法的圖像融合、圖像內(nèi)容檢索、三維重建等應(yīng)用。

　　作者：李彭軍，陳光杰，郭文明