《中共中央、國務(wù)院關(guān)于深化醫(yī)藥衛(wèi)生體制改革的意見》明確指出:“建立分工明確、信息互通、資源共享、協(xié)調(diào)互動的公共衛(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é)影像信息交換平臺,實現(xiàn)區(qū)域內(nèi)醫(yī)學(xué)影像數(shù)據(jù)與信息的共享。但目前離這個目標(biāo)仍然有相當(dāng)一段距離,其中遇到最大的障礙就是醫(yī)學(xué)影像文件的存儲問題。
1.區(qū)域PACS對存儲的要求
1.1 存儲特點
PACS 存儲主要是指圖像文件的存儲,其特點:① 數(shù)據(jù)量大,增長速度快,如301 醫(yī)院的放射科每天的影像壓縮后也有40多GB,1年約10TB;② 圖像文件通訊格式為DICOM、文件尺寸較大;③ 數(shù)據(jù)保存時間長,醫(yī)學(xué)影像一般要求能存儲15 年;④ 可分級存儲,近期訪問量大的數(shù)據(jù)采用在線存儲,遠(yuǎn)期訪問量小的數(shù)據(jù)采用近線或離線存儲;⑤ 可通過歸檔管理功能,實現(xiàn)容災(zāi)保護(hù)。
針對這些特點,區(qū)域PACS 設(shè)計應(yīng)該采用多數(shù)據(jù)中心的模式,以保證提供多個存儲節(jié)點的數(shù)據(jù)服務(wù)。
1.2 存儲現(xiàn)狀
目前,各醫(yī)院的PACS 一般都遵循DICOM 標(biāo)準(zhǔn),而在存儲方面則各行其便,沒有統(tǒng)一規(guī)范。當(dāng)醫(yī)院的業(yè)務(wù)發(fā)展越來越大,以及面向區(qū)域化后,這些PACS 就會面臨下面的問題:① 存儲可擴(kuò)展性差,多數(shù)醫(yī)院的PACS 存儲架構(gòu)很難長期支持,每過一定時間就要進(jìn)行擴(kuò)容操作,而且擴(kuò)容后文件查詢搜索等性能相應(yīng)降低;② 區(qū)域共享困難,各醫(yī)院的PACS 之間要建立數(shù)據(jù)共享,只能建立各自的存儲接口來實現(xiàn),這種數(shù)據(jù)傳輸方式是應(yīng)用層面的,它的改動會導(dǎo)致各PACS 相應(yīng)變動,造成升級維護(hù)困難;③ 安全性不佳,存儲數(shù)據(jù)的備份措施不足,很容易因硬盤故障等原因?qū)е掠跋駭?shù)據(jù)的大量丟失,甚至無法恢復(fù)。
PACS 提供商主要專注于應(yīng)用層面,存儲層面專業(yè)性不夠。要解決上述問題,只有建立統(tǒng)一的存儲平臺才能得以解決。從云計算發(fā)展而來的云存儲是一個很好的解決方案。
2.基于云存儲的區(qū)域PACS架構(gòu)設(shè)計
2.1 云存儲優(yōu)勢
區(qū)域PACS 平臺建設(shè)可以按混合云的方式進(jìn)行,即在區(qū)域PACS 平臺內(nèi)部,每個醫(yī)院的數(shù)據(jù)中心均作為云存儲的一個單元,它們聯(lián)合組成區(qū)域PACS 平臺的私有云存儲,主要用來存放近期數(shù)據(jù)。遠(yuǎn)期數(shù)據(jù)可存放在商業(yè)云存儲中,同時在各數(shù)據(jù)的本地做好備份。私有云存儲以高速網(wǎng)絡(luò)進(jìn)行建設(shè),如虛擬私人網(wǎng)絡(luò)(VPN)專線,以保證近期數(shù)據(jù)讀取的傳輸速度;遠(yuǎn)期數(shù)據(jù)存放在商業(yè)云存儲中,即使公有網(wǎng)絡(luò)速度較慢,數(shù)據(jù)讀取速度也能接受。采用云存儲的諸多優(yōu)勢:
(1)成本優(yōu)勢。醫(yī)院只需購買保存近期影像文件的設(shè)備,遠(yuǎn)期的歸檔數(shù)據(jù)放在商業(yè)云存儲中,不需要投入大量資金購買足夠的存儲設(shè)備、軟件建設(shè)和人力成本投入。
(2)管理優(yōu)勢。云存儲提供商負(fù)責(zé)存儲設(shè)備的運(yùn)轉(zhuǎn)、維護(hù)、升級及日常管理工作,醫(yī)院節(jié)省了相關(guān)投入。
(3)擴(kuò)展優(yōu)勢。云存儲的并行架構(gòu)原理決定了其擴(kuò)展方便性,用戶只需購買空間,不用考慮空間的擴(kuò)展與升級。
(4)訪問優(yōu)勢。對于使用云存儲的區(qū)域PACS 系統(tǒng),當(dāng)用戶在區(qū)域外登錄系統(tǒng)時,與訪問網(wǎng)站一樣方便,這個特性對于移動智能終端用戶很有用。目前很多三甲醫(yī)院在推廣使用IPAD、手機(jī)等智能終端進(jìn)行臨床診斷等醫(yī)務(wù)操作。對于采用云存儲的PACS 來說,從電腦到智能終端的移植將會變得非常容易、成本低。
(5)定制優(yōu)勢。不同醫(yī)院對于存儲的需求各有區(qū)別,在配置問題既要滿足性能與安全要求,又要節(jié)省成本。云存儲服務(wù)商會根據(jù)區(qū)域PACS的需求情況以及項目的預(yù)算,提供合適的存儲解決方案。因此云存儲產(chǎn)品不僅提供了空間本身,還根據(jù)需求給出了一個量身定制的解決方案。
2.2 Hadoop簡介
Hadoop 是由Apache 基金會開發(fā)的開源的分布式系統(tǒng)基礎(chǔ)架構(gòu),既是用戶不了解底層細(xì)節(jié)的情況,也可以開發(fā)分布式程序。Hadoop 平臺可運(yùn)行在普通的PC 機(jī)群上,極大地降低了研究開發(fā)成本。Hadoop 框架中最核心的設(shè)計是HDFS(Hadoop Distributed File System)、MapReduce 和HBase。
HDFS 是Google 的分布式文件系統(tǒng)(Google File System,GFS)的開源實現(xiàn)。其特點:容錯性高,可在低廉的硬件上進(jìn)行部署;數(shù)據(jù)傳輸速度高,對于數(shù)據(jù)集大的應(yīng)用程序特別適合;訪問可擴(kuò)展性好,只需簡單地在集群里添加節(jié)點就能實現(xiàn)客戶端同時訪問數(shù)量多的情況;操作方便,同樣有傳統(tǒng)文件操作,如文件的創(chuàng)建、刪除、重命名等;HDFS 數(shù)據(jù)塊的大小默認(rèn)為64 MB,適合處理和存儲大文件,但對小文件不適合。
HDFS 是主從結(jié)構(gòu)的體系框架,一個HDFS 集群通常由一個NameNode 節(jié)點與多個DataNode 節(jié)點組成。NameNode節(jié)點是主服務(wù)器,其功能有管理客戶端訪問、管理數(shù)據(jù)元和文件塊、管理命名空間、監(jiān)聽請求和處理請求、心跳檢測等。而各DataNode 節(jié)點則負(fù)責(zé)數(shù)據(jù)塊的讀寫,向NameNode 報告節(jié)點狀態(tài),執(zhí)行數(shù)據(jù)的流水線復(fù)制等存儲管理工作。
MapReduce 是由Map 和Reduce 函數(shù)組成的一種簡化的并行計算模型,分別進(jìn)行任務(wù)的分解和對結(jié)果的匯總。其原理是將待處理的數(shù)據(jù)集分解成多個子數(shù)據(jù)集,且每一子數(shù)據(jù)集都可并行處理。開發(fā)人員的主要工作是實現(xiàn) Map 和Reduce 函數(shù),而不必去考慮一些底層細(xì)節(jié),如容錯處理、負(fù)載平衡、網(wǎng)絡(luò)通信等,因此開發(fā)非常方便容易。
HBase 是一個開源的、基于列存儲模型的分布式數(shù)據(jù)庫,是Google 的Bigtable 分布式數(shù)據(jù)庫的開源實現(xiàn),它面向列,可伸縮性、可靠性高,性能好,其文件存儲系統(tǒng)是Hadoop HDFS,利用此技術(shù)可在普通PC 機(jī)上建立大規(guī)模結(jié)構(gòu)化存儲集群。
以這些核心支柱為基礎(chǔ)的Hadoop,能夠?qū)Υ罅繑?shù)據(jù)進(jìn)行分布式處理。其高可靠性體現(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)大多采用“在線- 近線-離線”三級存儲模式,這種模式常用直連式存儲,存儲設(shè)備直接與主機(jī)相連接,容量擴(kuò)充不方便,維護(hù)升級困難。另外,區(qū)域PACS 數(shù)據(jù)是PB 級的,要保證所有數(shù)據(jù)的存儲被高速實時訪問,目前技術(shù)下,直連式存儲顯然滿足不了這要求,即使是SAN( 存儲區(qū)域網(wǎng)絡(luò)) 和NAS( 網(wǎng)絡(luò)連接式存儲) 也難以實現(xiàn)。目前的架構(gòu)下,遠(yuǎn)期影像數(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ù)服務(wù)的中間層、調(diào)用這些服務(wù)的接口層以及具體的應(yīng)用層組成,見圖1。物理層,即存儲設(shè)備具有海量的存儲容量,存儲架構(gòu)為HDFS,通過HDFS 實現(xiàn)負(fù)載均衡、數(shù)據(jù)備份等功能,并向外提供統(tǒng)一的存儲訪問接口。中間層實現(xiàn)影像數(shù)據(jù)的存儲與讀取,該功能通過訪問物理層的HDFS 提供的接口實現(xiàn)。接口層在中間層的基礎(chǔ)上做進(jìn)一步的功能封裝,使開發(fā)編程更容易。應(yīng)用層則利用接口層提供的功能接口,編寫分布式的并行處理應(yīng)用程序。
圖1 云存儲架構(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é)點NameNode內(nèi)存,從而降低整個集群性能。另外,由于每個文件會被復(fù)制3 份,過多的小文件會使性能降低,因此需要建立一個處理小文件的抽象層,對每個病人采集到的圖像文件進(jìn)行處理。對于云存儲中小文件存儲與訪問問題,可通過自適應(yīng)文件系統(tǒng)進(jìn)行優(yōu)化。針對區(qū)域PACS 影像文件類型較為單一的特點,提出了兩個解決方案進(jìn)行研究。
第一個方案是將每幅圖像看作一幀,把一次檢查的所有圖像合并成一個序列圖像文件。在DICOM文件中,圖像數(shù)據(jù)保存在Pixel Data 數(shù)據(jù)元素中,它的值域中保存的像素數(shù)據(jù)可以是原始數(shù)據(jù),也可以是經(jīng)過封裝的。封裝的像素數(shù)據(jù)的值是由分割開的多個像素數(shù)據(jù)流組成,以此來表示多幀的圖像。此方案要等文件下載完后才能顯示,而不是醫(yī)生所習(xí)慣的邊下載邊顯示,當(dāng)病人一次檢查的圖像很多時( 如CT 圖像,可達(dá)上千張),圖像文件總大小達(dá)幾百M甚至G數(shù)量級,下載時間稍長會讓醫(yī)生覺得難以忍受。
第二個方案是分組壓縮。將病人的圖像文件按其序列(Series_no)號及編號(Instance_no)的順序進(jìn)行分組,每一組的文件總大小為64M左右,然后分別將每一組文件壓縮成一個壓縮文件進(jìn)行存儲,這樣在下載的時候,下載一組就解壓并顯示,以實現(xiàn)邊下載邊顯示圖像的功能。此方案的優(yōu)點還在于它對圖像的壓縮式無損,壓縮后文件通常不到原來文件總大小的1/2,明顯地減少了網(wǎng)絡(luò)傳輸時間。
為實現(xiàn)并測試這兩個方案的功能,設(shè)計了一套DICOM文件讀寫中間件,封裝了底層操作細(xì)節(jié),實現(xiàn)DICOM文件的查詢、讀取和寫入等功能,并為應(yīng)用層提供統(tǒng)一的接口,可根據(jù)配置選擇方案1或方案2。
3.云存儲測試及分析
3.1 測試方法
測試云架構(gòu)下的文件寫入與讀取速度,以及它們與DataNode 節(jié)點數(shù)的關(guān)系;同時測試方案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è)定),利用前述的中間件處理當(dāng)天接收的DICOM 文件,并發(fā)送到云存儲;接收醫(yī)生工作站下載DICOM 文件請求,如果本地有該文件,則從本地發(fā)送到醫(yī)生工作站,如果本地沒有,則從云存儲查詢并下載文件,發(fā)送到醫(yī)生工作站。
系統(tǒng)軟件環(huán)境:服務(wù)器操作系統(tǒng)Windows2008,數(shù)據(jù)庫用Oracle10g,云存儲文件系統(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é)點數(shù)增加,讀取速度相應(yīng)增加,基本是與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ù)量的增加,寫入速率也相應(yīng)增大,基本上與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.3s才能看到圖像,而方案2中,最多需2.3s就能看到圖像,最少僅0.3s就能看到。
另外,在方案2中,壓縮文件平均大小為21.7MB,離HDFS 默認(rèn)的64MB數(shù)據(jù)塊大小有不小差距,這仍會在一定程度上增加NameNode服務(wù)器內(nèi)存消耗,因此壓縮處理算法需要改進(jìn),將判斷壓縮前的文件總大小不超過64MB,改為判斷壓縮處理后的文件大小不超過64 MB,這需要在后續(xù)研究中改進(jìn)。
4.結(jié)束語
云存儲是目前的一個應(yīng)用研究熱點。云存儲服務(wù)為區(qū)域PACS 影像文件的存儲問題提供了有效的解決方案,有效解決了構(gòu)建區(qū)域醫(yī)學(xué)影像數(shù)據(jù)中心的成本高、可擴(kuò)展性差、傳輸帶寬不足、離線數(shù)據(jù)可用性差等問題,同時減低了投入,節(jié)約成本。本文構(gòu)建了一個以Hadoop 架構(gòu)為基礎(chǔ)的云存儲服務(wù)系統(tǒng),針對HDFS不適合CT、MRI 等小文件的存儲的問題,開發(fā)了一套中間件,用于將小文件合并為大文件,使其適應(yīng)HDFS的存儲特點。測試結(jié)果表明,以Hadoop 為基礎(chǔ)架構(gòu)的云存儲平臺隨著DataNode 節(jié)點增多,性能近似線性增加。同時還研究了文件大小對于客戶端讀取并顯示圖像效果的影響,結(jié)果表明單純地將病人一次檢查圖像合并為一個大文件是不可取的,應(yīng)當(dāng)考慮到網(wǎng)絡(luò)下載速度以及診斷醫(yī)生觀感,每個文件以不超過64MB為宜。下一步的研究工作是對中間件功能進(jìn)一步完善,并研究區(qū)域PACS云存儲系統(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.ezxoed.cn/
本文標(biāo)題:基于Hadoop的云架構(gòu)區(qū)域PACS存儲方案設(shè)計
本文網(wǎng)址:http://www.ezxoed.cn/html/support/11121511595.html