Hadoop（二）原理
4.HDFS存储方式
数据存储到服务器的过程
- 1.数据分块（会把数据按照128m一块进行分块）可配置
<property>
<name>dfs.blocksize</name>
<value>块大小 以字节为单位</value><!-- 只写数值就可以 -->
</property>- 如果是1k的数据 存储数据的大小就是1k，但是不仅仅需要存储数据，还需要存储元数据的信息()
- 2.元数据信息存储
- 3.数据分发
- 机架感知，负载均衡
- 数据备份（多分存储)
5. HDFS 读写流程
5.1NameNode 和SecondaryNameNode
首先我们需要知道这两个文件，fsimage和edits 文件hadoop元数据存储的全量和增量文件。
结构如下图所示：
具体的位置见配置项hdfs-site.xml：
<!-- namenode保存fsimage的路径 -->
<property>
<name>dfs.namenode.name.dir</name>
<value>file:///XX/install/hadoop-3.1.4/hadoopDatas/namenodeDatas</value>
</property>
<!-- namenode保存editslog的目录 -->
<property>
<name>dfs.namenode.edits.dir</name>
<value>file:///XX/install/hadoop-3.1.4/hadoopDatas/dfs/nn/edits</value>
</property>接下来详细的看一下NameNode和SecondaryNameNode的架构：
如下图为NameNode和SecondaryNameNode的具体架构。
NameNode元数据内存和持久化
1.首先我们需要知道，NameNode的查询和修改的操作都是要经过内存的。但是因为内存是不安全的，为了保证系统的可用性也需要把元数据存储在磁盘上一份（这其实是大多数框架增加效率 和 维持可用性的方法）。
2.如果只存储一个文件，文件是一直增大的，久而久之，会变成一个巨大的文件。a.读写的效率非常低，b.磁盘损坏恢复数据效率会非常的低。
3.hdfs 选择了 两个文件的存储方式 edits 存储增量的元数据信息，fsimage存储全量的元数据信息。
4.其中edits文件是滚动更新的，每次符合checkPoint操作后都会滚动生成一个新的edits文件进行最新的元数据操作。
SecondaryNameNode checkPoint操作
dfs-default.xml
首先看一下这三个参数：
-参数名称- | -默认配置- | -解释- |
dfs.namenode.checkpoint.period | 3600s | The number of seconds between two periodic（周期性） checkpoints. Support multiple time unit suffix(case insensitive), as described in dfs.heartbeat.interval. |
dfs.namenode.checkpoint.txns | 1000000 | The Secondary NameNode or CheckpointNode will create a checkpoint of the namespace every ‘dfs.namenode.checkpoint.txns’ transactions, regardless of whether ‘dfs.namenode.checkpoint.period’ has expired. |
dfs.namenode.checkpoint.check.period | 60s | The SecondaryNameNode and CheckpointNode will poll the NameNode every ‘dfs.namenode.checkpoint.check.period’ seconds to query the number of uncheckpointed transactions. Support multiple time unit suffix(case insensitive), as described in dfs.heartbeat.interval. |
1.snn会定期去检测对应的nameNode是否符合checkNode的条件。详细信息如图中所示
2.符合条件，进行checkPoint操作
3.滚动生成一个新的edits_inprogress文件
4.拉取最新的fsimage文件和之前的edits_inprogress文件（Http）
5.加载到内存再生成一个chept文件
6.响应给NameNode 进行下载。
7.下载之后进行重命名，结束。
namenode元数据信息多目录配置
- 为了保证元数据的安全性
- 我们一般都是先确定好我们的磁盘挂载目录，将元数据的磁盘做RAID1 namenode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性。
- 多个目录间逗号分隔
- 具体配置如下：
hdfs-site.xml
<property>
<name>dfs.namenode.name.dir</name>
<value>file:///XX/install/hadoop-3.1.4/hadoopDatas/namenodeDatas,file:///path/to/another/</value>
</property>5.2读流程
如下所示为客户端读取HDFS数据的具体流程
- 1.DistributedFIlesystem.open（）获取InputStream，并且获取到了数据的元数据信息
- 2.返回FSDataInputStream 对象
- 3.构造DFSInputStream对象时，调用namenode的getBlockLocations方法，获得file的开始若干block（如下Block1, Block2, Block3）的存储datanode（以下简称dn）列表；针对每个block的dn列表，会根据网络拓扑做排序，离client近的排在前；
- 4.read数据 按照Block的分片顺序读取数据。
- 5.调用DFSInputStream的read方法，先读取Block1的数据，与client最近的datanode建立连接，读取数据
- 6.读取完后，关闭与dn建立的流
- 7.读取下一个block，如block的数据（重复步骤4、5、6）
- 8.这一批block读取完后，再读取下一批block的数据（重复3、4、5、6、7）
- 9、完成文件数据读取后，调用FSDataInputStream的close方法.
5.3 写流程
6.容错
7.其他
7.1小文件治理
7.2优点与缺点
1. hdfs的优点
(1) 高容错性
1) 数据自动保存多个副本。它通过增加副本的形式，提高容错性。
2) 某一个副本丢失以后，它可以自动恢复，这是由 HDFS 内部机制实现的，我们不必关心。
(2) 适合批处理
1) 它是通过移动计算而不是移动数据。
2) 它会把数据位置暴露给计算框架。
(3) 适合大数据处理
1) 数据规模：能够处理数据规模达到 GB、TB、甚至PB级别的数据。
2) 文件规模：能够处理百万规模以上的文件数量，数量相当之大。
3) 节点规模：能够处理10K节点的规模。
(4) 流式数据访问
1) 一次写入，多次读取，不能随机修改，只能追加。
2) 它能保证数据的一致性。
(5) 可构建在廉价机器上
1) 它通过多副本机制，提高可靠性。
2) 它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。
缺点
(1) 不适合低延时数据访问；
1) 比如毫秒级的来存储数据，这是不行的，它做不到。
2) 它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况 下是不行的，比如毫秒级以内读取数据，这样它是很难做到的。
(2) 无法高效的对大量小文件进行存储
1) 存储大量小文件的话，它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的。
2) 小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。 改进策略
(3) 并发写入、文件随机修改
1) 一个文件只能有一个写，不允许多个线程同时写。
2) 仅支持数据 append（追加），不支持文件的随机修改。
7.3 HDFS安全模式
8.总结
