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