三种海量医学图像存储技术对比分析

高杰诚 ，杨媛媛

1 中国科学院上海技术物理研究所 医学影像实验室，上海市，200083

2 中国科学院大学，北京市，100049

0 引言

随着计算机和网络技术的不断发展，各种数据呈现爆炸式增长。根据IDC的报告显示，到2020年，全球大数据将比2010年增长22倍，或将达到44 ZB的体量[1]。目前国内的医学影像云平台的发展情况是在北京、上海、江苏等地分别采取了不同的方式来建立区域型医学影像平台[2]。然而这些平台设计不是很完善，整体上医院还是依靠传统本地文件存储（包括本地网络存储）的单一化方式来存取医疗数据。传统的数据存储方式将病人的电子病历、检查检验数据以及影像等医疗数据有效快速地集中存储和读取，可是相较于如今对大数据特性的要求，本地存储网络已经不能够胜任这个需求[3]。在国外，SwiftStack公司提出了一种用来解决病人医学数据存档的解决方案，包含了医学影像数据和厂商中立归档（vendor neutral archives,VNAs），通过基于OpenStack Swift的框架设计的分布式对象存储系统[4]。此外另一类分布式文件存储系统Apache Hadoop项目的hadoop distributed file system（HDFS）也被用于海量医学数据的分析中。不过很多医学影像数据属于小文件（如单幅CT图像512 kB、单幅MR图像120 kB等），影响了HDFS存取性能。不过目前有些机构对HDFS这一缺陷进行了一些优化，将小文件的访问效率和存取速度提高了2.7倍[5]。

由于这些存储医学图像的存储系统之间的对比分析一直未见报道，于是通过实验室研发的医学图像通信与存储系统（picture archiving and communication systems,PACS）接入这三种存储系统，从存取速度、部署方式、数据安全和性能等方面进行比较，为海量医学图像存储提供其中一种或多种存储方案。

1 三种存储方式简介

目前对于文件的存储，主要有三种方式：本地集中文件存储、分布式文件存储和分布式对象存储。在个人的日常生活中，这三种存储方式中以本地集中文件存储使用最为普遍。然而，随着信息时代的不断发展，各行各业的数据量都呈现指数上涨的趋势，这种传统的文件存储不仅会提高本地存储的硬件成本，同时还会使得存储硬件自身的保养、安放变得更为困难。因此，分布式文件存储和分布式对象存储就逐渐地被大多数厂商用于存储数据。

1.1 本地集中文件存储

本地集中文件存储主要是将文件都存储在本地环境中的方式，包括服务器内置硬盘存储、服务器直连存储、存储局域网络SAN和网络附加存储NAS，这类存储是当前绝大多数医疗数据存储采用的方法，优点在于在局域网环境下易于分配管理，具有一定的利用率，同时存取时可以借助于内存存储的优势达到很好的性能。当文件过于庞大或者是突然要存储大量的文件时，本地集中文件存储的性能会急剧下降，这是因为本地集中文件存储的高性能内存存储不能即时处理大文件或大量文件，而且自身成本过高；而成本相对较低的硬盘存储则速度更慢。此外，如果本地集中文件存储系统在传输过程中出现错误或者进行文件校验时，将会受到本地集中文件存储的文件系统路径的复杂度的影响[6]，效率降低。

1.2 分布式文件存储

分布式文件存储即利用分布式文件系统把多个存储节点的资源整合成一个集群协同工作，共同对外提供存储和业务访问。该存储方式不仅是存储设备硬件组合，还包括网络设备、服务器等硬件和控制软件、访问接口及各种对外服务软件等，具有配置简单、动态调整、可扩展性、高可靠性等特点。常见的分布式文件存储以HDFS为代表。

1.3 分布式对象存储

对象存储即将文件视为对象存储。对象化的文件包含了文件自身所包含的数据、元数据以及特定的全局特征值。文件的元数据指文件名、文件大小、创建时间、对象版本等不可更改的数据。和分布式文件存储相同，分布式对象存储的可扩展性也非常强。对象存储设备与本地集中文件存储和分布式文件存储设备不同的地方在于，其文件的存储路径不会像前两者那样层层分级，这样在存储的过程中会省去寻找路径过程中的麻烦和时间损耗。对象存储扁平化的存储方式更加易于分布式的架构，从而帮助对象存储能够保证文件存储的稳定性。分布式对象存储既拥有了网络附属存储（NAS）的分布式特点带来的稳定性，又拥有了存储区域网络（SAN）的高性能高速性能[7-8]。常见的分布式对象存储有OpenStack Swift等。

2 OpenStack Swift、HDFS存储原理

2.1 OpenStack Swift存储原理

OpenStack Swift是Rackspace公司开发的高可用性分布式存储系统，一开始Swift模块是用作OpenStack整个系统中Nova模块的子功能[9]。Swift通过牺牲一定的数据一致性，通过在软件层级上引入一致性散列（Consistent Hashing）和数据冗余性，保证了其高可用性和可伸缩性。OpenStack Swift支持云端部署和本地部署两种部署方式，不过由于其扁平化的存储方式更适合于云端部署。OpenStack Swift的对象传输通过RESTful API或者HTTPS协议实现[10]，适合频繁读写海量文件的场景。

（1）一致性散列

面对海量级别的数据对象，Swift通过一致性散列法则将数据寻址的问题解决。通过计算，Swift将这些对象数据均匀分布地放在各个虚拟节点上。Swift放弃了严格一致性，而是使用仲裁机制（Quorum）达到最终一致性（Eventual Consistency）。

（2）环数据结构

环数据结构是Swift用来将其系统中的虚拟节点映射到具体的磁盘上的。通过环数据结构，Swift的所有数据模型包含用户、容器、对象都可以保证其高度的一致性和可用性。

（3）Swift数据模型

如图1所示，Swift的数据模型为只有三层的层次模型，包含账户（Account）、容器（Container）以及对象（Object）三种。账户是Swift数据架构的顶层节点。账户包含了该账户下面的所有容器以及对象的所属；容器是用来包含所属对象；对象包含元数据（metadata）和内容（content）[10]。

图1 Swift的数据结构Fig.1 Data structure of Swift

（4）系统架构

Swift采用了完全对称的、可扩展的架构，避免了在单点失效时系统数据崩溃的情况。其组件包括：代理服务（Proxy Server）、认证服务（Authentication Server）、缓存服务（Cache Server）、账户服务（Account Server）、容器服务（Container Server）、对象服务（Object Server）、复制服务（Replicator）、更新服务（Updater）、审计服务（Auditor）、账户清理服务（Account Reaper）[11]。Swift的系统架构，如图2所示。

图2 Swift的系统架构Fig.2 Architectural structure of Swift

（5）文件安全

OpenStack Swift针对存储文件过程的安全问题有自己独特的解决方案：首先将API、计算节点等核心服务设计成必须要在两个安全域内同时存在。这样使得单一的对某个安全域的攻击无法有效地侵入核心服务[12]。其次在进行对象加密的时候，可以选择使用加密中间件或者OpenStack Barbican来进行对对象内容、对象元数据和非空对象的实体标签的根密钥管理[13]。OpenStack Swift还会对每个数据节点进行复制，这样如果当中任何一个节点出现故障，其复制节点会通过rsync服务同步到损毁节点中。

2.2 HDFS存储原理

HDFS是Apache Hadoop项目中用于存储的分布式文件存储系统。它在相对低成本的硬件基础上就能够搭建一个分布式存储系统。与传统的本地文件集中存储不同的是，HDFS具有高容错性、高安全性和高数据流通性[14]。HDFS的数据块传输可以通过HDFS提供的Java API实现。通过NFS Gateway组件，HDFS还可以作为客户端挂载到本地文件系统[15]。

HDFS同样适合云端部署和本地部署两种部署方式，不过这两种部署方式却由于HDFS本身设计的特性各有优缺点[16]。虽然HDFS最初设计的理念是基于本地数据中心且HDFS的读取性能非常受本地磁盘的I/O性能或者网速的影响，但HDFS若使用云端部署，相比本地存储可以直接数据拷贝，云端存储为了节省存储开销需要将数据先进行编码再进行拷贝[17]，读写性能会稍强于本地部署，且通过虚拟化共享存储层，使得HDFS部署所需的系统安装等变得更加方便。如今本地I/O和网速性能发展到不再限制HDFS的读取性能，VMware指出通过vSphere 6上部署4个虚拟机与物理本地存储进行数据处理速度比较时，虚拟机比物理部署在map-shuffle操作速度上更快[18]。

（1）核心组件

HDFS的系统架构，如图3所示。HDFS的核心组件包括NameNode和DataNode。NameNode是用来对元数据（metadata）进行操作，如打开、关闭、重命名文件以及路径等。此外NameNode还可以决定数据块（block）到DataNode的映射。DataNode是用来存储数据内容（content）的，它可以对数据的读写请求进行操作，同时它还对NameNode的指令进行数据块的建立、删除和复制的操作[19]。

图3 HDFS的系统架构Fig.3 Architectural structure of HDFS

（2）优势及缺点HDFS依据分布式的架构，可以形成高可用性（high availability，HA）和恢复机制。此外HDFS适合一次写入、多次读取、允许追加。这样的一致性模型有利于提高系统的吞吐量。然而HDFS并不适合小文件存储：小文件过多会占用NameNode的内存，且会造成寻道时间大于读写时间[5]，从而造成性能的浪费。

（3）文件安全

HDFS支持数据库和文件系统层级的加密，同时如果接入的应用满足应用层级加密，那么HDFS也可以满足应用层级加密[20]。此外，在HDFS中存储和读取的都是数据块而不是文件本体，并且一个文件会被分割成多个数据块。因此在攻击HDFS时只会获得意义不明、残缺的数据块并且很难将其还原成文件。

HDFS将存储的数据块进行复制分配到各个存储节点中，默认数值为3，这样可以保证，其中某个存储节点出现故障导致其数据块缺损，也能够通过其他存储节点中获得数据块并且修复该存储节点。

3 实验环境和测试结果

3.1 实验环境

为了测试这三种存储方式的存取医疗影像的性能，在虚拟机上搭建了三个集群，分别是OpenStack Swift集群、HDFS集群以及本地文件存储集群。本次实验所使用的OpenStack Swift版本号为2.18.0，HDFS版本号为3.1.1，Java版本为1.8.0_251，副本数为3，HDFS块大小为64 MB，内存大小均为4 GB，搭载系统为CentOS 7。本地集中文件存储由三个硬盘大小为60 GB的节点组成。OpenStack Swift和HDFS则各由一个硬盘大小为25 GB的控制节点和两个硬盘大小为60 GB的存储节点组成，其控制节点只参与存储和读取命令的调度而不直接参与存储过程。

3.2 存取速度测试

测试需要考虑到各种类型和大小的医学图像，常见的CT图像（平均大小545 kB）、MR图像（平均大小182 kB）、DX图像（平均大小8.29 MB）以及目前兴起的PET/CT图像（平均大小245 kB）均被纳入为测试的对象。采用实验室研发的PACS系统分别接入三种存储系统环境，各对4 000幅CT图像、MR图像、X光图像和PET/CT图像进行20次传输速度测试，测试基本流程如图4所示，再通过PACS医学图像诊断工作站分别读取图像并记录读取速度。

图4 测试流程Fig.4 Test flow chart

经过一轮测试可见，由于测试的医学图像数据量较小，本地文件存储的存储速度其CT约为1.64 ms/幅，MR约为0.97 ms/幅，DX约为74.79 ms/幅，PET/CT约为0.012 ms/幅；本地文件存储的读取速度其CT约为1.04 ms/幅，MR约为1.01 ms/幅，DX约为68.80 ms/幅，PET/CT约为0.013 ms/幅。OpenStack Swift较慢，其读取速度要比本地文件存储要慢15.46%。OpenStack Swift的存储速度CT约为1.95 ms/幅，MR约为0.96 ms/幅，DX约为77.11 ms/幅，PET/CT约为0.010 ms/幅；OpenStack Swift的读取速度其CT约为1.51 ms/幅，MR约为1.00 ms/幅，DX约为70.21 ms/幅，PET/CT约为0.010 ms/幅。HDFS的读取速度和本地文件存储的速度相当甚至略快，CT图像的存储速度比本地文件存储要快28.13%，约为1.28 ms/幅，MR约为0.96 ms/幅，DX约为70.17 ms/幅，PET/CT约为0.009 ms/幅；HDFS的读取速度其CT约为1.19 ms/幅，MR约为0.92 ms/幅，DX约为61.53 ms/幅，PET/CT约为0.007 ms/幅。这符合HDFS将文件变为数据块之后存储速度上升的事实。HDFS是实验中存取速度最快的存储系统。

3.3 高可用度测试和成本比较

为了检验OpenStack Swift和HDFS的高可用度，还要在一个存储节点出现故障时进行存取速度测试。本次测试的OpenStack Swift与HDFS集群及上一节实验配置除了各自关闭其中一个存储节点之外全部相同。

在减少一个存储节点之后，OpenStack Swift和HDFS的存储图像的速度没有多少改变，OpenStack Swift的存储速度CT约为1.95 ms/幅，MR约为0.97 ms/幅，DX约为77.20 ms/幅，PET/CT约为0.010 ms/幅；OpenStack Swift的读取速度其CT约为1.61 ms/幅，MR约为0.99 ms/幅，DX约为70.01 ms/幅，PET/CT约为0.011 ms/幅。HDFS的存储速度CT约为1.29 ms/幅，MR约为0.97 ms/幅，DX约为70.44 ms/幅，PET/CT约为0.009 ms/幅；HDFS的读取速度其CT约为1.24 ms/幅，MR约为0.96 ms/幅，DX约为62.41 ms/幅，PET/CT约为0.007 ms/幅。因此这两个分布式存储系统都可以保证高可用性。

从安装成本考虑，HDFS和OpenStack Swift都可以部署在成本较低的硬件中或者直接进行云部署。从部署时间成本考虑，OpenStack Swift的部署难度高于HDFS，缺少官方的错误解决方案和繁琐的部署步骤使得OpenStack Swift的部署时间成本远远高于HDFS，这样相较之下在解决部署或者运行的时候出现的故障，HDFS的解决速度会快于OpenStack Swift。

4 结束语

海量医学图像的三种存储技术，本地集中文件存储、分布式文件存储和分布式对象存储，在经过存取速度测试之后发现HDFS存取医学图像最快，在存储和读取单张CT图像都可以达到毫秒级。显然在本地集中文件存储性能发展遇到瓶颈，未来的海量医学图像存取在高速高稳定的要求下，分布式存储系统是相较于本地集中文件存储的更优解。此外在三个分布式存储系统中，HDFS经济成本和时间成本是最低的，因此HDFS最为合适。

在实验中，还有一些尚未考虑的因素，例如是否可将HDFS进行优化之后再进行文件传输测试，因为频繁地写入小文件是浪费HDFS性能的表现。HDFS的系统架构如果有了官方进一步的优化，分布式文件存储系统就可以应用到所有医疗数据的存储中。此外HDFS可以直接和大数据处理框架MapReduce对接，直接完成大数据存储处理的流程，这样更适合将来医疗云计算平台的搭建。综上，笔者推荐使用以HDFS为代表的分布式文件存储系统来作为存储和读取医学图像首选的存储系统。