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资源。