分布式文件系统hdfs的介绍

• 1.1 hadoop的文件系统
• 1.2 hdfs分布式文件系统设计的目标：
• 1.3 HDFS的架构图之基础架构
• • 1.3.1 NameNode与Datanode的总结概述
• 1.4 secondarynameNode如何辅助管理FSImage与Edits文件

hadoop的文件系统：
文件系统：是一个顶层的抽象，具体的实现，需要取决于你自己的获取的实例，
我们可以通过文件系统获取本地文件系统，操作linux磁盘上面的文件，也可以获取分布式文件系统，操作hdfs上面的文件
ftp:// ftp文件系统 可以做文件的上传下载
webHdfs：浏览器操作文件系统,可以允许我们通过浏览器上传，下载，修改，hdfs上面的文件
hdfs：分布式文件系统，最重要的一个
local：本地文件系统

• 1、硬件错误是常态，特别是硬盘的损坏是常态 副本机制
• 2、数据流访问 所有的访问都是访问大量的数据，使用IO流一直操作，追求的是稳定，不是效率
• 3、大数据集 假设所有存储到hdfs的数据都是海量的数据，不擅长处理小文件，一个小文件占用一个元数据，元数据都存储在内存当中，占用namenode的大量内存
• 4、简单的相关模型 假设文件是一次写入，多次读取，不会有频繁的更新，比较擅长存出一些历史数据
• 5、移动计算比移动数据便宜
• 6、多种软硬件的可移植性

1、 NameNode是一个中心服务器，单一节点（简化系统的设计和实现），负责管理文件系统的名字空间（namespace）以及客户端对文件的访问
2、 文件操作，namenode是负责文件元数据的操作，datanode负责处理文件内容的读写，跟文件内容相关的数据流不经过Namenode，只询问它跟哪个dataNode联系，否则NameNode会成为系统的瓶颈
3、 副本存放在哪些Datanode上由NameNode来控制，根据全局情况作出块放置决定，读取文件时NameNode尽量让用户先读取最近的副本，降低读取网络开销和读取延时
4、 NameNode全权管理数据的复制，它周期性的从集群中的每个DataNode接收心跳信息和状态报告，接收到心跳信号意味着DataNode节点工作正常，块状态报告包含了一个该DataNode上所有的数据列表

namenode负责更新保存元数据信息
datanode负责处理用户的读写数据
客户端通过namenode查找某个数据的所有的block块在哪些datanode上面，然后就去datanode上面读取数据
数据副本的存放机制：namenode会首先找离客户端最近的一台机器上传block块，然后再去做备份
namenode负责数据block块的复制，定期的检测block的副本数，如果不够3个，继续复制出来保证足够三个

①：secnonaryNN通知NameNode切换editlog
②：secondaryNN从NameNode中获得FSImage和editlog(通过http方式)
③：secondaryNN将FSImage载入内存，然后开始合并editlog，合并之后成为新的fsimage
④：secondaryNN将新的fsimage发回给NameNode
⑤：NameNode用新的fsimage替换旧的fsimage

完成合并的是secondarynamenode，会请求namenode停止使用edits,暂时将新写操作放入一个新的文件中（edits.new)。secondarynamenode从namenode中通过http get获得edits，因为要和fsimage合并，所以也是通过http get 的方式把fsimage加载到内存，然后逐一执行具体对文件系统的操作，与fsimage合并，生成新的fsimage，然后把fsimage发送给namenode，通过http post的方式。namenode从secondarynamenode获得了fsimage后会把原有的fsimage替换为新的fsimage,把edits.new变成edits。同时会更新fstime。
hadoop进入安全模式时需要管理员使用dfsadmin的save namespace来创建新的检查点。
secondarynamenode在合并edits和fsimage时需要消耗的内存和namenode差不多，所以一般把namenode和secondarynamenode放在不同的机器上。
fs.checkpoint.period: 默认是一个小时（3600s)
fs.checkpoint.size:  edits达到一定大小时也会触发合并（默认64MB)