Hadoop之HDFS

HDFS简介

Hadoop的核心组件：HDFS
目前得到广泛应用的分布式文件系统主要包括GFS和HDFS等，Hadoop就是使用的HDFS，它是Google GFS的开源实现
HDFS的优点有

• 存储超大文件，文件大小通常都是上百MB、TB、PB级别。
• 标准流式访问，基于“一次写入，多次读取”的构建思路，即只支持文件的追加写，不支持随机访问，这是最高效的访问模式。流式方式就是按照顺序来，一条线，找一次就够了。所以适合一次写，多次读的数据。
• 运行在廉价的商用机器集群上， Hadoop并不需要昂贵且高可靠的硬件
• 兼容廉价的硬件设备。在成百上千的廉价服务器上存储数据，常会出现节点
• 强大的平台兼容性。HDFS是由java编写的，支持JVM的机器都可以运行HDFS

HDFS的缺点

• 不适合低延迟数据访问。HDFS主要是面向大规模数据批量处理而设计的，采用流式数据读取，具有很高的数据吞吐率，但是，这也意味着较高的延迟。因此，HDFS不适合用在需要较低延迟（如数十毫秒）的应用场合。对于低延时要求的应用程序而言， HBase是一个更好的选择
• 无法高效存储大量小文件。小文件是指文件大小小于一个块（64MB）的文件，HDFS无法高效存储和处理大量小文件，过多小文件会给系统扩展性和性能带来诸多问题。首先，HDFS采用名称节点（Name Node）来管理文件系统的元数据，这些元数据被保存在内存中，从而使客户端可以快速获取文件实际存储位置。通常，每个文件、目录和块大约占150字节，如果有1000万个文件，每个文件对应一个块，那么，名称节点至少要消耗3GB的内存来保存这些元数据信息。很显然这时元数据检索的效率就比较低了，需要花费较多的时间找到一个文件的实际存储位置。而且如果继续扩展到数十亿个文件时，名称节点保存元数据所需要的内存空间就会大大增加，以现有的硬件水平，是无法在内存中保存如此大量的元数据的。其次，用 MapReduce处理大量小文件时，会产生过多的Map任务，线程管理开销会大大增加，因此处理大量小文件的速度远远低于处理同等大小的大文件的速度。再次，访问大量小文件的速度远远低于访问几个大文件的速度，因为访问大量小文件，需要不断从一个数据节点跳到另一个数据节点，严重影响性能
• 不支持多用户写入及任意修改文件。HDFS只允许一个文件有一个写入者，不允许多个用户对同一个文件执行写操作，而且只允许对文件执行追加操作，不能执行随机写操作
  HDFS的体系架构有
  
  

基本概念

1.块

HDFS中的文件被分成块进行存储，它是文件的最小逻辑单元，默认块大小为64MB

2.NameNode和DataNode节点

NameNode和DataNode属于HDFS集群的两类节点。
NameNode负责管理文件系统的命名空间，属于管理者角色。它维护文件系统树内所有文件和目录，记录每个文件在各个DataNode上的位置和副本信息，并协调客户端对文件的访问。名称节点（Name Node）保存了两个核心的数据结构，即FsImage和 EditLog。FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。操作日志文件 EditLog中记录了所有针对文件的创建、删除、重命名等操作。名称节点记录了每个文件中各个块所在的数据节点的位置信息，但是并不持久化存储这些信息，而是在系统每次启动时扫描所有数据节点重构得到这些信息。
名称节点在启动时，会将FsImage的内容加载到内存当中，然后执行 EditLog文件中的多项操作，使得内存中的元数据保持最新。这个操作完成以后，就会创建一个新的FsImage文件和一个空的EditLog文件。名称节点启动成功并进入正常运行状态以后，HDFS中的更新操作都会被写入到EditLog，而不是直接写入FsImage，这是因为对于分布式文件系统而言，FsImage文件通常都很庞大（一般都是GB级别以上），如果所有的更新操作都直接往FsImage文件中添加，那么系统就会变得非常缓慢。相对而言， EditLog通常都要远远小于FsImage，更新操作写人到EditLog是非常高效的。名称节点在启动的过程中处于“安全模式”，只能对外提供读操作无法提供写操作。启动过程结束后，系统就会退出安全模式，进入正常运行状态，对外提供读写操作。

DataNode根据需要存储、检索数据块，并定期向NameNode发送所存储的块的列表，属于工作者角色。它负责所在物理节点的存储管理，按照一次写入、多次读取的原则。存储文件由数据块组成，典型的块大小是64MB，尽量将各数据块分布到各个不同的DataNode节点上。DataNode负责处理文件系统客户端的文件读写请求，并在NameNode的统一调度下进行数据块的创建、删除和复制工作。如果在NameNode上的数据损坏，HDFS中所有的文件都不能被访问，由此可见NameNode节点的重要性。为了保证NameNode的高可用性，Hadoop对NameNode进行了补充，即第二命名节点（Secondary NameNode）

3.Secondary NameNode节点

系统中会同步运行一个Secondary NameNode，也称为二级NameNode。相当于NameNode的快照，能够周期性的备份NameNode，记录NameNode的元数据等，也可以用来恢复NameNode，但Secondary NameNode中的备份会滞后于NameNode，所以会带来一定的数据损失。为了防止宕机，通常将NameNode和Secondary NameNode设置为不同的主机。使用hdfs-site.xml中配置的dfs.namenode.secondary.http-address属性值可以通过浏览器查看Secondary NameNode的运行状态。
我们可以使用jps命令时发现SecondaryNameNode，说明Secondary NameNode节点已经启动。

Hadoop FS Shell命令

调用Hadoop的文件系统Shell（FileSystem Shell）的命令格式如下：
语法：hadoop fs
Hadoop的文件系统可以支持多种文件系统的访问，如Local（本地文件系统）和HDFS。访问时均使用URL路径作为参数，如”file://path”和”hdfs：//NameNodeIP:NameNodePort/path”，分别表示访问本地文件系统和HDFS。
在Hadoop配置（core-site.xml属性fs. defaultFS）中指定的文件的系统格式为：

<property>
          <name>fs.defaultFS</name>
          <value>hdfs://hadoop:9000</value>
</property>

所以可以省略hdfs:/NameNodeIP:NameNodePort

命令	涵义
hadoop fs -ls [路径]	列出该目录下所有文件。
hadoop fs -mkdir <paths>	创建目录
hadoop fs -cat <file>	查看文件
hadoop fs -put …	从本地文件中复制单个或多个文件到HDFS，也支持从标准输入中读取输入写入到目标文件系统
hadoop fs –get <localdst>	复制HDFS中单个或多个文件到本地文件系统，是put命令的逆操作。其中localdst只能是本地文件，src只能是HDFS文件
hadoop fs –mv URI [URI…]	将文件从源路径移动到目标路径，允许多个源路径，目标路径必须是一个目录。不允许在不同的文件系统间移动文件，也就是说所有路径都必须是同一文件系统URL格式
hadoop fs –cp URI [URI…]	将文件从源路径复制到目标路径，允许多个源路径，目标路径必须是一个目录。不允许在不同的文件系统间复制文件
hadoop fs –rm URI [URI…]	删除指定的文件，只删除非空目录和文件。
hadoop fs –rmr URI [URI…]	rm的递归版本，整个文件夹及子文件夹将全部删除
hadoop fs -test -[选项] URI	选项：-e 检查文件是否存在。如果存在则返回0。-z 检查文件是否是0字节。如果是则返回0。 -d 如果路径是个目录，则返回1，否则返回0。
hadoop fs -du URI [URI…]	显示目录中所有文件的大小。
expunge命令	清空回收站