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

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

    1.1 存儲(chǔ)特點(diǎn)

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

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

    1.2 存儲(chǔ)現(xiàn)狀

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

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

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

    2.1 云存儲(chǔ)優(yōu)勢

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

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

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

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

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

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

    2.2 Hadoop簡介

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

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

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

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

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

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

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

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

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

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

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

    2.4 基于HDFS的文件處理

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

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

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

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

    3.云存儲(chǔ)測試及分析

    3.1 測試方法

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

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

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

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

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

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

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

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

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

表2 讀取時(shí)間(s)

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

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

    4.結(jié)束語

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

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/

本文標(biāo)題：基于Hadoop的云架構(gòu)區(qū)域PACS存儲(chǔ)方案設(shè)計(jì)

本文網(wǎng)址：http://www.oesoe.com/html/support/11121511595.html