基于HDFS的区域医学影像分布式存储架构设计

    摘要：构建区域医学影像协作平台是均衡医疗资源、提高基层医院诊疗水平、降低医疗费用的有效途径，但是构建区域化影像平台在技术和成本上还存在巨大的挑战。本文详细分析了传统集中式存储和HDFS（Hadoop Distributed File System）分布式存储系统的优缺点，设计了一种适合HDFS特点的S-DICOM文件格式，以及集中式存储（FC SAN）和分布式存储（HDFS集群）结合的统一存储架构，开发了一套SDFO（S-DICOM File Operator）中间件，为上层的PACS应用组件提供透明的存储访问接口。测试结果表明此架构可以满足海量医学影像资料的快速存取和处理需求。

　　随着X线机、CT、磁共振等大型影像设备在临床上的广泛应用，影像检查已成为临床诊断最重要的依据之一。但是昂贵的影像设备和重复的影像检查也成为医院和病人医疗支出的重要部分。同时，影像诊断难度大、操作复杂度高、专业性强，基层医院极其缺乏优秀的影像诊断人才。医疗设备和人才的不均衡，也是造成目前“看病难、看病贵”的重要原因。构建区域一体化的医疗协作平台，是均衡医疗资源、提高基层医院诊疗水平、实现“有序医疗”的重要途径。其中区域医学影像协作平台的构建，是区域医疗协作的重要组成部分，但是构建区域化的医学影像协作平台在技术和成本上还存在着巨大的挑战。

　　1 构建区域医学影像协作平台面临的挑战

　　数字医学影像技术目前已有成熟的国际标准，即DICOM 3.0，遵照其标准建设的 PACS 系统也已从单机、科室逐步发展到全院、区域。目前国内许多大型三甲医院已开展全院PACS应用，实现了医院无胶片化。PACS系统区域化将是下一阶段政府卫生部门和医疗机构的主要研究目标，但是构建大型区域医学影像中心和协作平台目前还面临巨大的挑战。

　　1.1 建设费用高

　　PACS 的数据量远远大于 HIS、LIS 等其它医疗系统，区域医学影像数据达到数百TB甚至PB级，采用传统存储架构（如FC SAN/iSCSI等）费用极高。

　　1.2 传输带宽存在瓶颈

　　即使是高性能的FC SAN，其网络带宽和处理能力也难以达到PB级数据的快速处理和传输要求。

　　1.3 可用性受限

　　大型医院PACS系统常用“在线-近线-离线”的存储模式，离线数据大多存储在磁带库中，其可用性较差，数据不能实时获取。

　　1.4 缺乏一体化的应用平台

　　目前的医学影像协作，如远程影像会诊基本采用“点对点”的模式，缺乏一体化、跨平台、高可用的区域医学影像协同应用软件。随着云计算技术的飞速发展，为构建低成本、高可用、高性能的区域医学影像协作平台提供了一条有效的途径。云计算是Google率先提出来的一种新的技术和运营模式，从应用范围来看，云计算可分为公有云、私有云和混合云。从服务模式来看，云计算可分为 IaaS、SaaS和PaaS。区域医学影像云计算平台属于混合云的范畴，我们承担的课题就是研究通过医疗集团内部医院之间的高速城域网、医保网、电子政务外网、互联网等传输介质，为各类医疗机构提供SaaS模式的医学影像协作应用系统，包括Web DICOM终端、影像会诊、影像转诊、远程教育、数字胶片代存等服务。而高性能、高可靠的海量图像存储系统将是医学影像云计算平台的基础和关键，本文主要介绍一种基于Hadoop 平台的分布式存储和传统集中式存储（FCSAN）相结合的存储架构的设计和实现。

　　2 Hadoop 平台简介

　　Hadoop是目前应用最广泛的开源分布式存储和计算平台之一。它是根据Google的GFS分布式文件系统和Map/Reduce分布式计算技术而开发的开源平台，其设计目标是在普通的硬件平台上构建大容量、高性能、高可靠的分布式存储和分布式计算架构。Hadoop目前已在Yahoo、Facebook、亚马逊、百度、中移动等公司取得了广泛应用。其中Yahoo、FaceBook等公司已构建了数千至数万台普通服务器组成的大型Hadoop应用集群，FaceBook上存储的图像数据量目前已超过1 PB即1024 TB）。

　　2.1 Hadoop集群的特点和适用性

　　Hadoop HDFS分布式文件系统具有如下特点：（1）非常适合海量数据的存储和处理；（2）可扩展性高，只需简单添加服务器数量，即可实现存储容量和计算能力的线性增长；（3）数据冗余度高，缺省每份数据在3台服务器上保留备份；（4）适合“流式”访问，即一次写入，多次读取，数据写入后极少修改，这非常适合医学影像文件的特点；（5）除了数据存储能力外，Hadoop MapReduce分布式计算框架还可充分利用各服务器CPU的计算资源，便于后期开展基于海量医学影像数据的图像融合、图像内容检索、三维重建等数据密集型计算。

    2.2 存在的问题

　　Hadoop在构建医学影像存储系统时还存在以下问题：1）Hadoop的设计理念是针对大文件进行优化的，其默认的数据块大小为64 MB，而医学影像资料中常见的CT、MRI 的图像大小大多为 512 KB 左右，一次拍摄产生的图像数量大约为100 ~200幅，如果直接将这些大量的小文件存储在HDFS文件系统中，过多的小文件将导致HDFS的主节点NameNode内存消耗过大，降低整个集群的性能。2）HDFS的设计理念不适合实时应用，在数据写入的过程中，每个数据块需复制3份，其写入性能大大低于读取性能，因此不太适合需要快速获取图像资料并撰写诊断报告的PACS实时应用。

　　3 系统设计

　　针对上述问题，我们设计了一种适合Hadoop平台的序列DICOM文件格式（S-DICOM），以及一套传统的集中存储和HDFS分布式文件系统相结合的S-DICOM文件存储架构。

　　3.1 S-DICOM文件格式

　　CT、MRI等DICOM文件大小虽然只有512 KB左右，但是病人的每个部位的检查通常都有100~200张图片，这样每个病人每次检查的数据量也将达到50~100MB。而另一种常见的医学影像设备X线机（CR、DR），其单幅图像的数据量约为8~20 MB，每次检查拍摄的图片一般为2~4幅，其总数据量也满足HDFS文件系统的要求。因此，将一个病人一次检查的所有图像合并成一个文件，再存储到HDFS中是比较合理的。我们采用了Hadoop的SequenceFile文件格式，将每个DICOM文件转化成健值对（key/value）的形式，然后合并成一个单独的S-DICOM文件，其中key为原DICOM文件名，value为DICOM文件内容，文件格式（图1）。

　　3.2 混合式存储架构

　　单纯的HDFS分布式文件系统不适合实时应用，但是具备低成本、高可扩展、高性能、高可靠的特点，传统的集中存储（FC SAN）则非常适合小文件的快速写。因此，结合两者的优点我们设计了一套混合式存储模式，其核心是SDFO（S-DICOM File Operator）中间件，主要用于屏蔽底层操作细节，为上层的SaaS模式医学影像应用系统和DICOM应用组件提供统一的图像查询、读取和写入接口。SDFO的核心主要由SDFO Lo-cator、SDFO Reader、SDFO Writer、SDFO Converter、SDFO Client 五个部分组成。SDFO Locator 用于检索DICOM 文件的存储位置，SDFO Reader 用于读取 DI-COM 文件，SDFO Writer 负责将从影像设备获取的图像写入集中存储（FC SAN），SDFO Converter负责定时将FC SAN中的DICOM图像转换为S-DICOM格式，合并后存储到HDFS中。其系统框架（图2）。

　　医院PACS系统中存储的图像，超过3个月后，其访问量将大大下降，因此我们将3个月内的DICOM文件以其原始文件格式存储在FC SAN中，超过3个月的图像则定时转换成S-DICOM格式，存储到HDFS中（也可根据需要设置存储超期时间）。利用Hadoop HDFS的线性扩展能力，我们可以将传统PACS的“在线-近线-离线”模式简化为“在线-近线”模式，解决离线数据可用性差的问题。

    3.2.1 图像读取流程

　　 SDFO 从 Hadoop HDFS 集群和FC SAN中检索和读取图像的流程（图3）。

　　（1）从DICOM Locator获取图像存放的路径，如果图像存放在FC SAN中，则跳至第6步；

　　（2）从HDFS的NameNode获取文件数据块所在的DataNodes位置；

　　（3）调用SDFO的read方法，开始获取图像；

　　（4）从HDFS的DataNode 1获取第一个数据块，以此类推至其它的数据块，此步骤可以并行操作；

　　（5）从HDFS的DataNode n中获取最后一个数据块，将所有的数据块合并成完整的文件，关闭HDFS数据流，并将其转换成标准的DICOM图像；

　　（6）存放在FC SAN中的DICOM文件直接通过JAVA的本地文件系统接口读取。

　　3.2.2 图像写入流程 　　

　　SDFO 中间件中DICOM 文件的写入方式与传统的文件写入方式相同，直接通过JAVA本地文件系统接口写入FC SAN。

　　3.2.3 图像转换流程

　　图像转换流程定时将FC SAN中的 DICOM 文件合并成 S-DICOM 文件，存入 HDFS中。其转换流程（图4）。

　　（1）调用JAVA的本地文件系统接口，循环获取FCSAN 中某个文件夹下的文件列表（每个病人每次检查的所有图像存放在一个单独的文件夹中），将每个DI-COM文件转化成一个健值对（key/value），将key/vlaue健值对顺序写入一个单独的S-DICOM文件数据流；

　　（2）调用DistributeFileSystem的create方法，通过NameNode的RPC接口创建文件，并获取用于存放数据块的DataNodes列表；

　　（3）调用FSDataOutputStream，将S-DICOM文件转换成内部的数据队列，将数据写入第一个DataNode；

　　（4）数据块写入成功后，第一个DataNode将写入的数据块复制到第二个DataNode，依次类推至第三个DataNode。

　　（5）按相反的顺序，第三个DataNode写入成功后，依次向第二个和第一个DataNode返回ack packet，确认数据写入成功；

　　（6）循环写入所有的数据块后，调用close方法关闭FSDataOutputStream；

　　（7）向NameNode发送complete指令，确认文件写入完成，更新NameNode的元数据；

　　（8）向DICOM Locator写入DICOM文件的存储路径。

　　4 应用测试效果

　　4.1 软硬件配置

　　我们目前已搭建了20台服务器组成的Hadoop集群。CPU：Intel Xeon E5504；内存：8 GB DDR3；网卡：两块1000 Mbps以太网卡；硬盘：4块1 TB SATA。存储空间共计80 TB，按照Hadoop缺省配置，每个数据块在3台不同的服务器上保存副本，因此实际存储容量约为27 TB。每台服务器均接入千兆汇聚层交换机，汇聚层交换机万兆上联。操作系统：64位CentOS 5.4；Java环境：JDK 1.6.0-b09；Hadoop平台：Hadoop 0.20.2。

    4.2 测试结果

　　DICOM图像的写入以及3个月内图像的读取均是直接通过FC SAN完成的，其性能与普通的PACS环境区别不大，因此我们主要测试读取3个月以前的S-DI-COM 图像以及将 DICOM 图像合并转换成 S-DICOM图像的性能。Hadoop支持分布式读写，我们分别测试了1~5个SDFO Client的情况下，S-DICOM读取和转换的性能如下表所示（单位：MB/s）：

　　从测试结果可以看出SDFO的读性能基本是与Client 数量线性相关的，这是由于 Hadoop 中的数据块是均匀分布在各DataNode中的，读取文件时可以聚合各DataNode的网络带宽，随着DataNode数量的增大，其聚合的总带宽将远远超过传统的FC SAN传输速率。根据测试情况来看，客户端同时读取和转换一个病人一次检查的S-DICOM文件时间约为1~2 s左右，这样的延时对PACS系统的操作是可以忽略的。

　　从测试结果也可看出Hadoop的写入性能不佳，单个Client写入HDFS的速率只能达到10 MB/s左右，这是由于HDFS写入文件时需要同时写入3个副本相关。

　　但随着SDFO Client数量的增加，写入速率也相应增大，当SDFO Client数量为5时，总写入速率约为33MB/s。一个大型三甲医院PACS系统每天产生的图像数据量约为20 GB左右，全部转换成S-DICOM文件耗时约10 min，对于拥有较多医院的区域，可以通过增加SDFO客户端数量的方式，近似线性地提高转换和存储性能，在每天的夜间空闲时段进行数据转换任务也是可以接受的。

　　5 总结与展望

　　Hadoop平台是构建超大规模数据集群，实现存储聚合和数据密集型分布式计算的优秀平台，它可以有效解决构建区域医学影像数据中心的成本高、可扩展性差、传输带宽不足、离线数据可用性差的问题。但是Hadoop HDFS也存在不适合CT、MRI等小文件的存储及实时应用的问题。为此我们设计了一种S-DICOM文件格式，使其适应HDFS的特点，同时通过传统的集中式存储（FC SAN）和分布式存储（HDFS集群）组合的存储架构，开发了一套SDFO中间件，为上层的PACS应用组件提供透明的DICOM文件访问接口。该系统在测试平台上取得了比较满意的效果，能满足大型区域医学影像中心的功能和性能要求。今后我们将在此基础上开展进一步的研究工作：1）进一步提高系统的安全性，完善应用系统、存储架构和网络拓扑等方面的加密和授权机制，确保病人的隐私和数据安全；2）充分利用Hadoop集群的分布式计算能力，开发基于MapReduce算法的图像融合、图像内容检索、三维重建等应用。