Hadoop离线

文章目录

1 分布式文件系统设计思路以及文件系统的基本介绍1.1 设计思路1.2 文件系统的基本介绍 2 hdfs文件系统的设计目标3 hdfs的来源以及hdfs的架构图和副本机制以及block块存储3.1 来源3.2 架构图3.3 副本机制和block块存储 4 hdfs元数据信息详解以及fsImage元数据信息的查看4.1 详解4.2 fsImages元数据信息的查看 5 hdfs的edits元数据查看以及snn如何辅助管理namenode当中的元数据信息5.1 edits元数据查看5.2 snn如何辅助管理namenode当中的元数据信息 6 文件上传过程7 文件读取过程

1 分布式文件系统设计思路以及文件系统的基本介绍

1.1 设计思路

元数据信息记录： 只有一台机器时文件的查找方式：hello.txt /export/servers/hello.txt 多台机器时(需指定机器名称)：hello.txt node02 /export/servers/hello.txt

为了解决数据丢失的问题，引入了副本机制，也就是在一台机器done机时，可以在其副本机器中找到该文件

如果对文件进行切块存储，那么元数据信息又要继续变化 blk_00001 node01 node03 /export/servers/blk_00001 blk_00002 node02 node01 /export/servers/blk_00002 blk_00003 node03 node02 /export/servers/blk_00003

1.2 文件系统的基本介绍

Local：本地文件系统 HDFS：分布式文件系统 HSFTP：FTP文件系统 ftp:// 可以做文件的上传下载 WebHDFS：浏览器操作文件系统，可以允许我们通过浏览器上传、下载、修改HDFS上面的文件

2 hdfs文件系统的设计目标

硬件错误，由于集群很多时候由数量众多的廉价机组成，硬盘的损坏成常态（副本机制解决）数据流访问，所有应用以流的方式访问数据，设计之初边是用于批量的处理数据，而不是低延时的实时交互处理大数据集，假设所有存储到hdfs的数据都是海量的数据，不擅长处理小文件（因为一个小文件会占用一个元数据，元数据都存储在内存当中，大量的小文件会产生大量的元数据，导致占用NameNode大量内存）简单的相关模型，假设文件是一次写入，多次读取，不会有频繁的更新（比较擅长存储一些历史数据）移动计算比移动数据便宜，一个应用请求的计算，离它操作的数据越近，就余额高效多种软硬件的可移植性

3 hdfs的来源以及hdfs的架构图和副本机制以及block块存储

3.1 来源

起源于Google的GFS论文(GFS，Mapreduce，BigTable为google旧的三架马车) 发表于2003年10月 HDFS是GFS的克隆版

3.2 架构图

总结： Namenode：存储元数据，元数据保存在内存中或者磁盘，保存文件block和DataNode之间的映射关系 DataNode：存储文件内容，文件内容保存在磁盘上，维护block的id与DataNode本地文件的映射关系

NameNode主要负责管理文件系统的名字空间（namespace）以及客户端对文件的访问，还有存储元数据。DataNode则主要负责处理用户的读写数据。NameNode的元数据保存在两个地方，一个是内存，一个是磁盘。（磁盘存的是元数据的快照，如果快照非常大，停机再启动代价会非常大）

3.3 副本机制和block块存储

数据副本的存放机制： NameNode会首先找离客户端最近（跨交换机最少的）的一台机器上传block块，然后再去做备份(备份原则：与此机器同一交换机的另一台机器上和与此机器不同交换机的另一台机器上，为了防止交换坏掉)。 NameNode负责数据block块的复制。（定期检测block的副本数，如果不够3个，就进行复制） bolck块的大小，可以根据实际工作当中的文件特性来调整，如果都是一些大文件，可以微调block块的大小。这么做的原因可以举例来说明： 128M的bolck块：300M的文件会分成3个block块，要占用3个元数据 256M的block块，300M的文件只会分成2个block块，只需要占用2个元数据 这样可以有效节省NameNode的内存空间，这也是HDFS更擅长处理大文件的原因之一。

块缓存： distributedCache 可以用来实现我们的文件的缓存。

hdfs的权限验证 ：采用了与linux类似的权限验证机制，权限验证比较弱（防止好人做错事，不能阻止坏人做坏事）（HDFS相信你告诉我你是谁，你就是谁）

4 hdfs元数据信息详解以及fsImage元数据信息的查看

4.1 详解

hdfs元数据信息主要分为fsImage元数据和edits元数据 FSImage保存的是一份最完整的元数据信息（一份比较完整的元数据信息，存放在两个地方，一个是磁盘，一个是内存）。HDFS文件可以保存多少数据，取决于NameNode的内存大小，所以HDFS推荐存储大量的大文件，不擅长存储小文件。 edits保存的是最近一段时间操作的元数据信息。

4.2 fsImages元数据信息的查看

官方文档：http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsImageViewer.html

文件目录：cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current/ 编译命令：hdfs oiv -i fsimage_0000000000000000528 -o hello.txt -p XML oiv：为指定fsImages，-i：解析输出的目标文件，-o：输入文件，-p：解析方式为XML(字母都需大写)

5 hdfs的edits元数据查看以及snn如何辅助管理namenode当中的元数据信息

5.1 edits元数据查看

官方文档：http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsEditsViewer.html 文件目录：cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits/current/ 编译命令:hdfs oev -i edits_0000000000000000001-0000000000000000010 -o hello.txt -p XML oev：为指定edits，-i：解析输出的目标文件，-o：输入文件，-p：解析方式为XML(字母都需大写)

5.2 snn如何辅助管理namenode当中的元数据信息

SecondaryNameNode帮助namenode合并edits与fsImages 如何确定edits和fsimage合并了？(eidts文件达到一定大小，edits存活达到一定时间) 如果efits文件达到1G大小，合并一下 如果一直没有达到1G大小，达到一个小时就合并一下。

6 文件上传过程

客户端向namenode请求上传一个文件namenode反馈给客户端是否有权限上传客户端被通知拥有权限上传文件后，在客户端开始将文件切分成block块，并向NameNode询问第一个block块存储的位置通过机架感知原理，NameNode要找到离客户端最近（跨交换机最少的）的一台机器，并反馈给客户端客户端找到对应的DataNode以及对应block的id，然后开始建立RPC连接，并通过RPC连接建立一个pipeline当一个block传输完成之后，client再次请求NameNode上传第二个block到服务器，以此类推写入完毕，数据全部上传完成后，客户端会通知NameNode

客户端上传文件到datanode机器时使用的方式是udp，如果块上传时，上传到一半发时生了错误，不会继续上传，而是重新上传此块。block块存满之后，反向的校验机制会给客户端一个相应，告诉客户端第一个block已经保存，可以上传第二个block块……「block块ack机制」

7 文件读取过程

客户端发送请求，读取文件服务端(namenode)校验客户端是否有权限读取文NameNode查找元数据信息，找到这个文件对应的block块存储的位置客户端与DataNode通信建立socket通信，读取第一个block块直到所有的block块都读取完成后，在客户端进行block块的拼接，组成一个最完整的文件完毕

寻找规则，第一个找离客户端最近的block块找最近一次“心跳”的DataNode进行读取 block块读取到一半的时候抛错了，客户端会重新请求NameNode找出出错block的副本，找副本重新读，没有断点续传的功能