Hadoop-HDFS

一、Hadoop概述
Hadoop是Google的集群系统的开源实现。

• Google的集群系统：GFS、MapReduce、BigTable
• Hadoop的集群系统：HDFS、MapReduce、HBase
  Hadoop的设计初衷是为了解决Nutch海量数据存储和处理需求，可以解决大数据场景下的海量数据的存储和处理问题。

传统数据和大数据的区别：
①.传统数据

• GB、TB级别的数据
• 数据增长不快
• 主要为结构化的数据
• 统计和报表

②.大数据

• TB、PB级别的数据
• 数据持续的高速增长
• 半结构化、非结构化的数据

• 用于数据挖掘和预测性分析

  大数据是对海量数据的获取、存储、聚合和管理这些数据以及对这些数据进行深度分析和预测的新技术和新能力。

• 大数据定义：

  定义1：所涉及的数据量规模巨大到无法通过人工，在合理时间内截取管理处理并整理成为人类所能解读的信息。（Dan Kusnetzky,What is “Big Data”?）

  定义2：不用随机分析法（抽样调查）这样的捷径，而采用所有数据的方法。（维克托 ∙ 迈尔-舍恩伯格、肯尼斯 ∙ 库克耶，“大数据时代”）

  定义3：“大数据”是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。（“大数据”(Big Data)研究机构Gartner）

注：hadoop名字的起源：
Doug Cutting如此解释Hadoop的得名：“这个名字是我的孩子给一头吃饱了的棕黄色的大象命名的。我的命名标准就是简短、容易发音和拼写，没有太多的意义，并且不会被用于别处。小孩子在这方面是高手，Google就是由孩子命名的。”
Hadoop组成：HDFS、MapReduce、Yarn

---

二、Hadoop版本和下载安装

1.下载
下载地址：http://hadoop.apache.org/releases.html
Apache Hadoop的成熟版本分为两代，我们将第一代Hadoop称为Hadoop 1.0，第二代Hadoop称为Hadoop 2.0。
第一代Hadoop分为三个大版本，分别是0.20.x,0.21.x和0.22.x,其中，0.20.x最后演化成1.0.x,变为稳定版本，而0.21.x和0.22.x则添加了NameNode和HA等重大特性。
第二代Hadoop包含两个版本，分别是0.23.x和2.x，它们完全不同于Hadoop1.0，是一套全新的架构，均包含HDFS-Federation和YARN两个子系统，相比于0.23.x,2.x增加了NameNode HA和Wire-compatibility两个重大特性。
当然，截止发文前，hadoop出的新版本为 3.0.0-alpha1，但稳定版还没有出来。稳定版出来后，Hadoop有可能会进入第三代。

2.安装
Hadoop的安装分为单机方式、伪分布式方式、完全分布式方式。

单机模式：
1. Hadoop 的默认模式。
2. 当首次解压Hadoop 的源码包时，Hadoop无法了解硬件的安装环境，便保守的选择了最小配置。
3. 这种模式下，所有的3个XML文件均为空。当配置文件为空时，Hadoop完全运行在本地。
4. 因为不需要与其他节点进行交互，单机模式就不使用HDFS，也不加载任何Hadoop的守护进程。
5. 该模式主要用于开发调试MapReduce程序的应用逻辑。

伪分布式模式：
1. Hadoop守护进程运行在本地机器上；
2. 可以模拟一个小规模的集群；
3. 可以使用HDFS和MapReduce.

完全分布式模式：
1. Hadoop守护进程运行在一个集群上。

3.单机安装

4.伪分布式安装

5.完全分布式安装

---

三、HDFS的特点

1.HDFS概述

• HDFS为了保证数据存储的可靠性和读取性能，对数据进行切块后 并进行复制存储在集群的多个节点中。
• HDFS中存在一个名字节点NameNode和多个数据节点DataNode

NameNode：
1. 存储元数据信息
2. 元数据保存在内存/磁盘中
3. 保存文件、block、datanode之间的映射关系
DataNode：
1. 存储block内容
2. 存储在磁盘中
3. 维护了block id到文件的映射关系

2.HDFS优点

• 支持超大文件
  超大文件在这里指的是几百M，几百GB，甚至几TB大小的文件。
  一般来说hadoop的文件系统会存储TB级别或者PB级别的数据。
  所以在企业的应用中，数据节点有可能有上千个。

• 检测和快速应对硬件故障
  在集群的环境中，硬件故障是常见的问题。
  因为有上千台服务器连接在一起，这样会导致高故障率。
  因此故障检测和自动恢复是hdfs文件系统的一个设计目标。

• 流式数据访问
  Hdfs的数据处理规模比较大，应用一次需要访问大量的数据；
  同时这些应用一般都是批量处理，而不是用户交互式处理。
  应用程序能以流的形式访问数据集。
  主要的是数据的吞吐量，而不是访问速度。

• 简化的一致性模型
  大部分hdfs 操作文件时，需要一次写入，多次读取。
  在hdfs中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了。
  这样简单的一致性模型，有利于提高吞吐量。

• 高容错性
  数据自动保存多个副本，副本丢失后自动恢复
  可构建在廉价机器上
  构建在廉价机器上可以轻松的通过扩展机器数量来近乎线性的提高集群存储能力

3.HDFS缺点

• 低延迟数据访问
  低延迟数据。如和用户进行交互的应用，需要数据在毫秒或秒的范围内得到响应。
  由于hadoop针对高数据吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟来说，不适合用hadoop来做。

• 大量的小文件
  Hdfs支持超大的文件，是通过数据分布在数据节点，数据的元数据保存在名字节点上。
  名字节点的内存大小，决定了hdfs文件系统可保存的文件数量。
  虽然现在的系统内存都比较大，但大量的小文件还是会影响名字节点的性能。

• 多用户写入文件、修改文件
  Hdfs的文件只能有一次写入，不支持追加写入（2.0版本支持），也不支持修改。只有这样数据的吞吐量才能大。

• 不支持超强的事务
  没有像关系型数据库那样，对事务有强有力的支持。

---

四、HDFS技术细节

1.Block

• 最基本的存储单位。
• 在HDFS中，有一个特别重要的概念：数据块(Block)。前面介绍到，在HDFS中存储的文件都是超大数据的文件，我们可以把这个超大规模的文件以一个标准切分成几块，分别存储到不同的磁盘上。这个标准就称为Block。
• Block 默认的大小为64(128)M。这样做有以下几点好处：
  ①.文件块可以保存在不同的磁盘上。在HDFS系统中，一个文件可以分成不同的Block存储在不同的磁盘上。
  ②.简化存储系统。这样不需要管理文件，而是管理文件块就可以了。
  ③.有利于数据的复制。在HDFS系统中，一个数据节点一般会复制3份
• 对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。HDFS默认Block大小是128MB，以一个256MB文件，共有256/128=2个Block.
• 不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间

2.NameNode

• NameNode维护着HDFS中的元信息，包括文件和Block之间关系的信息、Block数量信息、Block和DataNode之间的关系信息，数据格式参照如下：
  FileName replicas block-Ids id2host
  例如： /test/a.log,3,{b1,b2},[{b1:[h0,h1,h3]},{b2:[h0,h2,h4]}]

• NameNode中的元数据信息存储在内存/文件中，内存中为实时信息，文件中为数据镜像作为持久化存储使用。

• 文件包括：
  fsimage 元数据镜像文件。存储某NameNode元数据信息，并不是实时同步内存中的数据。
  edits 操作日志文件
  fstime 保存最近一次checkpoit的时间

• 当有写请求时，NameNode会首先写editlog到磁盘edits文件中，成功后才会修改内存，并向客户端返回

• NameNode的metadata信息会在启动后加载到内存中

3.SecondaryNameNode

• SecondaryNameNode并不是NameNode的热备份，而是协助者帮助NameNode进行元数据的合并，从另外的角度来看可以提供一定的备份功能，但并不是热备，这种合并过程可能会造成极端情况下数据丢失！可以从snn中恢复部分数据，但是无法恢复全部。

• 何时触发数据合并？：
  根据配置文件设置的时间间隔：fs.checkpoint.period 默认3600秒
  根据配置文件设置的edits log大小 fs.checkpoint.size 默认64MB

• 合并过程：

  

步骤：
①.达到条件后 snn会将nn中的fsimage和edits文件拷贝过来；
②.同时nn中会创建一个新的edits.new文件，新的读写请求会写入到这个edits.new中；
③.在snn中将拷贝过来的fsimage和edits合并为一个新的fsimage；
④.snn将合并完成的fsimage文件拷贝回nn中替换之前的fsimage；
⑤.nn再将edtis.new改为 edits。
注：由于NameNode实时数据都在内存中，此处的合并指的是磁盘中的持久化的数据的处理。

判断： ssn可以对元数据做一定程度的备份，但是不是热备，对不对？
思考：什么情况下可能造成NameNode元数据信息丢失?
snn并不是nn的热备，但是能保存大部分备份数据。原因就在于edits.new中的数据丢失了就找不回来了

• 通常NameNode和SNN要放置到不同机器中以此提升性能，并提供一定的元数据安全性。

4.DataNode

• 在hadoop中，数据是存放在DataNode上面的。是以Block的形式存储的。
• DataNode节点会不断向NameNode节点发送心跳报告。
• 初始化时，每个数据节点将当前存储的数据块告知NameNode节点。
• 通过向NameNode主动发送心跳保持与其联系（3秒一次）
• 后续DataNode节点在工作的过程中，数据节点仍会不断的更新
• NameNode节点与之对应的元数据信息，并接受来自NameNode节点的指令，创建、移动或者删除本地磁盘上的数据块。
• 如果10分钟都没收到dn的心跳，则认为其已经lost，并copy其上的block到其他dn。
• Replication。多复本。默认是三个。

5.Block副本放置策略：

• 第一个副本：放置在上传文件的DN，如果是集群就外提交，就随机选择一台磁盘不太满，cpu不太忙的节点
• 第二个副本：放置在第一个副本不同机架的节点上
• 第三个副本：放置在与第二个副本相同机架的节点上
• 更多副本：随机节点

机架感知策略(参看文章)

---

五、HDFS的shell操作

• hadoop fs -mkdir /user/trunk
• hadoop fs -ls /user
• hadoop fs -lsr /user (递归的)
• hadoop fs -put test.txt /user/trunk
• hadoop fs -put test.txt . (复制到hdfs当前目录下，首先要创建当前目录)
• hadoop fs -get /user/trunk/test.txt . (复制到本地当前目录下)
• hadoop fs -cat /user/trunk/test.txt
• hadoop fs -tail /user/trunk/test.txt (查看最后1000字节)
• hadoop fs -rm /user/trunk/test.txt
• hadoop fs -rmdir /user/trunk
• hadoop fs -help ls (查看ls命令的帮助文档)

---

六、HDFS执行流程

1.HDFS读流程

• 使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
• Namenode会视情况返回文件的部分或者全部block列表，对于每个block，Namenode都会返回有该block拷贝的DataNode地址；
• 客户端开发库Client会选取离客户端最接近的DataNode来读取block；如果客户端本身就是DataNode,那么将从本地直接获取数据.
• 读取完当前block的数据后，关闭与当前的DataNode连接，并为读取下一个block寻找最佳的DataNode；
• 当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。
• 读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读。
• 当文件最后一个块也都读取完成后，datanode会连接namenode告知关闭文件。

2.HDFS的写流程

• 使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
• Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；
• 当客户端开始写入文件的时候，开发库会将文件切分成多个packets，并在内部以数据队列”data queue”的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas的合适的datanodes列表，列表的大小根据在Namenode中对replication的设置而定。
• 开始以pipeline（管道）的形式将packet写入所
  有的replicas中。开发库把packet以流的方式写入第一个datanode，该datanode把该packet存储之后，再将其传递给在此
  pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。
• 最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着”ack
  queue”，成功收到datanode返回的ack packet后会从”ack queue”移除相应的packet。
• 如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持replicas设定的数量。

3.HDFS的删除流程

• 先在NameNode上执行节点名字的删除。
• 当NameNode执行delete方法时，它只标记操作涉及的需要被删除的数据块，而不会主动联系这些数据块所在的DataNode节点。
• 当保存着这些数据块的DataNode节点向NameNode节点发送心跳时，在心跳应答里，NameNode节点会向DataNode发出指令，从而把数据删除掉。
• 所以在执行完delete方法后的一段时间内，数据块才能被真正的删除掉。

4.安全模式 **

• 在重新启动HDFS后，会立即进入安全模式，此时不能操作hdfs中的文件，只能查看目录文件名等，读写操作都不能进行。
• namenode启动时，需要载入fsimage文件到内存，同时执行edits文件中各项操作
• 一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件（这个步骤不需要SNN的参与）和一个空的编辑文件。
• 此时namenode文件系统对于客户端来说是只读的。
• 再此阶段NameNode收集各个DataNode的报告，当数据块达到最小复本数以上时，会被认为是“安全”的，在一定比例的数据块被确定为安全后，再经过若干时间，安全模式结束
• 当检测到副本数不足的数据块时，该块会被复制直到到达最小副本数，系统中数据块的位置并不是namenode维护的，而是以块列表的形式存储在datanode中。
• 当启动报如下错误时: org.apache.hadoop.dfs.SafeModeException: Cannot delete/user/hadoop/input. Name node is in safe mode
  使用如下命令退出安全模式:
  hadoop dfsadmin -safemode leave

---

七、java接口方式操作HDFS

1.Eclipse中Hadoop插件的使用

    //导入jar
    hadoop/share/hadoop/common/*.jar
    hadoop/share/hadoop/common/lib/*.jar
    hadoop/hdfs/*.jar

    //--下载
    FileSystem fs = FileSystem.get(new URI("hdfs://xxxx:9000")new Configuration());
    InputStream in = fs.open(new Path("/xxx"));//HDFS路径
    OutputStream out = ..
    IOUtils.copyBytes(in,out,buffersize,close);

    //--上传
    InputStream in = ..
    FileSystem fs = FileSystem.get(new URI("hdfs://xxxx:9000")new Configuration());
    OutputStream out = fs.create(new Path("..."));//hdfs路径
    IOUtils.copyBytes(in,out,buffersize,close);

    #问题：Permission Denied -- 权限错误
    FileSystem fs = FileSystem.get(new URI("hdfs://xxxx:9000")new Configuration(),"root");

    //--删除文件、文件夹(如果要删除的文件夹中有内容，必须选择递归删除)
    boolean fs.delete(new Path("目标hdfs路径"),是否递归删除);

    //--创建文件夹
    boolean fs.mkdirs(new Path(".."));