Hadoop
HDFS
组成部分
NameNode（NN）：负责存储元数据，处理用户访问请求， 提供读写路径；
Secondary NameNode：主要用于对主节点中的FsImage和追加文件进行合并重写，FsImage和追加文件EditLog的关系类似于Redis中的RDB和AOF；
Activate NameNode：负责对外提供服务的Leader节点；
Standby NameNode：Follower节点，备用选主，与Activate NameNode保障HA
DateNode（DN）：负责存储数据的存储节点，定期与NameNode进行心跳数据交换；
HDFS Federation
Why Federation：单个NameNode负责管理集群导致了单点性能瓶颈，即当集群机器数量特别多是元数据会填满NAMseNode的内存，因此需要进行水平扩展（Federation）提高系统扩展性；
Normal Federation
Block Pool存储于DN的内存中，由于某个NS中的Block会存在于多个DN中，因此不同DN中属于该NS的Block Pool共同组成了属于该NS的Block Pools；
DN是物理概念，Block Pool是逻辑概念。Block Pool只存储着属于该命名空间中的Block，但DN存储着不同Block Pools中的块信息。也就是说不同的Block Pool共用同一套DataNode集群，Block Pool为不同命名空间中的数据提供了隔离；
Namespace和Blocks共同组成Namespace Volume；
Datanode中的数据结构都通过块池ID（BlockPoolID）索引，即datanode中的BlockMap，storage等都通过BPID索引。在HDFS中，所有的更新、回滚都是以Namenode和BlockPool为单元发生的。即同一HDFS Federation中不同的Namenode/BlockPool之间没有什么关系；
缺点：访问不同的NN需要记住并输入不同的地址，非常麻烦。
ViewFS
ViewFS类似于Linux的文件系统设计，其将不同NN下管理的资源视为linux中的挂载点，比如NN1视为/tmp，NN2视为/mount1，通过利用挂载映射表其对不同的NN访问路径，同一转化为以根目录为起点的Linux文件路径。
配置默认的文件系统访问路径映射：
<configuration xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href="mountTable.xml"/> <property> <name>fs.default.name</name> <value>viewfs://ClusterName/</value> </property> </configuration>
注意如果开启了NN的HA，则使用fs.defaultFS，否则使用fs.default.name。
配置挂载目录，以/data和/tmp为例：
<configuration> <property> <name>fs.viewfs.mounttable.wecluster.link./data</name> <value>hdfs://master:9999/user</value> </property> <property> <name>fs.viewfs.mounttable.wecluster.link./tmp</name> <value>hdfs://master:9999/tmp</value> </property> </configuration>
此时访问/tmp和/data时就会自动添加上前缀路径。
缺点：没有负载均衡，且是客户端技术，升级维护后需要将配置文件分发给所有客户端，不易维护。
Router-Based Federation
Router：为解决客户端配置导致的维护繁琐问题，可以考虑使用代理的方式将挂载表与客户端解耦提高集群可维护性，而Router就是该代理服务。Router主要提供以下内容：
Federated Interface：与NN有相同的接口，用于解析Client请求并转发到正确的集群；
NameNode HeartBeats：接受Router管控的NameNode心跳信息，并将心跳中的集群属性信息存储到State Store；
为了高可用一般Router会监控多个NN节点，这样当本集群的NN万一挂掉可以使用其他Router进行路由；
State Store：即可以本地存储，也可以存到zk中，主要存储以下内容：
存储Mount Table，该表保存着文件路径和子集群的关系；
存储Memebership Table：存储Router监控的NN信息，如DN数量、NN的HA状态和Router状态；
因此，整个RBF的流程可以归纳为如下：
Client向Router发出读请求；
Router在Mount Table中找到实际的NN路径映射；
Router查询Membership Table中进行目标NN检查，确认alive；
向NN转发请求
Mapreduce
MapTask
ReduceTask
Shuffle
Yarn
Why Yarn：在MRv1中，计算和资源的调度完全由master单点负责进行，master不仅压力过大，而在只要宕机就会导致整个集群计算失败。可以看出，MRv1违背了单一职责这一设计原则，master承担了多个职责，导致系统维护的困难。此外，由于MRv1自己管理自己，因此无法支持其他的计算模型，如Storm和Spark等，系统复用性和兼容性较差，耦合严重。因此，为了提高系统兼容性和可扩展性，MRv2对将资源分配和计算调度进行了分离，并且根据依赖倒转原则设计实现了Yarn资源调度框架。任何计算模型只要实现了Yarn规定的接口即可运行。
组成
ResourceManager（RM）：负责全局的资源分配管控，管理ApplicationMaster，同时处理Client提交的Job请求。RM包含以下两个主要组件：
Applications Manager（AM）：负责接收用户的Job提交请求，为Job的AMs协商资源并通知NM启动，同时负责AMs的失败重启；
Scheduler：负责提交的Job作业调度，支持FIFO、公平调度和容量调度等策略；
NodeManager（NM）：NM主要负责局部（本机）资源管控，管理Container的生命周期并负责与RM进行心跳链接，向RM提交自己管控机器的使用状态；
Application Master（AMs）：用户提交的每一个Job都会对应一个AMs，AMs会算出本次Job所需要的资源并进行需求上报；
Container：资源分配调度的基本对象（CPU、存储和GPU等资源），对不同任务进行资源隔离。
流程
向RM(AM)提交计算需求，包括源文件、执行计算逻辑和输出路径，RM返回job_id；
RM(AM)找到有空闲资源的NM，通知其打开一个Container运行AMs；
AMs管理Job任务调度，计算需要的Task及其需要的资源，出具表单在向RM(AM)注册自己并申请Task计算资源；
RM根据AMs提交的资源申请通知相关NM开启Container，并将NM分配情况进行表单开具返回给AMs；
AMs根据RM返回的资源分配表找到相应的NM，通知进行Task的异步运行；
Task运行完毕后向AMs报告，当所有Task完成任务后AMs向RM(AM)申请注销自己，同时RM通知其余NM回收相关的Container资源。
