《中共中央、国务院关于深化医药卫生体制改革的意见》明确指出:“建立分工明确、信息互通、资源共享、协调互动的公共卫生服务体系。”在全国区域化医疗卫生改革进程中,区域图片存档及通讯系统(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://www.toberp.com/