英语原文共 6 页
云存储中分布式文件系统的演变与分析：分析调查
摘要：大数据处理和云计算是近年来越来越受欢迎的两个重要关注点。由于数据产业的迅速增长，对数据的高效处理，存储检索，结构化和非结构化管理的需求，已经成为目前IT产业非常重要的问题之一。在本文中，我们研究了各种分布式文件系统的发展变化，探究了其优点和其在云计算应用中的限制。分布式文件系统是一个基于客户端-服务器的应用程序，其允许用户访问，处理和修改存储在远程服务器上的数据，就好像它们存在于本地系统上一样。
谷歌文件系统（GFS）是一种由谷歌开发，以满足其不断增长的大数据需求的专有的分布式文件系统，其利用商业的硬件（常见的普通硬件）管理大规模原始数据。受GFS的启发， 开源项目Hadoop分布式文件系统（HDFS）应运而生。它旨在统一化的存储大块数据集，并为应用中客户端的流式数据访问提供高带宽集。在本文中，我们详细描述了GFS和HDFS模型，并根据它们在不同环境中的属性和特征行为来比较这两个分布式文件系统。我们还讨论了几种技术优化和修改，以减少甚至避免这些文件系统的局限性。
关键词：云计算；GFS；HDFS；HBase
Ⅰ.介绍
高效的数据存储被认为是云计算和大数据领域研究中一个非常重要且不可或缺的部分[1,2]。由于数据产业，客户量，云计算的需求比例大幅上涨，我们在使用传统存储访问和修改大数据时无法提供与过去相同的效率和可扩展性[3]。面临的主要挑战包括可扩展性，稳定性，传输效率，数据传输量等[4]。因此，我们必须改进我们的技术和设计，以满足对高可扩展性和效率的日益增长的需求。例如，一种可行的解决方案是改进我们存储方法，使我们可以存储少于过去的数据和（用于大数据存储[1]，提取，安全和维护所需的）元数据[16] 。在根级别，我们可以认为所有数据存储技术和方法分类均为文件系统。文件系统用来定义文件控制逻辑，如何对其命名，如何进行存储，检索和修改[3]。文件系统使用此元数据[16]来存储和检索文件。元数据标签源的一些示例包括：
（i）创建或修改文件的日期和时间
（ii）大小和其他文件相关属性等。
目前，云计算领域中最流行的文件系统是分布式文件系统（DFS）。DFS因其灵活性和可扩展性而广受欢迎。云计算服务完全取决于其底层架构的文件系统的类型和灵活性。许多流行的文件系统都是针对特定领域的应用程序设计，例如商业分析，研究和实验数据存储。
Ⅱ.分布式文件系统
分布式文件系统（DFS）是一种基于客户端-服务器的应用程序[6]，它允许用户访问，处理或修改存储在远程服务器上的数据，就像它们存在于自己的系统上一样。当客户端访问文件时，服务器或主机为用户提供该请求文件的副本。在处理数据并将数据返回给服务器时，文件都会被缓存到用户的系统中[7]。在DFS中，存在多个可以由网络中的多个隔离用户一次访问的中央服务器存储文件。使用适当授权的权限，客户端可以访问这些文件。客户端能够以处理本地系统上相同的方式来处理这些文件。当客户端完成文件的处理，则会通过网络将其返回到存储原始文件或已更改的服务器，以供此后该用户或其他用户检索[7]。.DFS也使用不同命名的方案，以此、映射和保持位于不同非中央服务器中的文件的跟踪的。它根据分层文件管理系统安排其文件。DFS通过配置集中存储将相关的文档分发到不同客户端上。来自Sun Microsystems的NFS和来自Microsoft的DFS是分布式文件系统的一些常见示例[6]。DFS的广泛使用背后的原因是其通过导出文件系统可与多个客户同时高效便利的共享信息。系统必须完成的主要功能包括：数据一致，统一访问，可靠性，效率，性能，可管理性，可用性和安全性[7]。
A. Network file System–NFS
1984年，网络文件系统（NFS），最普遍的分布式文件系统由Sun Microsystems开发[8]。 它是最早使用的DFS之一，也经常使用。 NFS背后的思路很简单，但由于其简单性，它有很多限制。NFS旨在提供对存储在远程计算机上的单个逻辑存储卷的直接访问。基于NFS的服务器将本地文件系统进行共享，使其可被外部客户访问。然后，客户端可以直接访问它，就好像它是自己系统的本地硬盘的一部分一样。该模型最重要的优点之一是其透明度。因此用户不必知道该文件在远程存储的某个其他系统上的位置或其他相关细节。网络文件系统的局限性如下：
- 缺乏可靠性：NFS中的所有文件都驻留在单个计算机上，这意味着如果计算机出现故障（例如，由于电源故障，配置问题，硬件问题等），则会导致由机器提供给用户[8]的所有服务永久或临时终止。这些情况可能导致机器上存储的数据丢失。
- 瓶颈：在NFS中，如果大量客户端同时尝试从其系统访问其远程服务器的文件，则服务器很容易过载。机器的有限处理能力导致服务器在满足内任意客户端的请求时表现不佳。
因此，NFS在网络中的用户数量较少，网络规模小[8]的时候足够使用，但我们不能依赖NFS来满足日益增长的大规模数据的处理需求以及被大量用户访问的云存储服务。
B.安德鲁文件系统-AFS
在20世纪80年代，安德鲁文件系统（AFS）由卡内基梅隆大学的研究人员[9]引入，以缓解分布式文件系统之间的可扩展性问题。在AFS的初始版本中，整个请求的文件缓存在客户端的本地磁盘上，以提高服务器上同一文件的多个请求的性能。因此，（本地满足的）请求减少了该文件所在的服务器上的总体负载。但是，第一次访问未缓存的文件效率不高。如果文件未被修改，则使用本地缓存的文件来提高性能。AFS初始版本的限制如下：
- 高路径遍历时间：为了在客户端访问文件，一方面服务器必须遍历从主目录到文件位置的完整路径。另一方面，这种遍历相当占用服务器处理时间，而这个时间服务器本可以用来处理其他客户端请求。
- 高流量：在AFS中，客户端利用大量流量生成验证消息，以此形式检查文件是否已被修改[9]。此流量会降低网络中文件传输的效率。
为了改进AFS的初始版本[9]，已经引入了两个方向来改进AFS的可扩展性和性能;
- 文件标识符（FID）的使用：为了节省服务器在遍历文件位置路径时的CPU时间，引入了文件标识符（FID）。FID清楚地提到了服务器感兴趣的文件，从而减少了服务器上的负载。
- 使用回调函数：回调是由服务器执行的一个简单函数，它将文件修改通知给已缓存同一文件的未修改版本的所有客户端。因此，不再需要使用用于检查文件状态的常规验证消息。对比分析已在表I中描述。
C.谷歌文件系统-GFS
在20世纪80年代，虽然下一版AFS是一个很大的改进，但谷歌仍然面临着大数据存储和处理的挑战。2003年，他们提出了谷歌文件系统（GFS）[10]作为他们自己的大数据管理问题的解决方案。它是一个可扩展的分布式文件系统，旨在处理大型分布式数据密集型应用程序GFS的设计目标与许多分布式文件系统的目标相同。硬件故障，吞吐量限制和延迟类型实例等不同因素促使科学家设计DFS。在设计Google文件系统时，有一些假设[10]必须考虑：
- 经济硬件构建模块：GFS基于低商品硬件组件构建，非常容易出现故障。 因此，它应该有一个规则来定期监视自己，以检测并从其组件故障中恢复。
- 系统存储并处理大量大型文件。同时，还应支持小文件进行处理。但优先级依然是处理大量数据，即高吞吐量。
- 工作负载中需要考虑两种读取：
（i）大流媒体读取：单个操作几乎以MB或更多读取[11]。它假定来自同一客户端的连续请求通常从文件的连续区域读取。
（ii）小随机读取：它包括一个只读取几KB的随机查询。
- 工作负载主要包括大量顺序写入[11]，它将数据附加到文件。这些文件会自动更新回其数据节点以供将来参考。同时，支持随机位置的小型写入，但效率不高。
- 明确定义的语义：系统的语义必须有效地实现和定义良好，以使多个用户可以在同一文件上并发附加。
- 高持续带宽被认为比低延迟数据访问更受欢迎。GFS的建立是通过更多地优先处理高速数据块来构建的。
如图1所示，GFS集群由单个主节点和多个块服务器组成，一次可由多个客户端访问。它作为服务器进程在Linux机器上运行。在机器资源允许的情况下，很容易在同一台机器上运行块服务器和客户机，并且可靠性的下降是可接受的，这是由于执行片状应用程序代码造成的。文件进一步划分为多个固定大小的块，其中每个块由主节点管理。 所有块都作为文件存储在本地磁盘上以读取和写入数据。
为了（保证）可靠性，每个块都在多个Chunk服务器上重复。主服务器维护所有文件系统元数据。这包括通过将块与其位置映射来命名空间和访问控制信息。GFS管理管理问题，例如从各个块收集垃圾数据以及在操作块之间迁移。主服务器定期与Heartbeat消息中的每个Chunk服务器通信[10]，以便为其提供指令并收集块服务器的状态。当要执行与元数据相关的操作时，客户端将与主节点交互。客户端或块服务器中的任何一个都不会缓存文件数据。
D. Hadoop分布式文件系统-HDFS
受GFS的启发，Hadoop分布式文件系统（HDFS）是利用GFS的分布式文件系统设计理念开发的，该设计运行在廉价商品硬件上[15]。与其他分布式文件系统不同，HDFS[12]被认为是一种高度健壮的分布式文件系统。它采用低成本硬件设计，可以容纳大量数据并提供更方便的访问[17]。为了存储如此庞大的数据块，文件被存储在多台机器上。这些文件以冗余方式存储，以防止系统在机器发生故障时可能丢失数据。它还使应用程序可以进行并行处理[15]。
HDFS具有类似于NameNode和GFS架构的DataNode的主从架构[12]。集群由一个名称节点（如图2所示）组成，主节点管理文件系统的命名空间，并且监察客户端对文件的访问[13]。接着，我们有许多数据节点，通常是HDFS集群中的一个。
因此，HDFS展示了一个高度可扩展且容错的文件系统，它允许用户的数据有效地存储在文件中。在内部，文件进一步分为多个块。然后将这些块存储在一组DataNode上以增加数据的冗余[14]。该Name Node负责执行文件系统命名空间操作，例如打开，重命名和关闭文件或目录。块也可以保持块到数据节点的映射。DataNodes满足远程客户端的读/写请求。DataNodes还有助于按照NameNode到DataNode的指令执行块的创建，删除或复制等指令。表2中描述了GFS和HDFS的比较分析。
Ⅲ.GFS和HDFS的局限性
谷歌文件系统被用来以可靠的方式存储大量数据，以便可以非常合理地处理相同的数据。虽然它支持全局命名空间，高效处理，快照和原子记录附加功能，但在GFS设计上存在一些局限性，例如：
- 在较小的级别上随机写入：GFS的写入工作负载始终是大型流。通过将一些功能移出GFS，我们可以为小文件上的随机写入获得更多益处[11]。
- 固定块大小：有时固定块大小为64MB会产生问题[17]。例如，当最后一个块被分成一些部分时，这些部分导致搜索整个新位置以访问文件系统的其他远端部分。它还增加了通信开销。
GFS和HDFS都不适合：
- 低延迟数据访问：由于数据存储在大容量的大块（64MB）中，因此GFS及其开源变体HDFS在提供更快的数据访问方面滞后[20]。 两者都旨在将大块数据压缩得更高。
- 处理小尺寸文件：GFS和HDFS都不适合处理小尺寸（小于1MB）的文件[19]。即使它们支持较小文件的操作，但也会导致效率下降。
- 数据频繁变化的情况：HDFS以其单写多次读取方案而闻名，但在数据被频繁修改和更新的情况下仍面临问题。
IV.改善GFS/HDFS
A.使用HBase解决低延迟数据访问问题
HBase是[21]，分布式，排序地图，模仿谷歌的大表格，以便在大量结构化数据中进行更快的查询搜索。它是基于Hadoop的开源和可扩展（水平）数据库。HBase运行在HDFS之上，它也用java编写（如图3所示）。HDFS文件在HBase中编制索引以便快速查询响应.HDFS的主要目的是批量处理大尺寸文件。低延迟数据读取不是HDFS的优先级。通过在HDFS之上使用HBase，我们可以从大块数据中对小文件或表进行低延迟访问。
B.使用缓存改进查询响应时间
集中式缓存管理[22]是一种显着改善文件系统查询响应时间的机制。它允许用户通过HDFS指定要在主存储器中缓存的路径（如图4所示）。它允许用户通过HDFS指定要在主存储器中缓存的路径（如图4所示）。在这里，NameNod
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
