Hadoop的读写流程
HDFS的文件读取过程
1、 Client向NameNode发起RPC请求，来确定请求文件block所在的位置；
2、 NameNode会视情况返回文件的部分或者全部block列表，对于每个block，NameNode 都会返回含有该 block 副本的 DataNode 地址； 这些返回的 DN 地址，会按照集群拓扑结构得出 DataNode 与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离 Client 近的排靠前；心跳机制中超时汇报的 DN 状态为 STALE，这样的排靠后；
3、 Client 选取排序靠前的 DataNode 来读取 block，如果客户端本身就是DataNode,那么将从本地直接获取数据(短路读取特性)；
4、 底层上本质是建立 Socket Stream（FSDataInputStream），重复的调用父类 DataInputStream 的 read 方法，直到这个块上的数据读取完毕；
5、 当读完列表的 block 后，若文件读取还没有结束，客户端会继续向NameNode 获取下一批的 block 列表；
6、 读取完一个 block 都会进行 checksum 验证，如果读取 DataNode 时出现错误，客户端会通知 NameNode，然后再从下一个拥有该 block 副本的DataNode 继续读。
7、 read 方法是并行的读取 block 信息，不是一块一块的读取；NameNode 只是返回Client请求包含块的DataNode地址，并不是返回请求块的数据；
8、 最终读取来所有的 block 会合并成一个完整的最终文件。
HDFS的文件写入过程
1、 client发起文件上传请求，通过RPC与NameNode建立通讯，NameNode检查目标文件是否已存在，父目录是否存在，返回是否可以上传；
2、 client请求第一个block该传输到哪些DataNode服务器上；
3、 NameNode根据配置文件中指定的备份数量及机架感知原理进行文件分配，返回可用的DataNode的地址如：A，B，C；
注：Hadoop在设计时考虑到数据的安全与高效，数据文件默认在HDFS上存放三份，存储策略为本地一份，同机架内其它某一节点上一份，不同机架的某一节点上一份。
4、 client请求3台DataNode中的一台A上传数据（本质上是一个RPC调用，建立pipeline），A收到请求会继续调用B，然后B调用C，将整个pipeline建立完成，后逐级返回client；
5、 client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（默认64K），A收到一个packet就会传给B，B传给C；A每传一个packet会放入一个应答队列等待应答。
6、 数据被分割成一个个packet数据包在pipeline上依次传输，在pipeline反方向上，逐个发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipelineack发送给client;
7、 当一个block传输完成之后，client再次请求NameNode上传第二个block到服务器。
写的过程中给会涉及到预写日志，每有操作会先记录到editlog，edits修改时元数据也会更新（每次hdfs更新时edits先更新后客户端才会看到最新信息）。当NameNode启动的时候，SecondaryNameNode第一次会先拉取一份完整的fsimage和editlog到内存中，执行editlog里的操作命令成为新的fsimage。Editlog满了会拉取下一份NameNode新的editlog，删掉原来的。最后SecondaryNameNode会将新的fsimage发回给NameNode，NameNode用新的fsimage替换旧的fsimage。
SecondaryNameNode（辅助NamNode合并fsimage和edits文件）出现的原因
如果NameNode执行了很多操作的话，就会导致edits文件会很大，那么在下一次启动的过程中，就会导致NameNode的启动速度很慢，慢到几个小时也不是不可能的，所以出现了SecondNameNode。
NameNode的存储目录树的信息，而目录树的信息则存放在fsimage文件中，当NameNode启动的时候会首先读取整个fsimage文件，将信息装载到内存中。
fsimage:是namenode中关于元数据的镜像，一般称为检查点。fsimage内容包含了namenode管理下的所有datanode中文件及文件block及block所在的datanode的元数据信息。
Edits文件存储日志信息，在NameNode上所有对目录的操作，增加，删除，修改等都会保存到edits文件中，并不会同步到fsimage中，当NameNode关闭的时候，也不会将fsimage和edits进行合并。随着edits内容增大，就需要在一定时间点和fsimage合并。是由core-site.xml里这两个配置参数决定的fs.checkpoint.period: 默认是一个小时（3600s)、fs.checkpoint.size: edits达到一定大小时也会触发合并（默认64MB)
Yarn的三种调度器
在Yarn中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，FairS cheduler。它们的区别如下：
1、FIFO Scheduler
FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。
2、Capacity Scheduler
Capacity Schedule调度器以队列为单位划分资源，队列以分层方式组织资源,设计了多层级别的资源限制条件以更好的让多用户共享一个Hadoop集群，比如队列资源限制、用户资源限制、用户应用程序数目限制。
队列里的应用以FIFO方式调度，每个队列可设定一定比例的资源最低保证和使用上限，同时，每个用户也可以设定一定的资源使用上限以防止资源滥用。而当一个队列的资源有剩余时，可暂时将剩余资源共享给其他队列。
3、Fair Scheduler
在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如下图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，在下图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
Yarn执行流程
1.client向yarn提交job，首先找ResourceManager发起请求
2.ResourceManager开启一个Container(资源抽象),在Container中运行一个Application manager
3.Application manager找一台nodemanager启动Application master
4.Application master向Application manager申请运行任务所需的资源
5.Resource scheduler将资源分发给Application master
6.Application master将获取到的资源分配给各个nodemanager
7.各个nodemanager得到任务和资源开始执行map task
8.map task执行结束后，开始执行reduce task
9.reduce task执行完后将结果反馈给Application master
10.Application master再反馈Application manager
11、Application manager向ResourceManager注销任务并释放资源。(历史任务将会保存到logs里)