欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

HDFS文件系统

大数据云计算 water 274℃ 0评论

HDFS文件系统

 

一、HDFS设计

    HDFS为hadoop的核心组件,为hadoop底层的文件存储系统。它通常运行在商用硬件集群上,用来存储超大文件、大规模文件。

    1、超大文件

    "超大文件"是指具有数百MB、数G甚至数T大小的文件;HDFS设计为了存储大量“超大文件”。

    2、流式数据访问

    HDFS的文件为“一次写入”、“多次读取”,这种高效的文件访问策略是HDFS的设计核心。被创建和写入的文件,将长时间存储在HDFS中,用来做数据分析计算。通常以流式访问整个文件或者文件的一部分。

    3、商用硬件

    Hadoop不需要运行在专业的昂贵的硬件上。它是设计运行在普通的(廉价)的商用机器上,并构架大规模集群。通常这些硬件都有普遍的故障率,HDFS提供了很多方案来提高文件的可用性。

    4、低时间延迟的数据访问

    HDFS不适合“低延迟”要求的数据访问,例如实时在线的数据访问,要求几毫秒访问延迟,这种场景是不适合HDFS的。HDFS以牺牲数据访问延迟性要求,达到“数据高吞吐量”优先的目标。

    5、大量小文件

    由于Namenode将文件系统的metada内存在内存中,因此文件系统所能存储的文件总数受限于namenode的内存总量。每个文件、目录、Block相关的metadata大概有150个字节,因此,一个Namenode

所能支持的文件个数是有上限的。因此HDFS并不适合存储大量小文件(数KB,数M),因为它们虽然不会消耗大量的磁盘空间,但是却潜在的增加了Namenode的负荷比。

    6、多用户写入,任意修改文件

    HDFS中的文件只有一个writer,而且write操作总是将数据append到文件的末尾。它不支持多个writer同时写入,也不支持任意位置的随机写,因为这是低效的,这归因与HDFS文件存储方式和Block的设计原理。

 

二、HDFS概念

    1、Block

    Block即为数据块,对于磁盘而言,也有block的概念,它是磁盘数据读写的最小单位,一般为512B,这是文件系统提升磁盘读取性能的方式。对于HDFS而言,Block有更多的含义,它比磁盘Block大的多,一般为64M甚至更大(128M,后期版本,默认为256M);一个HDFS文件在存储层面,会被分割成多个blocks片段,每个block作为独立的存储单元(replication)。与其他文件系统不同(包括磁盘存储),一个小于block大小的文件不会占用整个块空间。较大的block,对于Namenode管理文件而言是有益的,也可以有效的提高文件数据的读取性能。不过在Mapreduce应用中,此值还不能设置的过大,因为Map任务通常一次处理一个block数据,如果block过大会导致map的任务个数较少(少于集群节点数量),会在一定程度上影响mapreduce数据并行计算能力,拖慢job的整体运行速度。

 

    HDFS通过将一个文件在物理存储上分割成多个block,并分别将它们分布存储在集群的多个节点上,这种特性可以让HDFS保存一个大小超过本地磁盘容量的超大文件。以Block作为文件的物理存储单位,还大大简化了

存储子系统的设计,简化了存储系统管理;因为一个文件的block大小是固定的(可配置,一旦创建,则不能修改此参数),因此一个节点上能存储多少个block以及某个Block是否可以被放置是显而易见的。

 

    此外,Block这种小尺寸的数据块,可以很方便的replication,从而让HDFS文件的高可用和容错特性的实现更加简单。将每个Block复制到少数几个node上(默认为3),可以确保当某个Block被破坏或者节点软硬件故障时数据不会丢失。如果一个block不可用,系统将会从其他节点读取一个现有的block副本,如果某个Block的副本个数低于配置(3),那么Namenode将会为此block在合适的Node上创建新的副本,以保证Block的个数处于正常水平。

    我们可以通过“hdfs fsck <path>”指令获取有关Block分布的相关细节。

 

    2、Namenode与Datanodes

    HDFS中有两类节点,并以master-slave模式运行,即一个Namenoede和多个Datanodes。其中namenode作为master(角色),主要职责是管理集群的namespace,和协调与namespace变更有关的操作(block复制,rebalance等);它维护着文件系统树以及整棵树内所有的文件和目录。这些信息以两个文件形式持久保存在本地磁盘上:fsimage和Editlog。Namenode也记录着每个文件中所有block所在的数据节点信(blockMapping),blockMapping信息不会持久保存,因为这些信息会在系统启动时(运行时)由Datanodes通过心跳中的blockReport来反馈。

 

    Datanode是文件系统的存储节点,在HDFS架构模型中,它作为slaves存在。它负责存储文件的实际数据–Blocks,并与Namenode注册链接,通过心跳的方式向Namenode发送BlockReport信息(持有的blocks列表);同时Client可以直接与Datanode交互并访问指定名称的block中的数据。

 

    用户Application通过HDFS Client与Namenode和Datanodes交互来访问整个文件系统。HDFS提供了类似于POSIX的文件系统接口,因此用户在使用API接口时无需了解Namenode、Datanode的细节实现。Client在访问文件时,首先与Namenode通信并获取文件所有(或一批)Blocks列表以及它们的位置信息,此后Client与所需要的Block所在的一个Datanode建立链接并读写数据即可。

 

    因为Namenode保存了集群的namespace,是Client与Datanode的调度中心,因此如果Namenode失效,那么整个文件系统将不可用,只有Datanodes是无法重建集群的。Hadoop提供了多种容错方案用来解决Namenode的单点问题:SecondaryNamenode,CheckpointNode,BackupNode,还有更加复杂的HDFS HA架构(Standby Namenode)。它们的核心思想就是将Namenode中的namespace同步的在多个节点上备份,以便在故障时可以通过副本恢复集群状态。

 

 

三、HDFS接口

    1、读取数据

Java代码  收藏代码

  1. public void read(String path) throws Exception{  

  2.     Configuration conf = new Configuration();  

  3.     FileSystem fs = FileSystem.get(conf);  

  4.     BufferedReader reader = null;  

  5.     try{  

  6.         FSDataInputStream fsInput = fs.open(new Path(path));  

  7.         reader = new BufferedReader(new InputStreamReader(fsInput,"UTF-8"),256);  

  8.         String line = null;  

  9.         while (true) {  

  10.             line = reader.readLine();  

  11.             if(line == null) {  

  12.                 break;  

  13.             }  

  14.             System.out.println(line);  

  15.         }  

  16.     }catch (Exception e) {  

  17.         e.printStackTrace();  

  18.     } finally {  

  19.         IOUtils.closeStream(reader);  

  20.     }  

  21. }  

 

    FileSystem#open(path)方法可以用来打开一个文件,此方法返回FSDataInputStream对象,这个类继承了DataInputStream类,同时还实现了Seekable、PositionedReadable接口,它表达了可以从任何位置读取文件。

Seekable接口中seek方法允许跳跃到文件的任何位置作为起点读取数据。不过seek方法相对开销较大,不建议频繁的使用。

 

    2、写入数据

Java代码  收藏代码

  1. public void create(String path,String file) throws Exception {  

  2.     Configuration conf = new Configuration();  

  3.     FileSystem fs = FileSystem.get(conf);  

  4.     BufferedWriter writer = null;  

  5.     try {  

  6.         FSDataOutputStream fsOut = fs.create(new Path(path,file),true);  

  7.         writer = new BufferedWriter(new OutputStreamWriter(fsOut,"UTF-8"));  

  8.         writer.write("Hello,hadoop!");  

  9.         writer.newLine();  

  10.         writer.write("Hello,HDFS!");  

  11.         writer.flush();  

  12.     }catch (Exception e) {  

  13.         e.printStackTrace();  

  14.     } finally {  

  15.        writer.close();  

  16.     }  

  17. }  

 

    通过create方法创建文件,此方法有多个重载版本,可以在创建文件时指定权限、block大小、buffer大小等。创建文件时,如果父路径不存在则会创建,很方便。对于已经创建的文件,可以使用append方法在文件的尾部追加数据(继续写入)。create方法和append方法都会返回FSDataOutputStream对象,它继承自DataOutputStream,并实现了Syncable接口。与FSDataInputStream不同,它不允许通过seek的方式在任意位置写入数据。

 

    此外FileSystem中提供了大量API,可以进行文件的读写、目录操作、文件状态查看等。

 

三、Hadoop IO

    1、数据完整性

    HDFS中的数据都会被可靠的存储,庞大的Hadoop集群中因为磁盘、网络IO的故障或者系统的bug,可能会因此错误而导致文件损坏,hadoop中通过使用Checksum来检测文件数据的完整性。当数据第一次引入系统时计算Checksum,并在数据通过一个不可靠的通道进行传输时再次计算校验和,通过比较Checksum值即可知道数据在传输中是否损坏。如果校验和值不同,我们认为数据已损坏。常用的CheckSUM算法是CRC-32(循环冗余码校验)。

 

    HDFS会在写入数据时计算校验和,并在读取数据时验证校验和。校验和所占的开支很小。

    Datanode负责在验证收到的数据后存储数据极其校验和值,比如从Client接受数据以及在replication期间。正在写数据的Client将数据及其校验和发送到由一系列Datanodes组成的pipeline中,管线中最后一个datanode负责验证校验和。如果Datanode检测到错误,客户端会收到一个ChecksumException,操作将会被重试。

 

    客户端读取数据时,也会验证校验和,将它们与datanode中存储的校验和进行比较。每个Datanode均持久保存了一个用户验证的校验和日志,所以它知道每个数据块的最后一次验证的时间。客户端成功验证一个数据块后,会告诉这个Datanode,datanode由此更新日志,保存这个统计信息对于检测损坏的磁盘很有价值。每个Datanode也会在后台运行一个DataBlockScanner,定期验证此节点上所有的数据,该措施是解决物理存储魅力上损坏的有力措施。

 

    因为HDFS存储着每个block的replica,因此可以通过复制完好的数据block来修复损坏的快,从而得到一个新的、完好的复本。在Client在读操作时,如果检测到错误,则会向Namenode报告已损坏的block以及所在的Datanode,最后才抛出ChecksumException异常。Namenode将这个block标记为“损坏”(metada中),所以并不需要直接与Datanode联系,此后,Namenode会调度block的replication机制,将完好的Block重新再集群中复制(那个损坏的block将会被删除),从而保证了block的replication factor处于期望水平。

 

    可以在读取文件之间,通过FileSystem#setVerifyChecksum(boolean)方法来设定是否启用Checksum校验。

 

    2、压缩

    文件压缩可以减少存储文件所需要的磁盘空间;可以加速数据在网络和磁盘上的传输;当需要处理大量数据时,压缩特性将显得非常重要。Hadoop支持多种压缩算法:DEFLATE、Gzip,bizp2、LZO等。其中前三者Hadoop中已经有JAVA实现,包含在hadoop发布包中。LZO库需要单独下载。其中只有bzip2支持切分。在默认情况下,Hadoop会从运行平台中搜索原生代码库,如果找到就会自动加载并使用。我们可以通过将“hadoop.native.lib”配置项设定为false,来禁用本地库,此时将会使用内置的JAVA代码库(如果有的话)。

 

    所谓切分,就是压缩后的文件可以拆分为多个子文件片段存储,可以将任何子文件片段独立解压。目前只有bzip2算法支持拆分。那么在Mapreduce处理数据时,压缩文件是否支持拆分将是很重要的。例如一个压缩前1G的文件,block大小为64M,那么次文件将会被存储在16个block中;那么每个block将会有一个mapper任务读取。现在经过压缩后大小为1G的文件,存储在16个block中(数据流压缩后,存储HDFS,仍为64M一个Block)。那么一个压缩后的文件将由16个block文件片段组成,如果压缩算法不支持切分,那么将不能对任何一个block单独解压。Mapreduce不会尝试切分那些由不支持切分的压缩文件,那么任何一个mapper都需要额外的解压相应的block之前的所有blocks,才能够解压并读取当前block的数据,这就牺牲了block的本地性。

 

    对于巨大的、没有边界的文件,比如日志文件,可以考虑:

    1) 存储未经压缩的文件。

    2) 使用支持切分的压缩格式,比如bzip2。

    3) 使用SequeueFile,它支持压缩和切分。

    对于大文件而言,不应该使用不支持切分整个文件的压缩格式,否则将会失去数据的本地特性,导致mapreduce应用效率低下。不过对于mapper产生的临时数据以及reducer产生的结果数据,仍然推荐使用压缩,这可以提高数据在mapper与reducer之间的传输性能(mapper结果数据为保存在本地文件,而非HDFS中)。

转载请注明:学时网 » HDFS文件系统

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!