《中共中央、國務院關于深化醫(yī)藥衛(wèi)生體制改革的意見》明確指出：“建立分工明確、信息互通、資源共享、協(xié)調互動的公共衛(wèi)生服務體系。”在全國區(qū)域化醫(yī)療衛(wèi)生改革進程中，區(qū)域圖片存檔及通訊系統(tǒng)（PACS）是比較重要的一環(huán)。區(qū)域PACS 指以區(qū)域網(wǎng)絡平臺為基礎，以區(qū)域內中心醫(yī)院或大醫(yī)院為核心，建立跨醫(yī)院和醫(yī)療機構的醫(yī)學影像信息交換平臺，實現(xiàn)區(qū)域內醫(yī)學影像數(shù)據(jù)與信息的共享。但目前離這個目標仍然有相當一段距離，其中遇到最大的障礙就是醫(yī)學影像文件的存儲問題。
1.區(qū)域PACS對存儲的要求
1.1 存儲特點
PACS 存儲主要是指圖像文件的存儲，其特點：① 數(shù)據(jù)量大，增長速度快，如301 醫(yī)院的放射科每天的影像壓縮后也有40多GB，1年約10TB；② 圖像文件通訊格式為DICOM、文件尺寸較大；③ 數(shù)據(jù)保存時間長，醫(yī)學影像一般要求能存儲15 年；④ 可分級存儲，近期訪問量大的數(shù)據(jù)采用在線存儲，遠期訪問量小的數(shù)據(jù)采用近線或離線存儲；⑤ 可通過歸檔管理功能，實現(xiàn)容災保護。
針對這些特點，區(qū)域PACS 設計應該采用多數(shù)據(jù)中心的模式，以保證提供多個存儲節(jié)點的數(shù)據(jù)服務。
1.2 存儲現(xiàn)狀
目前，各醫(yī)院的PACS 一般都遵循DICOM 標準，而在存儲方面則各行其便，沒有統(tǒng)一規(guī)范。當醫(yī)院的業(yè)務發(fā)展越來越大，以及面向區(qū)域化后，這些PACS 就會面臨下面的問題：① 存儲可擴展性差，多數(shù)醫(yī)院的PACS 存儲架構很難長期支持，每過一定時間就要進行擴容操作，而且擴容后文件查詢搜索等性能相應降低；② 區(qū)域共享困難，各醫(yī)院的PACS 之間要建立數(shù)據(jù)共享，只能建立各自的存儲接口來實現(xiàn)，這種數(shù)據(jù)傳輸方式是應用層面的，它的改動會導致各PACS 相應變動，造成升級維護困難；③ 安全性不佳，存儲數(shù)據(jù)的備份措施不足，很容易因硬盤故障等原因導致影像數(shù)據(jù)的大量丟失，甚至無法恢復。
PACS 提供商主要專注于應用層面，存儲層面專業(yè)性不夠。要解決上述問題，只有建立統(tǒng)一的存儲平臺才能得以解決。從云計算發(fā)展而來的云存儲是一個很好的解決方案。
2.基于云存儲的區(qū)域PACS架構設計
2.1 云存儲優(yōu)勢
區(qū)域PACS 平臺建設可以按混合云的方式進行，即在區(qū)域PACS 平臺內部，每個醫(yī)院的數(shù)據(jù)中心均作為云存儲的一個單元，它們聯(lián)合組成區(qū)域PACS 平臺的私有云存儲，主要用來存放近期數(shù)據(jù)。遠期數(shù)據(jù)可存放在商業(yè)云存儲中，同時在各數(shù)據(jù)的本地做好備份。私有云存儲以高速網(wǎng)絡進行建設，如虛擬私人網(wǎng)絡（VPN）專線，以保證近期數(shù)據(jù)讀取的傳輸速度；遠期數(shù)據(jù)存放在商業(yè)云存儲中，即使公有網(wǎng)絡速度較慢，數(shù)據(jù)讀取速度也能接受。采用云存儲的諸多優(yōu)勢：
（1）成本優(yōu)勢。醫(yī)院只需購買保存近期影像文件的設備，遠期的歸檔數(shù)據(jù)放在商業(yè)云存儲中，不需要投入大量資金購買足夠的存儲設備、軟件建設和人力成本投入。
（2）管理優(yōu)勢。云存儲提供商負責存儲設備的運轉、維護、升級及日常管理工作，醫(yī)院節(jié)省了相關投入。
（3）擴展優(yō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的需求情況以及項目的預算，提供合適的存儲解決方案。因此云存儲產品不僅提供了空間本身，還根據(jù)需求給出了一個量身定制的解決方案。
2.2 Hadoop簡介
Hadoop 是由Apache 基金會開發(fā)的開源的分布式系統(tǒng)基礎架構，既是用戶不了解底層細節(jié)的情況，也可以開發(fā)分布式程序。Hadoop 平臺可運行在普通的PC 機群上，極大地降低了研究開發(fā)成本。Hadoop 框架中最核心的設計是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 是主從結構的體系框架，一個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ù)組成的一種簡化的并行計算模型，分別進行任務的分解和對結果的匯總。其原理是將待處理的數(shù)據(jù)集分解成多個子數(shù)據(jù)集，且每一子數(shù)據(jù)集都可并行處理。開發(fā)人員的主要工作是實現(xiàn) Map 和Reduce 函數(shù)，而不必去考慮一些底層細節(jié)，如容錯處理、負載平衡、網(wǎng)絡通信等，因此開發(fā)非常方便容易。
HBase 是一個開源的、基于列存儲模型的分布式數(shù)據(jù)庫，是Google 的Bigtable 分布式數(shù)據(jù)庫的開源實現(xiàn)，它面向列，可伸縮性、可靠性高，性能好，其文件存儲系統(tǒng)是Hadoop HDFS，利用此技術可在普通PC 機上建立大規(guī)模結構化存儲集群。
以這些核心支柱為基礎的Hadoop，能夠對大量數(shù)據(jù)進行分布式處理。其高可靠性體現(xiàn)在它保存的數(shù)據(jù)有多個副本，確保能夠針對失敗的節(jié)點重新分布處理，這也使其具有高容錯性。由于以并行的方式工作，處理速度大大加快，因此具有高效性。其可伸縮性則是由于它可方便增加節(jié)點，能夠處理 PB 級數(shù)據(jù)。此外，Hadoop 的建設成本低，以Hadoop 建立區(qū)域PACS 的云存儲是非常適合的。
2.3 系統(tǒng)架構設計
目前區(qū)域PACS 和大型醫(yī)院全院PACS 通常采用集中式存儲，存儲架構大多采用“在線- 近線-離線”三級存儲模式，這種模式常用直連式存儲，存儲設備直接與主機相連接，容量擴充不方便，維護升級困難。另外，區(qū)域PACS 數(shù)據(jù)是PB 級的，要保證所有數(shù)據(jù)的存儲被高速實時訪問，目前技術下，直連式存儲顯然滿足不了這要求，即使是SAN( 存儲區(qū)域網(wǎng)絡) 和NAS( 網(wǎng)絡連接式存儲) 也難以實現(xiàn)。目前的架構下，遠期影像數(shù)據(jù)一般是以離線方式，通過光盤庫或磁帶庫的方式保存，實時訪問困難，系統(tǒng)可用性差。
產生這些問題的根源主要是采用了集中式存儲架構。針對上述問題，采用私有云存儲與商業(yè)云存儲相結合的方式，更改區(qū)域PACS 架構，將集中式存儲改為分布式存儲，去除“離線”部分，將“在線- 近線- 離線”三級存儲架構更改為“在線- 歸檔”二級存儲架構。“離線”存儲，可以有效提高系統(tǒng)的可用性。這樣既可滿足PB 級存儲容量的需求，也可實現(xiàn)原來“離線”數(shù)據(jù)的實時訪問，提升系統(tǒng)可用性。
區(qū)域PACS的云存儲系統(tǒng)以Hadoop 為基礎架構，整個框架由基于HDFS 的物理層、用于處理和存儲影像數(shù)據(jù)服務的中間層、調用這些服務的接口層以及具體的應用層組成，見圖1。物理層，即存儲設備具有海量的存儲容量，存儲架構為HDFS，通過HDFS 實現(xiàn)負載均衡、數(shù)據(jù)備份等功能，并向外提供統(tǒng)一的存儲訪問接口。中間層實現(xiàn)影像數(shù)據(jù)的存儲與讀取，該功能通過訪問物理層的HDFS 提供的接口實現(xiàn)。接口層在中間層的基礎上做進一步的功能封裝，使開發(fā)編程更容易。應用層則利用接口層提供的功能接口，編寫分布式的并行處理應用程序。
圖1 云存儲架構示意圖
2.4 基于HDFS的文件處理
DICOM 圖像通常都是小文件，較大的文件如DR、CR一般是在10M 字節(jié)左右，而CT、MR 文件則只有幾百K 字節(jié)大小。由于HDFS文件系統(tǒng)里默認的數(shù)據(jù)塊大小是64M 字節(jié)，存放的小文件太多，將消耗大量HDFS 主節(jié)點NameNode內存，從而降低整個集群性能。另外，由于每個文件會被復制3 份，過多的小文件會使性能降低，因此需要建立一個處理小文件的抽象層，對每個病人采集到的圖像文件進行處理。對于云存儲中小文件存儲與訪問問題，可通過自適應文件系統(tǒng)進行優(yōu)化。針對區(qū)域PACS 影像文件類型較為單一的特點，提出了兩個解決方案進行研究。
第一個方案是將每幅圖像看作一幀，把一次檢查的所有圖像合并成一個序列圖像文件。在DICOM文件中，圖像數(shù)據(jù)保存在Pixel Data 數(shù)據(jù)元素中，它的值域中保存的像素數(shù)據(jù)可以是原始數(shù)據(jù)，也可以是經(jīng)過封裝的。封裝的像素數(shù)據(jù)的值是由分割開的多個像素數(shù)據(jù)流組成，以此來表示多幀的圖像。此方案要等文件下載完后才能顯示，而不是醫(yī)生所習慣的邊下載邊顯示，當病人一次檢查的圖像很多時( 如CT 圖像，可達上千張)，圖像文件總大小達幾百M甚至G數(shù)量級，下載時間稍長會讓醫(yī)生覺得難以忍受。
第二個方案是分組壓縮。將病人的圖像文件按其序列（Series_no）號及編號（Instance_no）的順序進行分組，每一組的文件總大小為64M左右，然后分別將每一組文件壓縮成一個壓縮文件進行存儲，這樣在下載的時候，下載一組就解壓并顯示，以實現(xiàn)邊下載邊顯示圖像的功能。此方案的優(yōu)點還在于它對圖像的壓縮式無損，壓縮后文件通常不到原來文件總大小的1/2，明顯地減少了網(wǎng)絡傳輸時間。
為實現(xiàn)并測試這兩個方案的功能，設計了一套DICOM文件讀寫中間件，封裝了底層操作細節(jié)，實現(xiàn)DICOM文件的查詢、讀取和寫入等功能，并為應用層提供統(tǒng)一的接口，可根據(jù)配置選擇方案1或方案2。
3.云存儲測試及分析
3.1 測試方法
測試云架構下的文件寫入與讀取速度，以及它們與DataNode 節(jié)點數(shù)的關系；同時測試方案1與方案2環(huán)境下，不同大小影像文件的下載并顯示效果。
硬件環(huán)境：采用1 臺服務器( 華碩 Z8NAD6，CPU ：Intel Xeon E5504 ；內存：8GB DDR3）與普通PC 機5 臺( 聯(lián)想啟天M488E，CPU ：E2180 2.0GHz，內存1GB) 進行模擬研究。普通PC 機運行DataNode，網(wǎng)絡是內部局域網(wǎng)、100M 網(wǎng)口。其中，服務器的功能是：接收從設備或醫(yī)生工作站傳來的DICOM 文件；在病人少的閑時階段（晚上時間，可以自行設定），利用前述的中間件處理當天接收的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 測試結果及分析
測試不同DataNode 的讀寫速度、測試結果，見表1。
表1 文件讀寫速度(MB/s)
從測試結果可以看出，隨著DataNode 節(jié)點數(shù)增加，讀取速度相應增加，基本是與Client 數(shù)量線性相關的。這是由于Hadoop 中的數(shù)據(jù)塊是盡可能均勻分布在各DataNode
節(jié)點中的，讀取文件時可以聚合各DataNode 節(jié)點的網(wǎng)絡帶寬，隨著DataNode 數(shù)量的增大，其總帶寬也大大增加。
從測試結果也可看出，Hadoop 的寫入速度明顯差于讀取速度，這與HDFS 的工作原理有關，因為寫入一個文件要同時做3 個備份。但隨著DataNode 節(jié)點數(shù)量的增加，寫入速率也相應增大，基本上與DataNode 節(jié)點成線性關系。
以某病人的CT 檢查為例，共有2185 幅圖像，文件總大小為1.15 G。在方案1中，生成了一個1.16 G 大小的DICOM 序列圖像文件；在方案2 中，生成了53 個壓縮文件，每個文件大小在17－25 MB，平均21.7 MB。測試過程中記錄所有壓縮文件的寫入/ 讀取總時間，再分別求平均值。測試結果見表2（方案2 的數(shù)據(jù)中，斜杠“/”前面是所有
壓縮文件的總讀取時間，后面是每個壓縮文件的平均讀取時間)。
表2 讀取時間(s)
從表2可看出，隨著DataNode 節(jié)點數(shù)增加，處理時間大大縮短，這與前面結果一致。方案2 的總處理時間均比方案1長，這是因為方案1只需1次網(wǎng)絡連接請求，而方案2 則需53次。但在方案1中，醫(yī)生至少需要17.3s才能看到圖像，而方案2中，最多需2.3s就能看到圖像，最少僅0.3s就能看到。
另外，在方案2中，壓縮文件平均大小為21.7MB，離HDFS 默認的64MB數(shù)據(jù)塊大小有不小差距，這仍會在一定程度上增加NameNode服務器內存消耗，因此壓縮處理算法需要改進，將判斷壓縮前的文件總大小不超過64MB，改為判斷壓縮處理后的文件大小不超過64 MB，這需要在后續(xù)研究中改進。
4.結束語
云存儲是目前的一個應用研究熱點。云存儲服務為區(qū)域PACS 影像文件的存儲問題提供了有效的解決方案，有效解決了構建區(qū)域醫(yī)學影像數(shù)據(jù)中心的成本高、可擴展性差、傳輸帶寬不足、離線數(shù)據(jù)可用性差等問題，同時減低了投入，節(jié)約成本。本文構建了一個以Hadoop 架構為基礎的云存儲服務系統(tǒng)，針對HDFS不適合CT、MRI 等小文件的存儲的問題，開發(fā)了一套中間件，用于將小文件合并為大文件，使其適應HDFS的存儲特點。測試結果表明，以Hadoop 為基礎架構的云存儲平臺隨著DataNode 節(jié)點增多，性能近似線性增加。同時還研究了文件大小對于客戶端讀取并顯示圖像效果的影響，結果表明單純地將病人一次檢查圖像合并為一個大文件是不可取的，應當考慮到網(wǎng)絡下載速度以及診斷醫(yī)生觀感，每個文件以不超過64MB為宜。下一步的研究工作是對中間件功能進一步完善，并研究區(qū)域PACS云存儲系統(tǒng)的數(shù)據(jù)安全與加密機制，確保醫(yī)院及病人的相關隱私及數(shù)據(jù)安全。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://m.hanmeixuan.com/
本文標題：基于Hadoop的云架構區(qū)域PACS存儲方案設計
本文網(wǎng)址：http://m.hanmeixuan.com/html/support/11121511595.html
相關文章
