分布式文件存储系统研究及应用

《分布式存储系统研究和应用实践》-1-分布式存储系统研究和应用实践二〇一二年二月摘要物质、能量和信息是自然科学研究的三个基本对象，处理、传输和存储是信息计算的三大基本任务。随着网络技术及信息处理技术的不断发展，个人数据和企业数据的产生量呈现爆炸性膨胀的趋势，IT系统正面临着海量数据存储成本高、管理困难、可靠性低的问题，为了充分利用资源，减少重复的投资，数据存储作为IT系统的主要架构和基础设施之一，逐步被作为一个完整的系统从IT系统中独立出来，分布式存储系统因为具有海量数据存储、高扩展性、高性能、高可靠性、高可用性的特点，目前正被作为企业海量数据存储方案被业界所广泛讨论和应用。因此对于分布式存储系统的研究不仅紧跟目前发展的趋势，而且具有较高的应用价值。本文基于对分布式存储系统的研究，旨在通过在网络环境下构建具有高传输性能、高可靠性、高可用性的网络分布式文件系统，通过网络数据流方式实现对海量文件系统中的数据进行存储和访问，解决大规模非结构化数据的存储、查询、高性能读取、高容错性的问题，为IT系统提供高性能、高可靠性、高可用性的存储应用服务，并为今后的分布式计算研究提供技术基础。本文阐述的主要内容如下：分布式架构的相关理论以及分布式存储系统的应用现状，介绍了分布式存储系统概念；然后引入开源项目Hadoop的HDFS分布式文件系统，接着对HDFS关键运行机制进行了详细分析；并在此基础上，通过搭建基于HDFS0.23版本的实验环境进行实际的测试验证，采集实验数据，并对实验结果作出进一步的分析总结，得到理论和实际结合的第一手资料；最后，通过结合实际需求，在对医学影像中心业务分析的基础上，对医学影像中心存储体系、功能结构及运行环境进行了设计和规划。关键词:分布式存储系统、HDFS、Hadoop

绪论背景说明IDC的一项预测曾指出，“数字宇宙”（digitaluniverse）项目统计得出，2006年的数据总量为0.18ZB，并预测在2011年，数据量将达到1.8ZB。1ZB等于10的21次方字节，或等于1000EB，1,000,000PB，或者大家更熟悉的10亿TB的数据。这相当于世界上每人一个磁盘驱动器所能够容纳的数据的数量级。在如此强大的需求下，对海量存储容量、高性能、高安全性、高可用性、可扩展性、可管理性的存储的要求不断提高。关于磁盘存储目前的情况是，磁盘存储容量快速增加的同时，其访问速度-磁盘数据读取速度却未能与时俱进。目前，普通的1TB磁盘，其传输速率约为100MB/S左右,写入则更慢，而10年前，10G的磁盘，其传输速率也有66M/s,即便换成基于闪存的SSD固态硬盘，也只是将读取速度提高3倍、写入速度提高1.5倍而已，甚至最先进的光纤通道硬盘，和内存的读取和写入数据的速率相比也不在一个数量级上。一个简单的减少磁盘读取时间的方法就是同时从多个磁盘上读取数据，假设，我们拥有100个磁盘，每个磁盘存储1%的数据，并行读取，所需要的读取时间，也相当于原来的1%左右。这种方法称之为条带化存储（Strip），是RAID（RedundantArrayofIndependentDiskes，独立磁盘冗余阵列）技术的一项重要特性，通过使用一组磁盘同时进行I/O操作，从而获得更大的I/O吞度量，并依靠存储冗余信息（镜像+奇偶校验）来保障数据的安全性。例如RAID10模式，数据块被分别以位或字节为单位进行分割并且并行读/写，同时，为每一块磁盘作磁盘镜像进行冗余，既保证了最高的读写存储性能，又通过镜像保护了数据，缺点是磁盘利用率比较低。设置RAID10至少需要安装4块硬盘，当把4块磁盘设置成RAID10后，每一对磁盘被设置成镜像，每一对磁盘之间被设置成条带以便数据快速传输。下图为RAID10的数据分布及镜像示意。网络存储应用除了个人PC机的本地存储，企业的大多数的存储应用，都是基于局域网或者广域网的文件共享和存储，目前很多简易的局域网内的文件共享和存储应用都是基于文件服务器，主要的功能是提供网络用户访问共享文件，通常是C/S模式，基于FTP或TCP/IP连接。这样的存储服务器，在访问的高峰期，单机IO负载很大，不能充分使用网络带宽，而且扩展性差，可靠性和容错能力需要依靠硬件来完成，比如RAID的磁盘阵列。随着网络技术的发展，网络的带宽已经超过了磁盘的带宽，现在，很多存储系统方案采用网络存储的技术来解决传统存储的问题，针对I/O是整个网络系统效率低下的瓶颈问题，最有效地方法是将数据从通用的服务器中分离出来，进行集中管理，形成所谓的存储网络。其中又有两种不同的实现手段，NAS（网络附加存储）和SAN(存储器网络)，两者之间的区别在于，NAS是每个访问客户端通过网络共享协议使用同一个文件管理系统，而SAN在每个访问客户端都有个文件管理系统。FC硬盘是普通的SATA硬盘的成本是的十倍，耗电量也是SATA硬盘的十倍，但是只提供1/10的密度，NAS和SAN虽然解决了存储速度和可靠性的问题，但是其高昂的成本和复杂的管理问题局限了其应用范围。针对服务器的I/O效率和网络访问的问题，通过分布式系统通过在不同的节点间实现共享，提供多个访问点提高性能，来实现各个节点的高效、一致的数据共享来解决。分布式存储相关理论分布式系统概念在网络基础设施及服务器性能不断成熟和发展的背景下，分布式系统架构越来越多的为人所关注，分布式系统架构以传统信息处理架构无法比拟的优势特性，正在成为企业实现提高效率、提高灵活性、降低成本的重要选择。分布式系统（DistributedSystem）是建立在网络之上的支持分布式处理的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。所谓的内聚性是指每一个分布节点高度自治，有独立的程序进行管理。透明性是指每一个分布节点对用户的应用来说都是透明的，看不出是本地还是远程。在一个分布式系统中，一组独立的计算资源展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。在传统网络系统中，这种统一性、模型以及其中的软件都不存在。用户看到的是实际的机器，计算机网络并没有使这些机器看起来是统一的。如果这些机器有不同的硬件或者不同的操作系统，那么，这些差异对于用户来说都是完全可见的。分布式系统和传统网络系统的共同点是：多数分布式系统是建立在网络之上的，所以分布式系统与传统网络系统在物理结构上是基本相同的。他们的区别在于：分布式系统的设计思想和网络系统是不同的。网络系统要求网络用户在使用网络资源时首先必须了解网络资源（比如：计算机的功能与配置、软件资源、网络文件结构等情况）；分布式系统是以全局方式管理系统资源的，它可以任意调度网络资源，并且调度过程是“透明”的，在利用分布式系统的过程中，用户并不会意识到有多个处理器的存在，这个系统就像是一个处理器一样。分布式存储系统概念由此而知，分布式存储系统是指通过分布式技术，将网络中不同节点上的存储设备通过分布式应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。分布式存储系统的最大特点是，数据分散存储在分布式存储系统的各个独立节点上，供用户透明的存取。分布式存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。分布式存储系统的应用现状以高性能、高容量为主要特性的分布式存储系统，必须满足以下4个条件1、应用于网络环境中；2、单个文件数据分布存放在不同的节点上；3、支持多个终端多个进程并发存取；4、提供统一的目录空间和访问名称；只有这样，考虑到目前网络总带宽超过单个磁盘带宽的特点，支持多个进程在多个磁盘上并发存取，增加文件系统的带宽，来提高存储的性能，并且通过动态增减分布节点，来实现整个存储系统容量的动态扩展性。分布式存储系统因为其高容量、高性能、高并发性以及低成本的特性而被众多IT企业特别是互联网服务提供企业所广泛关注和支持。下图为一部分常用的云存储产品，可谓是种类繁多、琳琅满目。随着宽带网络的发展，用户数量的不断增加，CDN（Contentdeliverynetwork）内容分发、P2P、数据压缩技术的广泛运用，以及分布式技术的完善，分布式存储（云存储）在技术上已经趋于成熟。从厂商的解决方案来看，面对目前互联网应用PB级的海量存储的存储需求，频繁的数据传输，都是通过应用分布式存储系统，实现在普通PC机上部署节点，通过系统架构设计提供强大的容错能力，针对大型的、分布式的、大量数据访问的应用给用户提供总体性能最高的服务。分布式存储系统架构分析目前，分布式系统的应用体系架构，主要有两种实现类型，一种是中心化（Centralization），一种是去中心化（Decentralization）。中心化体系架构中心化体系结构，顾名思义，就是系统中含有某些“中央节点“。中心化体系类似于我们网络拓扑中的星型拓扑，用一个节点作为中心节点，其他节点直接与中心节点相连构成的网络，中心节点维护了整个网络的元数据信息，任何对系统的分布式请求都要经过中心节点，中心节点通过处理后，给各个节点分配任务，再由分配到任务的各个节点处理完成后，直接将结果返回到目标位置，因此，中心节点相当复杂，通信的负载也是最大的，而各个节点的负载比较小。中心化的结构对于系统的可扩展性有较大的影响，因为那个”中心“很可能会成为瓶颈。在互联网上，中心化的结构还是比较常见的，例如，某个新闻网站。逻辑上，所有的用户都会通过访问同一个网址来获得服务。当然，这背后早就不再是一个服务器提供服务了。大致的体系架构如下图所示：联邦化体系结构在中心化体系结构的基础上延伸出一种联邦式的体系架构来通过对中心节点进行水平扩展的方式解决决单个中心化体系结构的局限性的问题。因此，联邦化体系结构虽然解决了“热点”的问题，但是不能完全解决单点故障问题，如果某个分区的中心节点失效，其管理的相应文件将不能访问，但是通常，中心节点都会配置有副中心节点，当主中心节点失效后，副中心节点将会接管。本次论文中要重点论述的分布式存储系统——HDFS中采用了这种联邦化的架构，NameNode相当于一个分区主节点，每个NameNode加上一个BlockPool形成一个NamesapceVolumn（命名空间卷），相当于磁盘文件系统的一个逻辑卷，各个逻辑卷加起来呈现的相当于整个硬盘。去中心化体系架构在这种结构中，相对于中心化架构，不再存在某类中央节点，总体上讲，每个节点的功能都是类似的或者说对称的，类似于我们网络拓扑中的环型拓扑。对于去中心化结构而言，最重要的问题之一就是如何把这些节点组织到一个网络中。一般而言，系统中的一个节点不可能知道系统中所有的节点，它只能知道在这个网络中自己的邻居并与这些邻居直接交互。去中心化体系结构，根据系统维护方式，又可以分为两类：结构化网络和非结构化网络。结构化网络网络是通过一个确定的过程建立起来的，节点数据的划分都通过哈希算法进行切分分配，寻址采用DHT(DistributedHashTable,分布式哈希表)方式（HASH表的应用类似于Oracle的HASH分区概念，通过HASH对数据进行散列分区），节点间通过Gossip协议进行通讯，使网络达到去中心化，提高系统可用性，在这种系统中，各个节点构成一个逻辑的环。非结构化网络在非结构化的网络中，网络的建立带有更多的随机性。每个节点都维护这一个局部视图（一个包含n个节点的表），这个视图中的节点就是它的邻居。它通过与邻居不断地交换视图内容来更新自己的视图。在此种结构中，因为整个体系中的节点都是对等，根据其动态组织的特点，所以对等节点可以随意的加入或者离开网络，所以，整个结构是一个自组织的动态网络，因此该体系结构必须控制数据的一致性，确保整个网络中的所有数据可以实现数据同步。正因为去中心化的架构具有数据动态一致性的特点，所以不仅可以做为文件存储系统，还可以作为键值对（Key-Value）的分布式缓存系统进行应用。大致的体系架构如下图所示：中心化体系结构与去中心化体系结构的比较中心化体系结构与去中心化体系结构各有优缺点，如下：中心化体系结构优点：一致性管理方便，可以直接对节点进行查询；缺点：存在访问的“热点”现象，单台服务器会形成瓶颈，容易造成单点故障，单点故障会影响个系统的可用性；去中心化体系结构优点：消除了单点故障，可用性高；缺点：一致性管理复杂，依赖节点间的网络通讯，交换机故障所导致的分割，依然会造成故障，不能直接查询；综合来看，中心化体系结构最大优势是结构简单、管理方便，查询效率高，去中心化体系结构最大的优势是可用性高，可扩展性高。下表比较了3种体系结构的综合性能，比较结果如下表所示：比较中心化联邦化去中心化可扩展性低中高可用性中中高可维护性高中低动态一致性低低高节点查询效率高高低执行效率高高低“中心化”与“去中心化”混合架构在实际的使用中，中心化结构和无中心化结构都有各自的问题，所以，实际的系统通常是混合结构的。例如著名的Emule（电驴）和BitTorrent系统。Emule和BitTorrent都是基于的P2P技术的文件共享软件，它们与传统的文件共享方式的区别是：共享文件不是在集中的服务器上等待用户端来下载，而是分散在所有参与者的硬盘上，所有参与者组成一个虚拟网络。在Emule中也存在一些服务器，不过这些服务器不再存放文件，而是存放这些共享文件的目录地址，客户端从服务器处得到或搜索到共享文件的地址，然后自动从别的客户端进行下载，参与的客户越多，下载的速度越快。“中心化”与“去中心化”间的选择对于两种架构设计的优劣，目前在网络上还存在很多争议，有人甚至认为去中心化的设计思想甚至是一种缺陷，为什么这么说呢？去中心化的设计相对于中心化设计的最大好处，也是其最大的优点是有极佳的伸缩性，因为去中心化，相当于无政府化，不用去向中心去登记和注销，从事物的两面性而言，有利必有弊，客户端的每个查询都会涉及到多个节点的响应，并产生不必要的网络IO，这里讲得查询，主要是基于DHT分布式HASH表的查询，这种设计在巨型、频繁伸缩的网络，比如Emule、Bittorrent这种网络是有其特殊意义的。由此可见，去中心化的分布式存储方案，从HighPerformance上讲并不是最佳的企业分布式存储方案。HDFS分布式存储系统研究HSDF系统架构和设计要点HDFS的特点HDFS（HadoopDistributedFileSystem），是一个设计用来保存大数据量的数据的分布式文件系统（PB级甚至是EB级），并提供快速访问这些数据的能力，数据通过冗余的方式保存在多台机器上，以来保存对失败的容错性和并行应用的高度可用性。HDFS和现有的网络文件系统相似，是一个运行在普通的硬件之上的分布式网络文件系统，然而它与普通网络文件系统也存在着一定的差别。HDFS具有高容错性，可以部署在低成本的硬件之上，同时HDFS放松了对POSIX的需求，使其可以以流的形式访问文件数据，从而提供高吞吐量地对应用程序的数据进行访问，适合大数据集的应用程序，比如：MapReduce的分布式计算。HDFS的设计相对网络文件系统，具有高性能、高可靠性、高可用性、高可扩展性的特点，主要表现在以下几个方面：HFDS设计用来保存非常大的数据量信息，就需要将数据分布到大量的机器上;HFDS的数据保存是可靠的，如果集群中的某些机器工作不正常，数据仍然是可用的;通过简单添加一些机器，提供快速，可扩展的数据访问能力，使得HDFS能服务于更多的客户端;在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理,比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量；HDFS与HadoopMapReduce能很好地集成，它在可能的情况下，能使数据读取、计算本地化;HDFS的系统架构HDFS采用master/slave架构，HDFS的架构示意图如下：从图中可以看出，一个HDFS集群是有一个Namenode和一定数目的Datanode组成。NameNode名称节点Namenode是一个中心服务器，是HDFS的中枢，负责管理文件系统的目录名字空间信息（namespace）和客户端对文件的访问，并且管理所有的DataNode；DataNode数据节点Datanode在HDFS中一般是一个节点一个，负责管理节点上它们附带的存储的Block（数据块）。在HDFS内部，文件不是放在一块磁盘上，一个文件其实分成一个或多个block（数据块），这些block存储在Datanode集合中不同的DataNode上，NameNode记录有block对应在不同的DataNode上的映射关系。从图中可以看到NameNode接受客户端的元数据请求，然后对DataNode发出BlockOps（块操作）指令，文件的创建、删除和复制操作，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创建、删除和复制。NameNode是整个集群的中枢可以形象的比喻为劳务中介或包工头，NameNode在线只有一个可用，NameNode主要负责：管理HDFS集群中文件系统的名字空间（Namespace）打开文件系统、关闭文件系统、重命名文件或者目录等；管理客户端对HDFS集群中的文件系统中的文件的访问实际上文件以块的形式存储在Datanode上，文件系统客户端向Namenode请求所要执行操作的文件块（该块存储在指定的Dadanode数据结点上），然后通过与Datanode结点交互来完成文件读写的操作。也就是说，Namenode结点还负责确定指定的文件块到具体的Datanode结点的映射关系。管理Datanode结点的状态报告包括Datanode结点的健康状态报告和其所在结点上数据块状态报告，以便能够及时处理失效的数据结点。DataNode用于存储数据在HDFS集群中，DataNode（数据节点）可以形象的比喻为农民工，一般是一台节点服务器对应一个DataNode实例，DataNode的任务是：负责管理它所在结点上存储的数据的读写Datanode数据结点进程还要在Namenode的统一指挥调度下完成对文件块的创建、删除、复制等操作，当与Namenode交互过程中收到了可以执行文件块的文件块操作的命令后，才开始让文件系统客户端执行指定的操作。向Namenode结点报告状态每个Datanode结点会周期性地向Namenode发送心跳信号和文件块状态报告，以便Namenode获取到工作集群中Datanode结点状态的全局视图，从而掌握它们的状态。如果存在Datanode结点失效的情况时，Namenode会调度其它Datanode执行失效结点上文件块的复制处理，保证文件块的副本数达到规定数量。执行数据的流水线复制（产生数据冗余）当文件系统客户端从Namenode服务器进程获取到要进行复制的数据块列表（列表中包含指定副本的存放位置，亦即某个Datanode结点）后，会首先将客户端缓存的文件块复制到第一个Datanode结点上，并且由第一个Datanode向第二个Datanode结点复制，……，如此下去完成文件块及其块副本的流水线复制。HDFS的设计要点HDFS基于GoogleFileSystem的高可扩展、高可用、高性能、面向网络服务的设计，是通过块结构的文件系统设计来实现的：在HDFS中的单个文件被分成相同大小的块，这些块被分布到HDFS网络中的多台数据节点（DataNode）的机器上，一个文件可由多个块组成，它们并不需要放到同一台机器上。保存每个块的机器是由中心服务器-名称节点（NameNode）通过负载均衡随机选择的，因此访问一个文件需要多台机器协作。使用多台机器保存一个文件，这些机器中任何一台崩溃都会导致文件不可访问，HDFS通过将每块复制到多台机器（默认3台）的方式来保证HDFS的高可用性。HDFS中默认使用块大小为64MB，这使得HDFS减少了对每个文件元数据的存储量，另外，通过把大量数据连续化存放在磁盘上，就可以快速地流式读取数据。这种设计的结果是HDFS倾向于处理大文件。HDFS文件数据是以一次写入，多次读取的方式访问的，元数据结构（文件名，目录名）会被大量客户端同时修改，所以元数据结构信息不适合进行同步，因为节点和节点之间的同步是相当耗费资源的。HDFS可靠性和性能主要通过数据块的副本来实现，并且HDFS采用一种称之为Rack-aware（机架感知）的策略来改进数据的可靠性、有效性和网络带宽的利用。比如：不同的机架间的两台机器的通讯需要通过交换机，显然，同一个机架内的两个节点间的带宽回避不同机架上的两台机器带宽要大。在通常副本数为3的情况下，HDFS的策略将一个副本存放在本地机架上，一个副本放在同一个机架上的另一个节点，最后一个副本放在不同机架上的一个节点。在读取时，为了降低整体的带宽消耗和读延时，如果客户端同一个机架上有一个副本，那么就读该副本。HDFS健壮性的主要目标是实现在失败情况下的数据存储可靠性，常见的三种失败：Namenodefailures,Datanodefailures和网络分割（networkpartitions)。硬盘数据错误、心跳检测和重新复制每个Datanode节点都向Namenode周期性地发送心跳包。Namenode在一段时间内收不到Datanode的心跳包，则认为这个Datanode死掉了，存储在这个Datanode上的数据块无法访问，Namenode开始不断查询哪些数据块需要复制。一旦出现Datanode死掉或者副本中断或者Datanode磁盘故障，都要开始进行数据重新复制。数据完整性当一份HDFS文件建立的时候，会生成这份文件的校验和，保存在HDFS命名空间的一个独立的隐藏文件夹中，客户端拷贝文件时，收到文件后就去匹配这些校验和看文件是否完整。如果不完整，则从另外一个Datanode重新拷贝。负载均衡HDFS中非常容易出现机器与机器之间磁盘利用率不平衡的情况，比如HDFS中添加新的数据节点。当HDFS出现不平衡状况的时候，将引发很多问题，比如，机器之间无法达到更好的网络带宽使用率，机器磁盘无法利用等等。一旦某个Datanode存的数据量低于某个阈值，通过HDFS的Rebalancer程序自动的把其它节点上的数据拷贝过来，使得HDFS达到一个平衡的状态。元数据事务日志和检查点对于任何对文件系统元数据产生修改的操作，Namenode都会使用一种称为EditLog的事务日志记录下来。例如，在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；整个文件系统的名字空间，包括数据块到文件的映射、文件的属性等，都存储在一个称为FsImage的二进制文件中，这个文件也是放在Namenode所在的本地文件系统上，该文件中将每一个文件或者目录的信息视为一个记录，每条记录中包括该文件（或目录）的名称，大小，user，group，mtime，ctime等等信息，Namespace重启或宕机的时候，就是根据读取这个FsImage文件中的信息来重构Namespace目录树结构。但是，Fsimage始终是磁盘上的一个文件，不可能时时刻刻都跟Namenode内存中的数据结构保持同步，而是每过一段时间更新一次Fsimage文件，以此来保持Fsimage跟Namenode内存的同步。而在一个新Fsimage和上一个Fsimage中间的Namenode操作，就会被记录在Editlog中，所以，FsImage和Editlog是HDFS的核心数据结构。这些文件如果损坏了，整个HDFS实例都将失效。由于NameNode只在启动的时候融合FsImage和Editlog文件，所以，随着时间的增长，对于一个繁忙的HDFS网络，EditLog会变得越来越大，造成下一次NameNode启动时间会变得越来越长。HDFS通过以下几种方法去解决以上问题：SecondaryNameNodeSecondaryNameNode用来定期合并FsImage和Editlog，把EditLog文件控制在一个限度下，SecondaryNameNode将最新的检查点存储在于PrimaryNameNode相同方式目录下的目录下。这样，检查点的image总是可以准备被NameNode读取。如果PrimaryNameNode挂掉了，硬盘数据需要时间恢复或者不能恢复了，这时候可以通过将SecondaryNameNode的CheckPoint文件到PrimaryNameNode的fs.checkpoint.dir指向的文件夹，执行ImportCheckPoint命令进行恢复。NameNode会读取需要导入的Checkpoint文件，保存到.dir目录下，（目前自动重启或在另一台机器上做Namenode故障转移的功能还没实现）。CheckpointNode（检查点）CheckPointNode是SecondaryNameNode的改进替代版，CheckpointNode周期性的创建NameSpace的检查点。它在活跃的NameNode上下载Fsimage和editlog，然后本地的把它们融合在一起，然后将新的镜像上传给NameNode。BackupNode（备份节点）这个结点的模式有点像mysql中的主从结点复制功能，NameNode可以实时的将日志传送给BackupNode，而SecondaryNameNode是每隔一段时间去NameNode下载FsImage和Editlog文件，而BackupNode是实时的得到操作日志，然后将操作合并到Fsimage里。当NameNode有日志时，不仅会写一份到本地editslog的日志文件，同时会向BackupNode的网络流中写一份，当流缓冲达到阀值时，将会写入到BackupNode结点上，BackupNode收到后就会进行合并操作，这样来完成低延迟的日志复制功能。HDFS的CheckPoint过程如下图所示：HDFS的高性能和高可用性的设计使得它局限于某些应用范围，HDFS为此作出了一些权衡：应用程序要使用流式读取文件，更多的考虑到了数据批处理，而不是用户交互处理，所以不支持定位到文件的任一位置；为了简化了数据一致性问题，实现高吞吐量的数据访问，适合一次写入多次读取，不支持附加（Append）读写以更新文件；文件很大，流式读取，所以系统不提供本地缓存机制；HDFS关键运行流程解析下面就HDFS的几个关键运行流程进行解析：格式化HDFS部署好了之后并不能马上使用，首先要对配置的文件系统进行格式化。这里的格式化指的是对HDFS的一些清除与准备工作，HDFS中的NameNode主要被用来管理整个分布式文件系统的命名空间(实际上就是目录和文件)的元数据信息，所以，NameNode会持久化这些数据为一个称为FsImage的二进制文件中，并保存到本地的文件系统中，同时为了保证数据的可靠性，还加入了称之为Editlog的操作日志，这两个文件分别存在配置文件的.dir和.edits.dir目录下，格式化时，NameNode会清空两个目录下的所有文件，之后，会在目录.dir和.edits.dir分别下创建文件fsimage、fstime、VERSION、image/fsimage，文件的用途如下：fsimage：存储命名空间(实际上就是目录和文件)的元数据信息；edits：用来存储对命名空间操作的日志信息，实现NameNode节点的恢复；fstime：用来存储checkpoint的时间；VERSION：用来存储NameNode版本信息；/image/fsimage:上一次提交前的fsimage文件；启动过程在HDFS整个系统中，包括了一台NameNode节点和若干个DataNode节点，HDFS的启动过程就是一个NameNode节点以及所有DataNode节点的启动过程；其中，NameNode的启动方式有：format、regular、upgrade、rollback、finalize、importCheckpoint六种，DataNode的启动方式有：regular、rollback两种；正常的启动都是regular方式，NameNode节点一定要在其它的任何DataNode节点之前启动，而且，在NameNode节点启动之后，其它的DataNode也不能马上就启动。NameNode启动步骤如下：启动RPCServer；读取fsimage文件，读取editlog文件，并进行合并，加载FSImage到内存，开启Server远程调用服务；进入安全模式，等待DataNode节点注册；统计DataNode节点上报的BlockReport，一定时间间隔没有新的注册和报告，就离开安全模式，开始服务；NameNode的启动流程如下：DataNode注册HDFS启动时，DataNode节点要向NameNode节点注册，一是告诉NameNode节点自己提供服务的网络地址端口，二是获取NameNode节点对自己的管理与控制。NameNode节点作为中心服务器要来收集所有的DataNode的当前工作情况，并以此来负责整个集群的负载均衡与任务的合理安排调度。DataNode节点通过调用专门的协议来向NameNode节点进行注册，发送数据传输/交换的服务地址端口，DataNode节点的存储器全局编号，查询DataNode节点当前状态信息的端口号，DataNode节点提供ClientDatanodeProtocol服务端口号这4种信息。NameNode接受到注册信息后的处理步骤如下：验证DataNode的版本是否一致；检查DataNode是否允许添加到HDFS集群中；将DataNode的描述信息和它对应的storageID做一个映射并保存起来；注册信息作为一次心跳被记录；该DataNode节点被加入到heartbeats集合中，NameNode实时监测该DataNode节点当前是否存活；在DataNode节点注册成功之后，DataNode会将在启动时，扫描其保存在dfs.data.dir所配置的目录下所保存的所有文件块，组织成Blockreport发送给NameNode，NameNode在接收到一个datanode的blockReport后，将这些接收到的blocks插入到BlocksMap表中，NameNode从report中获知当前report上来的是哪个DataNode的块信息,此后，DataNode定期的向NameNode节点发送心跳包，来告诉它自己当前工作是正常的。在NameNode节点有一个后台工作线程会定期的检测哪儿数据节点没有按时发送心跳包，对于那些没有按时发送心跳包的数据节点就认为它们是不可用的，并清除与它们相关的信息。DataNode注册的流入如下图所示：心跳连接分布式的架构中，心跳连接（Heartbeat）有着至关重要的作用，系统通过Heartbeat维持着master和slave之间，或者slave与slave之间的关系，让master了解slave的状态，让slave从master处获取最新命令，或者让各个slave了解其他slave的状态。在HDFS中，Datanode通过定期的向Namenode发送心跳，告诉当前Datanode的状态信息，顺便告诉Namenode自己还活着，而Namenode通过对Datanode的心跳的答复发送一些命令信息。HDFS中NameNode接收到DataNode的Heartbeat后的处理步骤如下：首先对DataNode的身份进行检查，版本信息，注册信息；更新NameNode中关于该DataNode的状态信息，比如总空间，使用空间，空闲空间等等；查询该DataNode相应的BLOCK的状态，生成对DataNode的命令列表，比如删除损坏BLOCK，增加副本个数不够的block等等；检查当前的分布式更新状态；将生成的命令反馈给相应的DataNode；Heartbeat处理完毕；写入文件HDFS作为面向网络服务的存储系统，是基于网络I/O数据流的文件操作，不同于通常的文件I/O数据流操作，在HDFS中，写入文件涉及到3个方面：写入客户端、NameNode和DataNode，写入的流程示意图如下：写入步骤如下：客户端通过调用文件系统API的Create方法来请求创建文件；通过对namenode发出rpc请求，在namenode的namespace里面创建一个新的文件，但是，这时候并不关联任何的块。Namenode进行很多检查来保证不存在要创建的文件已经存在于文件系统中，还有检查是否有相应的权限来创建文件；客户端开始写数据。开发库会将文件切分成多个包packets，并在内部以中间队列（dataqueue）的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储副本（replicas）的合适的datanodes列表，列表的大小根据在Namenode中对replication副本数的设置而定。这些DataNodes组成一个流水线（PipeLine），开发库把packet以流的方式写入第一个datanode，该datanode把该packet存储之后，再将其传递给在此pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。最后一个datanode成功存储之后会返回一个ackpacket，在pipeline里传递至客户端，在客户端的开发库内部维护着"ackqueue"，成功收到datanode返回的ackpacket后会从"ackqueue"移除相应的packet。如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持副本（replicas）设定的数量。读取文件在HDFS中文件是分块存储的，每一个块还有多个备份，同时不同的块的备份被存在不同的DataNode节点上，读取HDFS中的一个文件的时候，必须搞清楚这个文件由哪些块组成，这个操作就涉及到对NameNode的访问，因为NameNode存储了文件-块序列的映射信息，客户端通过映射信息得到实际数据的存储位置，然后与DataNode进行交互执行文件数据的读取操作。读取的流程示意图如下：读取的步骤如下：客户端通过用调用文件系统API的Create方法来请求打开文件，NameNode会视情况返回文件的部分或者全部数据块列表；对于每一个数据块，NameNode节点返回保存数据块的数据节点的地址；开发库返回网络数据流给客户端，用来读取数据。客户端调用数据流的read()函数开始读取数据。数据流连接保存此文件第一个数据块的最近的数据节点。Data从数据节点读到客户端;当此数据块读取完毕时，数据流关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点;当读取完列表的Block后，且文件读取还没有结束，客户端开发库会继续向NameNode获取下一批的Block列表；当客户端读取完毕数据的时候，调用close函数;在读取数据的过程中，读取完一个Block都会CheckSum验证，如果读取块验证失败，客户端会通知NameNode，尝试连接包含此数据块的下一个数据节点；如果客户端在与DataNode通信出现错误，则尝试连接包含此数据块的下一个数据节点;失败的数据节点将被记录，以后不再连接；删除文件用户或者应用删除某个文件，这个文件并没有立刻从HDFS中删除。相反，HDFS将这个文件重命名，并转移到/trash目录。当文件还在/trash目录时，该文件可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间，Namenode就会将该文件从namespace中删除。文件的删除，也将释放关联该文件的数据块。数据校验HDFS中的数据块有可能是损坏的，这个损坏可能是由于Datanode的存储设备错误、网络错误或者软件bug造成的，HDFS为了保证数据的可靠性，在数据实际存储之前都会校验数据的CheckSum，当客户端通过流水线写入文件到DataNode，最后一个DataNode会负责检查CheckSum，当客户端读取文件时，也会将下载的块的校验和与DataNode上的校验和进行比较。因为HDFS保存有同一个block的多个备份,所以它可以用好的副本来替换损坏的数据副本。如果某个客户端在读取数据时检测到数据错误,它会向NameNode上报信息告知具体的badblock还有DataNode，NameNode会把指定的block标记为"corrupt",之后的客户端就不会再被定位到此block,此block也不会再被复制到其它DataNode上，之后NameNode会调度一个此block的正常副本,以保证负载平衡，这之后,损坏的block副本会被删除。HDFS测试与分析测试目的测试HDFS的IO性能,高吞吐量,高可靠性，并对比与FTP传输方式进行性能分析。测试环境配置项详细HDFS测试集群配置项Hadoop0.23虚拟机OracleVMVirtualBox4.0.8CPU：1CPU内存：1024MB硬盘：30GB网卡：100MbpsOS:RedHatEnterpriseServer6.1(Kernel2.63.32-131.0.15.el6.i686)节点设置NameNode×1；DataNode×8，因为虚拟机缘故，网卡全部为100M；NameNode(80)DataNode1（81）DataNode2（82）DataNode3（83）DataNode4（84）DataNode5（85）DataNode6（86）DataNode7（87）DataNode8（88）HDFS设置副本数=3BlockSize=64MB（128MB）FTP测试服务器配置项FTP站点Internet信息服务(IIS)管理器

MicrosoftCorporation版本:6.0虚拟机OracleVMVirtualBox4.0.8CPU：1CPU内存：1024MB硬盘：30GB网卡：100MbpsOS:windowsserver2003测试客户端A类：网卡100MbpsB类：网卡1Gbps测试/监控工具集群端MRTG(MultiRouterTrafficGrapher)测试客户端IOMeterFTP客户端CuteFTP8Professional备注8bps=1Byte/s1Gbps=128MB/s100Mbps=12.8MB/S以下所有的测试数据网络吞吐量单位均为MB因为测试的时候存在硬件条件等资源的不足，故在对高并发的测试结果仅提供方向性的指导，如果需要更加精确的数据则需要更加复杂和大范围的测试测试环境网络拓扑图如下：测试度量DataNode个数：8测试样本文件大小：32MB、256MB、512MB、1GB读并发数:1、4写并发数:1最大客户端数:2测试结果与分析写入文件测试测试（1）在8台DataNode，BlockSize=64MB的情况下，在单台Windows客户端通过调用HDFSAPI，分别写入32MB、256MB、512MB、1GB固定大小的文件。我们记录下写入不同文件所花费的时间。（2）一台FTP服务器，配置使用默认配置，上传工具使用CuteFTP8Professional，分别写入32MB、256MB、512MB、1GB固定大小的文件。我们记录下写入不同文件所花费的时间。HDFS与FTP写入文件时间对比由上图可以看出，在各种大小不同文件的写入时间对比上，可以看出HDFS相对于FTP的写入效率要低一点，所以相对于FTP方式来说，HDFS在文件的写入效率上不占优势，这也符合之前我们HDFS的研究结论，因为文件通过客户端上传给HDFS后，还需要对文件进行分块、复制备份等操作，不如FTP处理方式单一，在一定程度上对损耗了文件的写入性能。单客户端读取文件测试（1）在8台DataNode，BlockSize=64MB的情况下，在单台Windows客户端通过调用HDFSAPI，分别读取32MB、256MB、512MB、1GB大小的文件，我们记录整个过程所花费的时间。（2）一台FTP服务器，配置使用默认配置，在单台客户端的情况下，下载工具使用CuteFTP8Professional，分别读取32MB、256MB、512MB、1GB大小的文件，我们记录整个过程所花费的时间。（3）HDFS与FTP读取花费时间对比从上图中，我们可以得出这样的结论，在单台客户端的读取情况下，HDFS的时间花费少于FTP文件共享的方式，并且随着读取文件的加大，HDFS的优势越明显文件大小1GB512MB256MB32MBFTP(MB/S)99911HDFS(MB/S)12121011他们读取文件的平均速度上来看，HDFS更加接近于服务器的网卡上行速率(12.5MB/S)，和客户端的网卡下行速度(12.5MB/S)，表明HDFS在文件读取的时候更加充分利用了网络IO。多客户端读取文件测试上面我们通过单个客户端，没有并发的情况下，进行了写入和读取效率测试。那么在多客户端并发访问的情况下，会发生什么情况呢？下面的测试就是，在多客户端读取文件的情况下，测试HDFS和FTP方式是否能达到客户端的IO最大值，及多并发的情况下，网络io的使用率HDFS客户端=4，文件大小分别32MB，256MB，512MB，1GB，取每个客户端读取同样大小文件花费时间的平均值FTP客户端=4，文件大小分别32MB，256MB，512MB，1GB，取每个客户端读取同样大小文件花费时间的平均值Hdfs在4个客户端的情况下hdfs花费的时间比FTP花费的时间要少的多，并且随文件的增大这HDFS读取文件的优势越加明显。接下来我们再从客户端文件下载速率分析一下，HDFS与FTP之间的性能差别，究竟有多大。我们就拿1G文件的读取速率来进行对比。A、B、C、D是4台客户端的编号。分析从以上的测试结果，可以看出:1、在客户端并发读取文件的情况下，HDFS方式的性能表现远远超过FTP方式。2、FTP每台传输速度速率比较平均，总带宽使用为9.28MB/S（4台客户端的带宽之和），这是因为每台客户端读取文件的时候都是访问的同一台FTP服务器所以，FTP服务器的带宽（出口带宽是100MB/S）成了客户端读取速度的最大障碍。3、HDFS的数据吞吐量为37.81MB/S37.81=10.237.81=10.22+8.57+9.35+9.67理论值为50MB/s=12.5MB/s×4同时，从集群中各台机器上通过MRTG采集的网络输入/输出数据，可以看出，部分DataNode会达到当前网络的最大速率（如：DataNode2、DataNode4、DataNode6）。针对HDFS的分块策略对文件读取速度的影响，我们又通过实验验证了不同的分块大小对HDFS读取速度的影响程度。客户端=4，文件大小=1GB，BlockSize=128MB，取每个客户端读取时间为了尽可能的避免2个客户端同时读取DataNode的情况，通过调整配置，将分块大小设置为128MB，测试文件样本为1GB大小文件，这样，文件将被拆分成8块，与DataNode的数量相同，这样在同一顺序下，同时两台客户端同时访问一台DataNode的几率最小，模拟的读取效果如下图：小文件读取测试从前面的研究中（见3.1.5章），我们得出这么这么一个结论，“HDFS倾向于处理大文件”。但是我们实际应用中，可能会要求用分布式文件系统来存储海量的小文件，于是我们又设计了512KB，1MB，1.5MB，2MB四个小文件数据样本，进行了单客户端文件读取测试，用于测试HDFS和FTP相比在读取小文件上的性能究竟如何。我们将HDFS的blocksize为1MB。为了得到更加精确的数据采用批量下载采用文件夹得方式，分别读取文件夹下的所有文件；ftp直接读取，HDFS通过调用API对指定文件夹下的文件进行遍历读取的方式，其中：采用文件夹得方式，分别读取文件夹下的所有文件；ftp直接读取，HDFS通过调用API对指定文件夹下的文件进行遍历读取（1）40个512KB文件（2）10个1MB文件（3）10个1.5MB文件（4）10个2MB文件进行批量下载，每个文件的平均下载时间为总时间除以文件个数。测试结果如下：从这个图中我们可以看出，HDFS在1.5MB以下的文件的时候相对于FTP读取相同的文件大小花费的时间要多一些，但是在1.5MB之后花费的时间开始比FTP少；在文件较小的时候网络IO的使用效率表现不明显，在数据量加大的情况下，越显明显，就好比100Mbps的网络和1Gbps的网络传1Mb的文件一样，在时间上感觉不到明显的差距，而在文件较小的时候HDFS的服务器NameNode的响应时间相对于FTP较长，并且随着文件数量的增加这一现象越显明显(我们这里所说的增加是以万为单位，因为所有的文件路径都是放在NameNode的内存中，文件越多，占用的内存越大反应越慢)。可靠性测试从前面的研究中可以的得出“HDFS可靠性和性能主要通过数据块的副本来实现”（见3.1.5章），在单一的DataNode出现故障不能服务时，NameNode会协调其他存储了相同数据副本的DataNode来提供剩余的数据，所以可靠性测试的主要方式是观察在BlockSize为64M，备份数量为3的情况下，不同大小的文件在上传后在HDFS上的数据块分布情况。如果数据块（Block）分布均匀的话，HDFS就能提供理论上的高可靠性，同时网络带宽也能得到更好的利用。我们选择的数据样本为，1GB、512MB、128MB、32MB文件，通过观察的发现Block在8台DataNode上的分布情况如下：从以上图表，可以看出文件越大，经过64MB分块划分后，Block数量也越多，在整个HDFS中的DataNode上也分布的越均匀。在实验中通过中断DataNode3上的网络连接，使其退出服务，而后经过重新连接，加入服务后，会发现原来在DataNode3上的Block在整个副本数设置为3的集群中存在4个副本，这是因为HDFS集群因某台DataNode退役，造成数据块副本数不足，为了保证可靠性，HDFS内部协调所有DataNode，保证集群中任一Block的副本数都维持在设置的安全数目。测试总结从以上实验结果和分项分析，总结如下：HDFS的读取性能明显优于写入性能，写入过程因为要经过分布式处理以及数据冗余的处理，写入过程较读取过程复杂，对资源和性能的消耗也要多一些，所以HDFS集群更适合数据“一次写入，多次读取“的情况；在读取的时候，HDFS在响应客户端请求时，会衡量集群的负载情况，经过均衡处理后，返回最合适的DataNode列表给客户端，尽可能减少访问“热点“的出现；HDFS的读取速度受分块和DataNode数量的影响，所以应该根据实际的DataNode规模大小以及所需存储文件在多数情况下大小，选择设置分块的大小进行调整和优化；在HDFS中的一个DataNode失效退役或某一数据块损坏后，HDFS为了可靠性考虑，DataNode通过心跳连接，发布状态信息之后，HDFS集群会收集并自动检查每个分块的复本数和有效性，在集群中，当正常的复本数小于设置的副本数时，HDFS将自动进行协同调整，将在其他DataNode上正常的副本复制到其他正常工作的DataNode上，保持整个集群的稳定性和可靠性；HDFS的不足以及改进策略HDFS作为目前比较优秀的分布式存储系统，在具有高性能、高可靠性、高可用性、高可扩展性的优点的同时，还存在了一些不足，比如：为了简化数据的一致性问题，目前HDFS不支持文件的添加；不支持数据自动均衡，即当某个Datanode节点上的空闲空间低于特定的临界点，那么就会启动一个计划自动地将数据从一个Datanode搬移到空闲的Datanode。当对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并分布到集群中以满足应用的要求；HDFS的下载策略是顺序下载数据块，不支持断点续传；目前不支持快照，即当数据损坏时，无法恢复到过去某一个正确的时间点；不适合大量小文件读取，HDFS中文件的元数据信息需要占用NameNode的150字节的运行内存和存储空间，过多的小文件会大量消耗NameNode的存储空间和运行内存,而且因为块太多，块的寻址时间很可能比数据传输时间还要长。并行读取其中，针对HDFS顺序下载的策略对性能的影响较大并且有改进的空间，HDFS客户端下载文件时，会从NameNode获取所有数据块的下载地址，当客户端下载某个数据块时，只是与存在有该数据块的一个DataNode建立连接并下载，如果一个下载概率大得热点文件的数据块存储在低带宽的DataNode上，显然，顺序下载的策略会导致DataNode的负载不均衡，尝试通过与所有存储该数据块的DataNode建立连接，使用一种并行下载的策略从这些DataNode上下载，以提高数据块的下载效率，并可以进一步实现文件的断点续传。大致思路如下：获得HDFS的BlockSize分块大小；通过调用NameNode方法，获取下载文件大小fileLength；将下载文件大小，按照BlockSize拆分成Round（fileLength/BlockSize）+1个数组，数组记录每个分块的开始位置和结束位置[StartPos,EndPos];在本地创建一个FileLength大小的空文件；通过多线程，并行下载每个Block，每个块在空文件指定的StartPos位置上进行写入；压缩处理通过将原始数据进行压缩后进行写入，读出数据时进行解压缩，将会节省大量的磁盘空间和网络带宽。数据压缩大致的如下两种策略：在客户端在写入文件的时候进行压缩，读取文件的时候进行解压缩操作；在DataNode接受到block后，对block文件进行压缩，发送Block时，打开Block时进行解压；其中，在客户端进行压缩的策略给HDFS带来的额外开销最小，因为压缩/解压缩处理的最大开销是CPU的开销，而将CPU的开销分散在各个客户端上，对HDFS整体的影响几乎没有。小文件优化对于小文件的处理可以通过以下几种方案进行优化：小文件打包归档Hadoop提供了HarFile、SequenceFile、MapFile三种方式对小文件进行归档处理，原理就是将多个小文件打包合并成一个大文件，打包后的文件由索引和存储两大部分组成，索引部分记录了原有的目录结构和文件状态，小文件和文件包通过构建的索引维护映射关系。HarFile、SequenceFile、MapFile结构示意图如下：文件名映射地址通过将文件名映射到文件的物理地址，简化文件访问流程，提高读写效率，目前，淘宝文件系统(TFS-TaobaoFileSystem)就是采用这种方式以满足淘宝网内部各项应用中的海量小文件的处理。在TFS中，将大量的小文件合并成为一个大文件，这个大文件称为块(Block),DataServer进程会给Block中的每个文件分配一个ID(FileID，该ID在每个Block中唯一)，并将每个文件在Block中的信息存放在和Block对应的Index文件中。TFS不像HDS那样NameNode需要存储文件名与Blockid，Blockid与DataNode的映射，而只需要存放<filename,blockid,offset,length>的映射以及<blockid,datanode>的映射。这样一来元数据信息就会减少很多，从而解决HDFS的NameNode的瓶颈问题。TFS的文件名由块号和文件号通过某种对应关系组成，最大长度为18字节。文件名固定以T开始，第二字节为该集群的编号(可以在配置项中指定，取值范围1~9)。余下的字节由BlockID和FileID通过一定的编码方式得到。文件名由客户端程序进行编码和解码，它映射方式如下图：TFS客户程序在读文件的时候通过将文件名转换为BlockID和FileID信息，然后可以在NameServer取得该块所在DataServer的信息（如果客户端有该Block与DataServer的缓存，则直接从缓存中取），然后与DataServer进行读取操作。TFS的整个读取过程如下图所示：中央节点水平扩展因为HDFS处理海量小文件的主要瓶颈在于NameNode，所以采用联邦化的体系结构，将NameNode进行水平扩展，并将BlockSize调小，增加NameNode数量，形成多个逻辑分区卷，减少块的寻址时间，关于联邦化体系结构的详细内容请参考《 联邦化体系结构》。分布式存储系统在区域影像中心的应用构想随着国际国内区域医疗信息整合和共享系统的建设和不断发展，区域化医疗影像中心作为区域医疗临床信息共享系统的重要组成部分，对区域医疗信息系统的建设起着举足轻重的作用，区域化医疗影像中心的主要建设目标，是实现区域内各个集团医院、医院、社区卫生服务站之间，医疗影像数据的共享、交换、调阅和存储。其中，分布在各医院的影像数据源，产生的数据量巨大，一家市级医院每日的数据生成量以GB计，一年以TB计算，如果采用专用的存储设备势必造成数据中心造价昂贵，维护成本巨大的问题，分布式存储系统一次写入，多次读取效率高的特性，可以很大程度满足区域化医疗影像中心系统海量数据存储以及高性能、高吞吐量的数据传输的应用要求。影像中心总体建设目标、范围与考量因素区域影像数据中心的总体建设目标主要体现在：区域内医疗机构的数字化医疗影像及报告的联网、存储、归档和互相调阅；逐步建立区域内全面数字化影像诊断系统；影像数据包括：CT、MR、DSA、RF、CR、病理、脑电图等影像检查的报告和图像；为了满足联网、存储、归档和互相调阅的目标要求，核心考量的因素有：网络带宽问题；海量数据存储量问题；整个架构的可扩展性；整个架构的高可用性；查询的统一性；数据特点及存储需求分析区域影像数据中心的主要数据来源是各个医院终端医疗影像设备产生的影像文件，影像文件少则几百KB，多则几十MB。相比其他医院信息系统（如HIS）而言，PACS系统的数据呈现专用数据格式、单个文件体积小、单位时间产生的数据量大等特点。综合考虑医疗影像数据存储和应用系统的需求，对区域影像数据中心存储的需求分析如下：大容量存储因为阅片和诊断的需要，对医疗影像图片的质量和精度有较高的要求，每张图片的容量从几百KB到几十MB不等，所以整个系统的存储容量非常巨大。高数据吞吐量因为数据中心面对大量的应用连接以及高容量的文件传输，不仅对网络的带宽和数据传输数量都有很高的要求;高可靠性和高可用性因为医疗影像数据中心作为整个区域医疗临床信息共享系统的关键应用，需要很高的可靠性和可用性保障；高可扩展性随着医疗影像数据中心的不断应用，对存储的需求量也会不断的增大，这就要求数据中心的存储系统可以方便可靠地在线扩展。传统存储方案面临的问题针对数据中心的数据特点及存储需求，传统的存储解决方案是采用存储区域网络（SAN-StorageAreaNetwork）来实现，其中又区分为FC-SAN（基于光纤通道的存储区域网络）和IP-SAN（基于TPC/IP的存储区域网络）。SAN通过专用的硬件实现高数据吞吐量、高I/O传输率，并通过磁盘阵列存储Raid实现高可靠性和高可用性。但是，针对医疗影像数据中心的建设，基于传统的网络存储设备方案面临以下几个问题：建设成本高区域医疗影像的数据量达到数百TB甚至PB级，采用传统存储架构（如FCSAN、IP_SAN、NAS等）的建造成本极高，而且维护复杂;传输带宽存在瓶颈即使是高性能的IP-SAN或FC-SAN，由于应用连接数量和文件数量的限制，其网络总带宽和处理能力也难以达到PB级别数据的处理和传输要求;扩展性差目前传统的网络存储设备的升级、扩容、数据迁移，过程复杂，成本高昂；针对以上几点问题，分布式的架构是比较合适的，分布式架构可以有效解决了中心化影像数据中心，建设成本和维护成本巨大（大型存储、高带宽网络、高性能服务器），传输带宽瓶颈、架构封闭，扩展困难，集成复杂的问题。分布式存储方案的优势分布式存储方案相对于传统网络存储方案具有以下优势：建设成本低分布式存储方案所构建的存储集群，运行于普通硬件（普通PC服务器+SATA硬盘）上，不需要购置昂贵的专用设备（SAN交换机+磁盘阵列+iSCSI硬盘），降低了投入成本，规避了投资风险；传统的网络存储方案需要配备专业人员进行维护，而且硬件和软件需要不断的更新换代，维护成本高昂，分布式存储的升级维护和故障处理简单，并且分布式存储的硬件更新和维护不会影响服务的正常使用；传输带宽高分布式存储方案在大型网站应用以及云存储方面的应用实践证明，分布式存储适用于大数据量和高并发访问的高性能的数据访问，并且分布式存储可以通过对存储集群规模的扩展提高总的传输带宽；扩展性高分布式存储方案能够实现海量数据的存储，具有良好的在线扩容能力，当存储容量不足时，可以扩展集群节点的存储空间容量或集群节点数量，而不必中断业务的运行，并且通过中心节点的水平扩展，优化存取性能；结合IHEXDS-I的思考区域化医疗影像中心方案需要采用集中存储和发布各医院机构终端的医疗影像的方式到区域医疗影像共享交换的目的，大体流程如下：各个医疗机构终端的影像设备或者信息系统直接将影像发送到数据中心；各个医疗机构的阅片工作站通过数据中心查询/提取需要的影像，数据中心提供整个区域影像的注册、发布、查询和提取服务；集成医疗环境（IntegrationHealthCareEnterprise，IHE）在2004年颁布了跨企业级文档共享技术框架（Cross-EnterpriseDocumentSharing,XDS），IHE根据影像信息共享交换的需求，在XDS技术框架的基础上，于2005年提出了XDS-I技术框架，IHEXDS-I（IntegrationHealthCareEnterpriseCross-EnterpriseDocumentSharing）-区域影像共享交换技术框架的核心思想就是分布式存储和集中式影像文档索引，这种架构可以减轻数据中心建设成本和系统压力，并能充分使用医疗机构原有的影像系统。基于IHEXDS-I技术框架的医院文档共享交换示意图如下：从IHEXDS-I的总体技术框架可以看出，中心化体系分布式架构设计（如HDFS的架构）是