写在前面：可先去看这篇文章《Hadoop生态剥茧抽丝（一），【中枢神经】Yarn的job流程》

一、hdfs写数据流程

1. 客户端通过DistriButed FileSystem模块向NameNode(Yarn系统中的ApplicationManager→ResourceScheduler→NodeManager)请求上传文件，NameNode（NodeManager）检查目标文件是否已经存在，父目录是否存在，不能上传会返回异常； 若通过检查，直接先将操作写入EditLog，并返回输出流对象;
2. 客户端确定可以上传后，客户端请求第一个block（单位：128Mb）上传到哪几个datanode服务器上;
3. Namenode返回三个datanode节点，假定分别为dn1、dn2、dn3;
4. 客户端通过FSDataOutputStream模块请求dn1上传数据， client将NameNode返回的分配的可写的数据集（DataNode列表和Data数据）一同发送给dn1,dn1收到数据集会继续发送给dn2,然后dn2发送dn3;
5. dn1、dn2、dn3逐渐应答客户端,通信管道（pipeline）建立完成;
6. 客户端开始往dn1上传第一个block(先从磁盘读取数据放到一个本地内存缓存)，以packet(64kb)为单位，dn1收到一个packet就会传给dn2,dn2传给dn3;dn1每传一个packet会放入一个应答队列等待应答(packet传完了，逐级应答);
7. 当一个block传输完成之后，客户端再次请求NameNode上传第二个block的应答队列;
8. 直到写完所有出局，关闭输出流， 发送完成信号给NameNode,关闭Yarn中相应的Application Master;

简化流程

client发送上传请求→NameNode确认是否可以上传→client开始上传→datanode构建通信管道→开始上传（缓存packet单位为：64kb）→ 上传完成后关闭流→通知NameNode关闭相应进程

流程图

二、hdfs读数据流程

1. 调用FIleSystem.open()方法，获取到DistributeFileSystem 实例；
2. Distribute FileSystem向NameNode发起RPC(远程过程调用)请求获得文件的开始部分或全部block列表，对于每个返回的block,都包含块所在的DataNode地址。这些DataNode会按照Hadoop定义的集群拓扑结构得出客户端的距离，然后再进行排序。根据就近原则读取文件，如：如果客户端本身就是一个DataNode,那么它极有可能从本地读取文件；
3. 同样需要确认目标目录是否存在，文件是否存在（存在则默认为追加），确认完成后，DistributedFileSystem会向客户端返回输入流对象FSDataInputStream，用于客户端读取数据。FSDataInputStream包含一个DFSInputStream对象，这个对象用来管理DataNode和NameNode之间的流；
4. 客户端中对象DFSInputStream找出离客户端最近的datanode（存放了所需的数据节点）的location，client客户端与相应的dataNode建立连接开始调用read方法读取数据，直至数据读取完成，关闭对应的连接，接着读取下一个block块
5. 读取完毕（所有的块合并成一个完整的最终文件），关闭输入流

简化流程：

client使用open方法，读取节点信息 → Namenod返回所需数据所在的节点locations → 根据DFSInputStream对象获取节点定位，根据就近原则开始并行读取数据 → 读取完成，关闭输入流

注：获取block信息是并行的，读取也是并行的，NameNode只是返回所请求的DataNode地址，并不是返回块数据

读数据流程图

三、名词

NameNode(Master)在HDFS中：

称为元数据节点（只能同时存在一个活跃的NameNode）：管理数据块block映射信息及副本信息：一个文件对应的块名及其块地址，以及每一个文件备份的数量

DataNode(slave)：实际存储数据块的节点，执行数据库的读写操作

SecondaryNameNode作用：

一是镜像备份，二是日志与镜像的定期合并（合并nameNode中的edit logs到fsimage中）

四、常见问题

① NameNode的启动过程？

第一阶段：NameNode启动

① 如果是第一次启动（NameNode格式化后第一次），则创建edit logs和fsimage文件，若不是第一次启动，则直接加载编辑这两个文件到内存
② 客户端（client）对元数据（存储在datanode）的增删改请求
③ NameNode操作先写入日志，更新滚动日志
④ NameNode下达相关指令

第二阶段：Secondary NameNode工作

① 询问NameNode是否需要checkpiont
② 执行checkpoint，拷贝日志文件（临时的）edit logs入镜像文件fsimage.checkpiont中
③ 定期执行合并操作（日志与镜像的定期合并）
④ 合并后的文件重命名为fsimage

② 集群的安全模式？：只支持访问元数据

语法：
查看安全模式：bin/ hdfs dfsadmin -safemode gets
进入安全模式：bin/ hdfs dfsadmin -safemode enter
离开安全模式：bin/ hdfs dfsadmin -safemode leave
等待安全模式：bin/ hdfs dfsadmin -safemode wait

③ 什么时候进入安全模式？

① 集群启动的过程中是安全模式，集群启动完成时，系统文件中99.9%（可设置）的块满足最小副本条件30s后解除安全模式;
② 当集群的block有缺失，丢失数量达到一个阈值时，具体表现为：系统文件中99.9%（可设置）的块不满足最小副本条件;
最小副本条件默认值：dfs.replication.min=1(最少要一个副本时)，第一次启动一个刚刚格式化的集群时不会进入安全模式

④ 解除安全模式的方法？

① 修复损坏的块文件，使其满足退出安全模式的条件
② 调低上述99.9%的阈值

<name>dfs.namenode.safemode.threshold-pct</name><value> 0 .999f</value>

③ 强制离开（临时用）

hdfs dfsadmin -safemode leave

④ 格式化集群（不推荐）

⑤ HDFS的可靠性策略？

① 文件完整性：

1. 文件创建时，每个块都会进行校验，校验和会存储在.meta文件中
2. 客户端获取数据时，同样会检测校验和是否相同，从而发现数据块是否损坏
3.  正在读取的数据块损坏，转而读取其他副本；NameNode发现数据库损坏，重新备份相应数据块以达到预设的备份数量
4.  DataNode在文件创建三周后验证数据库的checksum

② 网络或DataNode故障?

1.  副本冗余
2. 当DataNode宕机/网络故障时，Yarn系统不会马上下线该节点，会等待10分30秒（心跳感知策略），再将该DataNode下线
3. DataNode下线，集群会根据：机架感知策略，重新备份下线节点中的数据，保证副本的冗余

③ NameNode宕机？

1. 备用切换成主节点（namenode）,从而保证集群的高可用性
2. SeconderyNamenode镜像文件和操作日志磁盘存储
3. SeconderyNamenode镜像文件和操作日志磁盘存储多份，多磁盘存储

④ 其他保障可靠性策略？

1. 快照（保存集群的某个时刻影象，必要时可以进行还原）
2. 回收站机制：启用该机制后，FS Shell删除的文件不会立即从HDFS中删除，而是将其移动到回收目录中 （每个用户在/user /<username>/.Trash下都有自己的回收目录）
3. 安全模式：数据块损坏到了一个阈值，会进入安全模式

⑥ HDFS的优点：

① 高容错：数据冗余，且副本损坏后，会自动恢复
② 适合大数据处理：GB以上级别的海量数据，1000以上的节点规模
③ 流式数据访问：一次写入，多次读取
④ 成本廉价性：可部署在廉价的机器上
缺点：
① 不适合低延迟的数据访问：如毫秒级别的，低延时，高吞吐
② 无法并发写入，只能有一个写入者，不支持文件修改只能追加
③ 不适合小文件存取：每个数据块对应在NameNode的元数据需要150字节，一个小文件则占据一个元数据，大量的小文件存取对NameNode内存压力过大

集群的NameNode格式化后，使用start-all.sh启动datanode无反应？原因是namenode格式化后存储对应datanode的clusterId改变了，与原来的datanode的clusterId对应不上

datanode在强制关闭或异常断电情况下无法自动重新备份数据
datanode宕机后，重新将节点格式化后，当成新节点加入集群

HDFS的存储格式：

① sequenceFile:
1. 无压缩:io效率查
2. 记录级压缩：每条记录都压缩，压缩效率一般
3. 块级压缩：将到达一定大小的文件压缩

② Avro标记:数据定义（以json格式存储）和数据（二进制）一起存储在一条消息中，用于标记Mapreduce处理的子集
③ RCFile:行格式存储列数据
④ Parquet:Hadooop列存储格式，具有高效压缩和编码方案

HDFS的压缩算法

1. lzo:较快的压缩速率，较Gzip低的压缩效率，支持split,压缩后大于200M的优先考虑
2. Gzip:不错的压缩效率和速率，不支持split,文件压缩后在130M以内的优先考虑
3. Bzip2：压缩速率慢，比Gzip高的压缩效率，支持split,不支持native,可做为MapReduce作业的输出格式
4. snapp:不支持split，较Gzip高的压缩效率和压缩速率，不支持split,可作为Map、Ruduce之间的中间数据压缩格式，或者作为一个MapReduce的输出，另一个MapReduce的输入