前言：
首先这次重新学习为了后面校招，我会把我每天复习学到的一些觉得重要的知识点进行总结下来，持续更新，为实习做准备，加深记忆，从今天开始可能就不会法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命令
首先有三个命令：
-
hadoop fs：通用的文件系统命令，针对任何系统，比如本地文件，HDFS......（当文件系统是HDFS时候，与下面两个等效）
-
hadoop dfs：特定针对HDFS的文件系统，但hadoop3.0之后不推荐用（但是这个bug比较少）
-
hdfs dfs：hdfs文件系统的操作命令，建议用这个代替hadoop dfs的命令
我推荐用hadoop dfs因为我用hdfs dfs命令老有错误。。。
操作命令：
-
移动本地文件夹到HDFS端-moveFromLocal(注意一般的hdfs操作命令都是驼峰命名法)
hadoop dfs -moveFromLocal (本地文件夹位置) (HDFS文件夹位置)-
复制本地文件到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目录里面
找到这个目录查询档期那namenode到底存了什么，进入这个目录？
发现有两个目录dfs和nm-local-dir
进入nm-local-dir，我们发现是一些内存缓存（cache）
进入dfs，第一个data文件进去一直点是我们hdfs的副本的实时存储文件，里面存放我们的hdfs内容
进入第二个name，in_use.lock是缓存
再进入current，发现了namenode的存储内容（重点）
1. edits_0000000000000011702-0000000000000011703 是我们的操作内容（加密了无法查看）
2. edits_inprogress_0000000000000011704 可以理解为我们正在操作的内容（和后面的2nn有关系）
3. fsimage_0000000000000011701 和 fsimage_0000000000000011701.md5 是镜像序列话的文件，md5是加密文件
4. seen_txid记录当前操作的id，VERSION记录当前版本
然后我们进入2nn的目录，因为我是集群，所以我的2nn在另一个虚拟机上面
进入namesecondary
一直进到底
发现和我们的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 转换后文件输出路径我们用上面方法打开文件进行查看
打开xml文件
往下翻，下面有我们的树目录，里面记载了我们的父节点和子节点，也就是我们所说的上级目录和下级目录
