云计算大数据处理中的关键技术—分布式文件存储

分布式文件存储是云存储的一项关键技术，我们将从分布式文件系统存储的特点和其中的关键技术入手，再结合一个典型的分布式文件系统GFS来全面介绍。

文件存储系统可提供通用的文件访问接口，如POSIX、NFS、CIFS、FTP等，实现文件与目录操作、文件访问、文件访问控制等功能。目前的分布式文件系统存储的实现有软硬件一体和软硬件分离两种方式，主要通过NAS虚拟化，或者基于x86硬件集群和分布式文件系统集成在一起，以实现海量非结构化数据处理能力。

软硬件一体方式的实现基于X86硬件，利用专有的、定制设计的硬件组件，与分布式文件系统集成在一起，以实现目标设计的性能和可靠性目标，产品代表有Isilon、IBM SONAS GPFS。软硬件分离方式的实现基于开源分布式文件系统对外提供弹性存储资源，可采用标准PC服务器硬件，Hadoop的HDFS就是典型开源分布式文件系统。

（一）分布式文件存储的概念

1.分布式文件系统的概念

说到分布式文件系统，不得不先提及文件系统。众所周知，文件系统是操作系统的一个重要组成部分，通过对操作系统所管理的存储空间的抽象，向用户提供统一的、对象化的访问接口，屏蔽对物理设备的直接操作和资源管理。如果没有文件系统，让用户直接与计算机存储硬件交互，这种方式的效率和可行性简直令人难以想象。

根据计算环境和所提供功能的不同，文件系统可划分为四个层次，从低到高依次是：单处理器单用户的本地文件系统，如DOS的文件系统；多处理器单用户的本地文件系统，如OS/2的文件系统；多处理器多用户的本地文件系统，如UNIX的本地文件系统；多处理器多用户的分布式文件系统，如Lustre文件系统。

本地文件系统（Local File System）是指文件系统管理的物理存储资源直接连接在本地节点上，处理器通过系统总线可以直接访问。分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于C/S模式。一个典型的分布式文件系统服务网络可能包括多个可以同时供多个用户访问的服务器。另外，网络节点的对等特性允许一些系统扮演客户机和服务器的双重角色。也就是说，一个节点既可以是一个服务器节点，同时也可以是一个客户机节点。这种概念在P2P网络中是常见的。举个例子来说，用户可以“发表”一个允许其他客户机访问的目录，这时候，如果有其他用户访问这个目录，那么这个目录对客户机来说就像一个服务器终端，可以像访问本地文件系统一样访问文件目录。

2.分布式文件系统存储的特点

在前面介绍分布式存储技术时提到了分布式存储系统的需求，那么分布式文件存储实现的时候就应该充分考虑这些需求，分布式文件存储具有以下特点。

（1）扩展能力

毫无疑问，扩展能力是一个分布式文件存储最重要的特点。分布式文件系统存储中元数据管理一般是扩展的重要问题，GFS采用元数据中心化管理，然后通过Client暂存数据分布来减小元数据的访问压力。GlusterFS采用无中心化管理，在客户端采用一定的算法来对数据进行定位和获取。

（2）高可用性

在分布式文件系统中，高可用性包括两层含义，一是整个文件系统的可用性，二是数据的完整和一致性。整个文件系统的可用性是分布式系统的设计问题，类似于NoSQL集群的设计，比如中心分布式系统的Master服务器、网络分区等。数据完整性则通过文件的镜像和文件自动修复等手段来解决，另外，部分文件系统如GlusterFS可以依赖底层的本地文件系统提供一定支持。

（3）协议和接口

分布式文件系统提供给应用的接口多种多样，如HTTPRestFul接口、NFS接口、FTP等P0SIX标准协议，另外通常会有自己的专用接口。

（4）弹性存储

可以根据业务需要灵活地增加或缩减数据存储以及增删存储池中的资源，而不需要中断系统运行。弹性存储的最大挑战是减小或增加资源时的数据震荡问题。

（5）压缩、加密、去重、缓存和存储配额

这些功能的提供往往考验一个分布式文件系统是否具有可扩展性，一个分布式文件系统如果能方便地进行功能的添加而不影响总体的性能，那么这个文件系统就是良好的设计。这点GlusterFS就做得非常好，它利用类似GNU/Hurd的堆栈式设计，可以让额外的此类功能模块非常方便地增加。另外压缩在一定程度上减少了文件传输时的带宽消耗。加密为文件和文件夹提供安全保障。

（二）分布式文件存储实例

2003年，Google公开了他们的分布式文件系统的设计思想，引起了业内轰动。Google File System是一个可扩展的分布式文件系统，用于大型的、分布式的、对海量数据进行访问的应用。它运行于廉价的普通硬件上，但提供了容错复制功能，可以给大量的用户提供总体性能较高的可靠服务。

1.GFS的设计观点

GFS与过去的分布式文件系统有很多相同的目标，比如性能、可扩展性、可靠性、可用性，但GFS的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。

GFS与以往的文件系统的不同的观点如下。

（1）组件错误（包括存储设备或存储节点的故障）不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统由成百上千个用于存储的普通计算机构成，而这些机器由廉价的普通部件组成，但却面向众多的数据访问者。俗话说得好，一分钱一分货，廉价部件用得多了，质量就堪忧了，因此一些机器随时都有可能无法工作甚至还有无法恢复的可能。所以实时监控、错误检测、容错、自动恢复对系统来说必不可少。

（2）按照传统的标准，文件都非常大。长度达几个GB的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理快速增长的、包含数以万计对象的数据集时，即使底层文件系统提供支持，我们也很难管理成千上万的KB规模的文件块。因此在设计中，操作的参数、块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的件也必须支持，但不必优化。

（3）大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一个大仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。由于这些对大型文件的访问方式，添加操作成为了性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。

（4）工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百KB，通常达1MB和更多。根据局部性原理，来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。性能敏感的应用程序通常将对少量数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回地读。

（5）工作量还包含许多对大量数据进行的连续的向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。

2.GFS的设计策略

在了解了GFS与以往文件系统的不同观点之后，我们接下来重点分析它的设计策略。由于GFS最初是用来存储大量的网页的，而且这些数据一般都是一次写入多次读取的，那么在设计文件系统的时候就要特别考虑该如何进行设计了，主要体现在以下几个方面。

（1）一个GFS集群由一个Master和大量的ChunkServer构成，并被许多客户（Client）访问。文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunk-handle标识，chunk-handle是在块创建时由Master分配的。

（2）出于可靠性考虑，每一个块被复制到多个ChunkServer上。默认情况下，保存3个副本，但这可以由用户指定。这些副本在Linux文件系统上作为本地文件存储。

（3）每个GFS集群只有一个Master，维护文件系统所有的元数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约（lease）管理、孤儿块的垃圾收集、ChunkServer间的块迁移。

（4）Master定期通过HeartBeat消息与每一个ChunkServer通信，给ChunkServer传递指令并收集它的状态。

（5）客户和ChunkServer都不缓存文件数据。因为用户缓存数据几乎没有什么作用，这是由于数据太多或工作集太大而无法缓存。不缓存数据简化了客户程序和整个系统，因为不必考虑缓存的一致性问题。但用户缓存元数据（metadata）。此外，ChunkServer也不必缓存文件，因为块是作为本地文件存储的。依靠Linux本身的缓存Cache在内存中保存数据。

3.GFS的组件

GFS的组件主要有两个：Master和ChunkServer。

（1）Master(www.xing528.com)

Master的功能和作用如下。

1）保存文件/Chunk名字空间、访问控制信息、文件到块的映射以及块的当前位置，全内存操作（64字节每Chunk）。

2）Chunk租约管理、垃圾和孤儿Crunk回收、不同服务器间的Chunk迁移。

3）记录操作日志：操作日志包含了对metadata所做的修改的历史记录。它作为逻辑时间定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一、永久地被标识。

4）在多个远程机器备份Master数据。

5）设置Checkpoint，用于快速恢复。

（2）ChunkServer的一些特性

1）Chunk（数据块）的大小被固定为64MB，这个尺寸相对来说还是挺大的，这是因为较大的Chunk尺寸能够减少元数据访问的开销，减少同Master的交互。

2）Chunk位置信息并不是一成不变的，可能会由于系统的负载均衡、机器节点的增减而动态改变。

块规模是设计中的一个关键参数，GFS选择的是64MB，这比一般的文件系统的块规模要大得多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。块规模较大的好处如下。

减少Client和Master之间的交互。在开始读取文件之前，客户端需要向Master请求块位置信息，对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读操作也可以很方便地为一个规模达几个TB的工作集缓存块位置信息。

Client在一个给定的块上很可能执行多个操作，和一个ChunkServer保持较长时间的TCP连接可以减少网络负载。

这减少了Master上保存的元数据（metadata）的规模，从而使得可以将metadata放在内存中。这又会带来一些别的好处。

但是块规模较大也有不利的一面：

Chunk较大可能产生内部碎片。

同一个Chunk中存在许多小文件可能产生访问热点，一个小文件可能只包含一个块，如果很多Client访问该文件的话，存储这些块的ChunkServer将成为访问的热点。但在实际应用中，应用程序通常顺序地读包含多个块的文件，所以这不是一个主要问题。

（三）GFS的容错和诊断

GFS为文件系统提供了很高的容错能力，主要体现在两个方面：高可靠性和数据完整性。

1.高可靠性

（1）快速恢复

不管如何终止服务，Master和数据块服务器都会在几秒内恢复状态和运行。实际上，并不对正常终止和不正常终止进行区分，服务器进程都会被切断而终止。客户机和其他的服务器会经历一个小小的中断，然后它们的特定请求超时，重新连接重启的服务器，重新请求。

（2）数据块备份

每个数据块（Chunk）都会被备份到不同机架的不同服务器上，通常是每个数据块都有3个副本。对不同的名字空间，用户可以设置不同的备份级别。在数据块服务器掉线或数据被破坏时，Master会按照需要来复制数据块。

（3）Master备份

为确保可靠性，Master的状态、操作记录和检查点（checkpoint）都在多台机器上进行了备份。一个操作只有在数据块服务器硬盘上刷新并被记录在Master和其备份上之后才算是成功的。如果Master或硬盘失败，系统监视器会发现并通过改变域名启动它的一个备份机，而客户机仅仅使用规范的名称来访问，并不会发现Master的改变。

2.数据完整性

每个数据块服务器都利用校验和来检验存储数据的完整性。原因：每个服务器随时都有发生崩溃的可能性，并且在两个服务器间比较数据块也是不现实的，同时，在两台服务器间复制数据并不能保证数据的一致性。

每个Chunk按64kB的大小分成块，每个块有32位的校验和，校验和日志存储在一起，和用户数据分开。在读数据时，服务器首先检查与被读内容相关部分的校验和，因此，服务器不会传播错误的数据。如果所检查的内容和校验和不符，服务器就会给数据请求者返回一个错误的信息，并把这个情况报告给Master。客户机就会读其他的服务器来获取数据，而Master则会从其他的副本来复制数据，等到一个新的副本完成时，Master就会通知报告错误的服务器删除出错的数据块。

附加写数据时的校验和计算优化了，因为这是主要的写操作。因此只是更新增加部分的校验和，即使末尾部分的校验和数据已被损坏而没有检查出来，新的校验和与数据会不相符，这种冲突在下次使用时将会被检查出来。

相反，如果是覆盖现有数据的写，在写以前，我们必须检查第一和最后一个数据块，然后才能执行写操作，最后计算和记录校验和。如果在覆盖以前不先检查首位数据块，计算出的校验和则会因为没被覆盖的数据而产生错误。

在空闲时间，服务器会检查不活跃的数据块的校验和，这样可以检查出不经常读的数据的错误。一旦错误被检查出来，服务器会复制一个正确的数据块来代替错误的。

（四）GFS的扩展性能

对于分布式文件系统存储来说，系统的可扩展性是系统设计好坏的一个非常关键的指标。由于GFS采用单一的Master的设计结构，因此扩展主要在于ChunkServer节点的加入，每当有ChunkServer加入的时候Master会询问其所拥有的块的情况，而Master在每次启动的时候也会主动询问所有ChunkServer的情况。

GFS单一Master的设计方式使得系统管理简单、方便，但也有不利的一面：随着系统规模的扩大，单一Master是否会成为瓶颈？这看起来是限制系统可扩展性和可靠性的一个缺陷，因为系统的最大存储容量和正常工作时间受制于主服务器的容量和正常工作时间，也因为它要将所有的元数据进行编制，并且因为几乎所有的动作和请求都经过它。

但是Google的工程师们解释说：元数据是非常紧凑的，仅仅只有数KB到数MB的大小，并且主服务器通常是网络上性能最好的节点之一；至于可靠性，通常有一个“影子”主服务器作为主服务器的镜像，一旦主服务器失败它将接替工作。另外，主服务器极少成为瓶颈，因为客户端仅仅取得元数据，然后会将它们缓存起来；随后的交互工作直接与ChunkServer进行。同样，使用单个主服务器可以大幅度地降低软件的复杂性，如果有多个主服务器，软件将变得复杂才能够保证数据完整性、自动操作、负载均衡和安全性。

根据分布式文件系统存储的特点，并结合上面GFS的实例，我们总结一下分布式文件系统存储在设计、实现时主要关注的几个方面。

设计特点：分布式能力、性能、容灾、维护和扩展、成本。

分布式文件系统主要关键技术：全局名字空间、缓存一致性、安全性、可用性、可扩展性。

其他关键技术：文件系统的快照和备份技术、热点文件处理技术、元数据集群的负载平衡技术、分布式文件系统的日志技术。