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

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