大数据思想
- 计算向数据靠拢
- 高容错性:多副本模式
- 适合大数据计算:不管多大的数据,在程序员眼中只有128M
- 构建在廉价的机器上
- Hadoop不支持秒级解决数据
- Hadoop不适合小文件的存储
Hadoop 1.x 2.x HA Federation
Hadoop1.x的困境
-namenode有很多的隐患
-单点故障
-namenode只有一个节点,如果namenode节点出现故障,整个集群都会瘫痪
-namenode只有一个节点,很难水平扩展
-namenode随着业务的增多,内存占用也会越来越多
-将来服务器启动的时候,启动速度慢
-业务隔离性差
-项目后期namenode的吞吐量将会是集群的瓶颈
Hadoop2.x
-NameNode节点的高可用
-HA--high availability
-NameNode业余的水平扩展
-Federation
Hadoop-HA
思路:
-2.x hadoop启用了主备节点切换模式(1主1备)
-当主节点出现异常的时候,集群直接将备用节点切换成主节点
-要求备用节点马上就要工作
-主备节点内存几乎同步
-有独立的线程对主备节点进行监控健康状态
-需要有一定的选举机制,帮助我们确定主从关系
-我们需要实时存储日志的中间件
2.x组织架构
-Active NameNode(ANN)
-它的功能和原理的NN的功能是一样的
-接受客户端请求,查询数据块DN信息
-存储
-数据的元数据信息
-数据文件:Block:DN的映射关系
-工作
-启动时:接受DN的block汇报
-运行时:和DN保持心跳(3s,10m)
-存储介质
-完全基于内存
-缺点:数据的持久化
-Standby NameNode(SNN)
-NN的备用节点
-他和主节点做同样的工作,但是它不会发出任何指令
-存储:
-数据的元数据信息
-数据文件:Block:DN的映射关系
-工作:
-启动时:
-接受DN的block汇报
-运行时:
-和DN保持心跳(3s,10m)
-存储介质
-完全基于内存
-缺点:数据的持久化
-合并日志文件和镜像
-snn的fsimage和ann的fsimage
-所以只需要snn有操作的日志信息,就可以合并fsImage与edits信息
-SNN间隔一段时间就会去QJN上取回最新的日志
-当Edits达到阈值的时候,合并fsImage与edits
-SNN将合并好的Fsimage发送给ANN,ANN验证无误后,存放到自己的目录中
-DataNode(DN)
-存储
-文件的数据
-介质
-硬盘
-启动时:
-同时向两个NN汇报Block信息
-运行中
-同时和两个主节点保持心跳机制
-Quorum JournalNode (QJN)
-JournalNode是一个独立的小集群,它的实现原理和Zookeeper的一致( Paxos)
-当主节点产生日志文件的时候,就会同时发送到 JournalNode的集群中每个节点上
-JournalNode不要求所有的jn节点都接收到日志,只要有半数以上的(n/2+1)节点接受收到日志
-那么本条日志就生效
-SNN每间隔一段时间就去QJN上面取回最新的日志
-Failover Controller(故障转移控制器)
-启动时:
-当集群启动时,主备节点的概念是很模糊的
-当ZKFC只检查到一个节点是健康状态,直接将其设置为主节点
-当zkfc检查到主备NN节点是的健康状态,发起投票机制
-选出一个主节点,一个备用节点,并修改主备节点的状态
-运行
-Health monitor:时刻监控对应NN节点的健康情况
-如果健康出现问题,立马汇报被当前的ZKFC,ZKFC根据节点状况决定是否切换主备节点
-如果需要切换,调用方法开启ZK的投票
-主备模式比较害怕 “脑裂”
-Zookeeper(管理型软件)
-辅助投票
-和ZKFC保持心跳机制,确定ZKFC的存活
Hadoop-Federation
-通过多个namenode/namespace把元数据的存储和管理分散到多个节点中
-降低单个节点数据压力,计算压力
-namenode/namespace可以通过增加机器来进行水平扩展
-可以让更多的节点参与到运算
-namespace命名空间,通过这种方式确定要处理数据的路径
我们可以通过namenode和namespace组合使用
-所有的nn共享dn
-但是每一个namespace会单独管理自己的块
-会创建一个管理块的机制:blocks pool