HDFS 的复习
这里我们会分别从不同的角度，去阐述讲解HDFS的不同方面
- 写入HDFS
其整体流程为，client端连接NameNode，NameNode分别检查文件名和上传人的权限
当通过之后，client 会将文件按照默认128m的大小进行切分，并准备上传。
切分之后，对于每一个子块，都会去联系NameNode，获取可以上传的DataNode，
而NameNode返回DataNode则根据一定的规则的进行分配。
一般来说返回三个DataNode地址，默认选择一个节点，以及同机架上另一个节点一份，不同机架上上一份
客户端得到了DataNode列表之后，选择某一个进行连接，这个节点我们假设是A节点，A节点收到了请求，会尝试连接其他的节点，形成一个Pipline，这样在上传数据的时候，client调用A，A调用B，B调用C。 然后之后C返回Ack给B，B返回给A，A返回client
这样一个子块就上传完成了，之后Client 再请求NameNode，NameNode再返回三个 DataNode给client。
由写入HDFS引申出的问题有，如果上传的时候DataNode挂掉怎么办，这对应的流程为上传流程为一个piepline，所以当管道的某一环出现问题的时候，会导致client上传超时，因此client可以根据能收到的ack判断出哪个DataNode出现了问题，那么会和NameNode联系，并由NameNode下线DataNode
- 读取HDFS
在读取的时候，会尝试连接Name Node，请求block的位置
然后校验文件和权限，并返回block列表，对于每个分块，返回的block列表则是排序之后的，排序的规则则是根据client 的远近，心跳状态进行返回
之后client根据DataNode读取block，这个过程是并行的，同时读取多个分块文件，之后进行合并。
引申的问题是如果读取的时候，某个分块文件损坏，或者某个DataNode下线了怎么办
这时候会联系NameNode，获取到新的DataNode的地址。
- NameNode的元数据存储和架构
NameNode中包含fsimage镜像文件和edits编辑日志文件
类似mysql中的checkpoint一样，会不断的进行合并，将fsimages和edits文件合并为新的fsimage文件。
因此引申出的问题是关于secondary namenode，其工作机制是不断的合并edits log到fsimags文件中
询问NameNode是否需要checkpoint，然后根据返回来决定是否将合并
之后是将edits文件和当前的fsimage文件合并为一个临时文件，之后将这个临时文件copy到namenode上，最后重命名替换
还有就是NameNode的高可用
对于这一点的解决方案，则是采用NameNode HA
对于NameNode HA的实现，常见的有QJM的实现方案，Quorum Jorunal Manager
也就是拥有一个共享存储的基础上，只保存EditLog，并采用二阶段提交的方式进行分布式保存，关于Paxos算法，可以继续查看。
还有如果NameNode涉及到了脑裂问题怎么办？
如果涉及到了脑裂问题，最简单的是根据集群大小判断自己是否可以继续提供服务
如果已经无法对外提供服务，则会尝试将自己转换为Standby状态，不然就考虑杀死自己。
- HDFS中小文件过多的问题
因为文件对应的元数据大小是相对固定的，那么过多的小文件必然会压垮NameNode内存
- HDFS的组织架构
简单的可以分为Client，NameNode，DataNode，Secondary NameNode
Client 客户端，负责通过命令管理HDFS集群，可以上传文件，下载文件
NameNode 名称节点，主节点，负责存储元数据，包括block存储在哪些DataNode上，当client期望去读取的时候，可以将对应的存储DataNode返回，并且可以配置存储策略，从而控制哪些数据存储在哪些DataNode上
DataNode 数据节点，负责实际的数据存储，以及返回给client真正的文件内容
Secondary NameNode 当NameNode挂掉的时候，并不是替换NameNode，主要是用于辅助NameNode，帮其定期的合并Fsimage，Edits log
- MR中的Map，Reduce以及Shuffle阶段的流程
Map阶段首先涉及到了读取文件
需要进行简单的分片，分为更细粒度的小文件，然后进行简单的map处理之后，交给Collect
之后进行分区，写入buffer。在buffer中可能涉及到多次的落盘，在所有的数据落盘之后进行合并。最终生成输出文件。并提供了索引文件，方便不同的reduce进行拉取
Reduce阶段则是进行合并输出
则是可以分为copy，sort，reduce三个阶段，对应的是从不同的Map算子拉取文件，
以及将从不同map算子获取到的数据文件进行排序汇总
最终根据用户声明的reduce阶段进行处理计算
初次外还有Shuffle阶段
对于这样的一个阶段，MR或者Spark中都是着重设计的
这个阶段并不是对应着实际的算子，但是其在各个阶段都存在
这个阶段大致可以为在Map阶段的落盘，merge，之后就是相关的copy这一阶段则是根据map阶段的分区逻辑计算好了，从而方便reduce算子的copy
当然需要注意的一点是，由于Map阶段会进行不断的分区落盘，那么缓冲区的大小和map阶段的执行效率就有关联，其大小可以通过参数调整
- 中间状态传输时支持的压缩类型
由于涉及网络传输，那么中间状态的文件如果可以传输时可以减少发送量的
Gzip，bzip2，LZO，LZ4，Snappy这些压缩算法都是支持的，不过一般考虑Snappy
- MR with YARN是怎么样的一个架构
首先是一个统领全局的ResourceManager，其是一个全局的资源管理器，负责整个系统的资源管理和分配，主要由两个部分组成，调度器和应用程序管理器
然后是实际对应执行的MR任务的ApplicationMaster
一个应用程序都会对应一个ApplicationMaster，其会从RM中申请并获取到资源
并且去监控所有子任务的状态，确定任务是否正常执行
除此外还有就是NodeManager，对应的是yarn的各个执行节点
那么整体的一个执行任务流程就是
首先是提交完成了应用程序，之后是创建一个ApplicationMaster，那么对应的ResourceManager会为这个应用程序先分配NodeManager，并尝试启动这个ApplicationMaster
之后是ApplicationMaster启动完成，向ResourceManager进行注册，然后拆分为各个子任务，并为子任务申请资源
RM会分配资源，以Container的形式返回
AM在获取到资源之后，会和NodeManager通信，在其上面启动对应的子任务
子任务会不断的向ApplicationMaster回报自身状态，以便失败的时候重启任务
最后ApplicationMaster向Resource Manager注销并关闭自己