电脑基础 · 2023年3月19日

大数据-重新学习hadoop篇(第一天)-未完成

前言:

首先这次重新学习为了后面校招,我会把我每天复习学到的一些觉得重要的知识点进行总结下来,持续更新,为实习做准备,加深记忆,从今天开始可能就不会法leetcode的相关题解了,但是每天还是会做每日一题的,加油。

hadoop优势

1.高可靠性:Hadoop底层的hdfs会进行副本存储,当一台机器挂了的时候,它有副本就可以重新启动恢复

2.高扩展性:当双11这种网络拥堵情况出现的时候,可以扩充机器进行负载均衡,所以扩展性也是非常不错的

3.高效性:可以多节点同时工作和高可靠性相互依赖

4.高容错性:任务失败可以重新调度

hadoop的三个大版本显著区别(1.0,2.0,3.0)

对于hadoop1.0来说不存在YARN,没有资源调度,没有高可用,会出现单点故障

对于hadoop2.0来说增加了YARN,也有了多机器操作

对于hadoop3.0来说增加了HA,MapReduce得到了性能优化

hadoop的shell命令

首先有三个命令:

  1. hadoop fs:通用的文件系统命令,针对任何系统,比如本地文件,HDFS......(当文件系统是HDFS时候,与下面两个等效)

  1. hadoop dfs:特定针对HDFS的文件系统,但hadoop3.0之后不推荐用(但是这个bug比较少)

  1. hdfs dfs:hdfs文件系统的操作命令,建议用这个代替hadoop dfs的命令

我推荐用hadoop dfs因为我用hdfs dfs命令老有错误。。。

操作命令:
  1. 移动本地文件夹到HDFS端-moveFromLocal(注意一般的hdfs操作命令都是驼峰命名法)

hadoop dfs -moveFromLocal (本地文件夹位置) (HDFS文件夹位置)
  1. 复制本地文件到HDFS端-copyFromLocal

hadoop dfs -copyFromLocal (本地文件夹位置) (HDFS文件夹位置)

3.复制本地文件到HDFS端-put(与copyFromLocal用法一致,这个简单用的多)

hadoop dfs -put (本地文件夹位置) (HDFS文件夹位置)

4.复制HDFS端文件到本地-copyToLocal

hadoop dfs -copToLocal (HDFS文件夹位置) (本地文件夹位置)

5.复制HDFS端文件到本地-get

hadoop dfs -get (HDFS文件夹位置) (本地文件夹位置)

6.追加命令(因为HDFS不支持文件修改,或者说文件修改效率很低下)-appendToFile

如果要修改两种方法1.将hdfs文件get拉取到本地磁盘修改之后在put上去进行覆盖 2.追加

hadoop dfs -appendToFiile (本地文件夹位置) (HDFS文件夹位置)

7.一些其他的命令,类似于linux命令,Eg:ls,ll,cat,touch,chmod,tail .......

hadoop dfs -ls /

javaapi实现hdfs的读写过程

比较简单,没啥演示的,导入jar包,配置config,就可以使用了......

hdfs写入数据的流程

1. 用户请求数据namenode数据是否可以上传

2. namenode进行数据响应 第一点:查看该用户是否有权限进行写 第二点:查看上传目录是否可行

3. namenode响应结果(根据复制负载均衡和节点可用性来选择datanode)给用户(并且自己会将元数据存入本地磁盘保存,后面会说),用户开启流传输通达通道,每次发送一个block(0-128m)大小的资源

4. 用户准备发送,FsDataoutStream流发送,以最小单位chunk开始(512byte内容+4byte头文件),当chunk到达64k时候进行打包以流的形式发送到datanode

5. datanode被namenode选择好了之后,建立两个管道,第一个是传输管道,第二个是ACK应答管道(保证数据的完整性,如果机器挂断,后面还可以恢复)

6.数据传输采用串行方式进行传输,传给第一个datanode后,它一边接受一般往后面其他副本datanode进行传输,然后等代它们的ACK应答

网络括扑,节点距离计算

简单,不重要,了解即可,类似与树找父母节点

副本选择(根据源码读取得到结论)

1.第一步找到一个最近机架放至第一个副本

2.第二个是与第一个节点不同机架的最近机架(高可用性)

3.第三个是与第二个节点相同机架的不同节点(高效性)

解释:首先第一个节点找最近的是没啥好说的,第二个节点找不同就是为了宕机之后的恢复,高效性的体现,第三个与第二个在同一个机架是为了防止网络传输导致性能损失,因为第一个节点与第二个节点传递时候要建立一个网络连接(跨机架连接),第二个与第三个也要建立,但如果第二个和第三个在同一个机架的话,就可以避免跨机架传输减少网络资源浪费

为什么block大小一般是128m??(新浪面试题)

因为这个与硬盘传递效率有关,当hdfs找资源的时间为10ms时,我们理想状态下,当寻找时间是传递时间的百分之10的时候最为理想,所以传递时间为1s,正常我们的机械硬盘传递速度是100mb/s,好公司的固态硬盘可以达到200mb/s,所以当100mb/s的时候我们block为128mb时是最理想的(1024进制,不能是100mb吧?),所以大公司一般的block大小是256m

Hdfs读取数据流程

1.首先客户端向namenode发送读取请求,namenode根据1.用户权限 2.内容有效性(根据元数据是否存在)

2.namenode将元数据返回给客户端,客户端创建FsDataInputStream流进行block读取

3.根据负载均衡(每个datanode都有副本)来读取对应的datanode

4.串行从datanode读取好对应的block后,进行拼接就可以得到

namenode和Secondnamenode工作原理(重点)

一般开发环境下是不存在2nn的,因为有HA可以完美完成2nn的工作(因为2nn的内容没有nn完全,毕竟是秘书)

有个问题就是将namenode的元数据存在内存还是磁盘呢?

1.内存 计算速度快,但是宕机之后数据就没了,安全性不好

2.磁盘 计算速度慢,但是持久化到磁盘的话是安全的

有人说两个一起用?只会更慢........

我们根据core-site.xml发现了元数据和hdfs的存储数据在data目录里面

大数据-重新学习hadoop篇(第一天)-未完成

找到这个目录查询档期那namenode到底存了什么,进入这个目录?

大数据-重新学习hadoop篇(第一天)-未完成

发现有两个目录dfs和nm-local-dir

进入nm-local-dir,我们发现是一些内存缓存(cache)

大数据-重新学习hadoop篇(第一天)-未完成

进入dfs,第一个data文件进去一直点是我们hdfs的副本的实时存储文件,里面存放我们的hdfs内容

大数据-重新学习hadoop篇(第一天)-未完成

进入第二个name,in_use.lock是缓存

大数据-重新学习hadoop篇(第一天)-未完成

再进入current,发现了namenode的存储内容(重点)

大数据-重新学习hadoop篇(第一天)-未完成

1. edits_0000000000000011702-0000000000000011703 是我们的操作内容(加密了无法查看)

2. edits_inprogress_0000000000000011704 可以理解为我们正在操作的内容(和后面的2nn有关系)

3. fsimage_0000000000000011701 和 fsimage_0000000000000011701.md5 是镜像序列话的文件,md5是加密文件

4. seen_txid记录当前操作的id,VERSION记录当前版本

然后我们进入2nn的目录,因为我是集群,所以我的2nn在另一个虚拟机上面

大数据-重新学习hadoop篇(第一天)-未完成

进入namesecondary

大数据-重新学习hadoop篇(第一天)-未完成

一直进到底

大数据-重新学习hadoop篇(第一天)-未完成

发现和我们的nn是一样的配置,但是少了一个edits_inprogress_0000000000000011704,seen_txid

所以我们现在来看两个的工作机制会更清楚,再说之前提一句,fsimage文件是存储数据结果的,因为hdfs无法进行修改只能追加,edits是将操作过程记录下来,最后服务器启动的时候就会将二者合起来生成新的edits加载到内存

1.当启动服务器的时候fsimage(镜像文件)文件和edits(编辑日志)合并起来放到内存里面

2.当用户的CRUD操作来了之后,我们会先修改inprogress文件再同步到内存的edits(因为这样安全,防止突然宕机引起丢失数据)

3.2nn会规律的向nn发送checkpoint请求(1.一小时 2.当edits内容到100w条的时候)

4.如果checkpoint得到响应之后,2nn会把nn里面的inprogress和edits拉到磁盘进行合并,在自己磁盘里面进行备份(就是我们看到的那些edits文件,
但是没有inprogress,因为2nn不做资源调度


5.合并完成之后备份了之后,发送给nn,形成新的edits,并且nn建立一个新的fsimage覆盖原来的fsimage,之后用户的CRUD都会在新的fsimage进行备份存储

(2023.3.15.23点05分 )

我找到了一些方法查看fsimage镜像文件的方法

hdfs oiv -p 文件类型 -i 编辑日志 -o 转换后文件输出路径

查看edits文件的方法

hdfs oeev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径

我们用上面方法打开文件进行查看

大数据-重新学习hadoop篇(第一天)-未完成

打开xml文件

大数据-重新学习hadoop篇(第一天)-未完成

往下翻,下面有我们的树目录,里面记载了我们的父节点和子节点,也就是我们所说的上级目录和下级目录

大数据-重新学习hadoop篇(第一天)-未完成