Hadoop分布式文件系统方案
- 格式:doc
- 大小:122.50 KB
- 文档页数:8
Hadoop分布式⽂件系统(HDFS)详解HDFS简介:当数据集的⼤⼩超过⼀台独⽴物理计算机的存储能⼒时,就有必要对它进⾏分区 (partition)并存储到若⼲台单独的计算机上。
管理⽹络中跨多台计算机存储的⽂件系统成为分布式⽂件系统 (Distributed filesystem)。
该系统架构于⽹络之上,势必会引⼊⽹络编程的复杂性,因此分布式⽂件系统⽐普通磁盘⽂件系统更为复杂。
HDFS是基于流数据模式访问和处理超⼤⽂件的需求⽽开发的,它可以运⾏于廉价的商⽤服务器上。
总的来说,可以将 HDFS的主要特点概括为以下⼏点:(1 )处理超⼤⽂件这⾥的超⼤⽂件通常是指数百 MB、甚⾄数百TB ⼤⼩的⽂件。
⽬前在实际应⽤中, HDFS已经能⽤来存储管理PB(PeteBytes)级的数据了。
在 Yahoo!,Hadoop 集群也已经扩展到了 4000个节点。
(2 )流式地访问数据HDFS的设计建⽴在更多地响应“⼀次写⼊,多次读取”任务的基础之上。
这意味着⼀个数据集⼀旦由数据源⽣成,就会被复制分发到不同的存储节点中,然后响应各种各样的数据分析任务请求。
在多数情况下,分析任务都会涉及数据集中的⼤部分数据,也就是说,对HDFS 来说,请求读取整个数据集要⽐读取⼀条记录更加⾼效。
(3 )运⾏于廉价的商⽤机器集群上Hadoop设计对硬件需求⽐较低,只须运⾏在廉价的商⽤硬件集群上,⽽⽆须昂贵的⾼可⽤性机器上。
廉价的商⽤机也就意味着⼤型集群中出现节点故障情况的概率⾮常⾼。
这就要求在设计 HDFS时要充分考虑数据的可靠性、安全性及⾼可⽤性。
正是由于以上的种种考虑,我们会发现现在的 HDFS在处理⼀些特定问题时不但没有优势,⽽且有⼀定的局限性,主要表现在以下⼏个⽅⾯。
(1 )不适合低延迟数据访问如果要处理⼀些⽤户要求时间⽐较短的低延迟应⽤请求,则 HDFS不适合。
HDFS 是为了处理⼤型数据集分析任务的,主要是为达到⾼的数据吞吐量⽽设计的,这就可能要求以⾼延迟作为代价。
hadoop技术、方法以及原理的理解Hadoop技术、方法以及原理的理解Hadoop是一个开源的分布式计算框架,它能够存储和处理海量的数据。
它由Apache基金会开发和维护,是目前最流行的大数据处理解决方案之一。
Hadoop的技术、方法以及原理是构成Hadoop 的核心部分,下面我们将对其进行详细的解析。
一、Hadoop的技术1. HDFSHadoop分布式文件系统(HDFS)是Hadoop的核心组件之一。
它是一种高度容错的分布式文件系统,具有高可靠性和高可用性。
该文件系统将海量数据分散存储在多个节点上,以实现快速访问和处理。
2. MapReduceMapReduce是Hadoop的另一个核心组件,它是一种编程模型和处理数据的方式。
MapReduce将数据分成小的块,然后在分布式计算机集群上处理这些块。
MapReduce将任务分为Map和Reduce两个阶段。
在Map阶段,数据被分割并分配给不同的节点进行计算。
在Reduce阶段,计算的结果被合并起来并输出。
3. YARNHadoop资源管理器(YARN)是另一个重要的组件,它是一个分布式的集群管理系统,用于管理Hadoop集群中的资源。
YARN允许多个应用程序同时运行在同一个Hadoop集群上,通过动态管理资源来提高集群的使用效率。
二、Hadoop的方法1. 大数据存储Hadoop通过HDFS实现对海量数据的存储和管理。
HDFS的设计目标是支持大型数据集的分布式处理,它通过多个节点存储数据,提供高可靠性和高可用性。
2. 数据处理Hadoop通过MapReduce实现对海量数据的处理。
MapReduce 将数据分成小的块,然后在分布式计算机集群上处理这些块。
在Map阶段,数据被分割并分配给不同的节点进行计算。
在Reduce 阶段,计算的结果被合并起来并输出。
3. 数据分析Hadoop通过Hive、Pig和Spark等工具实现数据分析。
这些工具提供了高级查询和数据分析功能,可以通过SQL和其他编程语言来处理海量数据。
HDFS中DFS介绍分布式文件系统(Distributed File System,DFS)是一种用于存储和管理大规模数据的系统。
Hadoop分布式文件系统(Hadoop Distributed File System,HDFS)是由Apache开发的一个开源分布式文件系统,用于支持大规模数据处理应用的存储。
本文将详细介绍HDFS中的DFS的相关概念、架构和工作原理。
DFS的概念DFS是分布式文件系统的核心组件,它是将数据分布到多个节点上存储的一种文件系统。
DFS主要解决了大规模数据的存储和管理问题,保证了数据的高可靠性和高可用性。
HDFS的架构HDFS的架构是基于master-slave模式的,其中包含一个NameNode(主节点)和多个DataNode(从节点)。
NameNode负责管理文件系统的命名空间、存储元数据和控制数据读写操作,DataNode负责存储实际的数据块和处理数据的读写请求。
DFS的工作原理1.数据分块:当客户端要向DFS中写入数据时,首先将数据切分成固定大小的数据块(默认大小为128MB),然后将这些数据块分布在多个DataNode上存储。
2.元数据管理:NameNode负责管理文件系统的元数据,包括文件的命名空间、目录结构和数据块的位置等信息。
NameNode将这些元数据保存在内存中,并定期持久化到磁盘上。
3.数据访问:当客户端要读取数据时,首先向NameNode发送读取请求,NameNode返回包含数据块位置的元数据信息。
然后客户端直接与存储数据块的DataNode进行通信,读取数据块的内容。
4.数据一致性:HDFS使用写一次、多次读取的模式来保证数据的一致性。
当客户端要向DFS中写入数据时,先将数据写入一个临时文件,然后通知NameNode进行元数据的更新。
在大部分DataNode都成功接收到数据块后,NameNode将接收到的数据块认定为永久数据,此时客户端可正常访问。
分布式存储系统及解决方案介绍分布式存储系统是指将数据分散存储在多个节点或服务器上,以实现高可靠性、高性能和可扩展性的存储解决方案。
分布式存储系统广泛应用于云计算、大数据分析和存储等领域。
本文将介绍几种常见的分布式存储系统及其解决方案。
1. Hadoop分布式文件系统(HDFS):Hadoop分布式文件系统是Apache Hadoop生态系统的一部分,用于存储大规模数据集。
该系统基于块存储模型,将文件划分为块,并将这些块分布式存储在多个节点上。
HDFS使用主从架构,其中NameNode负责管理文件系统的命名空间和协调数据块的存储位置,而DataNode负责实际的数据存储。
HDFS提供了高吞吐量和容错性,但对于小型文件存储效率较低。
2. Ceph分布式文件系统:Ceph是一个开源的分布式存储系统,能够提供可伸缩的冗余存储。
其架构包括一个Ceph存储集群,其中包含多个Ceph Monitor节点、Ceph Metadata Server节点和Ceph OSD(对象存储守护进程)节点。
Ceph仅需依赖于普通的网络和标准硬件即可构建高性能和高可靠性的存储系统。
Ceph分布式文件系统支持POSIX接口和对象存储接口,适用于各种应用场景。
3. GlusterFS分布式文件系统:GlusterFS是一个开源的分布式文件系统,能够提供高可用性和可扩展性的存储解决方案。
它使用类似于HDFS的块存储模型,将文件划分为固定大小的存储单元,并将这些存储单元分布式存储在多个节点上。
GlusterFS采用主从架构,其中GlusterFS Server节点负责存储数据和文件系统元数据,而GlusterFS Client节点提供文件系统访问接口。
GlusterFS具有良好的可伸缩性和容错性,并可以支持海量数据存储。
4. Amazon S3分布式存储系统:Amazon S3(Simple Storage Service)是亚马逊云服务提供的分布式对象存储系统。
分布式存储解决方案下面将系统地介绍几种常见的分布式存储解决方案。
1. 分布式文件系统(Distributed File System, DFS):分布式文件系统将文件分割为多个块,并将这些块存储在不同的节点上,实现文件的高可靠性、高可扩展性和高性能。
其中比较著名的有Hadoop分布式文件系统(Hadoop Distributed File System, HDFS)和谷歌分布式文件系统(Google File System, GFS)。
HDFS将文件分割为固定大小的数据块,并将这些数据块复制到多个节点上。
通过对数据块的复制,实现了数据的冗余和高可靠性。
同时,HDFS还采用了主从架构和数据局部性原理,使得数据的读写操作能够高效地在节点之间实现负载均衡和数据局部性。
GFS采用了类似的设计思想,将文件分割为大量的数据块,并将这些数据块按照一定的规则分布到多个节点上。
通过为每个文件存储多个副本和采用主从架构,实现了数据的冗余和高可靠性。
同时,GFS还使用了日志结构文件系统和数据局部性原理,使得数据的读写操作能够高效地在节点之间实现负载均衡和数据局部性。
2. 分布式对象存储(Distributed Object Storage, DOS):分布式对象存储将数据存储为对象,并将这些对象通过哈希算法分布到多个节点上,实现对象的高可靠性、高可扩展性和高性能。
其中比较著名的有亚马逊云存储服务(Amazon S3)和谷歌云存储服务(Google Cloud Storage)。
这些分布式对象存储系统采用了分布式哈希表的设计思想,将对象根据其哈希值分布到多个节点上。
通过为每个对象存储多个副本和采用主从架构,实现了对象的冗余和高可靠性。
同时,这些系统还使用了一致性哈希算法和数据局部性原理,使得对象的读写操作能够高效地在节点之间实现负载均衡和数据局部性。
3. 分布式块存储(Distributed Block Storage, DBS):分布式块存储将数据划分为固定大小的块,并将这些块存储在多个节点的硬件设备上,实现块的高可靠性、高可扩展性和高性能。
大数据存储方式概述在当今信息时代,大数据已经成为各行各业的重要组成部分。
随着数据量的不断增长,如何高效地存储大数据成为了一个重要课题。
本文将从不同的角度对大数据存储方式进行概述,帮助读者更好地了解大数据存储的基本原理和方法。
一、分布式文件系统存储方式1.1 Hadoop分布式文件系统(HDFS)HDFS是Apache Hadoop项目的核心组件,采用分布式存储的方式,将大文件切分成多个块存储在不同的节点上,保证数据的可靠性和高可用性。
1.2 Google文件系统(GFS)GFS是Google开发的分布式文件系统,具有高容错性和高扩展性的特点,适用于大规模的数据存储和处理。
1.3 Amazon S3Amazon S3是亚马逊提供的对象存储服务,通过简单的API接口可以实现大规模数据的存储和访问,适用于云计算环境下的大数据存储。
二、分布式数据库存储方式2.1 HBaseHBase是基于Hadoop的分布式数据库,采用列式存储的方式,适用于实时读写大规模数据的场景,具有高性能和可伸缩性。
2.2 CassandraCassandra是一个高可用的分布式数据库系统,采用分区存储和副本复制的方式,适用于分布式数据存储和处理。
2.3 MongoDBMongoDB是一个NoSQL数据库,采用文档存储的方式,适用于存储半结构化和非结构化数据,具有灵活的数据模型和高性能的特点。
三、内存数据库存储方式3.1 RedisRedis是一个高性能的内存数据库,采用键值对存储的方式,适用于缓存和实时数据处理的场景,具有快速的读写速度和持久化功能。
3.2 MemcachedMemcached是一个分布式内存对象缓存系统,适用于存储热点数据和加速数据访问,具有简单的设计和高性能的特点。
3.3 AerospikeAerospike是一个高性能的NoSQL数据库,采用内存和闪存混合存储的方式,适用于实时数据处理和高并发访问的场景,具有可扩展性和可靠性。
分布式存储系统及解决方案介绍分布式存储系统是指通过将数据分布在多个存储节点上实现数据存储和访问的系统。
它通过数据的冗余备份和分布,提高了系统的可靠性和可扩展性,并能通过并行读写提升系统的性能。
下面将介绍几种常见的分布式存储系统及其解决方案。
1. Hadoop分布式文件系统(HDFS)HDFS是Apache Hadoop项目的核心组件之一,它使用大规模计算集群存储和处理大规模数据集。
HDFS采用了冗余备份机制,将数据分布在多个存储节点上,以提供高可靠性和容错性。
同时,HDFS采用了多副本机制,将数据复制到不同的节点上,以提供高可用性和读取性能。
解决方案:-均衡数据负载:HDFS通过将数据分布在多个节点上,实现均衡的数据负载,提高整个系统的读写性能。
-自动故障检测与恢复:HDFS具有自动检测节点故障并重新复制数据的功能,从而提高数据的可靠性。
-大规模并行处理:HDFS支持将数据划分成多个数据块,并行处理多个数据块,提升系统的处理能力。
2. GlusterFSGlusterFS是一个开源的分布式文件系统,它允许将多个存储节点组合成一个存储池,并提供统一的文件系统接口。
GlusterFS采用分布式哈希表作为元数据管理机制,将数据分布在多个节点上,并提供冗余备份和数据恢复机制。
解决方案:- 弹性伸缩:GlusterFS支持动态添加和移除存储节点,以适应不断变化的存储需求,提供弹性伸缩的能力。
- 均衡负载:GlusterFS使用分布式哈希表进行数据分布,实现均衡的数据负载,提高系统的读写性能。
- 数据冗余和恢复:GlusterFS提供冗余备份和故障恢复机制,以保证数据的可靠性和可用性。
3. CephCeph是一个分布式存储系统,它将数据划分成多个对象,并将对象存储在多个存储节点上。
Ceph通过分布式哈希算法将对象映射到存储节点上,实现均衡的数据负载。
解决方案:- 弹性伸缩:Ceph支持动态添加和移除存储节点,以适应存储需求的变化,并能自动平衡数据分布,提供弹性伸缩的能力。
[1] 许春玲,张广泉.分布式文件系统Hadoop HDFS与传统文件系统Linux FS的比较与分析[J].苏州:苏州大学学报(工科版), 2010,30(4):6-9.一、HDFS实现分布式的关键技术分析1.用户群空间和物理空间的彼此独立:通过添加Block层来实现●Map1: < Block, INodeF ile> ;●Map2: < Block, DataNode> ;(以上两组映射封装在B locksMap< Block, BlockIn fo> 以哈希映射实现, 作为描述Block 的重要元数据Blockinfo封装了该Block相关的INode、DataNode。
)●Map3: < INode, Block> (Map1逆向), 作为目录树的最底层存放在FSImage;●Map4: < DataNode , Block> (Map2逆向), DataNodeDescr iptor中定义的Block List。
2.数据块映射BlockMap从HDFS目前的设计架构来看, 前面的Map1、Map2通过Java的Map界面实现, 而Hadoop基于MapReduce范式也实现了自己的应用程序界面Mapper、Rducer。
JavaMap以整个集合为操作对象, 不利于任务的分解和并行处理, 因此HDFS仅在数据的存储上实现分布式, 对算法和操作的实现依旧是集中式的。
这样的设计, 造成集群过分依赖NameNode, 当文件系统越来越庞大、目录树的结构越来越复杂时, NameNode的处理能力将成为HDFS 的瓶颈。
也许正是考虑到HDFS整个集群目录的操作都集中在一台NameNode上, 所以出现了前面HDFS设计的两个重点, 努力简化目录树结构以减少空间占用。
即便如此, 从长远来看日益庞大的集群(甚至可能在将来出现涵盖整个互联网的唯一集群)使简化的目录树无法从根本上解决问题, 而一旦NameNode崩溃, 则意味着集群的瘫痪。
Hadoop分布式文件系统:架构和设计要点Hadoop分布式文件系统:架构和设计要点原文:/core/docs/current/hdfs_design.html一、前提和设计目标1、硬件错误是常态,而非异常情况,HDFS可能是有成百上千的server组成,任何一个组件都有可能一直失效,因此错误检测和快速、自动的恢复是HDFS的核心架构目标。
2、跑在HDFS上的应用与一般的应用不同,它们主要是以流式读为主,做批量处理;比之关注数据访问的低延迟问题,更关键的在于数据访问的高吞吐量。
3、HDFS以支持大数据集合为目标,一个存储在上面的典型文件大小一般都在千兆至T字节,一个单一HDFS实例应该能支撑数以千万计的文件。
4、 HDFS应用对文件要求的是write-one-read-many访问模型。
一个文件经过创建、写,关闭之后就不需要改变。
这一假设简化了数据一致性问题,使高吞吐量的数据访问成为可能。
典型的如MapReduce框架,或者一个web crawler应用都很适合这个模型。
5、移动计算的代价比之移动数据的代价低。
一个应用请求的计算,离它操作的数据越近就越高效,这在数据达到海量级别的时候更是如此。
将计算移动到数据附近,比之将数据移动到应用所在显然更好,HDFS提供给应用这样的接口。
6、在异构的软硬件平台间的可移植性。
二、Namenode和DatanodeHDFS采用master/slave架构。
一个HDFS集群是有一个Namenode和一定数目的Datanode 组成。
Namenode是一个中心服务器,负责管理文件系统的namespace和客户端对文件的访问。
Datanode在集群中一般是一个节点一个,负责管理节点上它们附带的存储。
在部,一个文件其实分成一个或多个block,这些block存储在Datanode集合里。
Namenode执行文件系统的namespace操作,例如打开、关闭、重命名文件和目录,同时决定block到具体Datanode节点的映射。
Datanode在Namenode的指挥下进行block的创建、删除和复制。
Namenode和Datanode 都是设计成可以跑在普通的廉价的运行linux的机器上。
HDFS采用java语言开发,因此可以部署在很大围的机器上。
一个典型的部署场景是一台机器跑一个单独的Namenode节点,集群中的其他机器各跑一个Datanode实例。
这个架构并不排除一台机器上跑多个Datanode,不过这比较少见。
单一节点的Namenode大大简化了系统的架构。
Namenode负责保管和管理所有的HDFS元数据,因而用户数据就不需要通过Namenode(也就是说文件数据的读写是直接在Datanode上)。
三、文件系统的namespaceHDFS支持传统的层次型文件组织,与大多数其他文件系统类似,用户可以创建目录,并在其间创建、删除、移动和重命名文件。
HDFS不支持user quotas和访问权限,也不支持(link),不过当前的架构并不排除实现这些特性。
Namenode维护文件系统的namespace,任何对文件系统namespace和文件属性的修改都将被Namenode记录下来。
应用可以设置HDFS保存的文件的副本数目,文件副本的数目称为文件的 replication因子,这个信息也是由Namenode保存。
四、数据复制HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。
它将每个文件存储成block序列,除了最后一个block,所有的block都是同样的大小。
文件的所有block为了容错都会被复制。
每个文件的block大小和replication因子都是可配置的。
Replication因子可以在文件创建的时候配置,以后也可以改变。
HDFS中的文件是write-one,并且严格要求在任何时候只有一个writer。
Namenode全权管理block的复制,它周期性地从集群中的每个Datanode接收心跳包和一个Blockreport。
心跳包的接收表示该Datanode节点正常工作,而Blockreport 包括了该Datanode上所有的block组成的列表。
1、副本的存放,副本的存放是HDFS可靠性和性能的关键。
HDFS采用一种称为rack-aware的策略来改进数据的可靠性、有效性和网络带宽的利用。
这个策略实现的短期目标是验证在生产环境下的表现,观察它的行为,构建测试和研究的基础,以便实现更先进的策略。
庞大的HDFS实例一般运行在多个机架的计算机形成的集群上,不同机架间的两台机器的通讯需要通过交换机,显然通常情况下,同一个机架的两个节点间的带宽会比不同机架间的两台机器的带宽大。
通过一个称为Rack Awareness的过程,Namenode决定了每个Datanode所属的rack id。
一个简单但没有优化的策略就是将副本存放在单独的机架上。
这样可以防止整个机架(非副本存放)失效的情况,并且允许读数据的时候可以从多个机架读取。
这个简单策略设置可以将副本分布在集群中,有利于组件失败情况下的负载均衡。
但是,这个简单策略加大了写的代价,因为一个写操作需要传输block到多个机架。
在大多数情况下,replication因子是3,HDFS的存放策略是将一个副本存放在本地机架上的节点,一个副本放在同一机架上的另一个节点,最后一个副本放在不同机架上的一个节点。
机架的错误远远比节点的错误少,这个策略不会影响到数据的可靠性和有效性。
三分之一的副本在一个节点上,三分之二在一个机架上,其他保存在剩下的机架中,这一策略改进了写的性能。
2、副本的选择,为了降低整体的带宽消耗和读延时,HDFS会尽量让reader读最近的副本。
如果在reader的同一个机架上有一个副本,那么就读该副本。
如果一个HDFS集群跨越多个数据中心,那么reader也将首先尝试读本地数据中心的副本。
3、SafeModeNamenode启动后会进入一个称为SafeMode的特殊状态,处在这个状态的Namenode是不会进行数据块的复制的。
Namenode从所有的 Datanode接收心跳包和Blockreport。
Blockreport 包括了某个Datanode所有的数据块列表。
每个block都有指定的最小数目的副本。
当Namenode 检测确认某个Datanode的数据块副本的最小数目,那么该Datanode就会被认为是安全的;如果一定百分比(这个参数可配置)的数据块检测确认是安全的,那么Namenode将退出SafeMode状态,接下来它会确定还有哪些数据块的副本没有达到指定数目,并将这些block复制到其他Datanode。
五、文件系统元数据的持久化Namenode存储HDFS的元数据。
对于任何对文件元数据产生修改的操作,Namenode都使用一个称为Editlog的事务日志记录下来。
例如,在HDFS中创建一个文件,Namenode就会在Editlog中插入一条记录来表示;同样,修改文件的replication因子也将往 Editlog插入一条记录。
Namenode在本地OS的文件系统中存储这个Editlog。
整个文件系统的namespace,包括block到文件的映射、文件的属性,都存储在称为FsImage的文件中,这个文件也是放在Namenode 所在系统的文件系统上。
Namenode在存中保存着整个文件系统namespace和文件Blockmap的映像。
这个关键的元数据设计得很紧凑,因而一个带有4G存的 Namenode足够支撑海量的文件和目录。
当Namenode 启动时,它从硬盘中读取Editlog和FsImage,将所有Editlog中的事务作用(apply)在存中的FsImage ,并将这个新版本的FsImage从存中flush到硬盘上,然后再truncate这个旧的Editlog,因为这个旧的Editlog的事务都已经作用在FsImage上了。
这个过程称为checkpoint。
在当前实现中,checkpoint只发生在Namenode启动时,在不久的将来我们将实现支持周期性的checkpoint。
Datanode并不知道关于文件的任何东西,除了将文件中的数据保存在本地的文件系统上。
它把每个HDFS数据块存储在本地文件系统上隔离的文件中。
Datanode并不在同一个目录创建所有的文件,相反,它用启发式地方法来确定每个目录的最佳文件数目,并且在适当的时候创建子目录。
在同一个目录创建所有的文件不是最优的选择,因为本地文件系统可能无法高效地在单一目录中支持大量的文件。
当一个Datanode启动时,它扫描本地文件系统,对这些本地文件产生相应的一个所有HDFS数据块的列表,然后发送报告到Namenode,这个报告就是Blockreport。
六、通讯协议所有的HDFS通讯协议都是构建在TCP/IP协议上。
客户端通过一个可配置的端口连接到Namenode,通过ClientProtocol与 Namenode交互。
而Datanode是使用DatanodeProtocol与Namenode交互。
从ClientProtocol和 Datanodeprotocol抽象出一个远程调用(RPC),在设计上,Namenode不会主动发起RPC,而是是响应来自客户端和 Datanode 的RPC请求。
七、健壮性HDFS的主要目标就是实现在失败情况下的数据存储可靠性。
常见的三种失败:Namenode failures, Datanode failures和网络分割(network partitions)。
1、硬盘数据错误、心跳检测和重新复制每个Datanode节点都向Namenode周期性地发送心跳包。
网络切割可能导致一部分Datanode跟Namenode失去联系。
Namenode通过心跳包的缺失检测到这一情况,并将这些Datanode标记为dead,不会将新的IO请求发给它们。
寄存在dead Datanode上的任何数据将不再有效。
Datanode的死亡可能引起一些block的副本数目低于指定值,Namenode不断地跟踪需要复制的 block,在任何需要的情况下启动复制。
在下列情况可能需要重新复制:某个Datanode 节点失效,某个副本遭到损坏,Datanode上的硬盘错误,或者文件的replication因子增大。
2、集群均衡HDFS支持数据的均衡计划,如果某个Datanode节点上的空闲空间低于特定的临界点,那么就会启动一个计划自动地将数据从一个Datanode搬移到空闲的Datanode。
当对某个文件的请求突然增加,那么也可能启动一个计划创建该文件新的副本,并分布到集群中以满足应用的要求。