1. 配置hadoop的windows依赖
1.1 将windows依赖 hadoop-3.1.0 拷贝到一个固定的位置.
例如: E:\hadoop\hadoop-3.1.0
1.2 配置环境变量
1) 新建变量
HADOOP_HOME=E:\hadoop\hadoop-3.1.0
2) 修改变量
path=......(不要改不要删已有内容);%HADOOP_HOME%\bin
2. NameNode 和 SecondaryNamenode 的工作机制:
2.1 NameNode是干啥的?
最主要负责的事情就是对整个HDFS中数据的元数据进行管理.
2.2 NameNode管理的元数据存在哪里? 内存+磁盘.
考虑数据的安全性或者是可靠性,元数据存到磁盘比较安全.
如果数据维护到磁盘,数据的安全可以保障。但是带来的问题是
访问效率低. 因为修改元数据是在磁盘进行修改的。因此效率低.
考虑到效率的问题,元数据存储到内存效率高. 带来的问题是数据
不安全.因为内存的数据容易丢失,比如服务器掉电或者其他故障等...
结论: 内存和磁盘都存.
2.3 如何在实现高效操作元数据的情况下,还能实现内存+磁盘的维护方案.
HDFS 通过 fsimage(镜像文件) + edits(编辑日志)的方案来解决问题.
镜像文件: 某个时刻对NN内存中元数据的一个快照. 镜像文件 <= NN内存中数据
编辑日志: 记录对HDFS的改操作.只做追加操作,因此效率高.
2.4 如果一直往edits文件中追加内容,改文件会变的特别大, 且会越来越大, 因此
需要隔一段时间或者合适的时机进行 fsimage + edits文件的合并工作, 从而生成
新的fsimage
新的fsimage = 旧的fsimage + edits
将fsimage 和edits的合并工作交给2nn完成. 大概的过程就是将nn机器对应的磁盘上的
fsimage 和 edits文件拉取到2nn的机器中,在2nn的机器中将fsimage + edits都读取到
内存中进行合并,然后生成新的fsimage ,再推送到nn机器中的磁盘上,nn中旧的fsimage
会保留,新的fsimage对应的是正在使用.
2.5 具体的工作细节:
-
NN启动时,需要自己先将磁盘的fsimage_current + edits001_progress 文件进行一次合并. 在内存中构建好元数据信息
-
当对HDFS进行改操作, 首先会在edits001_progress(正在使用的编辑日志)记录对应的操作,
然后对NN内存中的元数据进行相应的修改. -
2NN会每隔1个小时或者当 edits001_progress中已经记录了100万次的操作后,开始进行fsimage_current 和edits001_progress的合并
-
NN会将edits_progress进行所谓的滚动,说白了就是该文件不能再进行写入操作,会生成另外一个编辑日志文件
用于记录后续的写操作.
滚动正在使用的编辑日志: edits001_progress --> edits001
新的编辑日志: edits002_progress -
2NN 将NN中的fsimage_current 和 edits001 拷贝过来。加载到内存中进行合并. 合并完成后会生成新的fsimage_new.
-
2NN 将fsimage_new 推送到NN中, fsiamge_current --> fsimage_old 会保留,
fsimage_new -->fsiamge_current .
相当于会保留一份新的fsimage 和一份旧的fsiamge. -
总结: NN内存中的数据 = 磁盘上正在使用的fsimage + 正在使用的edits文件.
重点
- HDFS API
- 分析NN 和 2NN的工作机制.